Additional "spread" interpolations

[pixeloutlaw]

When using the spread option in the palette editor only linear RGB interpolation is supported. Human intensity perception is not linear in nature so perhaps additional interpolation methods may be added as drop down options.

If you have normal vision you'll see that the "spread" from pure green to pure black feels weighted toward the green end. If you look here you'll see just how different interpolation can be. HCL seems blending might be something quite useful!

​https://bl.ocks.org/mbostock/3014589

[pixeloutlaw]

Unbalanced RGB linear interpolation from green to black

[finticemo]

I would say that the main problem with GrafX2's interpolation is that it in a very real sense is NOT linear. It interpolates sRGB values as if they were linear, but sRGB itself is definitely not linear (​https://en.wikipedia.org/wiki/SRGB#The_sRGB_transfer_.28gamma.29_function has a nice graph). The result is mathematically nonsensical, but sometimes convenient (since it often produces more distinct shades than a linear interpolation).

I recommend you this: ​https://community.mypaint.org/t/real-color-blending-wip/390 , which explores the imperfections of different types of interpolation, and ​http://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html#introduction , which illustrates visually the difference between correct and incorrect RGB interpolation.

Personally I would suggest:

• Linear RGB interpolation as a 'usually better' default behaviour than the current sRGB; results are much closer to what your eye expects
• sRGB remaining as an option
• LAB as an option which is often better than Linear RGB, but not always wanted because it doesn't always produce 'neat' results
• HSL, HCL / LCH, HSY etc (any colorspace with a polar term like Hue) is generally one of the more problematic options; it's complicated to handle interpolation of Hue terms correctly, as discussed in the thread I linked.
• Being very careful about LAB implementations which HCL/LCH is based on). Most of them are subtly wrong. GIMP's ('cpercep.[ch]') is correct.

I'm less sure about what the correct way to go about a GUI might be. Since the current UI is jam-packed, we need to consider it carefully.

(right now, I just have a script that does this stuff, obviously it's completely separate from the palette editor)

EDIT: Something weird happened with the submission of this comment.. I hope it is showing up OK for others..

[PulkoMandy]

Sorry about the missing comments, I had some problem while upgrading the website to Trac 1.2. Everything should be running fine again now (I hope).

Anyway...

There is just enough space left to make the "spread" button a dropdown (like "sort"). We can include as much algorithms as we want there. It is nice to have several of them, including non-linear ones. Sometimes, this is what you want for various reasons (you want your gradient to look more colorful, you are working within specific constraints of some hardware, etc).

[yrizoud@…]

Just a precision, in Grafx2 the palettes are an abstract RGB cube space, we make no assumption that we are in sRGB, or that the image is intended to be viewed on the same device than the current one (whose gamma is unknown, anyway).

I think it's enough to have general option "Color mixing", choice between :

• "sRGB transfer curve", if I understand correctly (The Wikipedia page makes no sense to me, why do they suddenly talk of CIE XYZ ? Somebody smarter than me will have to find the transformation functions)
• gamma 2.2
• gamma 1.8
• linear RGB (still useful to anyone who is familiar with the oldschool aesthetic, or needs specific color effects)

No matter what the program automatically does, the user will always have cases where he wants a gradient "more focused on one side". It may be a good idea to have UI change where, after you hit "Spread" (and a gradient is computed and shown), a pop-up slider appears, positioned at 50%. If the user moves this slider up or down, the gradient gets recomputed with a bigger focus on the beginning/end. If the user hits any other control, this slider disappears.

[finticemo]

" I think it's enough to have general option "Color mixing", choice between :

"sRGB transfer curve", if I understand correctly (The Wikipedia page makes no sense to me, why do they suddenly talk of CIE XYZ ? Somebody smarter than me will have to find the transformation functions)
gamma 2.2
gamma 1.8
linear RGB (still useful to anyone who is familiar with the oldschool aesthetic, or needs specific color effects)

"
This terminology confuses me TBH
If I can expand a little:

• An image generally is considered to 'have' a colorspace / color profile (as distinct from the monitor colorspace)
• the word 'linear' in 'linear gradient' can have one of two meanings : linear in image colorspace, linear in true linear RGB.
• If you want a linear gradient in image colorspace, then you simply do a linear interpolation without any pre-processing.
• If you want a linear gradient in linear RGB, you convert the colors from image colorspace, do the linear interpolation, and convert them back.
• So, to me there are two parameters here, and they should be represented individually : the assumed colorspace of the image, and whether the gradient should be calculated in image colorspace or linear RGB.
• I consider this a simplification, as it means the image colorspace can go in the same dialog that selects dimensions and pixel scaler, and the choice of mixing is simply between 'image RGB', 'linearized RGB'..
• Additional colorspaces usually, IME, have an implicit preference (LAB, LCH, HSY imply linearized RGB, for example. Whereas HSL/HSV imply image RGB)
• I think that is more cleanly factored. Hopefully you agree.

Lots of software implements color management badly, and especially, confusingly, hopefully we can avoid that with a bit of thought.

Is there any case where gamma 2.2 is genuinely used, not sRGB (which sort of looks like 2.2 if you squint but isn't quite)?

Regarding correct sRGB->linear conversions, its fairly simple. Taken from python-colormath; this is expressed in 0..1.0 terms :

if V <= 0.04045:

linear_channels[channel] = V / 12.92

else:

linear_channels[channel] = math.pow((V + 0.055) / 1.055, 2.4)

The XYZ part is irrelevant if the illuminant is the same for source and destination spaces, which is a reasonable assumption for GrafX2. It is simply intended to prevent discoloration when switching illuminants.

Reverse transform is as follows:

if v <= 0.0031308:

nonlinear_channels[channel] = v * 12.92

else:

nonlinear_channels[channel] = 1.055 * math.pow(v, 1 / 2.4) - 0.055

That bias control would be really great IMO, particularly the interactive 'take an action, then modify that action' aspect. GIMP took a similar approach with box/ellipse select and it's really nice to use.

[pixeloutlaw@…]

Thank you so much for considering this change.
Just want to let you guys know people are still using an enjoying the software.
I'd be happy with a few pre-set options.
As you've discussed.

However the best control possible would probably be with a widget that allows users to define a curve by dragging a control point.

Now this would be a headache on the C side of things since you'd need to define and test a curve editor widget. However this gives you an idea what could be done (Taken from Gimp's "curves" editor)

​http://i.imgur.com/wh3ovq2.png
​http://i.imgur.com/NCEnBrC.png

The important thing is not to make a huge workload I suppose.

[PulkoMandy]

Move open tickets to 2.7 milestone