El mié, 12-03-2014 a las 23:35 -0400, Liam R E Quin escribió: > [ resending this to the list, at Gez's request :) ] Sorry for the accidental private mail :) > > 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. Notice that I'm talking about processing only. The output bitdepth should be the usual for each file format (for instance, although commercial RIPs no longer choke with 16bpc files, it's still recommended to send 8 bit and probably sending more won't make any difference, at least for offset). > > > 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. Why? Again, processing in high bit depth, soft-proofing against the target colorspace, saving to the destination bitdepth and profile. The "project" file keeps data and color latitude, the exported files are converted to the desired parameters. You can do exactly that with Blender's compositor, and it can save JPGs or PNG for the web. If an 8-bpc buffer can be displayed, the it's probably possible to generate an indexed projection on the fly, pretty much like gimp-2.9 does now. Gez. _______________________________________________ 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
