Google
  Web www.spinics.net

Re: [Gimp-developer] GIMP vs Photoshop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer



[Video For Linux]     [Photo]     [Yosemite News]    [Yosemite Photos]    [gtk]     [GIMP Users]     [KDE]     [Scanner]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]     [Webcams]