GNOME.org
 

[gimp-web] content: update the CMYK GSoC news.

commit e3886ee3f27f94ce54390442600fe4a7df1f5f11
Author: Jehan <jehan girinstud io>
Date:   Mon May 30 16:20:13 2022 +0200

    content: update the CMYK GSoC news.
    
    - Remove several wording where it feels like we were nearly against CMYK
      core support ("reluctant", "can't bring ourselves to recommend"). I
      can't say before 2012, but in the last 10 years, I only saw people
      interested, simply it was not a priority and truth is that many
      printing projects can be very safely worked in RGB (and possibly moved
      to CMYK in the end, with software like Scribus). It doesn't mean devs
      were reluctant. :-)
    - I'm not so sure if we can really say we revised the anyRGB plan. For
      me, it seems the idea was always to be as generic as possible (hence
      GEGL supporting CMYK now!) and saying "anyRGB" was more of a shortcut
      since GIMP only supported RGB (+ grayscale and indexed of course) so
      far. But sure. At least, let's remove the "recently" as we have been
      talking of adding CMYK core support for years now.
    - More accurate listing of file format support improvements in progress.
    - Adding the "moving the soft-proof profile into image data" part as
      it's a pretty big deal in the grand scheme.
    - Adding more "generic" talk.
    - In the end, open the discussion to spot colors, which is once again
      another "genericity" need of our upcoming implementation and which has
      been discussed on IRC. The idea is really not that we want to become a
      CMYK and RGB editing software. The idea is instead that we need to
      have a robust core, generic enough to be able to adapt to much more
      models (without each time rewriting all core code and a minimum of
      special-casing!).

 .../2022-05_CMYK-features-in-GSoC-2022/index.md    | 139 ++++++++++++++++-----
 1 file changed, 105 insertions(+), 34 deletions(-)
---
diff --git a/content/news/2022/2022-05_CMYK-features-in-GSoC-2022/index.md 
b/content/news/2022/2022-05_CMYK-features-in-GSoC-2022/index.md
index ac452bfc..44d65258 100644
--- a/content/news/2022/2022-05_CMYK-features-in-GSoC-2022/index.md
+++ b/content/news/2022/2022-05_CMYK-features-in-GSoC-2022/index.md
@@ -12,10 +12,11 @@ more detail.
 
 ## What's up with GIMP and CMYK anyway?
 
-Historically, we've been reluctant to implement CMYK support in GIMP as the
-program used to be hardwired to use sRGB color space for pretty much
-everything. Supporting any RGB color space is still work in progess, and print
-has been a mostly unknown territory for the project for decades.
+Historically, it was complicated to implement CMYK support in GIMP as
+the program used to be hardwired to use sRGB color space for pretty much
+everything. Supporting any RGB color space has been work in progress for
+many years, and print was not facilitated as a main workflow provided by
+our project for decades.
 
 Since late 2000s, we've been considering a late binding workflow for CMYK,
 i.e. where you work in RGB, softproof in CMYK and then export to CMYK. Peter
