Wrong color profile conversion when saving a photo which has ICC profile

[simohno]

Hello

I noticed that when a photo which is ICC-tagged (meaning it has an "ICC profile" data structure in the metadata, for example Adobe RGB 1998) is edited in XNV and then exported with File > Save As, when in the Options window the option "Preserve ICC profile" is checked, something really annoying happens for a photographer point of view:
The colours are converted to the monitor profile set in the Settings (in my case, that registered at the OS level, option "System"), and the monitor profile is (correctly) associated to the exported file.

So, instead of preserving the photo's colour profile (in the example, Adobe RGB), XNView makes an unwanted conversion, hence clipping/compressing the colours that are outside the monitor's gamut. The colours keep displayed correctly, but the fact that a photo gets described with a monitor profile is really annoying and is something "sacrilegious" in photography. I am starting using GIMP for every small edit, even if XNView is quicker.

I suppose this is an unintended behaviour, and it contrasts with the good colour managing workflow rules, so I reported it among the Bugs and in my opinion needs urgent revision as follows: the conversion of RGB values to the monitor profile is to do for the visualizing purpose only, after every edit, and the operations on the file have to be done in the original colour space! Thus preserving that colour space when saving.


Important side note: the File > Export module, contrarily to Save As > Options, lacks the possibility to incorporate an ICC profile, the current is discarded and colours are not converted to sRGB -> upon the next opening the image is wrongly interpreted as sRGB and the colours are wrong.
Ideally I would like to have an option to convert to a specified colour space in the JPEG format Options tab (e.g. to convert to sRGB for web publication).

Many thanks. Also, developers, please check my Suggestions also about colour management in XNView in the other forum page.
As a reference for corrections you can experiment with the GIMP (GNU) which behaves correctly with colour profiles, both on file and on monitor side. At present, XNView is great for photographic work only until you start using any bit of color management......


XNV MP version 0.98.1 on Windows 10 20H2 64 bit

[xnview]

yes, when loading a file with ICC profile, image data are changed and if you save it, you'll have new datas

[Armas]

Hello,
I raised this issue once in my post of 5 Jan 2021.
Obviously it is not on the priority list.
But even so, XnView is a very helpful programme! Maybe this bug will be fixed one day

[simohno]

Yes I love XnView for its fullscreen view with customizable informations shown in the corner!
It also handles quite well the colour profiles of both files and monitors for loading the images (except for some out-of-camera JPEGs as reported in my other post).
I really hope that a correction for the saving will come in the near future, and I am pleased to be not the sole to have noticed it!

Simone

[esv]

Have also just discovered this bug
Just a tip: if you disable "General→ICC→Use ICC profile for monitor", then e.g. cropping a file preserves the original color profile instead of overwriting it with the monitor profile
Another tip: batch conversion seems to work correctly, the "Options→Preserve color profile" appropriately preserves the original
But wish this got fixed, the monitor profile should not be embedded in the pic, it's only for the output...

[simohno]

Good, thanks... as workaround, we may disable using the monitor profile temporarily, just before performing the Save operation (?) so to keep viewing the file with the correct colours!
But it is tedious to do this each time...

[esv]

Good, thanks... as workaround, we may disable using the monitor profile temporarily, just before performing the Save operation (?) so to keep viewing the file with the correct colours!

You need to close the viewer if you have it opened and reopen it again, otherwise it bugs. But at least you don't have to restart the app. Still, I wouldn't trust this workaround for anything important without more extensive checks

But it is tedious to do this each time...

It definitely is
(btw, check the other tip, it seems that batch conversion doesn't suffer from this bug, but then it's not as convenient for a single picture)

[simohno]

Ok good to know, thanks. Let's hope for a quick correction, it should not be a deep change...

[pat56]

Just tested v 1.4.0, and the matter is always there

In my mind , there are 2 points to solve:

1. to give the ability to choose the color profile when saving the result of a modification (with save, save as, or export) exactly as ">Tools >Batch convert..." or XnConvert do it

2. probably more complex, to change the policy for the internal working color space.
- preamble: all people using a large gamut display, or even those who calibrate their monitor, will continue to select the "use monitor profile [selected at OS level]" option to manage good color corrections
- It seems that today, the screen color profile is used as working color space. This allows to send directly the instant image (after each correction) to the sceen, but limits seriously the result when a standard (~sRVB) screen is used, and gives a curious (reductive, strange, but not false) result when looking at the color profile of the jpeg
- so the matter is to change that. The more general would be to use a very large gamut, independant from input, output and monitor. But it supposes to change a lot the programming .... wait and hope

[bodayw]

I would like to add that the issue is not limited to images that have ICC embedded.

