Currently upstream only supports RGB or Greyscale colourspaces. If you try to open a PSD file with CMYK colours the application will refuse to do so.
Either include a plug-in that supports this or allow CMYK images/PSD files to be opened, edited & saved.
There are plug-ins that do conversions, but this is not quite the same.
Being able to work with the CMYK colourspace is required for professional image editing work. If this is not present then a case can still be made to continue using commercial alternatives instead.
I believe Krita supports this, so we could look at how they do it.
We may be able to fix this by pre-bundling a plug-in if the license permits it: https://wiki.archlinux.org/index.php/GIMP/CMYK_support
Apparently this may have been implemented at GEGL level, so might appear properly in a future version of upstream: https://www.patreon.com/posts/22901518
FWIW, Separate+ (one of the plugins which supports this referenced on the is GPLv2+ licensed. I think GEGL support would be better though, since it'd be fully integrated, rather than sort of tools for sort of doing it.
Apparently this is also being tracked on upstream gitlab, but no new solutions or planned release as yet: https://gitlab.gnome.org/GNOME/gimp/issues/52
I have received confirmation from upstream that CMYK colour space support has been implemented now in the GEGL and BABL subcomponents. It has also been enhanced to support blending of CMYK/RGB data and read/write TIFF and JPEG files using the CMYK colour space.
There is no timeline on when it will be implemented in the UI as yet. My guess is it will probably arrive after version 3.0, and around the same time as non-destructive editing.
Upstream update for CMYK PSD support: https://gitlab.gnome.org/GNOME/gimp/issues/354
Apparently this will be fixed in the GNU Image Manipulation Program 2.10.20.
I have set the milestone for this to 0.2.0, as that will be the release when we rebase on that version.
We're actually basing on 2.10.18 but using the newer BABL and GEGL bindings. We should take some time to review whether it's possible to backport those changes.
May bring into 0.2.2 if we can backport changes. Otherwise they'll be added when we next do a big rebase in July 2021.
Most helpful comment
Apparently this will be fixed in the GNU Image Manipulation Program 2.10.20.
I have set the milestone for this to 0.2.0, as that will be the release when we rebase on that version.