L + L from RGB

[ihowarth]

It's always struck me that using RGB from a set of (aligned, integrated, cropped) LRGB images just for colour information is throwing away potentially useful pseudo-L signal.   I've poked through the forums and I'm not at all surprised that others have had the same thought, but I've failed to find a 'recipe' that's clear enough for me to be confident of understanding it (which is not to say there's no clear recipe!).

Here's what I *think* is one way to proceed -- if anyone can correct, clarify, or comment I'd be grateful...

(i)  Take linear RGB image.   Use ChannelExtraction to split into CIE L*a*b components.  To avoid ambiguity, let's call the resulting luminance channel L'.
(ii)  Write out the linear L and L' files to disk
(iii)   Read them back in to ImageIntegration (because it will only accept external files, not 'views' <sigh>)
(iv)   Execute ImInt with
combination: average
normalization:  additive with scaling
weights:  noise evaluation
Defaults under "scale estimator" (iterative k-sigma, evaluate noise)
NO pixel rejection
Now at this point you realise that ImInt won't work with fewer than 3 images, even though you're not doing any pixel rejection.
So add L and L' in a second time (to give 4 images) -- quicker and easier than using NoiseEvaluation and PixelMath

This gives a new integrated L that uses all the photons (not just those through the L filter) -- i think.

Sound plausible?  Or am i missing something?    Or is LRGBcombination already doing this stuff for me?  (Don't really see how it can be, in nonlinear space...)

Thanks
ian

[pfile]

instead of ChannelExtraction i just integrate the R/G/B masters together to form a pseudo-L.

i think the problem with L* is that it is a perceptual luminance so at the very least you'd want to set all the RGB weights to 1 and the gamma to 1 in RGBWorkingSpace (and apply it to the RGB image) before you extracted L*. otherwise green will be over-represented in the L*.

anyway if you are using an OSC and have an RGB image, you could still split it into its constituent R/G/B images and then just integrate them together to get a pseudo L, then integrate the pseudo L with the real L.

rob

[jlodge]

This is perplexing me considerably, I have read so much about and am still unsure which way to proceed. I am still very new to PI so please include detail as I get lost in some posts when assumed detail is missed out.

Some people recommend pfile's method as does Warren in his book, then others on SL and CN poo poo it in favour of combining and whitebalance the RGB, then with the RGB working space tool, experimenting with different weights for each channel before using the extract-luminance tool.

Pfile, I have my R,G and B masters and have linear fitted them to the strongest one, then is it just a case of integrating them, no rejection and with noise evaluation to get the pseudo lum?

If I have some Lum subs, what is the best way to combine them with the pseudo luminance that is made from the RGB masters? I read about using pixelmath and weights, but how do you decide how much weight to give each one?

Also I have read so many conflicting things about whether to only gather RGB, forgetting Lum or the converse where people gather a little RGB in favour of lots of Lum. I know that Juan advocates the former and for me this is preferable as I have the ASI1600MM-Pro and I end up with loads of Lum files.

[pfile]

so for my part i have stopped bothering with the L filter because i live in an extremely high LP area and i find that the L is just so full of gradients and other nastiness that the result is very difficult to work with, requiring at the least some heroic DBE. so if i do an RGB image, i just use the RGB filters and make a pseudo-L as we are discussing. although LP sources are starting to become more and more broad-spectrum, i feel like there is still some worth in the gaps in the astrodon G2E filter set with respect to sodium vapor lights. but i find that processing the L separately from the RGB is worthwhile, so i generally make a pseudo-L from the RGB images and proceed from there. hence there's nothing to combine on the L side since i have no L subs.

anyway, as you point out, by default ImageIntegration analyzes the noise in the input images and weights the images based on that analysis. so even if you have done a linear fit, that will be undone by the noise weighting in II. so IMO you might as well skip the LF step. juan has recommended the noise-weighted average in the past for production of pseudo-L, since it in theory results in the highest SNR "L" image possible from your RGB data.

i think if you have real L subs then you can create the a master L frame from them and then integrate that master with the master pseudo-L. II wants a minumum of 3 images, so what you can do is just add the pseudo-L master twice and the L master twice and then again do the noise-weighted integration.

the "mostly L and a few (possibly binned) RGB" probably works great if you have dark skies and can get extremely clean L images. since that doesn't work for me, i'm in the "all RGB" camp.

rob

[jlodge]

Thank you Rob, that has helped me a great deal.

I am in the UK and 99% of the LP is broad spectrum LED lights now, I image from Bortle 5 skies, so probably not worth doing separate L subs.

Whilst we're on this subject, if you have NB data, should all of it be integrated to form the pseudo L? For example I have Ha,OII, SII for the Pacman Nebula, I also took some RGB for correct star colour, is it advisable to combine all 6 masters to make the Lum?

Likewise I have been working on M81/M82 and have some Ha as well as RGB, can the Ha be added into the mix to make the Lum?

Jon

[pfile]

i'm not sure about integrating RGB and NB together - the filter bandwidths are really quite different. i assume your star color RGB images are pretty short integrations compared with the NB? that would also be a big SNR mismatch.

as for adding in Ha to the L, i wonder if the SNR in the dimmer parts of the Ha image could compromise the SNR of the pseudo L.

maybe others can comment on these topics, i don't have a good handle on whether its a good idea or not. my instinct tells me no but i suppose it depends on the relative quality of the NB/RGB data.

rob

[jlodge]

Yes the star colour RGB images are short compared with the NB, that all makes sense as does the adding Ha to L.

Thanks again,

Jon