Re: Hue Shift From Curves and Levels

Hello Carl,

I am switching back on list.

Am 21.11.07, 00:36 -0800 schrieb Carl Cole:

> Hi Kai-Uwe
> 
> I am sorry about the confusion regarding my sending the full curves.c file. I
> didn't understand the email size restriction. It is quite reasonable. I will
> send patches in the future. I have attached a patch for curves.c only.

No problem. Hope it works for you.

> I will look further into levels and learn better how it works and what the
> appropriate patch might be.

Fine.

> When you say "toggle", are you referring to a new check box on the
> curves/levels dialog? (Perhaps, labeled something like "Preserve Hue"?) A
> check box may be a good idea. When I apply curves, I create a curve that is
> monotonically increasing. However, it is possible to enter a curve shaped like
> a U or an M. I am not sure why someone might do this, but in this case, the
> patch may be inappropriate.

Yes, 'toggle' was though of as a check box. But I changed my mind and 
think it is not needed further. The single channels are accessible. 
Provided that someone want to manipulate red, green and blue is 
understandable that the result is different for all single channel curves 
(red, green and blue) than for one single value curve.

> I am not sure what you mean by "the touching of the clipping of HDR data".
> Please explain better.

Touching is probaly missleading. Clipping of HDR should be avoided at all.
 
> First, what does HDR mean?

High Dynamic Range is a short hand for lightness representations not 
purly relying on the computaional base like obviously for pure integer 
representations. A integer has a value range and 0 means black and MAX_INT 
means white. HDR can easily exceed the typical white of 1.0 and is capable 
of representing physical units like cd/m².
HDR is most often represented in float data types, But there are other 
possibly too like Cineon, represented as a integer with black and white 
point and a logarithmic scaling.

> One guess about "touching the clipping ...", do you mean that the
> interpolation result should be rounded, rather than simply cast back to 8 or
> 16 bits?

Your patch implements a very nice clipping of highly saturated colours. 
Just this clipping would not be wise for HDR types like CinePaint's 
32-bit FLoat and 16-bit Half (OpenEXR/Nvidia/...).

> I am new to Cinepaint -- please allow me to ask a couple basic questions.
> Within Cinepaint, what internal data types are used to represent color pixel
> data? (8-bit, 16-bit, float?, double?, what else?) Is there a data type whose
> precision covers all of these internal working types?

5 types are implemented.
uint_8
uint_16
bfp   - 16-bit binary fixed point a uint_15 with a the first bit signaling 
        a additional 1.0...2.0 range for over whith, a little bit like HDR 
Half  - 16-bit floating point, used in OpenEXR and modern graphics cards
float - 32-bit IEEE

float or double cover all other types.

> Within curves.c, there are parallel routines for U8 and U16. I did not notice
> any floating-point routines. My patch is in the form of a macro that casts the

Curves is a integer LUT thing. Floating point interpolation is not 
implemented.

> 8-bit or 16-bit integers to double, performs the interpolation as double, then
> casts back to 8 or 16 bits. I chose double so I wouldn't have to worry about
> rounding errors while I was investigating whether the basic routines worked at
> all. Double may not be the best choice for production code. You can advise me.

It is a good thing for a common implementation. If you have lots of time 
and want to speed things up you may optimise. A good candidate would be to 
omit your code in case the value curve is not touched at all and should do 
nothing. This was no problem with the simple LUT's. Now it could be done 
better.

> What is the preference of the Cinepaint developers regarding numeric type for
> intermediate numbers, such as my interpolation routine? Double? Float?
> GDouble? Write parallel subroutines instead?

The up to date way is a reference implementation in float or double.
If there is much demand or the routines are used very often they can be 
optimised for each data type.

> Within levels.c, there are three parallel routines (U8, U16, and bfp). Is bfp
> some form of floating point? So far, I don't understand what bfp does that is

Please read above about bfp. As a not floating point data type it should 
get clipped as well. For your code it should make no difference.

> different from U16. I did notice that for bfp, the levels transfer function
> (that determines the new value from the old) is an array of type guint16. So I
> figured I could interpolate as double and cast back to U16. Am I
> misunderstanding something?

Handle bfp just like any other uint16_t. The difference is in displaying 
and file export.

> Thanks for your explanations. I will look further into levels and see what I
> can understand.
> 
> Regards,
> 
> Carl

kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org



> Kai-Uwe Behrmann wrote:
> > Hello Carl,
> > 
> > after discussing your changes with Hartmut, a CinePaint developer, we
> > found the touching of the clipping of HDR data in the way you do for
> > curves is not an option. Clipping is not desired at all for floating
> > point data.
> > 
> > The IEEE float and Half code can stay as is in levels.c.
> > 
> > Thanks
> > Kai-Uwe
> > 
> > 
> > Am 20.11.07, 08:38 +0100 schrieb Kai-Uwe Behrmann:
> > 
> > 
> > > Carl,
> > > 
> > > I omitted the toogle as the single channels are still accessible. I
> > > had to look close.
> > > 
> > > The curves work as is.
> > > 
> > > The levels still show the old behaviour of huge colour shifts. It is
> > > observable when moving the lower and the upper end.
> > > CinePaints floats are as well not covered.
> > > 
> > > Would you take a look into the levels code?
> > > 
> > > 
> > > kind regards
> > > Kai-Uwe Behrmann
> > > --
> > > developing for colour management www.behrmann.name + www.oyranos.org
> > > 
> > > 
> > > Am 20.11.07, 06:42 +0100 schrieb Kai-Uwe Behrmann:
> > > 
> > > 
> > > > Your message to CinePaint's devel list was rejected due to its
> > > > rather large size. We have a reasonable 80kB limit.
> > > > 
> > > > There are several way to limit the size.
> > > > 
> > > > A: supply a patch like:
> > > > $ diff -aur old_curve.c curve.c > sat.diff
> > > > $ diff -aur old_levels.c levels.c >> sat.diff
> > > > sat.diff was here some few kilobytes and would have passed.
> > > > 
> > > > B: submit to CinePaints SourceForge patches page
> > > > 
> > > > Anyway I am about evaluating the patch and if it is ok I will
> > > > create the toggle for you. Thanks for stepping into this area.
> > > > 
> > > > best regards
> > > > Kai-Uwe
> > > > 
> > > >

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Cinepaint-developers mailing list
Cinepaint-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/cinepaint-developers