StarTools

I’m having trouble getting almost any color in the Duoband process of my HOO Veil. When I first open the module and the settings are Scientific Color and the Identity (Off) Matrix settings, colors are almost neon bright red and blue/teal. However when I try to go to Artistic or change the Matrix to various Duoband, the image goes almost completely white with maybe a little color. Regardless of saturation settings or the RGB channel settings. Any advice?

Wayne

Wayne have you taken a mask to sample white balance of stars ?

Hmmmm,,,, Any chance you could share the dataset so we can see what's going on?
I've not come across issues with duoband filtered datasets before....

Wayne have you taken a mask to sample white balance of stars ?

This is what you want for RGB images but it doesn't help with duoband /bicolour as there is no natural rgb look to the stars under this configuration. I second Ivo's request to see your data.

Cheers Richard

Here is a link to the final integrated Ha and O3 stacks and the TIFF of the processed image up to color calibration. These consist of 68 3-minute Ha and 67 3-minute O3 images taken with an FLI Kepler KL4040 Scientific CMOS camera at high gain calibrated with matching darks and flats. This cameras images behave very differently when processing than any of my other cameras' images. You'll see how milky white they show up when initially loaded but they can be successfully autodeveloped, wiped etc.

PS added master dark and master flats

https://1drv.ms/u/s!Aod6X19w9TMD9ASySe6 ... R?e=RQjNS8

Thanks Wayne

whixson wrote:Here is a link to the final integrated Ha and O3 stacks and the TIFF of the processed image up to color calibration. These consist of 68 3-minute Ha and 67 3-minute O3 images taken with an FLI Kepler KL4040 Scientific CMOS camera at high gain calibrated with matching darks and flats. This cameras images behave very differently when processing than any of my other cameras' images. You'll see how milky white they show up when initially loaded but they can be successfully autodeveloped, wiped etc.

PS added master dark and master flats

https://1drv.ms/u/s!Aod6X19w9TMD9ASySe6 ... R?e=RQjNS8

Thanks Wayne

Thank you Wayne for uploading these datasets. These datasets look very peculiar indeed; as if they have been pre-stretched (which would explain the problem the Color module has trying to recover the color ratios) or have some sort of significant non-linear response baked in. I do know some sensors exhibit significant non-linearity in the higher parts of the dynamic range, and looking at the dataset, everything is indeed bunched up into the higher part of the dynamic range.
Most modules in StarTools (AutoDev, Decon, Denoise / Denoise 2 and - as we have seen - Color) appear to respond to this dataset congruent with a dataset that is not linear across its entire dynamic range.

Having a quick look at the FLI website yields some clues;

Kepler KL400 Operational Modes
The KL400's Low Dynamic Range (LDR) mode reads the image once and digitizes it to 12-bits. The user has eight gains to select from in LDR mode. Adjusting the gain affects full well size, dark current growth, and linearity.

Given you have used a (too) high gain, my strong suspicion is that this has significantly impacted linearity.

See also here, where this vendor states that non-linear response for most cameras typically starts at ~60% of full well capacity (which you seem to have exceeded by far!).

Interesting. The post you linked was by Tolga Gumusayak, one of the foremost users of the Kepler 4040. The way the camera is supposed to work is simultaneously take a low and a high gain image and merge them to get a quasi HDR image. In this way it would keep the merged image in the linear range I suppose. I’ve given up using it in this mode due to calibration issues. Maybe just take much shorter subs?

Wayne

whixson wrote:Maybe just take much shorter subs?

Use unity gain (e.g. a gain where photons are counted as one electron). From what I can see, the camera is doing its very best not to overexpose your images by bunching everything up non-liearly in the upper part of the dynamic range. It's a neat feature/attribute, but it wreaks havoc on the linearity of your dataset (and possibly bit-depth).

Is there any particular reason you have the gain turned up?

Thanks, your insight into what is happening is appreciated. The camera currently doesn’t allow user-selectable gain. They have predefined low-gain and high-gain settings, you can choose one or the other or a merge. The merge crossover is 3800 ADU (on a 12-bit 4096 Max scale). I’ve been using the high gain channel only to avoid the calibration issues with the merged frames but may go back to that.

Wayne

whixson wrote:Thanks, your insight into what is happening is appreciated. The camera currently doesn’t allow user-selectable gain. They have predefined low-gain and high-gain settings, you can choose one or the other or a merge. The merge crossover is 3800 ADU (on a 12-bit 4096 Max scale). I’ve been using the high gain channel only to avoid the calibration issues with the merged frames but may go back to that.

Wayne

Hmmm... perhaps try the low gain?
Definitely learnt something new myself