getting L* back into RGB- failing

[HadesZ]

So I am attempting my first LRGB image. And honestly , Narrowband processing seems way easier already lol.

I am attempting to follow this process outline (which I found here on the forums, posted by troypiggo)

"Calibrate/integrate subs to get master L, R, G, B
LRGBCombination just the RGB channels
BackgroundNeut and ColorCalibration the RGB image
Stretch the L and RGB images (masked stretch or use the STF function)
Extract the L channel from the RGB image in the Lab color space
Linearfit the extracted L from Lab to the stretched L image
Channel combine the linearfit L back into the RGB image
Then LRGBCombine the L into the RGB image."


my problem is this... at the  "Channel Combine the linearfit L back into the RGB image"  I am assuming I use "lab" mode for this still, but in the channel source drop downs,  my RBG image I used to extract the Lum from, is not available to select, it does not show up in the list of sources at all. and if I try dragging the channel combine process onto the RBG image manually, it tells me that the source image is not found. any suggestions on where I am messing up?  LRGB seems like a massive pita compared to the NB processing I have done.. I am hoping I see the light soon. lol

thanks for any and all suggestions and information.

[pfile]

hm, i have never used a flow like that. i am not sure what the point is of putting the L back into the RGB image and then immediately replacing it by way of the LRGB combine. maybe troy can comment.

i would just skip the last 3 steps before LRGBCombine and instead just apply the processed L image to the RGB image using LRGBCombination.

rob

[HadesZ]

ok, how would I apply just the  L back into the RGB? since RGB has already been combined...  would I just uncheck R,G,B in LRGBCombination and just leave L checked, and drop that process onto my RGB image?

if so, would I do anything specific with Channel weights ? or no since these have been Linear Fit?

[pfile]

that is correct, leave RGB blank, and only load name of the L image into LRGBCombination, then apply to the RGB. make sure there is no mask enabled on the RGB image. i've never messed with the channel weights, but i think most people will boost the saturation a little (by making the saturation number smaller; the control is "backwards").

rob

[HadesZ]

hmmm... I may need to tweak with my combination process more. I do this and my image is SUPER dark, even after a STF, and my colors are insanely over saturated for some reason. more tinkering tomorrow I guess. if you have any other suggestions on ways to LRGB combine pfile id appreciate any insight!

thanks
-Hades

[pfile]

hm... well without seeing the input images to LRGBCombination it's hard to guess at what's going wrong...

rob

[ChoJin]

The original flow was correct:
- stretch L
- stretch rgb
- extract L* from the stretched RGB and linearfit it to fit the Stretched L
- ChannelCombine the fitted L* back to RGB (you unselect all channel but the L and drop the icon to the stretched RGB image)
- use LRGBCombine to merge the stretched L with the (fitted) RGB image

The idea is to match the Stretched RGB with the Stretched L before LRGBCombine.
From what I gathered from this forum (from' Juan), it is important to do so to prevent from noise issues.

[pfile]

never had to do that. i understand what is being driven at with that flow, but if you stretch your RGB and L similarly in the first place (for instance by using autoSTF on both) then it is not necessary.

rob

[ChoJin]

This is not what Juan and Vicent said though. I know authority arguments aren't really good arguments, but I haven't seen detailed arguments from them, but considering the source, I'd tend to listen to them ^^

[pfile]

thats fine

however the point is that they need to be comparably stretched, which is what they have both said in the past. one question is, why not fit the stretched L to the extracted L* and save the step of re-inserting the L* back into the RGB? ostensibly both your stretched L and stretched RGB look good to you, so i don't see why you have to do it the other way around. there's nothing stopping you from adjusting the image after the merge.

and also the extraction of L* in either case is touchy. do you set the RGB weights and gamma to 1 first? or is it OK that the L* is perceptual?

rob

[ChoJin]

I agree with you, and the only explanation I could come up with is that LRGBCombine is not doing the same thing than ChannelCombine, but I didn't take the time to read the code to figure out exactly how they differ

Hopefully someone will explain further, Juan? Vicent?

[msmythers]

Just wanted to jump in with this one posting from 2010 from Juan about the LRGBCombination tool. Hope it helps.

https://pixinsight.com/forum/index.php?topic=2485.msg16700#msg16700



Mike

[HadesZ]

Ok I'm still lost then, because after I extract the L* from the RGB , it doesn't let me put it back into the RGB image. It says the RGB image is not available.

Also, why put it back in at all? Nothing has been done with it right? It was used to make the L image fitted to match the brightness of the RGB more closely. So why does it need to get put back into the RGB image? Also... As far as I could tell... It didn't change my RGB image at all, so when the L* is extracted... Is it actually taken away from the rgb stack, or is it cloned and a new image created (of just the Luminance)

[pfile]

well maybe i have misread that flow, but i thought what was happening is that you extract the L* from the RGB, then modify that L* by linear fitting it to the L, and then put the modified L* back into the RGB. in theory this should make the (perceptual) brightness of the RGB match that of the L you are going to combine it with.

i misunderstood this at first, not realizing that it was intended to normalize the brightness of the RGB and L. which is why i was saying, why not do it the other way around - dim or brighten the L to match the RGB, so that you dont need to re-inject the L* back into the RGB.

so even though the L* of the RGB gets replaced during LRGBCombination, it was necessary because the L and the RGB should be of similar brightness when you run LRGBCombination. pretty much all i have been trying to say is that if you process the L and the RGB similarly (for instance, using AutoSTF to stretch both images) then they should already be compatible, and this linearfit step should not be necessary.

at any rate i dont think anyone can really debug whats going wrong with your images unless you post them somewhere so that we can look.

rob
 

[RickS]

I don't think it makes any sense to extract the L*, tweak it and then push it back.  That results in lightness not matching the colour components.  The way I have done this in the past is:

• apply RGBWorkingSpace 1:1:1 to the RGB (favouring green doesn't make sense for astro photos IMO)
• extract L* from the RGB with ChannelExtraction
• use L* as the reference for LinearFit and apply to the separately stretched Lum
• combine Lum with RGB using LRGBCombination (select Lum as L, untick R, G and B, apply process to RGB)

This makes the Lum compatible with the lightness in the RGB before combining it.  I don't do this very often because, as Rob said, it's not necessary if you match the stretches for L and RGB and you can adjust for some disparity with the Lightness and Saturation sliders on LRGBCombine.

If you're getting super dark results perhaps somewhere in the process you've got some unstretched data, perhaps by picking the wrong image accidentally?

Cheers,
Rick.