Re: [Gimp-developer] image modes and indications

[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:
>
> > The proper solution to this problem is _not_ to have an indicator of
> > the current image mode,
>
> ...which I didn't even suggest :)
>
> > but to get rid of the concept of image mode altogether.
>
> Completely agreed

I disagree… at least to do it so carelessly, see below.

> > Images shall always be composed in 32-bit floating point
> > RGBA

Which RGB? Is it scRGB of GEGL "guts"? :)

> > 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).

I agree idea of 32 bits "to rule them all" is tempting from programmer's 
point of view, but at the same time wasteful and prone to generate more 
problems than it solves. Here comes the second problem I mentioned earlier.

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.

I think using 32 bit fp for all images is trying to make things appear 
simpler than they really are and it'll only make them more complicated.

This is where I see a potential problems. I think we need proper proof 
of concept or at least a couple of use cases described in very detailed 
way, to be sure it'll actually work as intended.

> Which, however, isn't the main point of my mail :)
>
> Alexandre Prokoudine
> http://libregraphicsworld.org

-- cut --

My best!
thebodzio