eeColor LUT box white clipping

[Ivan Kolesov]

Hi everybody,

The problem seems to be as follows (sorry if I've mixed up some details).

When loading LUTs with TruVue software, only 65 bit LUTs are accepted,
but the last bit is omitted, so it's effectively 64-bit. This is
corroborated by the fact that TruVue's default LUTs end at values much
lower than 1.000000. The issue is pointed out in the ArgyllCMS docs
and a workaround for making the full-range input work, as I understand
it, is by modifying the 1D tables (only input tables in case of PC
monitors) so they end at values lower than 1.00000. The LUTs
accompanied by these 1D tables end at 1.000000.

Problem is, it doesn't seem to work. The last clipped bit seems to
correspond to around 4 units on RGB scale (0-255). This is clearly
visible when I view the same test pattern in two different modes, i.e.
1. eeColor processing off, color management applied in image viewer;
2. software color management off, eeColor processing set to the same
profiles as in case 1 (input: sRGB; output: ArgyllCMS-generated
profile). Now, in case 1 the whites can be discriminated at up to 244
bar (not a very good monitor, yes), while in case 2 it's only 240.

Either I'm doing something wrong, or there's a clipping problem. Can
some happy owners of a LUT box please check if they have the same
problem in full-range mode? Also, and this is addressed to Graeme
Gill, what if the LUT files built via collink were compressed instead
of the 1D tables to allow for the clipping? Does it even make sense?


Thank you.

[Graeme Gill]

Post by Ivan Kolesov
When loading LUTs with TruVue software, only 65 bit LUTs are accepted,
but the last bit is omitted, so it's effectively 64-bit. This is
corroborated by the fact that TruVue's default LUTs end at values much
lower than 1.000000. The issue is pointed out in the ArgyllCMS docs
and a workaround for making the full-range input work, as I understand
it, is by modifying the 1D tables (only input tables in case of PC
monitors) so they end at values lower than 1.00000. The LUTs
accompanied by these 1D tables end at 1.000000.

Right.

Post by Ivan Kolesov
Problem is, it doesn't seem to work. The last clipped bit seems to
correspond to around 4 units on RGB scale (0-255).

Unfortunately I'm not in a position to test it, since I don't have an eeColor.
I can only go on what I'm told.
(If anyone would like to remedy this situation, please feel free
to donate an eeColor.)

Post by Ivan Kolesov
This is clearly
visible when I view the same test pattern in two different modes, i.e.
1. eeColor processing off, color management applied in image viewer;
2. software color management off, eeColor processing set to the same
profiles as in case 1 (input: sRGB; output: ArgyllCMS-generated
profile). Now, in case 1 the whites can be discriminated at up to 244
bar (not a very good monitor, yes), while in case 2 it's only 240.

Sorry, it's not at all clear to me exactly what you are testing. Drawing
conclusion depends critically on the exact setup and setup details.

You haven't detailed what equipment is driving your display, nor
how it is configured.

If you want to investigate this issue, then I'd suggest doing so
with a noop 3dlut with the eeColor in and out of the video signal
path.

You can generate such a noop set of tables using something like:

collink -v -3e Rec709.icm Rec709.icm test

If you look at the resulting tables you will notice that the input
curves map 1 to 0.984375, and then the 3dlut maps entry 63 (which
is the one corresponding to an input of 63/64 = 0.984373) to an
output of 1.0. So if the eeColor operates the way I'm told, and
if you are running Computer 0-255 levels through it, it should
be having no effect. (Of course if you are actually running TV levels
16..235, it will have no effect either :-)

Post by Ivan Kolesov
Gill, what if the LUT files built via collink were compressed instead
of the 1D tables to allow for the clipping? Does it even make sense?

No, it does not. As soon as the signal hits the (hardwired) entry 64
of the cLUT, then it's going to map to an output of 1.0. In order to have
complete control over the output, those hardwired entries need to be
avoided. The only way to do that is with the 1D input LUTs.

Graeme Gill.

[Ivan Kolesov]

Post by Graeme Gill

Post by Ivan Kolesov
Problem is, it doesn't seem to work. The last clipped bit seems to
correspond to around 4 units on RGB scale (0-255).

Unfortunately I'm not in a position to test it, since I don't have an eeColor.
I can only go on what I'm told.
(If anyone would like to remedy this situation, please feel free
to donate an eeColor.)

I'm working on it. :)

Post by Graeme Gill

Post by Ivan Kolesov
This is clearly
visible when I view the same test pattern in two different modes, i.e.
1. eeColor processing off, color management applied in image viewer;
2. software color management off, eeColor processing set to the same
profiles as in case 1 (input: sRGB; output: ArgyllCMS-generated
profile). Now, in case 1 the whites can be discriminated at up to 244
bar (not a very good monitor, yes), while in case 2 it's only 240.

Sorry, it's not at all clear to me exactly what you are testing. Drawing
conclusion depends critically on the exact setup and setup details.
You haven't detailed what equipment is driving your display, nor
how it is configured.

Well, the hardware setup is the same for the two above cases: DVI-HDMI
from PC (0...255) to LUT box, HDMI-DVI from LUT box to monitor. The
monitor matrix is essentially 6bit+FRC, which probably explains the
clipped blacks and whites (<16 and >244) that I get all the time (the
control setup is a direct PC-to-monitor connection via DisplayPort)
not only with the I1Pro rev. D, but also with the Spyder2. The problem
is, I had a smaller dynamic range via hardware CM (in LUT box) than
via software CM (lcms in the image viewer).

Anyway, I've done another round of profiling this weekend, this time
with calibration, and the problem is gone. Now the "white wash" is the
same in both cases (at ~244). The only apparent difference is that
this time calibration was performed prior to profiling. I guess, since
this problem is not always reproducible, it must be due to some other
unknown factor, not ArgyllCMS's handling of 3DLUTs for the box.

Post by Graeme Gill
If you look at the resulting tables you will notice that the input
curves map 1 to 0.984375, and then the 3dlut maps entry 63 (which
is the one corresponding to an input of 63/64 = 0.984373) to an
output of 1.0. So if the eeColor operates the way I'm told, and
if you are running Computer 0-255 levels through it, it should
be having no effect. (Of course if you are actually running TV levels
16..235, it will have no effect either :-)

I wasn't aware it's essentially 63 bit. In that case, there really
should be no difference. And yes, the TV levels did look all right.
Thank you for the answers.


Ivan Kolesov

[Graeme Gill]

Ivan Kolesov wrote:

Hi,

Post by Ivan Kolesov
Well, the hardware setup is the same for the two above cases: DVI-HDMI
from PC (0...255) to LUT box, HDMI-DVI from LUT box to monitor. The
monitor matrix is essentially 6bit+FRC, which probably explains the
clipped blacks and whites (<16 and >244) that I get all the time (the
control setup is a direct PC-to-monitor connection via DisplayPort)

Hmm. Is there no way of configuring the display card for Video level out,
or the TV for PC range in ?

You can of course use the ArgyllCMS TV range out encoding options
to deal with it too.

Post by Ivan Kolesov
not only with the I1Pro rev. D, but also with the Spyder2. The problem
is, I had a smaller dynamic range via hardware CM (in LUT box) than
via software CM (lcms in the image viewer).

It's really hard to know how the eeColor deals (or doesn't) with
different encoding ranges. The guess at the moment is that it
doesn't, hence the need to configure collink appropriately
with the correct encoding.

