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

[Bogdan Szczurek <thebodzio gmail com>]

12-01-31 07:18, Martin Nordholts:
> 2012/1/30 Nathan Summers<rockwalrus gmail com>:
> > Big images require lots of ram, but in my mind a high-quality photo
> > editing program doesn't limit the size of how big an image you can
> > edit with it to much smaller than how much you would normally be able
> > to fit into ram.
>
> Absolutely, but you'll still want big amounts of RAM when you work
> with big images.

At least we all agree about that ;D

> > Given the wide variety of input sources, output formats, and rendering
> > targets that the vision contemplates, I wouldn't be so bold as to call
> > image modes an unnecessary burden.  While it's true that it's often
> > (but not always) desirable to work in the highest precision possible,
> > getting an effect correct down to the 22nd binary digit isn't always
> > the top priority of the user.
>
> I really don't understand why someone would want to deal rounding
> errors. If you want them to create an artistic effect, you should use
> a filter that simulates it. I think it is safe to say that most users
> of a high-end photo manipulation program don't want to deal with
> rounding errors. To then force them to make a choice about it would be
> a disfavor and unnecessary burden.

I agree that having more precision is more favourable mathematically. 
But is it so "visually"? I mean we'd have more precisely determined 
color components but will it really "show"? And if it will, then how 
much? Just a couple of questions, that, I believe, can't be answered 
right now. I said it before, I say it again: let's wait and see :). Real 
world application will for sure provide us with "proofs", while 
continuing this could unfold into battle of "I thinks" and "IMHOs" not 
"knows".

> > Given that the product vision you linked to explicitly included
> > targets like application icons and web pages, and I know of no
> > standard application icon or web page graphic format that even
> > optionally supports HDR, it's not far-fetched to say that a program
> > that targets icons and web page graphics that has the ability to  work
> > in the native bit depth of those kinds of graphics can still be called
> > high-end.
>
> In the case of application icons and web page graphics, the extra bits
> of precision would be used to get rid of rounding errors when you
> stack layers and effects on top of each other.
>
>
> > Punting a decision on how to support non-RGB workflows until after you
> > have code for RGB workflows is pretty much a recipe for coding
> > yourself into a corner, especially if you toss out the existing
> > support for non-RGB workflows (i.e. indexed and grayscale) in the
> > process.
>
> Well, I don't think so. The strategies for dealing with RGB and CMYK
> are different enough for them to co-exist without stepping on each
> other's feet. As long as we don't implement RGB naively and
> short-sighted, we will be able to add CMYK support later without many
> conflicts with RGB.

A focal point is needed and if it had to be RGB… well… so be it. 
Meantime why not to think a little bit about the future? :) Why not 
dwell for moment in a world of non-square pixels, generic substractive 
and additive color models (who said RGB is *the best* and *ultimate* 
solution?), non-orthogonal pixel grids… dreams, dreams… :) That's it for 
the (hopefully) "inceptive" off-topic :)

My best!
thebodzio