> > 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. All of it seems reasonable to me :). > 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. Docs state it as âscRGBâ. I don't argue about well defined conversion to absolute color coordinates (every color model have them, I should think). My only concern is about 20% of visible spectrum missing from scRGB. If operation yields a color from that absent 20% of spectrum, that color have to be âpushedâ into available space. That's the obvious. What isn't is how often it happens (are some statistics available?) and how serious is that for color reproduction? If it's less than a couple of pixels then I'm calmed down :). > 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. I can only say that I back that up. Best regards! thebodzio
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
