Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:

There are three possible workflows for print:
Early binding: All the assets are converted to CMYK and editing is done
in CMYK. The files you send to the print shop are CMYK.
Late Binding: Everything is worked in RGB. The print shop converts to
Intermediate Binding: Creative work is done in RGB, the files are
converted to CMYK prior sending them to the print shop.

GIMP can't edit CMYK directly, but it can serve to the other two
possible workflows.

Note that the case I mentioned the other day as seeming to be out of
scope is when you *are* the print shop, and you (sometimes) receive the
cmyk files, or need to edit them. E.g. remove an impression number from
the imprint page and then send to imposition... but it seems it's in
scope and just not there yet.


Having the title/status bar(s) show which display filters are active 
would be very useful, especially given that if you close the display 
filter window, any activated filters (or deactivated, in the case of the 
Color Management filter) are still applied to the image.

That would be an interesting addition, but I wonder if the current model
of having multiple "working profiles" can't be replaced by something
more useful.
This is probably off-topic, but having to worry about the file profile,
a working profile, a print preview profile and a print profile in the
preferences as global settings seems messy and inefficient. And in GIMP
2.9 it probably doesn't make so much sense as it used to.

The world is messy, I'm afraid.

From a user point of view having all the imported stuff converted
automatically to a high quality internal model (high bit depth linear
scRGB?) and having per-image output/proof settings seems more
straightforward and less error prone than the current mixture of

Are you going to pay for the extra memory I'll need? I only have 32G and
already with 2.9 I sometimes am swapping.

It may or may not be a problem for keeping legacy compatibility, but I
can imagine how simplified the UI and common workflows would be (no
bit-depth "modes", no assign/convert to profile, no profile-mismatch
warnings, simplified CM preferences, etc).

You might not always be able to do round-tripping, because a colour in
the input image's colour model might be out of gamut for the working
profile. I don't know how big an issue that would be. Similarly you'd
end up using colours that wouldn't come out at all right on your output
device. The warnings are there for a reason...



Liam Quin - XML Activity Lead, W3C,
Pictures from old books:
Ankh: freenode/#xml

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]