Issue 104 in gpick: LCH (shortest path) mode for blend-colors and Mix Colors

7 views
Skip to first unread message

gp...@googlecode.com

unread,
May 5, 2013, 10:17:50 PM5/5/13
to gp...@googlegroups.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 104 by fintic...@gmail.com: LCH (shortest path) mode for
blend-colors and Mix Colors
http://code.google.com/p/gpick/issues/detail?id=104

The attached patch implements LCH (shortest h distance) interpolation mode
for Blend Colors and Mix Colors. This looks similar in nature to 'HSV
(shortest hue distance)' but is much better quality + more consistent. I
currently use just the LCH mode (for getting painterly/vivid color
transitions) and LAB mode (for all other transitions)

BTW, this is the same person as 00a...@gmail.com, this is my new account.

I have not implemented a non-shortest-distance option, as I think this
option is confusing and inconsistent (sometimes takes shortest path,
sometimes takes longer.) IMO the better option is either to omit the
non-shortest-path option (so, remove plain 'HSV' item from the options), or
to make the non-shortest-path option always take the -longest- path (this
is what GIMP does; so it has 'HSV shortest path' and 'HSV longest path').

I favor removing the non-shortest-path option personally (it doesn't seem
to have a real use case), but am willing to implement either solution.
I opened this issue to get feedback on whether anyone uses the plain 'HSV'
option or would use a 'longest path' option, and to give Albertas the
opportunity to give his input or veto any removal.


Attachments:
implement-lch-gradienting.diff 2.7 KB

--
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

unread,
May 21, 2013, 8:29:21 PM5/21/13
to gp...@googlegroups.com

Comment #1 on issue 104 by fintic...@gmail.com: LCH (shortest path) mode
In the absence of any feedback, I've committed this patch. Leaving this
issue open because there is still the related issue of the inconsistency of
the HSV blending modes ('HSV shortest hue distance' behaves consistently,
but plain 'HSV' sometimes takes the longest path and sometimes takes the
shortest one, according to it's naive calculations.)

gp...@googlecode.com

unread,
Jun 11, 2013, 11:55:29 AM6/11/13
to gp...@googlegroups.com

Comment #2 on issue 104 by thezbyg: LCH (shortest path) mode for
I agree that the non "shortest hue distance" option can be removed as it is
mostly useless.

gp...@googlecode.com

unread,
Jun 11, 2013, 10:32:02 PM6/11/13
to gp...@googlegroups.com
Updates:
Status: Fixed

Comment #3 on issue 104 by 00a...@gmail.com: LCH (shortest path) mode for
This issue was closed by revision 885c6b48e38b.

gp...@googlecode.com

unread,
Jun 14, 2013, 4:09:22 PM6/14/13
to gp...@googlegroups.com

Comment #4 on issue 104 by thezbyg: LCH (shortest path) mode for
I think that we can simplify HSV and LCH mode names. There is only one HSV,
and one LCH mode now, and that makes long and descriptive names
unnecessary, and a simple 'HSV' or 'LCH' should be ok.

Attachments:
hsv-mode-name.patch 1.9 KB

gp...@googlecode.com

unread,
Jun 14, 2013, 9:27:34 PM6/14/13
to gp...@googlegroups.com

Comment #5 on issue 104 by fintic...@gmail.com: LCH (shortest path) mode
Good point, most people won't care about the difference between longest and
shortest path anyway. Thanks, I've applied that and seem to have fixed my
problem with the hg history branching and merging for no good reason, too.
Reply all
Reply to author
Forward
0 new messages