On 11/17/06, <b class="gmail_sendername">Bart Coppens</b> <<a href="mailto:kde@bartcoppens.be">kde@bartcoppens.be</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Friday 17 November 2006 18:04, Mikhail Lyossin wrote:<br>> The better choice for all of us would be to have some switch in options<br>> which would allow to use anyone any representation he likes.<br>I'm not sure about that, sounds a bit confusing, no?
</blockquote><div><br>What's wrong with that? I mean only interface representation to the user in color selector module.<br>So, for example, if color is stored as floating point, user may see it's numbers in all possible forms, such as Integer 8 and 16 bit, Percentage, and Floating point, of course.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> The only<br>> requirement is to provide ability for the user to set out-of-gamut colors,
<br>> like negative or very large numbers in any mode to avoid occasional color<br>> clamping, I think.<br>Actually, does lcms have an out-of-gamut-check function? I looked at that<br>once, but could only find a parameter so that lcms would change out of gamut
<br>colors to another color. Not quite what I had in mind...<br></blockquote></div><br>Here is a difference between "warning that you already lost" and "keeping out of gamut values".<br>Unfortunately, not every colorspace definition allows to keep these colors, but this talk makes sense at least for RGB8bit_Int - RGB16bit_Int - RGB16bit_Float - RGB32bit_Float colorspaces.
<br>