Hello Sergey,
>
> On 11 October 2013 13:25, "Stefan Böttner" <virtual...@gmx.de> wrote:
> Now my point is this: You can think of this as non-uniformly scaling a circle
> in the color plane. You are able to specify scaling factors in a- and
> b-directions independently, causing your circle to become an ellipse.
> However, this way the principal axes of your ellipse will always remain the
> a- and b-axes, but more generally an ellipse could be rotated as well. We are
> currently unable to specify this rotation.
>
> I get your idea. It's like singular value decomposition of a linear transform
> vs only its scaling matrix. It is certainly more powerful. In other words,
> it's hue rotation combined with chroma change vs just chroma change. I'm not
> sure mixing these two modifications in the same tool is a good idea
> usability-wise. Hue rotation is an orthogonal concept and belongs to a
> separate tool, while ab curves should be used only to adjust chroma
> (colorfulness). In fact, it is probably possible to achieve what you want by
> combining ab curves and doing a uniform hue adjustment in colorzones. Hue is
> supposed to be atan2(b*, a*).
that's almost, but not exactly, what I'm proposing. Mathematically, it's
conjugation with hue rotation, which means you also apply an inverse rotation
after scaling. In the singular value decomposition you mention that's the other
orthogonal matrix you get, which will actually be the inverse of the first one
because here this is the special case that your decomposed matrix is symmetric
(i.e. we are in fact doing a simpler spectral decomposition). That being said,
no hue rotation will actually remain in the picture, it just influences how
(i.e. in which directions) the scaling is applied.
> The user needs to have reasonable expectations about tool's effect. Will
> rotated color axes a' and b' be intuitive enough? The Lab curves themselves
> are hard to master, but there are books and papers written about their use.
> What's going to be the effect of applying a 2x scaling to a* rotated 15°?
The colors affected are visualized in the user interface. Currently, that's the
gradient between greenish and purplish you get to see, because that's what the
standard a-axis spans. When rotation is applied, the user interface would of
course visualize the color gradient the rotated axis spans, and I believe it
would be clear what colors would be affected by which curve.
I don't think it would be any more difficult to use.
> The user needs to be able to choose tool's parameters based on observed image
> and his mental previsualization of the desired result. Given some color and
> targeting another color, what hue rotation angle he should choose? How it
> would affect other colors? Adding another parameter to Lab curves increases
> the dimensionality of the parameter space, without giving visual guidelines
> to choose the right set of parameters.
My idea is this: I would change the hue rotation (called it phi in my original
post), until the displayed gradient contains exactly that color I wish to
emphasize, e.g. that particular tone of green I desire for the foliage in my
photo rather than the "default negative a green".
> Is it going to be used mostly for small rotation angles (slight hue
> adjustments) or mostly large rotation angles (let say 45°)? The former case
> is likely well serve by existing color correction tools applied before/after
> standard Lab curves.
It turns out that anything more than the interval 0 to 45 degrees is redundant,
because the other angles would be equivalent to an angle in this range and
applying appropriate sign inversions on a and/or b and swapping a and b (which
gives a total of 8 combinations, and 8*45 degrees gives the full 360 degrees).
However, it wouldn't hurt to offer the entire 0 to 360 degree range and I
believe it would actually be more intuitive to be able to use the full range.
> I suppose, it's necessary to review use cases for such a tool. Like real life
> photos, and see if the desired result cannot be achieved with more
> conventional and existing tools.
There's probably always *some* alternative way to get things accomplished.
Basically what I'm saying is that from a mathematical point of view the choice
of a and b axes is arbitrary and their scaling possibilities seem incomplete.
From a practical point of view, I've frequently felt that the hues which the
standard axes represent are not exactly the ones I wanted to modify. This
applies e.g. to the aforementioned foliage (the green is getting too bluish),
blue skies, and the red of roof/brick tiles which is getting too purplish). As
I said before, I realize that there are alternative ways to adjust the color
which may work better here. Sometimes I still wish I could do it the way I
proposed.
Stefan
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
