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

[ resending this to the list, at Gez's request :) ]

On Wed, 2014-03-12 at 17:43 -0300, Gez wrote:
El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió:
On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:

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.

You're right, there's no free software tool fully capable for that


I'm curious to know how many print shops would consider using GIMP if it
had native CMYK. I suspect that the majority of people ranting about the
lack of CMYK are mostly designers who know just one way to send stuff to
print shops, not print shops.

The print shops I know generally use either mac-based tools or
proprietary RIP systems, or (usually) both.

But the future is longer than the now.

Ok, good point. I missed the segment of users who work with huge scans
On the other hand, is 8-bit enough for the type of work you do?

I scan at 8bpp 2400dpi, or at 16bpp 1800 or 2100dpi right now; when I
scan an A3 page at 16bpp and 2400dpi, as I did for
as an experiment, Gimp quickly reached over 15G of memory, and I needed
to use "discard undo history" after every operation, so I quickly scaled
the image down. For the rest of that book I'll be scanning the
individual figures.

Like you, I do prefer the higher bit depths, so it's a compromise.


Anyway, rather than bitdepth, my comment was about giving the artists a
framework to create freely without worrying (much) about the constraints
of input/output colorspaces.
It's impossible to have that with 8 bpc. And correct me if I'm wrong,
but I suspect that using proofing filters on non-linear 8bpc carries a
lot of problems and the result can't be completely reliable.

No, I think it's probably fine. Most commercial RIPs these days deal
with at least 10 and more likely 16bpp.

Maybe we can have the flexibility and power just keeping two modes: 16
bit integer for memory-conservative tasks and 32 bit float for high
quality stuff.
That would rule out editing GIF animations and also make preparing
images for the Web or for use n mobile devices very hard.

[...] lots of good stuff deleted, because...

Anyway, this is just an idea. It's not a small change and I'm not
suggesting that it has to be done the way I said. I think this is an
interesting topic to discuss since seems more suitable for
non-destructive editing than the current approach.



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]