Re: Vuescan - new features
- From: Don <phoney.email@xxxxxxxxx>
- Date: Mon, 05 Dec 2005 19:40:03 +0100
On Mon, 5 Dec 2005 00:27:23 +0100, philip@xxxxxxxxxxxxxxxxx (Philip
Homburg) wrote:
>>Yes, you can set points directly (i.e. blind) in the curve but that's
>>a very blunt instrument. Doing that means making assumptions about the
>>image. For example, using the "standard" S curve (64,128,192) assumes
>>where the shadows, midtones and highlights are.
>>
>>However, even in that case, basing this "blind" setting on a gamma 2.2
>>image while the curve is applied to a gamma 1.0 image doesn't get
>>around that root problem.
>
>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.
>>It wouldn't be the first time that Vuescan fails to do the simplest of
>>things which is precisely why it can be justifiably described as buggy
>>and unreliable.
>
>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.
>>>If you select bin 128 in the window, then yes, you may end up changing bin
>>>56 in the 2.2 gamma corrected image. But the 2.2 gamma correct image is only
>>>there to display what you are doing. The real image is in gamma 1.0.
>>
>>Which is precisely the root of the problem, apparently.
>
>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.
>>>You 'cannot' display a gamma 1.0 image directly.
>>
>>I notice quotes around 'cannot' which means you know what I'm going to
>>say (so just ignore the next bit) but for the benefit of kibitzers:
>>
>>Actually, one can. That's what linear editing is all about. One simply
>>recalibrates the monitor to gamma 1.0 as well and then the image does
>>not appear "dark and contrasty".
>
>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".
>>But even in that case looking at one image while editing another (in
>>the current context) is just asking for trouble. But such convoluted
>>contraptions are one of the major trademarks of Vuescan and why it is
>>so buggy and unreliable.
>
>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.
.
- References:
- Vuescan - new features
- From: Robert Feinman
- Re: Vuescan - new features
- From: Don
- Re: Vuescan - new features
- From: Philip Homburg
- Re: Vuescan - new features
- From: Don
- Re: Vuescan - new features
- From: Philip Homburg
- Vuescan - new features
- Prev by Date: Re: Vuescan - new features
- Next by Date: Re: Scanning from within a Visual Basic project
- Previous by thread: Re: Vuescan - new features
- Next by thread: Re: Vuescan - new features
- Index(es):
Relevant Pages
|