Histogram "drop" after L combination <- problem or not?

[Greg Schwimer]

I have an RGB image and a synthetic luminance that I by integrating the RGB masters. This was done during the linear phase. After a normal initial processing (crop, DBE, BN, CC, etc) I stretch both the RGB and L masters using STF-based HT stretches. I then use ChannelCombination to combine the L.

The initial RGB histo looks fine. What I'm scratching my head about is the after L combination histo. The peak drops substantially. I've tried various initial processing variations - linear fit to different channels, no linear fit, NR, no NR, and in each case I see a large peak drop. In some cases the peak drop is low enough that it appears almost flat. I've also tried running HDRMT on both the RGB and L images prior to combination - same result.

Am I missing something? Is this normal behavior? Am I doing something wrong?

Thanks!
Greg

[jkmorse]

Greg,

Best way to create a synlum is using the Image Integration tool.  Here is the protocol I have in my workbook (freely available if you are interested as I share it with about 200 people around the world.  Just drop me a line at jkmorse57@gmail.com if you are interested).

ii.   Create Synthetic Lum:

In general, the unweighted average of individual RGB components does not lead to an optimal result in signal-to-noise ratio terms. An optimal synthetic luminance must assign different weights to each color component, based on scaled noise estimates.

This process can be done very easily with the ImageIntegration tool. Open ImageIntegration and select the RGB files. Use one of the RGB channels as the reference for integration.
Then leave all tool parameters by default (you can click the Reset button to make sure) and click the Apply Global button. The relevant parameters are as follows:

- Combination = Average
- Normalization = additive with scaling
- Weights = Noise evaluation
- Scale estimator = iterative k-sigma
- Generate integrated image = enabled
- Evaluate noise = enabled
- Pixel rejection = No rejection
- Clip low range = disabled
- Clip high range = disabled

You can make several tests with different scale estimators and select the one that yields the highest noise reduction. The integration result is the optimal luminance image that you can treat in the usual way (deconvolve if appropriate, stretch to match the implicit RGB luminance, combine with RGB using LRGBCombination, etc).

Hope that helps,

Jim

[jkmorse]

Note that what I quote is from my workbook, but was written by Juan in an older post.  He gets the credit for the technique.

Jim

[Greg Schwimer]

Thanks Jim. That's exactly how I made the lum channel that I was using.

[RickS]

Have you tried using LRGBCombination to add the Lum to your RGB data?  That's how I normally do it.

Cheers,
Rick.

[Greg Schwimer]

Thanks Rick. I just gave it a try and got the same result.

[RickS]

Greg,

That seems like odd behaviour.  I've never noticed anything like it with my L/RGB combines.  I presume the Lum histogram looks "normal" with a peak roughly in the same range as the RGB histogram?  What's your working colour space?  I'm not sure it would actually have any effect, but did you change the RGB working space of the RGB image? (RGBWorkingSpace process)  I normally set mine at 1:1:1 early in processing so that luminance masks represent colours equally.

Cheers,
Rick.

[Greg Schwimer]

Odd it is. The lum histo does look normal before and after stretch. I've been using the default working space. I tried setting it on the RGB image just prior to adding lum in and get the same result again. I can try it before combining the R, G, and B images while still linear. Might that make a difference?

In case there is interest in looking at the data, it can be found here:

https://www.dropbox.com/sh/ll11zdxk7fn4i6s/AADxqDKQvYQXN_W4ROXyMM8Ca?dl=0

[RickS]

Hi Greg,

I have go run some errands (Saturday morning here!) but I'll have a play with the data when I get back.

Cheers,
Rick.

[pfile]

usually when this happens, there's a big "spike" of pixels of a single value that is not renderable in the histogram display at full size. but it's there and it forces the scale of the histogram display to be quite large, such that "real" part of the histogram is all squashed down.

in this case, after stretching the images with AutoSTF+HT there are a whole lot of pixels with the value 0.00000 in both the RGB image and the L images. if you zoom the histogram way in, you might be able to see that spike. you can also use pixelmath to add 0.001 to the whole image and then since the spike is detached from the left edge you can see it a little better.

executing the pixelmath expression iif($T<0.0001,random(),$T) on the (original) combined LRGB image spreads the value of the those 0 pixels all over the place and the histogram returns to normal.

of course this is all dependent on how you stretched the image. overall something seems funny in the image - i'd expect the bright stars in the L image to all have clipped, but the core of the brightest star seems to have a 16-bit ADU count of around 15,000. so it seems there are a lot of pixels in the background that invariably get clamped to 0 when you do the histogram stretch, which leads to this problem.

rob

[RickS]

I took the linear masters from the Dropbox link and did a fairly minimal workflow and didn't see the same problem.  Here's what I did:

RGB:

• Crop edges
• Combine R/G/B with LRGBCombine
• Ran DBE a few times to get rid of coloured gradients
• BackgroundNeutralization and ColorCalibration
• HT stretch
• ACDNR with lightness mask: slight Lightess nr and a little heavier Chrominance nr
• HT black point adjust/slight stretch

Lum:

• Crop edges
• DBE
• Light MLT noise reduction with linear mask
• HT stretch

Then I combined the Lum with the RGB using LRGBCombination (set L channel and drag New Instance triangle over RGB image.)  The final histogram looked fine.  See attached pics.

Cheers,
Rick.

[Greg Schwimer]

usually when this happens, there's a big "spike" of pixels of a single value that is not renderable in the histogram display at full size. but it's there and it forces the scale of the histogram display to be quite large, such that "real" part of the histogram is all squashed down.