Post by Ivan Kolesov
I wasn't aware it's essentially 63 bit.

The eeColor has 64 entry tables with a fake 65'th entry
wired to 1.0, so the entries are numbered from 0..64, as per usual
computer notation.

Graeme Gill.

[Ivan Kolesov]

Hi,

Post by Graeme Gill
Hmm. Is there no way of configuring the display card for Video level out,
or the TV for PC range in ?

I guess that would not be useful, since I only use this hardware
chain, and since that other clipping most probably occurs in the
monitor, not at an earlier stage, the results would be the same.

Post by Graeme Gill
You can of course use the ArgyllCMS TV range out encoding options
to deal with it too.

Yes, that would be great, but I only use PC levels now. A new 8-bit
monitor would be a more permanent solution.

Post by Graeme Gill
It's really hard to know how the eeColor deals (or doesn't) with
different encoding ranges. The guess at the moment is that it
doesn't, hence the need to configure collink appropriately
with the correct encoding.

Still, my curent profiling attempt shows that the LUT box can actually
handle the CM process quite well for TV and PC range. I only have to
figure what I did wrong previously to get the clipped whites in the
previous profiling instance. I don't think I have the knowledge,
though.

Post by Graeme Gill
The eeColor has 64 entry tables with a fake 65'th entry
wired to 1.0, so the entries are numbered from 0..64, as per usual
computer notation.

Right, my bad. :)



Ivan Kolesov