3 ms·

> GIMP 3.0 supports palettes outside of the "Standard Red Green Blue" (sRGB) range, such as "Cyan Magenta Yellow Key" (CMYK) and (CIELAB). This expanded color s

> GIMP 3.0 supports palettes outside of the "Standard Red Green Blue" (sRGB) range, such as "Cyan Magenta Yellow Key" (CMYK) and (CIELAB). This expanded color support, especially for CMYK, is essential to those who work with print and desktop publishing. However, GIMP continues to use sRGB, grayscale, and indexed colors for storing color information internally for now. Conversion to other color spaces is done on output, where necessary. The wording here is confusing, because it makes it sound like CMYK/CIELAB will only be applied at the very end of the image transformation pipeline. That would really limit the usefulness of adding these extra color spaces, since doing the manipulation in a different color space than RGB is often the point. But the linked blog post on GIMP.org[0] words it a little differently: > What it means for color correctness in particular is that we will now do color conversion only when needed (last-second conversion) and therefore won’t lose information when it could have been avoided. For instance, say you color-pick color from an image: if we were to convert to an intermediate format, before using it on a second image (which may or may not be in another color format), we’d do 2 conversions. Which means more possibility of precision loss. The issue is even more flagrant if the input and output formats are the same (i.e. no conversion should happen at all). And this will be even more a problem when we will have core CMYK backend (we really want to avoid doing a round-trip to an intermediate format with CMYK, which doesn’t have bijective conversion with most other color models, even when working unbounded and ignoring precision issues). That sounds more like the information of the original color space will be kept as well, and transformations will be applied only when necessary, to avoid lossy roundtrips. Which is not quite the same. [0] https://www.gimp.org/news/2024/02/21/gimp-2-99-18-released/#color-space-invasion https://www.gimp.org/news/2024/02/21/gimp-2-99-18-released/#...

chongli 2y ago
This doesn’t make any sense to me. If I have 2 CMYK images open I should be able to colour pick and copy/paste between them and do any other sorts of manipulations with them without any colour space conversions taking place. The only colour space transformation that should happen when working with a CMYK image is when the image is displayed on screen. The CMYK data is interpreted with the attached colour profile (perhaps provided by the commercial printer I’m using) and then the colours are converted to RGB via my monitor’s profile and displayed on screen. None of these converted colours are ever saved in the file, and they need to be updated whenever any part of the image is altered (say using a dirty region -> repaint system). Now if I do happen to open both a CMYK image and an RGB image and then try to copy and paste part of the RGB image into the CMYK one then a one-time conversion to CMYK needs to take place. Otherwise if I’m working only with CMYK images then no conversions should take place. It sounds to me like the GIMP may have been written so that all of its operations are specialized to work with RGB pixels and so they cannot implement native editing on CMYK images without doing round trip conversions all over the place? If that’s the case then they need to buckle down and do the hard work of rewriting everything to be colour space independent. I also want to note that Photoshop added CMYK support in version 2.0 which was released in 1991. This was before they even added layers! Photoshop was essentially designed for print almost from the very beginning. Having all the colour space stuff figured out before adding huge numbers of features was a major advantage. Trying to retrofit CMYK support into the GIMP seems like a bit of a nightmare.
- cmyk_student 2y ago
  Hi! That's actually what we were doing for GIMP 3.0. Originally, GIMP stored pixels in structs that just contained the pixel values (like GimpRGB's r, g, and b values). Now all pixel data is stored in GeglColor objects, which contain the color model, space, and profile information in addition to pixel values. So you can just request, say, the 8bit CIE LAB or 16bit CMYK version of the pixel and retrieve it from the object. I made a proof-of-concept CMYK mode for GIMP before this conversion was done - it would be even easier now. I hope to return to it and implement in GIMP proper in a near future release.
  - vanderZwan 2y ago
    You might want to send in a correction to the LWN article then, since the wording there is giving the wrong impression. Good luck with the implementation of CMYK mode, I'm certain it will make GIMP a lot more attractive to many users! (are CieLab and OKLab also being considered?)
    - cmyk_student 2y ago
      Yep - in fact, when discussing the idea for CMYK mode it was brought up that we should make it flexible for CieLab and other color modes. Unless someone beats me to it, I'll likely try to make a merge request with CMYK mode first, then use it as a reference commit for implementing other color models.

chongli 2y ago

This doesn’t make any sense to me. If I have 2 CMYK images open I should be able to colour pick and copy/paste between them and do any other sorts of manipulations with them without any colour space conversions taking place. The only colour space transformation that should happen when working with a CMYK image is when the image is displayed on screen. The CMYK data is interpreted with the attached colour profile (perhaps provided by the commercial printer I’m using) and then the colours are converted to RGB via my monitor’s profile and displayed on screen. None of these converted colours are ever saved in the file, and they need to be updated whenever any part of the image is altered (say using a dirty region -> repaint system). Now if I do happen to open both a CMYK image and an RGB image and then try to copy and paste part of the RGB image into the CMYK one then a one-time conversion to CMYK needs to take place. Otherwise if I’m working only with CMYK images then no conversions should take place. It sounds to me like the GIMP may have been written so that all of its operations are specialized to work with RGB pixels and so they cannot implement native editing on CMYK images without doing round trip conversions all over the place? If that’s the case then they need to buckle down and do the hard work of rewriting everything to be colour space independent. I also want to note that Photoshop added CMYK support in version 2.0 which was released in 1991. This was before they even added layers! Photoshop was essentially designed for print almost from the very beginning. Having all the colour space stuff figured out before adding huge numbers of features was a major advantage. Trying to retrofit CMYK support into the GIMP seems like a bit of a nightmare.

cmyk_student 2y ago
Hi! That's actually what we were doing for GIMP 3.0. Originally, GIMP stored pixels in structs that just contained the pixel values (like GimpRGB's r, g, and b values). Now all pixel data is stored in GeglColor objects, which contain the color model, space, and profile information in addition to pixel values. So you can just request, say, the 8bit CIE LAB or 16bit CMYK version of the pixel and retrieve it from the object. I made a proof-of-concept CMYK mode for GIMP before this conversion was done - it would be even easier now. I hope to return to it and implement in GIMP proper in a near future release.
- vanderZwan 2y ago
  You might want to send in a correction to the LWN article then, since the wording there is giving the wrong impression. Good luck with the implementation of CMYK mode, I'm certain it will make GIMP a lot more attractive to many users! (are CieLab and OKLab also being considered?)
  - cmyk_student 2y ago
    Yep - in fact, when discussing the idea for CMYK mode it was brought up that we should make it flexible for CieLab and other color modes. Unless someone beats me to it, I'll likely try to make a merge request with CMYK mode first, then use it as a reference commit for implementing other color models.