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