|
|
So a 12 bit camera has an inherent gain of 16 build into the data. If you want to cope with this you could do two things: 1) Extend the number of predefined histogram settings. So add more presets similar like "super extreme" 2) Detect the bit depth from the histogram and adapt. An image from a 12 bit camera has only maximum 4095 grey levels. A tru e16 bit camera has 65535 grey levels maximum. |
|
|
Detecting the number of grey levels and therefore the real bit depth of the camera is relative easy. You can go through the histogram and measure the smallest step. It requires only to analyse maybe the first 5000 value on the low end. It works even for darks. It is already build in ASTAP popup menu "Show statistics". But you have to take into account the binning. For my old ASI1600 camera, I measure the following with the darks: ASI1600: bin 1x1, smallest step in the image is 16. bin 2x2, smallest step in the image is 4. IMX571: bin 1x1, smallest step in the image is 1. But getting more histogram predefined settings will also work. But one problem highlighted is that setting the sliders is more difficult because the histogram peak for a real 16 bit camera is very small. The CCDCiel histogram shows the full range 0..65535. You could adapt the histogram to the data peak. E.g. make the scale 10 times larger then the sliders settings. I'm doing something similar in ASTAP. See attached screenshot of the CCDciel histogram vs the one from ASTAP for the same image. For the stretching in ASTAP, there is no need to measure the bit-depth. If I remember well it is looking to the data peak width. That is a third way of dealing with it. Best way forward would be to provide you with some short exposures with an IMX571 camera to see the effect. I can't find any in my archive but I will make them as soon as possible. |
|
|
Attached the comparison of the CCDciel and ASTAP histograms. Also a 50sec exposure made with my IMX571 camera. Note you have to set the histogram predefined setting to extreme. Untitled.png (16,931 bytes) |
|
|
As an experiment I have modified the previous image such that the data is as a 12 bit sensor. So the image data is multiplied with 16 and I subtracted 3000 to keep the offset low. See attached. Till my surprise the display in CCDCiel is as good as the original. So this factor of 16 in the data does not effect stretching. Then the only thing to do is maybe: 1) Add a predefined setting which is stronger then extreme. Or better make them all stronger. 2) Adjust the histogram scale from a fixed 0.65535 to something depended on the histogram data. Such that the peak is better visible. |
|
|
Han, I can probably not make change to the program this weekend. But there is a button that help to view and adjust the histogram. Click the button with the magnifying glass and plus sign to clip the graph at the current histogram clipping. Then it is easy to make fine adjustment with the sliders. |
|
|
That magnify glass, I did not notice it before. No hurry. I will try to make some high gain images myself to see the effect. Something does not add up. My experiment with mulitplying the image data with a factor 16 did not change the view in CCDciel. That would indicate that the gain doesn't do anything to the preview. It is neutralized by the CCDCiel stretching. |
|
|
Some foggy sky but I could do some testing.The extreme stretch preview in CCDciel is equal for gain 1e-/ADU and 100e-/ADU. But for for high stretch the gain 1e-/ADU is less streched. My conclusion is that the gain is only a substitute for stretching but it does not help to get a better picture. Some sample astrotif files you could delete once seen. result test2.jpg (879,809 bytes) |
|
|
The problem is that the stretching is not good coping with the offset and the bell shape width. Depending on the offset or bitness, the histogram looks different except for predefined extreme since it looks to the Fsd which follows only the bitness. This afternoon I had some inspiration and modified the stretching routine. See attached. Try it out. In cu-fits, a new procedure TFits.bell_median_and_begin_and_end() to find the median of the bell shape in the histogram and the begin and and of this bell shape. In fu_viu, I modfied Tf_visu.SetLimit(), the stretching is now done with the values from the procedure bell_median_and_begin_and_end() I work well with my test images. An offset change has no influence. The width of the bell shape in the histogram has also no influence. Variable Fbell_min is not used but needs to be calculated anyhow. |
|
|
This new stretching is very good, it work fine with your images but also with my stock of test images. It will require lower setting for standard imaging but this is good because this let more margin and the gradation step is finer. But I have to add a "very low" setting for the spectra image, this is a change I wanted to do but now it is really need. It set the range from datamin to 99.99% of the histogram to clip only the hot pixels, so this is the same as "data range" but without the 0.01% of the brighter pixels that are clipped. I attach a sample spectra so you can take a look. The change is in https://github.com/pchev/ccdciel/commit/938aad3455f18c5eafa871ab343d30ee8bc4afce |
|
|
Hi Patrick, I'm reworking my proposal from yesterday. It doesn't work perfectly with images with a lot of nebula visible. Then the background gets too dark. It will likely be ready this afternoon, I will check with your sample spectra. Additional, I also think it would be better to replace the magnifier by automatic reducing the range of the histogram plotted. For a real 16 bit sensor most data is in the very low part of the histogram. So instead of plotting the histogram values 0..65535, reduce the plotted range to something like 0..4000 depending on the histogram data. So a modification of PlotHistogram. |
|
|
Yes, I was thinking that something like the magnifier must be always activated. Maybe as it is, depending on the clipping, but with some more margin to allow both side manual adjustment. I will keep only the "full range" button on the left because some people want to always see a 0-65535 histogram to know where they are related to saturation. |
|
|
Attached my latest proposal. No more ideas here. I will leave further modifications to you. 1) New procedure Tf_visu.analyse_histogram; It analyses from the histogram calculates the predefined settings for setup() 2) Procedure HistStats() is no longer required. The code has moved to Tf_visu.analyse_histogram 3) Procedure bell_median_and_begin_and_end() is no longer required I'm little unsure if scaling with FimageC; is done all correctly. I assume it should be done after setting FHistStop, FZoomStop in SetUp(). Please check. The scale of the plotted histogram is now adapted automatically. rsVeryLow was not defined in your latest code. I fixed it temporary with cbHistRange.Items[1]:='Very low';//rsVeryLow; |
|
|
I reply in the wrong issue, sorry. This work fine for me. I fixed the use of FimageC for floating points images. The automatic zoom on the histogram is good, I removed the magnifier button. The new change : https://github.com/pchev/ccdciel/commit/4dc4eda623243de70d581e7945f0e1b3d1590c4b |
|
|
I never realised FimageC was for floating points images. In ASTAP after reading floating point images or png, jpeg, I scale them all to 0..65535 based on the max value seen during reading. This simplifies processing. All images have internally the same scale 0..65535. When saving floating point images, I keep the 0..65535 scale. There is no standard for this except some use the arbitrary scale 0..1, |
|
|
Yes they are scaled to 0...65535 and FimageC is used to simplify the computation of the original value from the histogram value. FimageC:=MaxWord/(FimageMax-FimageMin) |
- Anonymous
