GNOME Bugzilla – Bug 640613
support for exporting CMYK TIFF format
Last modified: 2018-05-24 12:56:05 UTC
Created attachment 179351 [details] [review] add CMYK TIFF exporter plug-in I think that the separate+ plug-in is not proper for the GIMP distribution because the separate+ plug-in has unnecessary features for general users and the separate+ workflow is not very seamless. I wrote the subset version of separate+ (named separate-) as a GIMP file plug-in. Separate- is the CMYK TIFF exporter and is very simple to use.
Putting on 2.8 so we don't forget to look closer at this, would be nice to have this in 2.8 IMO.
I will try to add support for JPEG/PSD format into the separate-.
Created attachment 183234 [details] [review] add CMYK file export plug-in I added support for JPEG and Photoshop PSD formats into separate-.
We desperately need to get 2.8 out, let's look at this for 2.10 instead
Hey all, There is a patch, and apparently one of interest. Unfortunately it does not apply anymore against master (4 year-old patch!). But I guess we are still interested into it, no? Shouldn't we have a look at it? Yoshinori > if you are still around, would you be kind enough to update your patch against current GIMP master? Thanks!
Created attachment 338738 [details] [review] add CMYK file export plug-in update for 2.10
Created attachment 338739 [details] [review] add CMYK file export plug-in Sorry, I made a mistake.
Thank you! The patch applies cleanly, and GIMP builds fine. A quick note. When a preferred ICC profile for CMYK is not set, the plug-in says: "Could not save '$PATH/image.tif': Destination profile cannot be loaded or is not CMYK profile. Please check the color management preferences." We don't use the term "destination profile" currently, we call it "preferred ICC profile". Should the plug-in call it that way as well? I'm not sure. What are your opinions? Also, the plug-in appears to read both preferred ICC profile and rendering intent from the settings (which is great!), but doesn't make it possible to choose a different profile or a different rendering intent on per-image basis at the export time (without changing global preferences before that). Is that intentional behavior? I'm not sure myself, that's why I'm asking :) Overall, I'm very happy that this is about to be resolved, even though it's one of the first steps to what we want GIMP to be able to do with CMYK :)
Sorry, but I don't think this is about to be resolved :( This plug-in duplicates all the saving code for the supported file formats, instead of adding YMCK saving support to the existing format plug-ins.
Review of attachment 338739 [details] [review]: The configure.ac check is not needed, btw - all of the libraries involved are hard dependencies now.
How many years you need, when you reach a consensus? Can it be so dramatic? I do not believe that you have something to do.
Yoshinori > would it be possible for you to update your patch following review from Mitch on comment 9? Basically don't create this new plugin, but simply add CMYK support into each plugin for the formats you want to have supported (TIFF, jpeg and PSD, isn't it?). Duplicating saving code for every format would be a maintenance nightmare since we'd have to port every change on these formats in 2 places. That would be awesome. Thanks! :-)
Putting back to 2.10 milestone. We decided to simply put the very import bugs as blockers. Anything non-blocker have simply very few chances to make it unless someone decides to give it an importance (by working on it and providing working patches).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/356.