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

[Liam R E Quin <liam holoweb net>]

[ 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
> purpose.

[...]

> 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
> completely.
> 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
http://www.fromoldbooks.org/DehioBezold-Kirchliche/pages/001-600dpi/
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.

Yes.

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml