Issue 105 in gpick: RGB linearization is broken

[gp...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 105 by fintic...@gmail.com: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

This is simple to reproduce -- drop black and white into the 'Blend Colors'
dialog, reduce the first number of steps so there is only one inbetween
color, and check the 'middle color'. This should be no darker than #777777,
but not only is it much darker (#3b... or thereabouts), it's also not a
shade of actual gray, it's greenish.

Not sure when this change was introduced, but the
color_rgb_get_linear/color_linear_get_rgb functions seem to be using
incorrect coefficients (2.1 vs 2.2, or ideally (most accurately) a 2-part
function that's linear below a certain point and gamma 2.4 above that
point).. and also a different coefficient(2.0) for the green channel. I
haven't had the time yet to track down when this change occurred, but it
makes RGB blends much worse in quality (overall, way too dark, and as I
mentioned, discolored.)

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[gp...@googlecode.com]

Comment #1 on issue 105 by fintic...@gmail.com: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

It's not clear that this was ever correct, but something recent seems to
have made it vastly worse (probably something outside of the above
mentioned functions)

[gp...@googlecode.com]

Comment #2 on issue 105 by fintic...@gmail.com: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

I take that back: the attached patch to color_rgb_get_linear,
color_linear_get_rgb,
implementing the companding recommended by Bruce Lindbloom,
http://www.brucelindbloom.com/Eqn_RGB_to_XYZ.html +
http://www.brucelindbloom.com/Eqn_XYZ_to_RGB.html, seems to have fixed the
excessive darkness. These equations were already in use for the existing
RGB <-> XYZ transforms, but for some reason (speed?) were not used in the
linear <-> nonlinear RGB transform functions).

Not pushing this patch yet because I'm sure there was a reason for the use
of unconventional and asymmetric coefficients in the previous RGB
de/linearization code, and hope to find out what those reasons were.

Attachments:
correct-rgb-companding.diff 1.7 KB

[gp...@googlecode.com]

Comment #3 on issue 105 by thezbyg: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

The original de/linearization functions are a total fail. Worst of all
things, is that the linearization code is in color_linear_get_rgb, and
delinearization code is in color_rgb_get_linear.

I do not think there was any reason to do anything differently, and not use
a proper sRGB to linear conversion.

[gp...@googlecode.com]

Comment #4 on issue 105 by fintic...@gmail.com: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

Okay, then I'll reverse the meaning of those two functions so
color_rgb_get_linear returns linearized results and color_linear_get_rgb
returns delinearized, adjust references appropriately, and push.

[gp...@googlecode.com]

Comment #5 on issue 105 by fintic...@gmail.com: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

Never mind the 'reverse the meaning'. It seems that they are currently
(with my patch) already correct and the code using them is already correct
too. I'll just check everything and push the patch as-is.

[gp...@googlecode.com]

Updates:
Status: Fixed

Comment #6 on issue 105 by 00a...@gmail.com: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

This issue was closed by revision 9664b3ff15f6.

[gp...@googlecode.com]

Comment #7 on issue 105 by fintic...@gmail.com: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

BTW, I've noticed that for some reason I'm obligated to do 'merge commits'
every time I 'hg pull;hg update' from Google code and there are actual
changes transferred. I'd like to avoid clogging up the commit log with
these things but 'hg push' doesn't seem to work without first 'hg
merge'ing, despite the fact that the merge commits report 'no changes'.
Currently trying to fix this, any suggestions will be gratefully received.

[gp...@googlecode.com]

Comment #8 on issue 105 by thezbyg: RGB linearization is broken
http://code.google.com/p/gpick/issues/detail?id=105

Before doing 'hg push' to Google Code repository, you can run 'hg pull
--rebase', or 'hg rebase' if you already have pulled some remote changes
while having local commits. This will move your local commits after the
most recent remote commit.

The '--rebase' flag and 'hg rebase' command requires 'rebase' extension.
which is included with default Mercurial distribution, but must be enabled
by editing your '.hgrc' file.

More information about 'rebase' extension:
http://mercurial.selenic.com/wiki/RebaseExtension