STF -> Histogram Transform not working as expected

[RyanHa]

I want to do a stretch that is the same as the STF function.

My understanding is that I can do this by doing an STF, then dragging the triangle to the HT process to copy the settings, then drag the HT process triangle to the image (and then un-doing the original STF). I feel like I have done this before, but the results on a DARK are not as I am expecting.

I took some screen shots of what I am doing to hopefully help illustrate what I am doing.

Thanks,
--Ryan

 

[fredvanner]

Could you try repeating this with 24bit LUT enabled for the STF. Darks typically have a small dynamic range, and, particularly if offset by a bias that is large compered with the dynamic range, may cause posterisation problems with the standard LUT. This will result in a posterised result for the STF. Since the HT actually performs the per-pixel stretch transformation (without using a look-up table), the HT output should represent the actual stretch.

 

[fredvanner]

... incidentally, there are probably better tools than the STF if you want to analyse the content of your darks.

 

[RyanHa]

I tried enabling 24 bit LUT and had what seems to be the same result.

I am interested to hear about other tools to analyze darks btw.

I am finding what seems to be a lot of hot pixel read noise in my darks after installing a new camera driver. I am trying to find a way to demonstrate this. The default STF (ctl-A) shows it really well but if there is another technique to analyze this it would be even better.

Can you point me to some details on that?

Thanks!
--Ryan

 

[pfile]

it is a longshot but because you have the "follow view" checkmark ticked in STF its possible that the STF tool is picking up the stretch from a different image as you are mousing around to click/drag stuff. if you turn that off you'll at least eliminate the possibility that the STF is changing between the image you ran STF on and when you drag the triangle to the HT process.

rob

 

[fredvanner]

I've just tried reproducing your problem. I get exactly the same effect, but I've discovered that this is just a matter of screen rendering of zoomed images. If I "un-zoom" my STF and HT images to 1:1 or higher, they are the same.
There are so many tools in PI that it is a matter of personal taste and experience as to what is best to use. My first start is always Statistics. If all is well, the mean/median will be about the same, and the avdev/MAD are a reasonable indicator of the dynamic range of the dark image.
My other friends are PixelMath (hard clipping/rescaling) and CurveTransformation in linear mode (small icon at bottom right), using the "input", "output" controls to put the (piecewise linear) curve exactly where I want it (often based on the statistics).

 

[fredvanner]

... BTW your images look very similar to dark images I get with my new ASI2600 CMOS camera. The dark current is usually so small that it is hardly worth taking darks! (but I also get those hot pixels...)

 

[RyanHa]

Interesting.

What is very odd to me is that in my calibrated subs with the new driver, there appear to be more obvious hot pixels. (Note that these integrate out with dither).

BUT if I run statistics on an individual DARK with the old driver and run Statistics and Noise Evaluation script the DARKs with the new driver have lower noise and lower mean.

Then I applied the same histogram to both and did binarize to try to clip everything but the hot pixels and sure enough there is more "dark signal" from the old one.

I am doing new DARKs and will see what the image looks like if I match the dark master post-driver upgrade to see what happens.

--Ryan