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

[Martin Nordholts <enselic gmail com>]

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.


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


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

/ Martin


-- 

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