Question on deconvolving RGB images

[Ignacio]

I've noticed that, when estimating a PSF on an RGB image, DynamicPSF generates estimates on each color channel for each selected star. Then, when it generates an estimated PSF for the set, it is a monochrome image. I guess this is the luminance channel.

The, the deconvolution tool offers the possibility of deconvolving each channel separately, but using a single luminance-based PSF. Wouldn't it be more consistent to carry thru the full RGB PSF model, and use luminance or each indivudual channel PSF accordingly? Did I miss some setting to do this?

Otherwise, one has to split the RGB image, build a PSF, and deconvolve each channel separately. And yes, I know that luminance is responsible for resolution, but when dealing with OSC cameras and colors of stars, this is not so obvious to me. You may get bleeding in one color if working with a luminance only PSF.

Ignacio

[Carlos Milovic]

Hi Ignacio

The "correct" way to do that should be deconvolving all three color channels. The problem is that controlling that, and achieving a "balanced" result (or, at least with some equivalency in the fluxes, so you end with the correct color balance) is pretty hard. So, the easier way to go is to operate over the luminance.
The problem with that approach is that many stars are shrienkied in the process, and you'll end with ugly halos, or other artifacts. The way I fix that is extracting the luminance, deconvolve, and then import it with the "ImportL" process I published. It adjust the chrominance accordenly to the variations in the luminance, so saturation is fixed for the star haloes, and they are much less annoying.

[Ignacio]

Thanks, Carlos, I'll give it a try.

Ignacio

[pfile]

yes, in order to deconvolve my DSLR images i found that i had to generate 3 different PSFs, one per channel. for whatever reason the FHWM of my red channel is always different than the G and B, so in the end i'd use the G PSF on the G and B images, and the R PSF for the R image. otherwise, as Carlos says, i would get halos and ringing in the R channel.

only in the last few days did i realize that i should have been doing what Carlos suggests - making a synthetic L image and deconvolving that.

one question i do have about the LRGB combination - is this usually done on the linear data? seems like that's the right time to do it.

where is ImportL ? is it another windows-only Process?

[Ignacio]

only in the last few days did i realize that i should have been doing what Carlos suggests - making a synthetic L image and deconvolving that.

I think that is what the deconvolution tool does for you, in its default settings. Carlos, is suggesting something extra, that combines the deconvolved luminance with a somehow modified chrominance.

Ignacio

[Geoff]

Here is the thread on importL
http://pixinsight.com/forum/index.php?topic=3270.msg22489#msg22489

[pfile]

only in the last few days did i realize that i should have been doing what Carlos suggests - making a synthetic L image and deconvolving that.

I think that is what the deconvolution tool does for you, in its default settings. Carlos, is suggesting something extra, that combines the deconvolved luminance with a somehow modified chrominance.

Ignacio

well sort of, but not really. as far as i can tell if you do deconvolution on an RGB image, each plane is deconvolved separately, with a single PSF. the problem is that the FHWM and thus the PSF of each channel is subtly different. the PSF generated from the RGB stars is not representative of any one plane, and is too large or too small for one or more of the planes.  and so there's no one set of deringing parameters that can prevent ringing in all channels simultaneously.

i think Carlos is saying to extract the L from the RGB (and probably with R,G,B weights = 1) and deconvolve that image by itself, then merge it back with your (un-deconvolved) RGB using his ImportL process. but you could also just do LRGB combine. his ImportL process modifies the RGB saturation based on the luminance so that you don't get weird color halos around the stars.

thanks for the pointer geoff... no macosx version is there. i wish juan would at least make a build server for the rest of the team so that they could automatically generate their experimental modules for all supported platforms.

[Ignacio]

So then what's the point of the "target" setting in the deconv. tool?

Ignacio

[pfile]

i don't know - i wonder if it's broken? i don't think it can have the effect of creating a synthetic Luminance image because otherwise i'm not sure why i'd see different ringing in each channel the way i did.

