Re: GIMP's future internal image data format

Bogdan Szczurek <thebodzio@xxxxxxxxx> · Tue, 31 Jan 2012 13:11:07 +0100

12-01-31 07:18, Martin Nordholts:

2012/1/30 Nathan Summers<rockwalrus@xxxxxxxxx>:

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
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gimp-developer-list