|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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
[Home] [Video For Linux] [Photo] [Yosemite News] [Yosemite Photos] [Yosemite Book Store] [gtk] [GIMP for Windows] [KDE] [Scanner] [Memory] [GEGL] [Gimp's Home] [Gimp on Windows] [Steve's Art] [Webcams]