i'm pretty sure Carlos is advocating extracting the L* from your RGB and then deconvolving that, not simply choosing L as the target in the Deconvolution process.

[Juan Conejero]

when estimating a PSF on an RGB image, DynamicPSF generates estimates on each color channel for each selected star. Then, when it generates an estimated PSF for the set, it is a monochrome image. I guess this is the luminance channel.

It isn't the luminance. DPSF generates a synthetic PSF image for the selected stars. If a star has several PSF fits (for several channels for example), each fit is treated as a different PSF. So we could say that the generated PSF model is more like an "average" of the selected stars.

In the current version of the DPSF tool, if you want to get a synthetic PSF model for each color channel, you have to split the image first and apply the same instance of DPSF to each channel. This is very easy to do if you save a process icon (just a few clicks).

The, the deconvolution tool offers the possibility of deconvolving each channel separately, but using a single luminance-based PSF.

For OSC and DSLR data, the PSF of the image should be the same for the three RGB channels, unless the optical system has severe color-dependent aberrations---and in such case one should fix them at the hardware level. The DynamicPSF tool should give you negligible differences among the three channels of one of these images.

For separate RGB and LRGB acquisition, it is true that the "strictly correct procedure" would be to treat each color component as what it is: a different image. In practice, however, doing this does not make any sense in most cases. The main reason is that what you deconvolve is the integration of (hopefully) many images, not a single frame, since you need to increase SNR for deconvolution. Hence, the PSF of each channel is actually an average, which tends to be the same for the whole data set, and also tends to be Gaussian.

Wouldn't it be more consistent to carry thru the full RGB PSF model

Perhaps more convenient in some cases, but not more consistent. The Deconvolution tool works with a monochrome PSF model for simplicity, and mainly for the reasons exposed above. Again, if you want to deconvolve each channel separately, you can split the image first and recombine it with the deconvolved channels.

You may get bleeding in one color if working with a luminance only PSF.

If that happens, then it is probably because (a) you are trying to deconvolve marginal (i.e., too noisy) data, (b) you are using a nonlinear color space to perform luminance/chrominance separations, or a combination of both. If you apply deconvolution correctly to the luminance (which is *not* the same as the CIE L* component), then this shouldn't happen. You can also protect your bright stars---which are "singularities" for deconvolution---with a suitable mask.

So then what's the point of the "target" setting in the deconv. tool?

i don't know - i wonder if it's broken? i don't think it can have the effect of creating a synthetic Luminance image because otherwise i'm not sure why i'd see different ringing in each channel the way i did.

No it isn't. Perhaps we are confusing luminance and lightness here. Deconvolution only makes sense for linear data. If applied to a nonlinear color component, such as a synthetic CIE L* component (lightness), then it is being used unrigorously with "cosmetic purposes", but not as deconvolution.

For this reason the Deconvolution tool offers you to work on the CIE Y component (luminance) or on separate RGB/K components: these are the *only* valid options for deconvolution.

However, special care must be taken to deconvolve the implicit luminance of a RGB color image:

- Of course, the raw integrated data must be used, i.e. the unstretched output data of the ImageIntegration tool.

- The RGB working space of the target image must be linear. Open the RGBWorkingSpace tool, extend the Gamma section, and uncheck the "Use sRGB..." option. Then set Gamma=1. Now you should define custom luminance coefficients. For compatibility purposes, the default weights are those of the sRGB space, which are quite inappropriate for DSOs (e.g., the green channel has ten times more relevance than blue and three times more than red). If you want to use a uniform linear RGB working space, then set the three coefficients equal to one. This is usually the best option. Now apply the RGBWorkingSpace process to the image.

- Select the Luminance (CIE Y) target in the Deconvolution tool.

- Use a suitable ScreenTransferFunction to inspect your image during deconvolution.

Let me know if this helps.

[Juan Conejero]

