Quoting Kai-Uwe Behrmann <k...@gmx.de>: > I find it great to see XYZ<->sRGB conversions becoming reversible. > However, I would expect the gamut is still visible for real devices. > sRGB is not a device but more of a colour space.
Exactly. You got the point. And as a such it has no defined gamut other than the encoding. On real devices, things are quite different. > Without having yet looked at, does Lab still collapse to device gamut > in a PCS->Device conversion? Device is refered as a printer or > monitor CLUT profile. In V4 there is a reference gamut, but yes, whole Lab space in the ICC Lab gamut, which is a cube 0..100, -128..+178, should be mapped to device coordinates by the profile. In those cases the roundtrip trick may work to detect the gamut. Something similar is internally used by the engine right now. However, I plan to use the implementation of segment maxima that comes in 2.0 to check gamut by geometric means, which for sure will be more reliable than the roundtrip. > How to handle sRGB colour space versus matrix monitor profiles? The > gamut boundary detection would expectedly behave similiar, while the > meaning is completely different. sRGB as a non device colour space > can handle super bright intensities, the monitor could burn to ashes > for the same physical intensities. The point here is that no gamut information is encoded in the profile. If you want to take the 0..255 cube as the gamut, that's fine but does not mean the monitor gamut is such cube. For example, a monitor can deliver the same physical color on [20, 20, 250] that on [20, 25, 253] just because the blue channel cannot be more chromatic. Then you got an apparent gamut the real device cannot render. All the best Marti ------------------------------------------------------------------------------ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
