It is the curve that matters, not where the control points are.
But the control points determine the curve!
Selecting
a curve is an interactive/iterative process. Getting some idea where the
'bad' parts of the image fall on the curve is useful, not not required.
That's where we disagree. Yes, it is possible to use a generic S curve
for example but, as I mention, for anyone who actually wants to know
what they're doing it's essential to identify the parts of the image
one wants to change and, conversely, parts of the image one doesn't
want to disturb.
That depends. If new features don't work the first time, send a detailed
bug report to the author and it will probably be fixed.
I don't use Vuescan, but judging by reports from other users author's
reactions fall into two broad categories if he can't fix the bug:
He explodes with abuse or tells the user they're "blacklisted" -
whatever that means.
I don't have a Vuescan license because I can usually live with the limitation
of the vendor supplied software.
But the trail versions I tried were never buggy in my experience. Just
not worth the money.
That too. But it depends how thorough your tests were. In any case,
Vuescan's track record of all the bugs is in the public domain.
As I keep saying, for a highly compressed web JPG even Vuescan will do
and I have even recommended it to people who have such low
requirements. But for anything else it's pretty useless.
That is not the root problem. It is supposed to work like that.
It may be supposed to work like that, but that's not an excuse. A
design flaw is still a design flaw, even if it's implemented as
intended which in case of Vuescan is always a question mark because of
all the bugs.
The 'cannot' is there for two reasons:
1) of course you display a gamma 1.0 image directly on a gamma 2.2 monitor:
it just won't look very good.
Indeed! As I mention in a parallel message I tried it once and the
posterization made it virtually unusable. But it did "work".
2) as far as I know all my graphics cards have 8-bit/ch D/A converters and
8-bit/ch is not enough for gamma 1.0. Of course there is the additional
problem that in general monitors don't support gamma 1.0 anyhow.
Exactly! Hardware limitations also cause posterization at gamma 1.0.
Even at gamma 2.2 the limitations of 8-bit color are potentially a
problem when working with 16-bit images, not to mention HDR.
(Trying to use 8-bit/ch LUTs to convert from gamma 1.0 to 2.2 is bound to make
things even worse).
Again, I couldn't agree more! Which is yet another reason to avoid
unnecessary conversions and "guesswork" but try to be as exact as
possible. Which is why I would not describe a fixed 2-point S
correction as "Curves".
Looking at one image while editing another is exactly what my XYZ library
does. There is no magic there. (Of course, if you select in Photoshop
any color space other the monitor color space, you end up with the same
thing. Typically not with luminance, but with saturation).
Yes, but that's different which is why I noted "in the current
context".
It's quite common to look at one image while working on another and I
can list a number of such cases when such an approach makes sense. But
the problem here is it does not.
Anyway, it's all academic because apparently in case of Vuescan it's
even worse. There is no image to look at all! The "curves" can only be
set "blind" using *2 fixed* control points and are applied *after* a
whole bunch of other processing.
Don.