I forgot to mention something important about the DynamicPSF tool. Quoting myself:

In the current version of the DPSF tool, if you want to get a synthetic PSF model for each color channel, you have to split the image first and apply the same instance of DPSF to each channel.

This is not correct, actually. You have another way, probably much more convenient, to compute the PSF model separately for individual RGB channels without splitting the image. Simply select one of the channels for visualization; for example: Image > Display > Red (Ctrl+Shift+R or Cmd+Shift+R). Then DPSF will only generate PSF fits for the red channel. In this way you get channel-specific PSF fits as individual stars, and hence you can generate a model for a single channel by selecting only the corresponding stars. I forgot this functionality in my previous post (so much work, so much code, ... I tend to forget what I implement )

[Ignacio]

Thank you, Juan, for taking the time and for your detailed answer. I follow most (if no tall) of the correct rules for deconvolving (linear image, working space, luminance, etc.), and I use a world class apo refractor for imaging (AP130GT). Still, I have found (slightly) better results when deconvolving each color channel separately (btw, thanks for shortcut in building RGB PFSs), than when just doing a single deconvolution on luminance.

A few comments/questions:

1. You say that the monochrome PSF generated by the DPFS tool on an RGB image is an average of the three individual PSFs for each color channel.
     a. What happens with atmospheric refraction? Should one first split and align the individual color channels (I actually do this!)
     b. Even if very well corrected, apo refractors have slightly different optimal focus points for each color channel. When shooting with a DSLR, for a single "optimal" focus point, each color will produce a slighlty different PSFs.
     c. Does the astmospheric dispersion act different on different wavelengths? I guess yes, so this would also have different impact on each channel PSFs.

Granted these effects may be small, but my experience is that I get somewhat better results, particularly resolving color of small stars.

cheers
Ignacio

[pfile]

even with a very nice refractor, when using an OSC, slight differences in focus in each plane can still be present. and when using camera lenses it's almost certain to happen. so sometimes there is no hardware fix. my experience is exactly as Ignacio's, right down to having to re-align the RGB images to one another. so, like it or not i guess, we are ending up with different PSFs in each channel and we need to deal with this somehow.

to be clear, i was not talking about getting ringing when applying deconvolution to a synthetic L* image. i was talking about doing exactly what Ignacio was describing, and arriving at an average PSF which ends up being very much wrong for the R channel. now, it could be that the problem is that i never set the RGB weights to 1:1:1, but since in my case the B and G FHWM are much better than R, i still think the average PSF would be too small for the R channel and lead to ringing while B and G are fine.

anyway, that's why i started breaking the image into it's 3 greyscale components and deconvolving each separately. but it's very difficult to get the results to be the same in each channel, which is why i became interested in the synthetic L* method. however, it sounds like this method is just wrong from a mathematical perspective.

wikipedia says that in CIELAB, L* = 116*(Y/Yn)^1/3 - 16. when you set the RGB weights to 1 and gamma to 1, what part of this equation changes? it would seem that no matter what you do the conversion is non-linear given the cube root and that's the source of deconvolving L* being non-rigorous mathematically, is that right?

[Ignacio]

I forgot to mention something important about the DynamicPSF tool.

This is not correct, actually. You have another way, probably much more convenient, to compute the PSF model separately for individual RGB channels without splitting the image. Simply select one of the channels for visualization; for example: Image > Display > Red (Ctrl+Shift+R or Cmd+Shift+R). Then DPSF will only generate PSF fits for the red channel. In this way you get channel-specific PSF fits as individual stars, and hence you can generate a model for a single channel by selecting only the corresponding stars. I forgot this functionality in my previous post (so much work, so much code, ... I tend to forget what I implement )

Had no luck with this, Juan. Tried it on an RGB image by displaying different color channels and got exactly the same PSF (that is, without reselecting stars). Adding a "color channel" option in the "sorting" dialog would help.

Ignacio