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

2012-01-31 Thread Bogdan Szczurek
W dniu 12-01-31 15:48, gespert...@gmail.com pisze: 2012/1/31 Bogdan Szczurek mailto:thebod...@gmail.com>> 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 "sho

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

2012-01-31 Thread gespert...@gmail.com
2012/1/31 Bogdan Szczurek > 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

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

2012-01-31 Thread Bogdan Szczurek
> Am Dienstag, 31. Januar 2012 schrub Bogdan Szczurek: > > [...] > >> non-square pixels > > GIMP has that for ages. Still, besides information about "uneven" horizontal and vertical resolutions not stored within image itself. So designer have to remember his image has non-square pixels and to

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

2012-01-31 Thread Tobias Ellinghaus
Am Dienstag, 31. Januar 2012 schrub Bogdan Szczurek: [...] > non-square pixels GIMP has that for ages. [...] signature.asc Description: This is a digitally signed message part. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http:

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

2012-01-31 Thread Bogdan Szczurek
12-01-31 07:18, Martin Nordholts: 2012/1/30 Nathan Summers: 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,