[ 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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
