Hi!!

On Sat, Feb 7, 2009 at 6:27 AM, Guillermo Espertino wrote:

Hi.
I don't know if this can be considered as a bug, but I'd like to discuss some potential issues in the color profile embedding strategy. Currently (correct me if I'm wrong) the procedure for images without embedded profile is to silently embed the working RGB profile upon opening.
This can be really problematic when the user has a sequence of images without profile (for instance a rendering from a 3D program) and want to retouch a couple of images.
The result will be that the retouched images will have a profile and the others won't, and that can bring troubles when importing the image sequence into a color managed software. A simple way to avoid this would be to ask when an image without profile is opened, just like when an image with a different profile than the working profile is opened. A dialog could allow the user to choose wheter to keep the image unmanaged or embed the working profile.

It's a good idea, however this particular way of doing it is not practical -- because in many cases, the majority of images opened do not have a profile. We need to find an approach that would not require vast amounts of dialog interaction.

In any case, profiles are NOT automatically attached to images without profiles, in my tests with PNGs. The reason you might assume they are, is that GIMP automatically displays images which have no profile attached, as if they had the working profile attached.

If your experiences don't match the above, perhaps the specific save plugin in question does (wrongly) attach the working profile when saving.

David

Guillermo Espertino wrote:

I'd like to discuss
some potential issues in the color profile embedding strategy. Currently (correct me if I'm wrong) the procedure for images without embedded profile is to silently embed the working RGB profile upon opening.

What do you think?

Hi

I think we should have behave like this:

* Color profiles shall only be embedded/referenced in an exported/saved image if there is a color profile attached to the GimpImage

* When opening an image without a color profile attached, it shall be *displayed* as if it would be in the color space specified by the working color profile in Preferences but we shall not attach the working space color profile to the image

So, opening an unmanaged image will display it as if it is in the color profile specified in Preferences, but since a color profile will not be attached to the image unless the user does Image -> Mode -> Assign Color Profile, no color profile will be embeded/referenced when the image is resaved, and we would not have to show annoying dialogs whenever the user opens an un-color-managed image.

- Martin

Hi,

I wrote a small patch for checking embedded profile . http://cue.yellowmagic.info/softwares/files/profile_status.diff

Example 1: Image has no profiles http://cue.yellowmagic.info/softwares/images/gimp_profile_status1.png

Example 2: Open the gray-scaled image that has "Dot Gain 15%" profile http://cue.yellowmagic.info/softwares/images/gimp_profile_status2.png

Hi,

On Sat, 2009-02-07 at 09:41 +0100, Martin Nordholts wrote:

I think we should have behave like this:

* Color profiles shall only be embedded/referenced in an exported/saved image if there is a color profile attached to the GimpImage

* When opening an image without a color profile attached, it shall be *displayed* as if it would be in the color space specified by the working color profile in Preferences but we shall not attach the working space color profile to the image

That is exactly what we do. Or at least that's what the code is meant to do. If it doesn't, then we probably have a bug.

Sven

Sven Neumann wrote:

Hi,

On Sat, 2009-02-07 at 09:41 +0100, Martin Nordholts wrote:

I think we should have behave like this:

* Color profiles shall only be embedded/referenced in an exported/saved image if there is a color profile attached to the GimpImage

* When opening an image without a color profile attached, it shall be *displayed* as if it would be in the color space specified by the working color profile in Preferences but we shall not attach the working space color profile to the image

That is exactly what we do. Or at least that's what the code is meant to do. If it doesn't, then we probably have a bug.

Sven

So I can go ahead and revert this commit then? (rev 23135):

2007-08-07 Sven Neumann

* plug-ins/common/png.c (save_image): in the absence of an embedded color profile, write the sRGB chunk.

- Martin

Yoshinori Yamakawa wrote:

Hi,

I wrote a small patch for checking embedded profile . http://cue.yellowmagic.info/softwares/files/profile_status.diff

Example 1: Image has no profiles http://cue.yellowmagic.info/softwares/images/gimp_profile_status1.png

Example 2: Open the gray-scaled image that has "Dot Gain 15%" profile http://cue.yellowmagic.info/softwares/images/gimp_profile_status2.png

Nice! I think we should try to get something along those lines into GIMP 2.8

Could you create a bug report at bugs.gimp.org and attach the patch there so we can track it while we clean it up please?

- Martin

Hi,

On Sun, 2009-02-08 at 06:44 +0900, Yoshinori Yamakawa wrote:

I wrote a small patch for checking embedded profile . http://cue.yellowmagic.info/softwares/files/profile_status.diff

Example 1: Image has no profiles http://cue.yellowmagic.info/softwares/images/gimp_profile_status1.png

Example 2: Open the gray-scaled image that has "Dot Gain 15%" profile http://cue.yellowmagic.info/softwares/images/gimp_profile_status2.png

I don't quite understand what this patch is supposed to do. The display of color profile information in the Image Properties dialog is already there. What does your patch add? To me it looks like the dialog only becomes more confusing and misleading.

Sven

Hi,

On Sat, 2009-02-07 at 23:03 +0100, Martin Nordholts wrote:

So I can go ahead and revert this commit then? (rev 23135):

2007-08-07 Sven Neumann

* plug-ins/common/png.c (save_image): in the absence of an embedded color profile, write the sRGB chunk.

I don't think we should do any code changes before we know exactly what we want. IMO we should first determine what we want, create a set of test cases and find out what the current code is doing. Then, when we know what needs to be changed, open bug reports and do the changes. Otherwise we will end up with an inconsistent mess.

Sven

Sven Neumann wrote:

Hi,

On Sat, 2009-02-07 at 23:03 +0100, Martin Nordholts wrote:

So I can go ahead and revert this commit then? (rev 23135):

2007-08-07 Sven Neumann

* plug-ins/common/png.c (save_image): in the absence of an embedded color profile, write the sRGB chunk.

I don't think we should do any code changes before we know exactly what we want.

I agree that someone should sit down and specify exactly how we want color management to work before doing major surgery.

However, reverting that commit is not major surgery and to me writing an sRGB profile in the absence of an embedded profile is just plain wrong. If something like that was supposed to done it should at least be the RGB profile selected in the Color Management preferences, but even doing that would be making hasty assumptions. What if the user don't want a profile to be embedded in the PNG and does not want any gamma information to be saved either?

It is IMO better to not write any color profile at all than to write one that might be wrong.

Could you elaborate on why the change was made in the first place please? Maybe I miss something

- Martin

On Sunday 08 February 2009 08:39:38 am Sven Neumann wrote:

Hi,

On Sun, 2009-02-08 at 06:44 +0900, Yoshinori Yamakawa wrote:

I wrote a small patch for checking embedded profile . http://cue.yellowmagic.info/softwares/files/profile_status.diff

Example 1: Image has no profiles http://cue.yellowmagic.info/softwares/images/gimp_profile_status1.png

Example 2: Open the gray-scaled image that has "Dot Gain 15%" profile http://cue.yellowmagic.info/softwares/images/gimp_profile_status2.png

I don't quite understand what this patch is supposed to do. The display of color profile information in the Image Properties dialog is already there. What does your patch add? To me it looks like the dialog only becomes more confusing and misleading.

Sven

I am finding this thread to be confusing. In the Color Management section of the Preferences dialog there is a drop down to set the "File Open behavior" and the options are "Ask what to do", "Keep embedded profile" and "Convert to RGB workspace". Shouldn't this setting also affect the way files opened without an embedded profile work? If not then either is should be generalized to do so or another preference item for how to handle images with no profile should be added with similar options. that way the user will have control over how this behaves.

Hal

On Sun, 08 Feb 2009 17:39:38 +0100 Sven Neumann wrote:

I don't quite understand what this patch is supposed to do. The display of color profile information in the Image Properties dialog is already there. What does your patch add? To me it looks like the dialog only becomes more confusing and misleading.

I'm sorry that I can't explain in English very well.

See the following image: http://cue.yellowmagic.info/softwares/images/gimp_profile_status_comparison.png

In case of using the GIMP and any other softwares, handling the image without color profile is very important. Some software may handle it in the different workspace. Some software may handle it without color management. The behavior of the other software becomes unpredictable if the GIMP covers that the image doesn't have profile.

Hi,

On Sun, 2009-02-08 at 20:03 +0100, Martin Nordholts wrote:

I agree that someone should sit down and specify exactly how we want color management to work before doing major surgery.

Yes. We absolutely need a document that describes the workflows that are handled by the current implementation. Then we need some test images that can be used to verify that everything works as it is supposed to. Any volunteers?

However, reverting that commit is not major surgery and to me writing an sRGB profile in the absence of an embedded profile is just plain wrong. If something like that was supposed to done it should at least be the RGB profile selected in the Color Management preferences, but even doing that would be making hasty assumptions.

Well, choosing a working profile other than sRGB is totally unsupported and will definitely lead to bad results. But you are correct, the PNG plug-in is doing the wrong thing here and we should revert that change. Probably even in also in the gimp-2-6 branch.

Sven

Hi,

On Mon, 2009-02-09 at 05:52 +0900, Yoshinori Yamakawa wrote:

See the following image:
http://cue.yellowmagic.info/softwares/images/gimp_profile_status_comparison.png

In case of using the GIMP and any other softwares, handling the image without color profile is very important.

Ah, I think I understand now. The idea behind your changes is good and we should implement something like this for 2.8. But the wording you have chosen in your implementation is very misleading. "Untagged RGB" will be confused with tagging for data resources. We should better use a title like "No Embedded Color Profile". And the working space profile is not used "temporarily". We need to find a better phrase to describe that GIMP uses the default workspace profile due to the fact the the image has no embedded color profile.

Sven

On Tue, 10 Feb 2009 20:24:34 +0100 Sven Neumann wrote:

"Untagged RGB" will be confused with tagging for data resources. We should better use a title like "No Embedded Color Profile".

"Untagged" is used in Adobe Photoshop. I think that the other phrase may be used, but, individually, I wants more short phrase.

And the working space profile is not used "temporarily". We need to find a better phrase to describe thatGIMP uses the default workspace profile due to the fact the the image has no embedded color profile.

I think that is "temporarily" *for the image*. The image and a workspace are less related by the GIMP. After editing the image, that relation will be lost. When re-opening the image with the GIMP, the image will be related with the workspace that specified at the time.

If I use the other phrase, it is as follows:

"GIMP assumes that "Adobe RGB (1998)" (workspace profile) is embedded."