Deconvolution changes

[RBA]

In the last PixInsight's update I noticed the "Linear" and "Luminance" checkboxes in the Deconvolution tool are gone, and they've been replaced by the "Target" pulldown menu, which, if I understand this correctly, leaves out applying deconvolution to the CIE L* component??

Other than a cleaner UI, are there any other reasons beyond this change? I'm jst curious.

[Juan Conejero]

Hi Rogelio,

The CIE L* component (lightness) is a nonlinear function of RGB components. Hence, it is conceptually incorrect trying to deconvolve it.

The new version of the Deconvolution process allows you to work exclusively on the luminance component (CIE Y) or on individual RGB components. This change is intended to make the implementation of this tool more rigorous. The RestorationFilter tool, also pertaining to the Deconvolution category, still provides a CIE L* target, although CIE Y is the default option.

Needless to say, the CIE L* component can always be extracted as an independent image, which can be "deconvolved" for cosmetic purposes without physical justification.

Along with this change, version 1.6.9 introduces a rigorous differentiation between lightness, the L* component of CIE L*a*b* and CIE L*c*h*, and relative luminance, in the photometric sense, which is exclusively the Y component of CIE XYZ. Note that these changes affect the whole platform, including the core application and all standard tools. I'll further elaborate on this important topic in a separate thread.

[RBA]

The CIE L* component (lightness) is a nonlinear function of RGB components. Hence, it is conceptually incorrect trying to deconvolve it.

I was going to ask if the reason was related to making clear that non-linear deconvolution isn't recommended in/by PixInsight, but I decided not to say anything in case I screwed up

Regarding lightness/relative luminance, what terminology are you suggesting people use from now on? Are you ditching the word "luminance" as the L component in CIELab?

[Juan Conejero]

Are you ditching the word "luminance" as the L component in CIELab?

Absolutely. For example, when we talk about LRGB combination we actually refer to lightness/RGB combination, or the process of replacing the L* component in the CIE L*a*b* and CIE L*c*h* spaces. Referring to L as the luminance is incorrect in this case.

The term luminance is often used quite loosely among the astrophotography community, and PI has not been an exception until version 1.6.9. With the new version I've tried to make a thorough revision of the core application and all standard tools, getting rid of these inaccuracies once and for all. Time to improve our terminology and the way we refer to such critical concepts as luminance and chrominance.

From now on, when we speak of luminance we are referring exclusively to the photometric meaning of this term. For example, an image acquired through a clear filter (or with no filter) with a linear monochromatic device can be called luminance. The same image after a nonlinear transformation (histograms, curves, etc.) is no longer a luminance, as the luminance is a linear function by definition. However, if we can describe the nonlinearity of an image as a gamma function, we can compute its CIE Y component after linearization, as an approximation to the original luminance.

In the case of the word chrominance, I have made the decision to preserve its use in all cases, including linear and nonlinear color spaces, in absence —to my knowledge— of a better term to describe the purely chromatic information of a color (as opposed to pure illumination perception). I don't discard making a second revision of the whole platform to replace the word chrominance where a better terminology can be applied.

[Juan Conejero]

Hi Again. Forgot to comment on this:

non-linear deconvolution isn't recommended in/by PixInsight

There is no such thing, neither in PixInsight nor anywhere else Deconvolution only makes sense with linear data.

[RBA]

Hi Again. Forgot to comment on this:

non-linear deconvolution isn't recommended in/by PixInsight

There is no such thing, neither in PixInsight nor anywhere else Deconvolution only makes sense with linear data.

Easy cowboy!   My only observation was that prior to 1.6.9, as far as I can remember, something that you now label as "there's no such thing" was the default values for the Deconvolution tool in PixInsight (using CIE L* as the luminance of the target image), and in 1.6.9 it was gone, so my first thought was what I said up there.

But if we're to get deeper into this, perhaps nitpicking a bit, in certain forensic situations, when only non-linear data is available, the folks deciding what to use to "recover" the data probably find situations where it makes a lot of sense to utilize deconvolution algorithms versus say edge-enhancement or other "restoration" methods. I don't have the expertise to refute their use of deconvolution algorithms on non-linear data.

And there may be situations even in astroimages, that applying a deconvolution algorithm may yield better results than using other techniques. Yes, in that case you're not truly deconvoluting, but can you use a deconvolution tool simply as a "sharpening" tool despite it would be "conceptually wrong"? Absolutely! And I won't get into the debate about whether the end result is more or less important than the road that led to it. Not now

PS: For the record, I barely use deconvolution, it very rarely makes sense in the images I've been producing lately, and if I decide to use it, I'd always do it on linear data, but I don't wear a scientist coat when I process my images and as you may have noticed, I tend to fancy challenging the Pixel Police for a whole bunch of reasons

[Juan Conejero]

in certain forensic situations, when only non-linear data is available, the folks deciding what to use to "recover" the data probably find situations where it makes a lot of sense to utilize deconvolution algorithms versus say edge-enhancement or other "restoration" methods.

Don't believe what you see on CSI 

No, there is actually no such situation. The CSI folks have basically two options:

- If the PSF is accurately known and the nonlinear data can be linearized accurately by a gamma function, then they can deconvolve the CIE Y component. This involves defining the appropriate RGB working space (RGBWorkingSpace tool) in PixInsight, to define the reference white (not critical), the luminance weights (usually 1:1:1) and the gamma value (critical) that characterize the RGB data.