When color management is enabled and forced, meaning:
- Settings - General - ICC - Use ICC profile for monitor (slower) is checked
- RGB profile used when embedded profile doesn't exist - sRGB is selected

Convert and "Save as" any non-ICC-embedded images would result in color shift.

And worst of all, obviously the resulting image would NOT have embedded ICC, even with "keep ICC profile" option checked, given there is no ICC embedded in the source file.

This means that these images would be displayed in blatantly wrong colors, and there is no way to tell without comparing with the source. Should qualify as "Must fixes"?

Even if the color shift is expected behavior (I do not agree), at the very least, converted images should have the monitor color profile embedded in this situation, so people would know what has happened to the colors, and these files would still be displayed with correct colors in a color-managed environment.

And as others have suggested, the monitor color profile should be only used for displaying images on that specific monitor, not to be involved in changing the colors when saving images. This should not be the expected behavior.

Given that color management is not enabled by default, the issue is probably not as widespread. However, users who do enable the above settings - those are all sensible settings - are the ones who care about color accuracy and would really be annoyed by this issue.

[simohno]

Hello bodayw,
I have not noticed anything until now, when working on non-ICC equipped images (e.g. from smartphone), with the settings you mention enabled. In fact, I only use XnView as photo editor for quick changes on those kind of photos, not to have embedded the monitor profile on output!

Which kind of "color shift" do you refer to? The internal conversion of the colors to the monitor profile (used as working color space), as described by pat56?

Thanks to pat56 for sharing these findings; I did not know about the use of monitor profile as working color space, it sounds not very good as workflow. It causes a saturated colors clipping / a color range compression, in case the original photo has a wider gamut than the monitor... I can confirm that using a very large color space (e.g. WideGamut RGB, ProPhoto) is the "state of the art" in photo editor tools (see for example in RawTherapee).

[bodayw]

Which kind of "color shift" do you refer to? The internal conversion of the colors to the monitor profile (used as working color space), as described by pat56?

Yes, by "color shift" I just meant the conversion from source image color space -> monitor color space, which depends on the monitor color profile. This is clearly not a very accurate way of describing it...was probably just trying to imply that this is unwanted.

[jaeae]

Hello!

I have been trying to use XN mp to replace Corel Aftershot in Ubuntu 16.04. Using the latest 1.4.3 at the moment.

Otherwise the XNview is brilliant, BUT the ICC color management is not working properly.

When saving images, the program saves the JPG with monitor profile, which is completely wrong. Monitor profile is for viewing the image colors correctly only.

For example, I have a laptop with poor display that shows about 80% of sRGB color space. If there is no color management, the sRGB images will look washed out, because the color space does not fit to monitor's color space.

Also, there is no way to convert for example, AdobeRGB images to sRGB when exporting or saving. Only possibility is to keep images ICC profile, but that feature has a bug, it does not keep it, it saves with monitor ICC.

Any updates on this bug + missing feature?

[simohno]

I would like to add that the issue is not limited to images that have ICC embedded.

When color management is enabled and forced, meaning:
- Settings - General - ICC - Use ICC profile for monitor (slower) is checked
- RGB profile used when embedded profile doesn't exist - sRGB is selected

Convert and "Save as" any non-ICC-embedded images would result in color shift.

And worst of all, obviously the resulting image would NOT have embedded ICC, even with "keep ICC profile" option checked, given there is no ICC embedded in the source file.

This means that these images would be displayed in blatantly wrong colors, and there is no way to tell without comparing with the source. Should qualify as "Must fixes"?

Even if the color shift is expected behavior (I do not agree), at the very least, converted images should have the monitor color profile embedded in this situation, so people would know what has happened to the colors, and these files would still be displayed with correct colors in a color-managed environment.

I re-read your post, and got aware that for photos non-equipped with ICC the situation is crazy. A true color shift happens, unless we (with another program) assign to the jpegs the monitor profile. Even quickly cropping and re-saving a picture from Google, if I check "use monitor profile" in the settings, converts the colors to the monitor profile without then embedding this profile, and further programs would assign sRGB mis-interpreting the colours... have I understood well?
So, in the end, when using a monitor profile, we can use XnView only for viewing. Better the (slower but strong) GIMP.

[bodayw]

I re-read your post, and got aware that for photos non-equipped with ICC the situation is crazy. A true color shift happens, unless we (with another program) assign to the jpegs the monitor profile. Even quickly cropping and re-saving a picture from Google, if I check "use monitor profile" in the settings, converts the colors to the monitor profile without then embedding this profile, and further programs would assign sRGB mis-interpreting the colours... have I understood well?
So, in the end, when using a monitor profile, we can use XnView only for viewing. Better the (slower but strong) GIMP.

Yes, exactly. Potentially this is a bigger problem.

Current workaround is to always use the "batch convert" tool, and never use "save as".