[Gimp-developer] GIMP's future internal image data format

[Martin Nordholts <enselic gmail com>]

I don't want to hijack Alexandre's thread with the interesting
discussion that started therein, so here's a new thread for it.

2012/1/27 Bogdan Szczurek <thebodzio gmail com>:
> W dniu 12-01-27 10:16, Alexandre Prokoudine pisze:
>> On Fri, Jan 27, 2012 at 11:01 AM, Martin Nordholts wrote:
>>> Images shall always be composed in 32-bit floating point
>>> RGBA
>
> Which RGB? Is it scRGB of GEGL "guts"? :)

Hi thebodzio

In the end, yes, GIMP's native image data format will likely be 32 bit
floating point per component/channel, pre-multiplied linear light RGBA
with the same primaries and white point as scRGB (and consequently
sRGB).

>>> and then have suitable filters and export mechanisms to deal with
>>> grayscale and indexed images.
>
> …and 16 bits per channel… and 8 bits per channel… and bitmaps (1 bit)… and
> multichannel… and CMYKs (I wrote some time ago about them on this list)…
>
> I see two problems with that.
>
> First is memory use. I'll give an example from my own backyard about
> bitmaps. Contrary to what may appear bitmaps are still very important image
> mode. At my work I use them as both small and precise means for preparing
> and storing scanned pages of old books destined to be reprinted. Given I'll
> be compelled to use 32 bits for each pixel I'll practically "waste" 31 bits.
> So my images (of course at the time of manipulating them in GIMP) will take
> 32 times more space than necessary. It may seem harmless, but take into
> account that such bitmaps are oftentimes of sizes about 8000 x 10000 pixels.
> Pretty much the same crude calculations are true for other "pixel depths" as
> well (8 bits – 4 times, and so on).

First, I must point out that your arguments needs to be derived from
the GIMP product vision [1], not personal requirements. Saying "I need
GIMP to do X" is not a valid argument for adding support for X in
GIMP, you need to say "GIMP needs to do X to fulfill the product
vision". Otherwise GIMP is doomed to begin (keep?) delivering an
inconsistent user experience in some areas.

There are two solutions to the memory usage problem:

1. Buy more RAM. GIMP does not need to run well on a 512 MB RAM
machine because it is reasonable to expect users of a high-end photo
manipulation program to acquire sufficient amounts of RAM. NOTE: I'm
not saying GIMP should be wasteful with memory...

2. Make GIMP clever. If GIMP encounters a tile with only values 0.0
and 1.0, the 32 bpc data can be transparently, i.e. without the user
noticing, replaced with 1 bpc data. As soon as more bits of precision
is required to avoid loss of data, GIMP can transparently convert the
tile back to RGBA float. The same kind of optimization can be done for
completely black, white and transparent tiles too.

Maintaining support in GIMP for an internal image data format of 8 bpc
or adding support for an native image data format of 16 bpc is silly
because such formats is going to result in rounding errors and lack of
HDR support, which is not high-end.


> I understand "filters" and "export mechanisms" are to be basically means of
> "cramming" information from fp pixels into "less precise" units. It means
> it's very probable some information will be lost/distorted. It will happen
> in more or less dramatic way, but the problem remains: what tools do we need
> to give to user to enable them *complete* and *precise* control over
> "conversion" results (meaning: this pixel should have *exactly* this or that
> value). When you stick to "image modes" as your paradigm in app itself, you
> don't have to worry much about it – user "gets what he sees" (granted he's
> into proper CM workflow ;)) or at least have absolute control over sample
> values right "on the canvas". Moving this control from "canvas" to "export"
> will result in another layer of complexity with (probably) reduced
> capabilities for the sake of "simplicity". Most of the time it'll probably
> work (much like CM), but I think it'll be a hell to debug and enemy of
> marginal, yet important use cases.

If you want a pixel to be RGB u8 (128, 90 90) when you export to a
PNG8, simply paint that pixel RGB u8 (128, 90 90). There are no
problems for RGBA float to represent RGB u8. Maybe I don't fully
understand what you mean, could you give a concrete and clear use case
that illustrates a problem?

/ Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"