×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Differentiating between OSC and Mono cameras

  • Posts: 13
  • Thank you received: 0
The problem is still that the debayer that is being used is only 8 bits per channel. This means that significant data is lost when converting from a 16 bit raw camera to a color image. In the end, for my purposes I took the gray scale data from the driver and ran it through a 16 bit per channel debayer prior to contrast/gamma adjustments. The result is a much higher quality image.

If the camera driver is going to be doing the debayer, then it should be implemented in a way that minimizes loss of data. The current implementation degrades the image by more than I was willing to accept.
9 years 2 months ago #2862

Please Log in or Create an account to join the conversation.

  • Posts: 712
  • Thank you received: 174
Jasem, it is not a good idea. To do it you have to interpolate most of the pixels in the image and you will be never able to calibrate it correctly (particularly in combination with sub-framing). Debayering before calibration is good just for preview. Another problem is, that some cameras do not report if they are mono or OSC (e.g. no ATIK as far as I know).
9 years 2 months ago #2863

Please Log in or Create an account to join the conversation.

Where is the debayer code that uses 8bit per channel? The one in SBIG CCD uses 16bit per channel.
9 years 2 months ago #2864

Please Log in or Create an account to join the conversation.

  • Posts: 712
  • Thank you received: 174

It is not necessary true, you can make 3D FITS even with 64 bit floats. Another question is how to display it :-)
9 years 2 months ago #2865

Please Log in or Create an account to join the conversation.

  • Posts: 13
  • Thank you received: 0
The debayer in the ATIK driver results in an 8 bit per channel color image. Because of this, I resorted to always using the raw output from the camera, doing my own calibration and debayer and just asking the user whether their camera is color or not.

It feels wrong that the driver does the debayer. The camera driver should expose sufficient properties (bayer offsets) that a general purpose debayer routine can be used for color conversion outside of the driver layer. Just my $.02
9 years 2 months ago #2867

Please Log in or Create an account to join the conversation.

  • Posts: 712
  • Thank you received: 174
I don't understand, ATIK driver doesn't debayer and probably never will do (but maybe you are not speaking about our INDI driver).
9 years 2 months ago #2871

Please Log in or Create an account to join the conversation.

  • Posts: 13
  • Thank you received: 0
Ah yes, I may have been using the ccd_simulator driver to test now that I think about it. The ATIK driver just gives me no way to know whether it is a color or monochrome camera, so I just have to ask the user and then do my own debayer after calibration.
9 years 2 months ago #2872

Please Log in or Create an account to join the conversation.

  • Posts: 8
  • Thank you received: 0
If some drivers do debayer and others don't it seems we have no choice but to implement this in the client (which seems to me to be the right place anyhow since debayering algorithms improve all the time and you wouldn't want to update a bunch of drivers every time). Also if you'll be calibrating your images you must not debayer before calibration, so again it needs to happen in the client, not the driver. What's the argument in favor of doing it in the driver?
9 years 2 months ago #2875

Please Log in or Create an account to join the conversation.

I actually read about this yesterday and today (single shot color cameras and post processing), and since I didn't have any color cams (except for a guide one I don't use), it sounded that debayering in the driver is the way to go, but I now agree with the others that it should be done in the client. Thankfully, only one driver implemented the debayer routine so it would be easy to remove.
Last edit: 9 years 2 months ago by Jasem Mutlaq.
9 years 2 months ago #2876

Please Log in or Create an account to join the conversation.

  • Posts: 13
  • Thank you received: 0

Does this mean you're going to attempt to expose a color/mono flag and the bayer offsets for color cameras from the driver? That's really all that would be needed for the client to be able to debayer properly in the client. In my case, I hard coded the offsets for my camera, but I would love to make my client be able to work with any camera regardless of whether it is color or monochrome.
9 years 2 months ago #2877

Please Log in or Create an account to join the conversation.

  • Posts: 8
  • Thank you received: 0

This is what I'd like to see. Standard properties for sensor type/pattern (Mono, RGGB, RGBE, CMYG, RGBL, etc. are all used in various CCD and DSLR cameras) and bayer offset x and y similar to what the ICameraV2 interface from ASCOM exposes on Windows. Some cameras cannot have this info retrieved from hardware, so you wouldn't be able to absolutely rely on their being present, but if present it would prevent having to prompt the user.
9 years 2 months ago #2878

Please Log in or Create an account to join the conversation.

Well, shouldn't this information reside in the client? i.e. let the user sets those variables if they want to debayer the image. Why would they exist in the driver?
Last edit: 9 years 2 months ago by Jasem Mutlaq.
9 years 2 months ago #2879

Please Log in or Create an account to join the conversation.

Time to create page: 0.917 seconds