tips/tricks for drawing color-managed color picker controls?

[Paul Miller]

I'm working on a new set of color picker controls that are properly
managed with OCIO.

For simple pots I can just transform each color before painting with my
toolkit (I'm not going through OGL for these).

But for more complex controls like color spectrums and color-backed
alpha spreads, is there anything other than rendering the control (in
float) to a temporary buffer, doing the apply on the buffer, then
clipping the buffer (color-wise) to the display?

For example, I'm assuming transforming/clipping each point of a gradient
is not the same as generating the gradient in float and
transforming/clipping each pixel of it independently?

[Jeremy Selan]

Are you doing this in qt or pyqt?

-- Jeremy

[Paul Miller]

On 12/19/2011 4:04 PM, Jeremy Selan wrote:
> Are you doing this in qt or pyqt?

My UI is Qt. If I can get away with pre-transforming/clipping my colors
and then just feeding them to a QGradient, I'd be happy. But I can
render everything into a floating-point backing buffer and clip to the
screen if I have to.

[Jeremy Selan]

You should not need a floating-point backing buffer.  You can pretransform a lattice of float colors (or per-pixel for 1d gradients), and then clip + convert to a QColor gradient for drawing.

The big subtlety is that if your gradient interpolation space is scene-linear (and you apply a scene-linear to display view transform), the gradient will look terribly non-uniform.   I.e. Artists will hate it.   The workaround is that you essentially want to separate a view transforms 1D + 3D components, where the 3D part of the view transform is applied, but the 1d part is not.  This is what the COLOR_PICKER role is for.

We have pyqt code that is a nice example of this, let me see if I can get permission to post it.

-- Jeremy

[Paul Miller]

On 12/19/2011 4:27 PM, Jeremy Selan wrote:
> You should not need a floating-point backing buffer. You can
> pretransform a lattice of float colors (or per-pixel for 1d gradients),
> and then clip + convert to a QColor gradient for drawing.
>
> The big subtlety is that if your gradient interpolation space is
> scene-linear (and you apply a scene-linear to display view transform),
> the gradient will look terribly non-uniform. I.e. Artists will hate
> it. The workaround is that you essentially want to separate a view
> transforms 1D + 3D components, where the 3D part of the view transform
> is applied, but the 1d part is not. This is what the COLOR_PICKER role
> is for.
>
> We have pyqt code that is a nice example of this, let me see if I can
> get permission to post it.

Ah yes I noticed my gradients were not looking uniform. If you have an
example of using the picker role, that would be awesome.

[Paul Miller]

On 12/19/2011 4:27 PM, Jeremy Selan wrote:

> You should not need a floating-point backing buffer. You can
> pretransform a lattice of float colors (or per-pixel for 1d gradients),
> and then clip + convert to a QColor gradient for drawing.
>
> The big subtlety is that if your gradient interpolation space is
> scene-linear (and you apply a scene-linear to display view transform),
> the gradient will look terribly non-uniform. I.e. Artists will hate
> it. The workaround is that you essentially want to separate a view
> transforms 1D + 3D components, where the 3D part of the view transform
> is applied, but the 1d part is not. This is what the COLOR_PICKER role
> is for.
>
> We have pyqt code that is a nice example of this, let me see if I can
> get permission to post it.

Jeremy - any luck getting some sample code that shows how to avoid the
extra display transform?