Debayering the images in kfitsviewer is not supported since the CCD for the DSI Color (ICX254AK) uses a complementary color filter array rather than the "standard" RGGB CFA. The CMYG CFA was used on some of these older cameras but is not really used anymore.
I don't have pixinsight, but a little searching seems to indicate that it can debayer these images.
Read More...
I pushed another branch called bin_no_deinterlace. This has the same changes as the other branch and an additional change to not deinterlace the frame if y-binning is enabled. I think this will work better, but I it would be nice if you could test both and find out for sure.
Read More...
I think the file should be at /usr/lib/udev/rules.d/99-orionssg3.rules. Do you still see this problem after rebooting?
Read More...
I finally got around to implementing binning and subframing. To try it out, do:
git clone github.com/bgilsrud/indi-3rdparty.git
cd indi-3rdparty
git checkout ssg3_updates
Then you can build the drive like you normally would. I don't have one of these cameras, so I can only simulate how I think it should behave and I was able to see the USB sequences that I was expecting. I think the most useful test would be to take a recognizable image with binning enabled...there's a good chance that the frame will be reassembled incorrectly. The code will still attempt to deinterlace the downloaded image, which I'm thinking is not correct when binning is enabled.
Read More...
I'm glad to hear it works!
How did you install the driver? It should come with a udev file (99-orionssg3.rules) to automatically set the permissions, so I'm not sure why that's not working.
Read More...
Cool shot, Andrew! It's really neat to see the noise at the edges and see how it gets cleaned up as more images overlap toward the center.
Sorry, I've been a little distracted lately, but I'll get to the changes that we mentioned in the next day or so. The issues you mentioned with the short exposures could be related to timing of the download code. Unless the camera has some external memory, the little microcontroller in the camera can't buffer a full frame so it's possible that it needs the host to be ready (ie, have requested a bulk transfer) before the exposure is done. It's possible that the driver isn't meeting that timing for super short exposures. I think this would be difficult to fix without changing things too much. It would be a lot simpler to limit short exposures to a value that we know works. Any thoughts?
Thanks,
Ben
Read More...
Hi Emmanuel,
I would start by double checking that the usb device file has the correct permissions. The driver comes with a udev file that should take care of this, but maybe it's not working correctly?
Do:
ls -alh /dev/bus/usb/${BUS}/${DEVICE}
where BUS and DEVICE are determined by the lsusb output (004 and 003 in your output above).
Read More...
I'll take a look at implementing some of this over the weekend. I think the illumination differences between the even and odd field would only occur with short exposures since the readout time would become insignificant at longer exposures. I don't have this camera, but I do have a Meade DSI I which also has an interlaced sensor and see this same thing. I do agree with your point regarding the readout time. 2s is crazy for a sensor that small and would make it almost useless for a guide cam.
Read More...
I'm glad that you were able to get some images out off it!
I started to implement binning and then put that on hold. I just double checked and see that the driver is still advertising binning support, which was not what I intended. Binning could be added without a lot of effort, but I wondered how valuable that would actually be given that the sensor is small and the pixels are already pretty large. But, someone who's motivated could do it 
Subframing is also not supported by the driver, but we understand enough of the camera control protocol that it could be.
I believe that the cooling is a setpoint-style interface. That is, the driver tells the camera the desired temperature and the camera is responsible for adjusting peltier power and fan speed to achieve the desired set point. The G3 hardware can only cool down to ~10c below ambient. If you set the cooling to something like 5C below ambient I would expect that you would see the power spike and then decrease as it reaches the setpoint and maybe settle somewhere around 50% (+/- 20%). You could also try experimenting with cooling in the orion capture studio and see if you see the same power/fan behavior. I suspect that the fan is controlled by the uC on the camera rather than through the driver. At least, that's what I would do if I designed the camera. Also, I don't think there were any write commands whose function wasn't figured out.
I would love to see what you were able to image with the camera!
Read More...
Thanks for the info and the dump, Andrew!
I believe that the G3 color and mono use the ICX419AKL and ICX419ALL, respectively. They have the sample pixel layout since they're the same chip (just one has a color filter array on it).
I'm assuming that you're able to capture an image in orion capture studio and it looks fine, right? Any chance you could get a wireshark dump while using the indi driver?
I've compared the wireshark dump for the mono and color G3 cameras and don't see any obvious differences in the image download. I think you might be right about command 20 being the way to distinguish color vs mono. As it turns out, VID/PID 0x07ee/0x0501 is the identifier for the Mammut Lyuba L429 camera, so I can fix my guess. You're also right about the geometry of the pixels being of by 1nm. That wouldn't cause the crash, but it should still be fixed.
It might also be helpful if you could get a backtrace as described in section 3 of [this guide](indilib.org/forum/general/571-read-befor...support-request.html).
Read More...