@@ -24,16 +25,17 @@ plan](http://blog.mmiworks.net/2009/05/gimp-enter.html) for that, but the
 image processing engine was missing the required changes, and someone would
 have to work on exposing everything in GUI.
 
-We ultimately lacked contributors to do that ourselves, and [one
-patch](https://gitlab.gnome.org/GNOME/gimp/-/issues/356) we got from a
-contributor some years ago couldn't be merged for architectural reasons, it
-had to be redone completely to play well with the rest of GIMP's code.
+We ultimately lacked contributors interested into prioritizing that, and
+[one patch](https://gitlab.gnome.org/GNOME/gimp/-/issues/356) we got
+from a contributor some years ago couldn't be merged for architectural
+reasons, it had to be redone completely to play well with the rest of
+GIMP's code.
 
 A few years back, Øyvind Kolås finally [added the missing
 bits](https://www.patreon.com/posts/cmyk-progress-22901518) to GEGL, our image
 processing engine, that made it possible to do things like blending a CMYK
-image with an RGBA image and the writing the result as a TIFF CMYK file. This
-paved the way to this particular GSoC project.
+image with an RGBA image and writing the result as a TIFF CMYK file.
+This paved the way to this particular GSoC project.
 
 ## What is the objective of the GSoC project?
 
@@ -46,32 +48,95 @@ images in a CMYK color space and convert them to RGB(A) for viewing and
 editing. You will also be able to export images to CMYK. We are currently
 targeting TIFF, PSD, PDF, EPS, AI, and PDF file formats.
 
-While we can't bring ourselves to recommend editing CMYK images in a
-non-native color space, being able to both open (if only to view) and export
-CMYK data is clearly a step forward.
-
-Here is the current progress:
-
-- CMYK PSD CMYK loading has already been available since GIMP 2.99.10 thanks
-to Jakob Boerema, the code will be updated by Nikc for 2.99.12.
-- CMYK JPEG loading and exporting is done and will be available in GIMP 2.99.12
-thanks to Jehan Pages.
-- CMYK TIFF loading and exporting is a work in progress by Nikc and might be
-available in GIMP 2.99.12 (no promises on that yet).
+While you won't be able to edit CMYK images in a non-native color space
+yet, being able to both open (if only to view) and export CMYK data is
+clearly a step forward. Moreover while working with a CMYK backend is
+useful for some use cases (controlling your black colors or other
+accurate color mix as per printer instructions, ink coverage, trapping,
+overprinting and whatnot), working with \*RGB images, then moving
+to CMYK in the end, is still a recommended workflow for many types of
+works. For instance, graphics professionals in the GIMP team and around
+worked with a lot of success with a mix of GIMP and
+[Scribus](https://www.scribus.net/), which is a software we warmly
+recommend.
+
+Here is the current progress regarding CMYK support in file formats:
+
+- JPEG:
+    * CMYK JPEG loading has been supported in GIMP for many years.
+    * CMYK JPEG loading has been recently ported to using `babl` for
+      conversion by Jehan Pagès.
+    * CMYK JPEG exporting has been implemented as well by Jehan Pagès.
+    * These new support will be available in upcoming GIMP 2.99.12 and
+      were implemented as a demonstration sample for Nikc since
+      [Jehan](https://film.zemarmot.net/) is the project mentor.
+- PSD:
+    * CMYK PSD 8-<abbr title="Bit per Channel">bpc</abbr> CMYK loading
+      has already been available since GIMP 2.10.18 thanks to Massimo
+      Valentini.
+    * The code has been updated by [Jakob Boerema](https://www.jacobboerema.nl/en/)
+      to load 16-<abbr title="Bit per Channel">bpc</abbr> CMYK PSD files
+      in GIMP 2.99.10.
+    * Work is in progress by Nikc to port CMYK PSD load code to use the
+      `babl` library for conversion (should be available for 2.99.12,
+      provided it passes review).
+    * Exporting CMYK files in the PSD format could also be within the
+      scope of this GSoC project.
+- TIFF:
+   * CMYK TIFF loading and exporting is a work in progress by Nikc and
+     might be available in GIMP 2.99.12 if it passes review on time.
+- Other formats with CMYK support will be considered.
 
 **A new dockable dialog for color management**. To aid the late binding
-workflow, Nikc will develop a new dockable dialog to convert between color
-spaces via ICC profiles, control soft-proffing etc. This is the next step
+workflow, we need to be able to easily switch soft-proofing (simulating
+the CMYK result). Right now switching it ON/OFF and choosing profiles is
+done through menus which is cumbersome.
+
+Nikc will develop a new dockable dialog to convert between color
+spaces via ICC profiles, control soft-proofing, etc. This is the next step
 after CMYK support in various file formats. We'll feel comfortable talking
 about this more once it's being actively worked on.
 
+**Soft-proof profile(s) as first-class citizen**: currently the
+soft-proof profile is attached to the view, which means it disappears
+and needs to be set up again in-between sessions. Also the selected
+profile is not available to plug-ins which makes our CMYK export
+capabilities much less interesting until it gets implemented. This is
+why we want to move the soft-proof profile to become an image data
+instead, which will be stored in the XCF file. Nikc announced to have
+already started to work on this.
+
+Discussions are ongoing to make this change generic to allow storing
+even several simulation profiles in the long run. This will make sense
+in particular when GIMP will support the concept of multiple export
+targets, as was [theorized in an early blog
+post](https://girinstud.io/news/2015/09/improving-the-export-process-in-gimp/).
+Indeed a single image can be targetted differently for low-quality web
+previewing, for high-quality digital viewing, for printing… And it can
+even have different print targets. This is not in the scope of this GSoC
+project but are things we need to take into account early on when
+modifying the core code.
+
 **Identifying and fixing issues with color management**. There are still all
 sorts of bugs and imperfections in GIMP's color management implementation. We
 already know about some of them and we have no doubt that others will manifest
-themselves as the work on this GSoC project continues. So fixing those is
-definitely part of the project. One such example is [porting the CMYK color
-selector](https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/633) to using
-[babl](https://gegl.org/babl/).
+themselves as the work on this GSoC project continues. Among the obvious
+areas to look on in details are: color picking and [sample
+points](https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/589),
+[color
+selection](https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/633),
+soft-proofing, various types of previews, maybe improved ways to work on
+specific color channels…
+So fixing or improving those is definitely part of the project. As you
+can see from the links above, work has already been started on some of
+these areas, and porting more code to using
+[babl](https://gegl.org/babl/) for streamlined conversion is a big part
+of the project.
+
+Note that all improvements are not necessarily about CMYK-only in the
+end, since we have been working to make our color code more generic,
+which means that some changes may need to happen on a lower level, hence
+enhancing the workflow, efficiency and accuracy with any color model.
 
 ## When are we shipping the results of the GSoC project?
 
@@ -82,13 +147,19 @@ this spring/summer to be part of GIMP 3.0.
 
 The short answer is 'eventually'.
 
-Previously, we talked about anyRGB approach to editing that was within the
+Previously, we talked about *anyRGB* approach to editing that was within the
 scope of the Space Invasion initiative (end-to-end ICC profile attribution for
 an image while passing it through various operations in the node composition).
-Essentially, you should be able to open an image in e.g. AdobeRGB color space
-and never convert it to e.g. sRGB unless a particular GEGL operation requires
+Essentially, you should be able to open an image in e.g. *AdobeRGB* color space
+and never convert it to e.g. *sRGB* unless a particular GEGL operation requires
 that.
 
-We recently revised the anyRGB plan to extend it to anyModel (RGB, CMYK, LAB
-etc.). This is going to be a major undertaking, we do not expect to ship this
-in v3.0 and we'd rather not give any estimations at this time.
+We revised the *anyRGB* plan to extend it to *anyModel* (RGB, CMYK, LAB
+etc.). This is going to be a major undertaking, we do not expect to ship
+this in v3.0 and we'd rather not give any estimations at this time.
+
+Even staying within the scope of the printing world, hardcoding the CMYK
+model would make no sense. Instead what if you could also add spot color
+channels for instance? This is the direction we are heading to and the
+result of the groundwork which has been slowly built up for many years
+now.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]