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

[Gez <listas ohweb com ar>]

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.