Some images don't have an embedded ICC profile. Those images by default are assigned either sRGB or a linear gamma version of sRGB. But sometimes the image isn't really an sRGB image. Sometimes it's the output of raw interpolation and has no embedded profile and needs to be assigned a camera input profile. Sometimes someone made a mistake and assigned the wrong profile using some other image editing software. Sometimes sRGB is embedded deliberately to sidestep limitations in some image processing software (such as raw processors that don't provide for raw color output). Sometimes the image is an exr image. Some exr images have chromaticity information embedded, from which krita should but doesn't seem to construct an on-the-fly profile other than linear sRGB. Sometimes the exr wasn't created in the sRGB color space but still doesn't have any chromaticity information, so again the ability is needed to be able to assign the right ICC profile. I stll think I might have missed the option somewhere in the krita gui, because the ability to assign an ICC profile is such an incredibly basic part of color management. Please note that converting from one ICC profile to another is not at all the same as assigning an ICC profile to an image. Conversion presumes the initial ICC profile is correct! Reproducible: Always Steps to Reproduce: 1. Open an image and look around for the part of the gui that allows to assign a new ICC profile. 2. Fail to find the part of the gui that allows to assign a new ICC profile. 3. Close krita in frustration. Actual Results: I resort to some command line program to assign an ICC profile to my image. Then I open the image again. If the image is an exr image I'm just out of luck because exr images don't allow embedding ICC profiles and I don't think krita reads embedded chromaticity information if there is any. Expected Results: There should be provision for assigning an ICC profile to an image, either because it doesn't have one and sRGB isn't the right profile to assign, or it does have one but it has the wrong embedded profile. And if krita can't already read exr chromaticity information and construct an appropriate ICC profile on the fly, that would be a nice additional functionality too. No additional information. Hopefully the actual problem is simple user error and I just don't know where to look for the "assign profile" part of the gui.
Profile can be changed under Image->Properties...
That did seem like the obvious place in the gui to assign a new ICC profile. But actually all it does is ***convert*** from the embedded or assumed profile (which is sRGB if there is no profile embedded) to the profile that is picked in the Image->Properties dialog. I just double-checked to confirm. Using Krita, I opened a tiff that improperly had the sRGB profile embedded and I changed the Image->Properties->Mode->Profile to the appropriate ICC profile. Krita converted from the embedded profile to the new profile. It didn't assign the new profile. Convert and assign are completely different operations. "Convert" changes the RGB values while preserving the XYZ values to the extent possible given any color gamut mismatches between the source and destination ICC profiles. "Assign" keeps the RGB values the same and reinterprets their meaning in XYZ space according to the newly assigned ICC profile.
Well... It seems to be more complicated than that: void KisImageManager::slotImageProperties() { KisImageWSP image = m_view->image(); if (!image) return; QPointer<KisDlgImageProperties> dlg = new KisDlgImageProperties(image, m_view); if (dlg->exec() == QDialog::Accepted) { image->convertProjectionColorSpace(dlg->colorSpace()); } delete dlg; } This calls KisImage::convertProjectionColorSpace, which calls KisImage::setProjectionColorSpace, which sets the colorspace of the image to the new colorspace (combination of color model and profile), but which does not actually convert pixels in any of the layers.
To be more specific: "convert" in Krita creates an lcms transform and applies to the pixel data in all layers. "Assign" sets a new colorspace for the image, then updates the projection. That means in practice that the layer data is converted to the image colorspace before composing the layers. The layers themselves are untouched.
Boudewijn's description of "assign" coheres with what I would assum would happen. However I assure you that when I (tried to) assign a new ICC profile to an image (Image->Properties->Mode->Profile and choose a new profile from disk), the image was actually converted from the old profile to the new profile. The colors, which were wrong in the first place, continued to be wrong. When I saved the image to disk, exiftool showed that the new profile had been embedded. But as the colors remained constant, clearly the RGB values had changed. Assigning the proper color profile in Cinepaint and Gimp makes the colors on the screen immediately change. Not so with Krita. I thought perhaps there was a delay in redrawing the screen, so I closed and reopened Krita and then opened the "was it converted or was it assigned" image again. The colors were still wrong, even though the new profile had been embedded. I opened this image with Cinepaint and Gimp to confirm: new profile, wrong colors. What krita did was convert, not assign. Perhaps I don't know how to use (Image->Properties->Mode->Profile) to assign a new profile? Is there a step I'm missing?
Well, what happens is that the projection of the image is created again, and if you export to tiff, it's the projection that is saved, not the pixel data of the layer. This is getting complicated... So, on loading an image with one layer, we create a new new image with that layer. The layer and the image pixels are shared, because there is one layer and the image and the layer have the same colorspace. Then we change the colorspace of the image. This means that the layer no longer is in the image colorspace and we create a projection, and compose the layer data onto the projection. This involves first converting the layer data on the fly to the image colorspace. Then on export, we save the projection pixels to the tiff image -- and those are converted, of course. I'm not sure what the right approach here is, right now :-(
> Then we change the colorspace of the image. This means that the layer no longer is in the image > colorspace and we create a projection, and compose the layer data onto the projection. > This involves first converting the layer data on the fly to the image colorspace. Then on export, > we save the projection pixels to the tiff image -- and those are converted, of course. So if I understand correctly, 1. Image->Properties->Mode->Profile and picking a new ICC profile actually "Convert[s] projection color space] (quoting what the undo/redo button shows). The net result of this operation is that the image as seen on the monitor has been converted from the source to the destination color space, and the actual image is converted upon saving. Perhaps this option could use a new gui label to make it clear what's really happening? Perhaps "Convert image projection color space"? 2. And "Image->Convert Image Color Space" converts the image AND the projection, so the actual image has already been converted by the time the image is saved. 3. Neither option allows the assignment of a new ICC profile to the image. Two questions: First, what two different usage scenarios are served by the existing two different ways of converting an image from one color space to another? In other words, what is the practical difference in the resulting image and/or editing options available to the user when following the first conversion option versus the second conversion option? What's the point of converting the image projection color space without also converting the image itself, given that the image itself is also converted to the image projection color space upon saving to disk? Second, could a third, new option be added to the krita interface to actually assign a new profile and then update the projection to match the newly assigned profile? As an aside, some applications use the terminology "assume a new profile" instead of "assign a new profile"; but trying to make "assign" and "assume" mean two different things in the user gui strikes me as asking for user confusion. I think "assign" is a better choice than "assume" for this third user option. Also, digiKam/showfoto allows the user the option to assign a new ICC profile, but apparently only upon first opening the image. This is not a good approach. The better approach, and the one followed by Cinepaint, Photoshop, Gimp (at least to date, not sure what direction the Gimp developers are going), is to allow the assigning of a new profile at any time. With the digiKam approach, if you pick the wrong profile to assign, your only option is to close the image and reopen it. And also, sometimes the user deliberately wants to assign a new ICC profile to an image that technically already has the correct profile, to change the look of the image. "Look" profiles that add or subtract saturation or change the tonality of an image are easy to create with Argyllcms by manipulating the target shot. And there are "look" profiles available commercially, which can't be used without the ability to assign a new profile to the image.
The inability to assign the correct profile to an image can be worked around for most file formats, simply by making sure the correct profile is embedded before opening it with Krita. However, currently there is no way to embed an ICC profile in an OpenEXR file. So the only OpenEXR files that can be correctly opened and displayed with Krita are linear gamma sRGB files. This severely limits the usefulness of Krita's otherwise very nice ability to work with OpenEXR files.
Hm... I'm not sure that icc profiles make a lot of sense with openexr files. OpenEXR usually is 16f or 32f and used together with opencolorio. In that case, the icc profile associated with the image is not used at all.
People who use ICC profile color-managed editing applications have been asking OpenEXR to provide support for ICC profiles for a long time: Older threads: https://lists.nongnu.org/archive/html/openexr-devel/2005-11/msg00017.html https://lists.nongnu.org/archive/html/openexr-devel/2012-11/msg00002.html Newer thread: http://lists.nongnu.org/archive/html/openexr-devel/2013-07/msg00031.html http://lists.nongnu.org/archive/html/openexr-devel/2013-07/msg00032.html OpenEXR is just a data container and neither chromaticities nor linearity of the RGB data is enforced in any way. It's up to the user to know how to properly interpret the data. RGB data stored in the OpenEXR data container doesn't need to be encoded using the sRGB primaries. It also doesn't need to be encoded linearly. See msg00032 above, which mentions "If a user wants to store Rec709 data in an EXR, I'm not going to stop them. I know of at least one major studio that does this". Darktable can export OpenEXR data that's encoded using any ICC profile the user chooses, including nonlinear ICC profiles, and RawTherapee is working to add OpenEXR support. It would be nice if Krita could allow the user to assign an ICC profile to OpenEXR files in order to properly interpret OpenEXR files that were exported by other ICC profile color managed image editors. Most people currently using OpenEXR are indeed manipulating linear gamma data. But that's because most people currently using OpenEXR aren't using photographic editing applications. Instead they are working with HDR scene-referred data. While editing photographic images I routinely switch between working with linear and nonlinear data, depending on the editing task at hand. I realize Krita's main focus isn't photographic images, but the line between photographic image processing and digital painting is pretty blurry.
WISHGROUP: Larger Usability Fixes
Created attachment 103692 [details] 2017-01-29 - git diff of the proposed fix changes The patch adds proper change without conversion behind the color space and profile in the "Image properties" dialog (v.3.1.88). Done through adding actual calls to setProjectionColorSpace() and assignImageProfile() for a given image.
Phabricator URL for the patch - https://phabricator.kde.org/D4328
Git commit 4763f5e524c0cc08f38dae4b1a89d28a2649a985 by Albert Astals Cid, on behalf of Dimitar Dimitrov. Committed on 26/02/2017 at 23:54. Pushed by aacid into branch 'master'. Proper change of color space and profile for image through "Image properties" dialog Differential Revision: https://phabricator.kde.org/D4328 M +1 -0 libs/image/commands/kis_image_set_projection_color_space_command.cpp M +1 -0 libs/image/kis_image.cc https://commits.kde.org/krita/4763f5e524c0cc08f38dae4b1a89d28a2649a985