- They can use the ATrousWaveletTransform tool. This is the recommended option. With the appropriate wavelet scaling function and a careful tuning of layer parameters, ATWT will outperform deconvolution in virtually all cases.

Bear in mind that if the data can't be well linearized and the PSF is unknown, as almost always happens, applying deconvolution is as shooting in the dark. The unknown PSF can be found by trial-error, and with some experience this manual work can yield very good results, but then, why not use ATWT, which is much faster and controllable?

As an alternative to the tools that PI currently provides, we have blind deconvolution. BD is powerful and can be an interesting option if the PSF is unknown (mainly to save time), but again, if the data are nonlinear, deconvolution doesn't make sense.

So the bottom line is: I have removed the CIE L* target from Deconvolution because it really does not make any sense and just adds more chances for confusion and misuse. We have powerful tools to sharpen nonlinear data that make using Deconvolution in those cases a very wrong choice.

[Juan Conejero]

And there may be situations even in astroimages, that applying a deconvolution algorithm may yield better results than using other techniques.

Depends on the definition of 'better results'. If the quest is for enhancements evaluated as such without any technical basis, then the whole discussion makes no sense from a technical perspective.

If the procedures are to be selected using more rigorous technical criteria, then using deconvolution with nonlinear data really makes no sense. On one hand, as we have noted previously many times, deconvolution is an image processing technique with a physical justification, and the required physical conditions are invalidated if the data are nonlinear. The other reason is that deconvolution is pretty inefficient as a sharpening process. It is much more processor-intensive and much more difficult to control and understand than a wavelet-based sharpening tool for example, and it actually cannot provide better results with nonlinear data.

[RBA]

No, there is actually no such situation.

Ok then. In absence of hard data (I don't know anyone who does forensic image engineering - or whatever is called - for a living) I have to take your word for it.

So why in heaven did you choose the default option in PixInsight's Deconvolution tool to be a non-linear luminance component in the first place?

BTW I have yet to see one single episode of CSI, House and all these "fancy culebrones" When my first kid was born, the only things I've ever watched on TV are movies (played on the computer or DVD) and occasionally, news.

As for the definition of "better results", it's meant as a qualitative/subjective attribute. Something as real as anything else but probably pointless in this forum.

"...without any technical basis, then the whole discussion makes no sense from a technical perspective." -> Redundant.

[RBA]

BTW just for the record, I'm not trying to argue something that I "got it" a while ago. Rather, I have this bad habit of questioning things...   

[Juan Conejero]

So why in heaven did you choose the default option in PixInsight's Deconvolution tool to be a non-linear luminance component in the first place?

It was an error. I 'discovered' the problem in 2007, if I remember well, and then I added the CIE Y target (which was selectable through the 'linear' checkbox). I decided to preserve the optional CIE L* target for compatibility, but being conscious that this was an important inconsistency.

Now I finally have decided to target this problem, along with the lack of a rigorous terminology for luminance —both are sides of the same coin actually— before entering the 1.7 cycle. The revision of key concepts and terms has probably not ended here. I am considering a deep revision of the whole concept of RGB working spaces in PixInsight, to provide a more rigorous and versatile infrastructure.

[Juan Conejero]

BTW I have yet to see one single episode of CSI, House and all these "fancy culebrones" smile When my first kid was born, the only things I've ever watched on TV are movies (played on the computer or DVD) and occasionally, news.

Oh, I don't have TV

[Philip de Louraille]

Juan said (extracted)
> From now on, when we speak of luminance we are referring exclusively to the photometric meaning of this term. For example, an image acquired through a clear filter (or with no filter) with a linear monochromatic device can be called luminance.
and
> when we talk about LRGB combination we actually refer to lightness/RGB combination, ...(deleted)... Referring to L as the luminance is incorrect in this case.

I see a contradiction here. In an LRGB data set (yet to be processed) the L data is an "image acquired through a clear filter ... with a linear monochromatic device can be called luminance"  So L is luminance, no?

Or... ar you saying that in the raw, pre-processed (linear) LRGB dataset, L is luminance, but once the dataset has been processed (and de-linearized in the process), if one were to extract the L data from the resulting image it would be called "lightness" ?

[netwolf]

Juan,

So are you saying that we should not use Deconvolution on RGB either combined R, G and B and then combined (From filters on a monchrome camera) or RGB providued by OSC camera?

I have been trying to do jus this, I have seperate R, G and B data which i have combined (Still non linear) but no matter what combination i use for Decon it produces ringing or very odd results. Best I could get was setting StdDv to 2-3 and Shape to 5-6. Still ringing on stars is notable. I used Star mask , both dervied from RGB (using midtone control to stretch and get) and extracting L fromg RGB and then HT stretch and then extract Starmask.  Neither protect the stars to well. I test both by masking image to ensure all stars were protected b ythe inverse of the mask. I also noticed that unless I turned Dergining off or set to very low Black value say 0.02 or bellow, it would always produce divergence in 2nd iteration and then more further down within 10 iterations.

From your tutorial it seems i need to find the mean FWHM value for the image to cacuclate the PSF = STdDv, I will try this with ReadPSF. But how about the shape value? IT would be nice to see a video tutorial with some detailed information on the various deconv settings and how to set them.

For the PSF external feature, what is the method by whcih we should get the PSF model? Is there anything within Pixinsight to help us do this?

Regards
Fahim