On Tue, Mar 8, 2011 at 7:47 PM, Bogdan Szczurek <thebodzio@xxxxxxxxx> wrote: > Yes, but why use RGB at all if one can use e.g. XYZ from the start? > So "wide" RGB would also require greater than 8 bit depths to work > satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per > component). I think one consolation is possible backward compatibility > with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a > trouble of defining such “new” RGB workspace: what white point should > be choosen and what primaries (all have to be defined in some absolute > color coordinates BTW)? Whatever space would be choosen we wouldn't > escape color conversions in color managed workflow, so while I'm not > RGB enemy I fail to see the reason to stick to it especially since > there are “wider” color spaces that are more intuitive to work with. It is a matter of which well defined color space the operations desired provide sensible outputs. For some types of operations doing them in premultiplied linear light RGB is superior to doing them in sRGB, CIE Lab or other more or less perceptual spaces, for other operations the opposite is true. My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color - whis is why the operations of GEGL request temporary working buffers in their preferred working space (this is where babl does the; optimized; conversions you correctly state have to happen) rather than blindly handling incoming numbers. The RGB space defined by and used by babl uses the same primaries as sRGB, and has well defined conversions to CIE Lab, Xyz and others. The preferred^Wenforced working space of some operations in GEGL might need some scrutinization and review, though for compositing; gaussian blurs; interpolation etc I think the current choice of linear light RGB. GEGL also does not support working in an internal 8bit or 16bit mode, it is floating point with high precision and additional headroom/footroom (wide gamut/HDR) for all temporary buffers, if the desired output is 8bit it happens when displayed or exported. Operations like for instance unsharp-mask does not work correctly if termporary results are clipped. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ ; http://ffii.org/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
