[01.08.02.1098 Ripley Win64] a Deconvolution issue

[Bart_van_der_Wolf]

Hello,

I have come across a deconvolution problem that was probably already present in the previous release some weeks ago, but was hard to reproduce for debugging (some files were problematic, others not), so I couldn't report it before. I have now created a source file (see ZIPped attachment) that again gives somewhat similar (d)effects to what I reported in http://pixinsight.com/forum/index.php?topic=5050.msg34839#msg34839, but now without the color artifacts.

The TIFF file (Link:http://bvdwolf.home.xs4all.nl/temp/PixInsight/JTF-Testchart-bug.zip) was saved from Photoshop CS6 (which saves 16-b/ch images as 15-bit+1), with an AdobeRGB profile assigned and embedded. I've also tried saving without compression and with both LZW and ZIP compression to see if that mattered, which it didn't. All those variants produce the same error.

After opening in PI, the file looks as expected, I then applied a Convolution with the default settings (see attachment), and then a Devonvolution  (see attachment for settings) to reverse the blurring as far as possible. The 1000 iteration maximum should not be problematic since the image is without noise, and the kernel is assumed to be identical to the convolution kernel. The deconvolution produces correct tonality when the target is set to RGB/K components, but the wrong tonality when Luminance (CIE Y) is used.

The same error exists when the Van Cittert algorithm is used instead of Richardson-Lucy, and also choosing regularized or non-regularized makes no difference. It's something to do with how Luminance is selected, I suspect.

If resulting images are needed, just let me know, but I assume that the resulting difference is not due to my installation and can be reproduced at your end, because I also heard from a Trial license user that he got strange results.

Hopefully this can get resolved soon, anyway before the new TGVRestoration process becomes available, I'm looking forward on how that would handle this target.

Kind regards,
Bart

[Juan Conejero]

Hi Bart,

I can't reproduce this problem. The results of deconvolution are correct color wise in both cases (RGB/K and CIE Y). See the attached screenshots.

I have attached two screenshots (see next post for the second screenshot), one with color management enabled and the other with it disabled. In both cases there are no hue changes except, naturally, where pixels get saturated after deconvolution.

[Juan Conejero]

Second screenshots with color management disabled.

[Juan Conejero]

Note: I have replaced the screenshots with new JPEG files *without* ICC profiles embedded, since I've seen that Firefox was not interpreting them correctly (Side note: Hard to believe that web browsers, including Mozilla Firefox, are still unable to implement color management decently in 2014...).

[Bart_van_der_Wolf]

Hi Bart,

I can't reproduce this problem. The results of deconvolution are correct color wise in both cases (RGB/K and CIE Y). See the attached screenshots.

Hi Juan,

The problem is not the color in this case, but the Gamma (?) or tonality.

In this linked screenprint (http://bvdwolf.home.xs4all.nl/temp/PixInsight/2014-07-04_16-18-45.png) the differences are shown.

Top left shows the original.
Top right shows a clone after convolution.
Bottom left shows a correct deconvolution result of the convolved clone with the RGB/K as target.
Bottom right shows the wrong deconvolution result of the convolved clone with CIE Y as target.

A few Ripley sub-releases back, there would be (virtually) no difference between the two target selection results because gamma was correctly converted/linearized, I assume.  Pixels should not saturate after correct deconvolution.
Of course there is a huge difference in processing time because RGB/K requires multiple channels to be deconvolved instead of one.

Hope that helps to better explain the issue.

Kind regards,
Bart
 

[Juan Conejero]

Hi Bart,

Ah, I see. This happens because you are working in a nonlinear RGB color space (the default RGBWS in PixInsight is sRGB, where a gamma of approximately 2.2 is assumed). Assign a linear RGBWS to the image before deconvolving its CIE Y component and your results will be as expected. See the attached screenshot.

So there's no bug here, but just the expected result of assuming the sRGB space for a linear image.

[Bart_van_der_Wolf]

Hi Bart,

Ah, I see. This happens because you are working in a nonlinear RGB color space (the default RGBWS in PixInsight is sRGB, where a gamma of approximately 2.2 is assumed). Assign a linear RGBWS to the image before deconvolving its CIE Y component and your results will be as expected. See the attached screenshot.

So there's no bug here, but just the expected result of assuming the sRGB space for a linear image.

Hi Juan,

That still doesn't explain why conversions were correctly done automatically for more than a year, until a few versions ago. I interpreted it that the source gamma (from the profile, 1/2.2 in this case) was correctly converted with a gamma 2.2 adjustment to linear Y before deconvolution, and back to 1/2.2 before rendering the result. A linear gamma source image would remain linear, regardless of RGB/K or CIE Y target setting. Maybe something changed about using the assumed gamma and the actual gamma of an image?

Puzzled,
Bart

[Juan Conejero]

Perhaps you changed the default RGBWS to a linear space in a previous version. Since then, some of the latest versions may have reset configuration settings back to default values automatically.

PixInsight has no way to know the RGB working space an image is referred to when it loads it. Remember that RGB working spaces for color management and image processing tasks are separate and unrelated in PixInsight, so embedded ICC profiles have nothing to do with the RGBWS used for luminance/chroma separations. The RGBWS for each image is saved to project files (.xpsm), but there's no way to store them in TIFF files for example.

So when PixInsight loads an image, it automatically assigns the default RGB working space. This RGBWS is used to perform all luminance/chroma separations. If you load an image and the default RGBWS has gamma=2.2, then the CIE Y component is not a linear combination of RGB components; you must assign a RGBWS with gamma=1.0 (either explicitly, or by setting the default RGBWS for the whole platform) for this to happen.

See the equations for conversion between the RGB and CIE XYZ spaces:

http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html
http://www.brucelindbloom.com/index.html?Eqn_XYZ_to_RGB.html

(the relevant sections are Gamma and sRGB Companding). When you select the CIE Y component in deconvolution, it simply:

- Extracts the CIE X, Y and Z components from the RGB data in the RGBWS of the image (or in the default RGBWS if none has been assigned)

- Applies deconvolution to the CIE Y component. Call Y' this deconvolved CIE Y component.

- Converts back the CIE X,Y',Z to RGB.

So if your image is linear, you must assign a linear RGBWS (gamma=1) to it before performing luminance/chroma separations. In this way PixInsight knows how to compute the true luminance of the image. In the case of a linear image, the luminance is a linear combination of RGB components.

[Bart_van_der_Wolf]

Perhaps you changed the default RGBWS to a linear space in a previous version. Since then, some of the latest versions may have reset configuration settings back to default values automatically.

Hi Juan,

You may be on to something with that ...
The defaults seem to have changed from what I had set.

PixInsight has no way to know the RGB working space an image is referred to when it loads it. Remember that RGB working spaces for color management and image processing tasks are separate and unrelated in PixInsight, so embedded ICC profiles have nothing to do with the RGBWS used for luminance/chroma separations. The RGBWS for each image is saved to project files (.xpsm), but there's no way to store them in TIFF files for example.

Working space profiles I can understand, but embedded profiles should give PI a clue about the assumed starting position. My example TIFF have Adobe RGB embedded, so no guessing is required as to the native file gamma. But as indicated above, the default PI Color management settings allow to ask when a mismatch is detected upon loading. I'll see if that solves it in daily use.

So when PixInsight loads an image, it automatically assigns the default RGB working space. This RGBWS is used to perform all luminance/chroma separations. If you load an image and the default RGBWS has gamma=2.2, then the CIE Y component is not a linear combination of RGB components; you must assign a RGBWS with gamma=1.0 (either explicitly, or by setting the default RGBWS for the whole platform) for this to happen.

I understand that with the wrong assumptions things will go wrong with the luminanvce/chroma separations. It's the assumptions that should follow the embedded profile through the workingspace profile IMHO, unless no profile is embedded or it is changed after loading.

See the equations for conversion between the RGB and CIE XYZ spaces:

http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html
http://www.brucelindbloom.com/index.html?Eqn_XYZ_to_RGB.html

I also love Bruce's website, very useful, I frequently recommend it to others myself.

Thanks for pointing to the possibly changed preferences, it seems like PI follows those settings. The rest follows logically it seems.

Cheers, and have a nice weekend,
Bart