On Thu, 2014-03-13 at 01:19 -0300, Gez wrote: > El mié, 12-03-2014 a las 23:35 -0400, Liam R E Quin escribió: > > > 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. Because for 256-colour GIF animations you are forced to care about individual pixel values, and use indexed-mode colour with a fixed palette. (strictly speaking GIF can handle higher bit depths too, but for widest distribution you have to keep it simple). GIMP has the GIMP Animation package to help people make animated GIFs so it has quite a following. For JPEG and PNG, maybe it's OK in most cases, but "soft proofing" isn't the same as "you edit what you will use". . > 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. Yes, although 8-bit GIF is not 8 bit per channel but 8 bit for all three channels, so you really care about which colours are allocated. Like, a lot. Anyway, we'll see how it turns out. GIF animations of kittens might not actually be in GIMP's primary use case market... GIF89a doesn't seem to support embedded ICC profiles, by the way ;) -- 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
