El jue, 13-03-2014 a las 02:36 -0400, Liam R E Quin escribió: > > > > 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. > > > 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... Ok, so the problem is indexed images. How does it work now in 2.9? Is it really 8 bpp or is it 8bpc and the projection is converted to indexed? I found these articles (maybe outdated) that seem to imply the latter: https://lwn.net/Articles/497132/ "Because GEGL operations are defined on abstract buffers, adding support for an entirely different image format is a matter of writing a new format for babl, the underlying pixel transformation layer. During the GEGL hack-a-thon, Kolås wrote such a back-end for indexed color images (such as you find in the GIF format). Natterer had originally planned to drop support for indexed images, but with the babl format defined, they work just as well as any other format in the GEGL-ified GIMP. GEGL also allows GIMP to use all sorts of painting and filter operations on indexed images (such as smudging and blurring) that are typically not possible on indexed color." http://blog.mmiworks.net/2009/06/gimp-squaring-cmyk-circle.html "The core of the solution model is that this projection is again a surface, that can be worked on, to make the corrections that are specific to this indexed set‑up. The non‑destructive nature of GEGL makes it possible to reapply these corrections after more creative development, or to adjust them at a later stage." What I'm saying isn't very different than developers already said: https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html I'm just presenting a case for a simplified workflow that could cover the same possibilities without a lot of modes and options that could lead to unintended screwups. > GIF89a doesn't seem to support embedded ICC profiles, by the way ;) Untagged images for the web are always assumed as sRGB, and I'd say that if you use any other profile you should tag them so CM takes care of the proper color transforms. Untagged images in an unknown colorspace are one of the nasty consequences of an inefficient color workflow that made the hideous command "assign profile" necessary in the first place. _______________________________________________ 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