in this case, after stretching the images with AutoSTF+HT there are a whole lot of pixels with the value 0.00000 in both the RGB image and the L images. if you zoom the histogram way in, you might be able to see that spike. you can also use pixelmath to add 0.001 to the whole image and then since the spike is detached from the left edge you can see it a little better.

executing the pixelmath expression iif($T<0.0001,random(),$T) on the (original) combined LRGB image spreads the value of the those 0 pixels all over the place and the histogram returns to normal.

of course this is all dependent on how you stretched the image. overall something seems funny in the image - i'd expect the bright stars in the L image to all have clipped, but the core of the brightest star seems to have a 16-bit ADU count of around 15,000. so it seems there are a lot of pixels in the background that invariably get clamped to 0 when you do the histogram stretch, which leads to this problem.

rob

Thanks Rob. I'm not sure what to make of this. What might cause the "pile up" of zero value pixels? I'm modifying STF to get what I want for background and minimal clipping. I'm not clear on what would cause such a spike. I've confirmed that I do see it though - $T + 0.1 makes it very obvious.

I specifically aimed at an exposure time for the subs such that I never exceeded ~50K ADU for any filter. This ended up being 180s. There were ~60 of each channel. Weird.

[RickS]

I specifically aimed at an exposure time for the subs such that I never exceeded ~50K ADU for any filter. This ended up being 180s. There were ~60 of each channel. Weird.

I didn't see anything wrong with your master integrations.  There was the usual "rough edges" due to dither that I cropped but no other issues.  Perhaps this was a side effect of something you did in the processing?

Cheers,
Rick.

[pfile]

usually when this happens, there's a big "spike" of pixels of a single value that is not renderable in the histogram display at full size. but it's there and it forces the scale of the histogram display to be quite large, such that "real" part of the histogram is all squashed down.

in this case, after stretching the images with AutoSTF+HT there are a whole lot of pixels with the value 0.00000 in both the RGB image and the L images. if you zoom the histogram way in, you might be able to see that spike. you can also use pixelmath to add 0.001 to the whole image and then since the spike is detached from the left edge you can see it a little better.

executing the pixelmath expression iif($T<0.0001,random(),$T) on the (original) combined LRGB image spreads the value of the those 0 pixels all over the place and the histogram returns to normal.

of course this is all dependent on how you stretched the image. overall something seems funny in the image - i'd expect the bright stars in the L image to all have clipped, but the core of the brightest star seems to have a 16-bit ADU count of around 15,000. so it seems there are a lot of pixels in the background that invariably get clamped to 0 when you do the histogram stretch, which leads to this problem.

rob

Thanks Rob. I'm not sure what to make of this. What might cause the "pile up" of zero value pixels? I'm modifying STF to get what I want for background and minimal clipping. I'm not clear on what would cause such a spike. I've confirmed that I do see it though - $T + 0.1 makes it very obvious.

I specifically aimed at an exposure time for the subs such that I never exceeded ~50K ADU for any filter. This ended up being 180s. There were ~60 of each channel. Weird.

i wonder if it's something about the calibration. how do the uncalibrated frames look ADU-wise?

i don't know why rick did not see this - i originally thought that the problem might lie in the "rough edges" and so the problem would go away with a crop, but it didn't. the low-value pixels are all over the place. before stretching, they are something like 0.008 if i remember correctly. not that there's anything wrong with any particular value in a linear image after integration - after all the input frames need to be normalized before integration. maybe there is an outlier sub in there that's making things weird...?

rob

[Greg Schwimer]

I didn't see anything wrong with your master integrations.  There was the usual "rough edges" due to dither that I cropped but no other issues.  Perhaps this was a side effect of something you did in the processing?

I can't imagine what that would be. I did a crop, channel comb, DBE, BN, CC, then stretch. I tried this with and without linear fitting the channels, first to red then to green. Same result each time. I also tried a round where I used MLT for linear noise reduction.  I did allow some minor shadow clipping during the stretch, which mainly impacted the RGB master. It was maybe 0.05% clipped.

i wonder if it's something about the calibration. how do the uncalibrated frames look ADU-wise?

i don't know why rick did not see this - i originally thought that the problem might lie in the "rough edges" and so the problem would go away with a crop, but it didn't. the low-value pixels are all over the place. before stretching, they are something like 0.008 if i remember correctly. not that there's anything wrong with any particular value in a linear image after integration - after all the input frames need to be normalized before integration. maybe there is an outlier sub in there that's making things weird...?

Here's a random sampling of uncalibrated sub stats. I don't think anything really looks odd here. Thoughts?

Code: [Select]

RED
count (%)   100.00000
count (px)  16200000
mean        1195.0
median      1194.0
avgDev      18.0
MAD         14.0
minimum     1093.0
maximum     55325.0


GREEN
count (%)   100.00000
count (px)  16200000
mean        1322.6
median      1321.0
avgDev      24.6
MAD         20.0
minimum     1194.0
maximum     55436.0

BLUE
count (%)   100.00000
count (px)  16200000
mean        1316.1
median      1314.0
avgDev      24.4
MAD         20.0
minimum     1175.0
maximum     55309.0

I *did* create new master bias and dark frames as part of this project. The old ones were ~6 months old and I felt like it was time for a fresh set as I was seeing some odd patterns. The calibrated data does look better as a result. Maybe I'll try hitting these with the old dark and bias frames. Not sure why that would cause this though.