Re: [Gimp-developer] image modes and indications

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

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

-- cut --

My best!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]