XnView Software

thanks to helmut i've been able to edit this post and include a
screenshot directly which illustrates this issue.


click to enlarge

the image clearly shows the selected raw negative displaying as
much brighter than it's thumbnail. in the browser there are three
negatives, bracketed in exposure. each negative is accompanied by
a positive. the same nconvert command produced the three positives
from each negative. this implies that nconvert is auto-correcting the
density of the raw image before it makes the positive. if that was not
the case, the three positives would show the exposure variations
from the bracketing. all six files are avaiable for upload if necessary
for debugging. the code that produced all three negatives follows.

in addition, though fuzzy, it can be seen that the bottom info bar
in the xnview window shows the raw image as 2193x1460. this is
incorrect. each dimension should be doubled to be correct.

found this behaviour using both v4.79 and v4.92 on wxp home.

here's a line from my script:

C:\Program_O\XnView\nconvert -out tga -log -high_res -raw_camerabalance -negate -brightness 80 -contrast 80 -gamma 1 -o $outname $wdgfile

the items with the '$' preceeding are variables which get their values from
elsewhere in my script. the 'negate' command is given as, in this case, i'm
capturing single images from a film negative.

the tip-off that there is something odd going on is that i can see noise
differences in the images as the exposures increment.

these are behaviours i posted about exactly a year ago and it's still
happening!:

http://newsgroup.xnview.com/viewtopic.p ... highlight=

edit: new info. just downloaded xnviewmp for osx. in the browser the
varying exposures of cr2 images is also correctly displayed here. the
image preview below and to the left of the main browsing frame also
shows the cr2 files correctly. this is different from the regular xnview app
in which this preview auto-corrects the image. if i click the tab labeled
'preview' at the top of the main window (next to the 'browser' tab), it takes
me to a full screen preview of the selected image. this full screen image
does auto-correct which is different from the behaviour in the previous
page.

browser frame: cr2 displays correctly
browser preview frame: cr2 displays correctly
full screen preview: cr2 displays incorrectly (auto-corrected)

obviously, this auto-correcting of raw images is a big problem as the
whole point of using raw is control. when the app takes that control
away from me it defeats the purpose of the format.

maybe some clues here as to how to get this fixed? hope so. and, by
the way, the new version looks very nice. my preference, however, is
to get this issue finally fixed for existing versions to make them fully
usable.

this is very frustrating. any help is appreciated,
BabaG

just checking. been a few days since i posted this. will anything
be done? is it reproducable? do you need files? is it low priority?
i have a lot of cr2 files to process now and was expecting to work
with nconvert.

over a week and no response at all?

Sorry for not replying. The problem is that your simple (?) problem has a long but complex description. I've tried to wade through your text but gave up after short time.

Could you perhaps describe your problem in some clearer words and/or samples. Is your problem in XnView or in nconvert or both? Is it just a viewing problem or a conversion problem? Thank you in advance for your help...

thanks for replying helmut. guess i was being confusing when i thought
i was being thorough!

the problem is with nconvert, and maybe xnview also. since nconvert
is not a viewer, though, i've used xnview to illustrate the nconvert issue.
that's what the screenshot is for. the fact that xnview also illustrates the
issue implies that it may also have the problem.

using nconvert, no matter what i do with a cr2 raw file, the raw file is
auto-corrected before i can process it. that means that if i have three
cr2 files of varying brightness in the originals, the variety of brightness
is lost because nconvert darkens the lighter one and lightens the
darker one.

a good example of this might be a series of shots of a sunset. one would
expect them to get darker as the sun goes down. using nconvert, however,
i cannot get this effect because nconvert brightens them up as they
naturally darken.

this is illustrated in the screenshot from xnview. i presume xnview uses
the same libraries and processes as nconvert in this regard since the
screenshot clearly illustrates the issue.

in the thumbnail frame of the xnview window there are three negatives,
a dark one, a middle one, and a light one. the screenshot shows one is
selected. the viewer frame below the thumbnail frame shows the
selected thumbnails parent raw file. it it clearly seen to be displayed as
being a different brightness than the thumbnail above it.

if i run the command line from the original post, all three negatives
produce positives that look the same. that should not be the case
since the command calls for 'raw_camerabalance'. they should vary
in brightness as do the negatives.

hth,
BabaG

Thanks, BabaG. So the problem is: nconvert auto-compensated the exposure of cr2 files which can be seen in the screenshot.

The first step to solve your problem is to understand and reproduce the problem. Could you provide three CR2 sample files?

i've pm'ed you with a link.

BabaG

BabaG wrote:i've pm'ed you with a link.

BabaG

Thanks for the link. Would it be possible to make the images publicly available (sure enough you should provide images which have no real value)? (This way, any person could try to reproduce your problem - not just me.)

they're kind of big. how would i do that?
or maybe you could grab them and put them someplace?
the images i've linked should be fine to post publicly.

BabaG

helmut, did anyone get the files?

BabaG

Sorry for not replying earlier. I've zipped and uploaded your CR2 images (30 MB).

Auto-Brightness in XnView: off
When viewing the CR2 images in XnView browser, one can notice that the thumbnails have different lightness, but the preview hasn't.

I've searched the options a bit and there's Tools > Options > General > Read/Write > Camera RAW > Automatic brigthness. For comparing different exposures it might be a good idea to turn this off. XnView will then no longer auto-correct the preview or the opened image.
BTW: Does this standard setting make sense?

Auto-correction in nconvert: Bug?
When using your conversion command line for nconvert above, I have the same result: The images converted by nconvert are auto-corrected.
This might be a bug or might have to do with the options used:
-raw_camerabalance
-brightness 80
-contrast 80
But I'm neither a RAW specialist and nor a nconvert specialist.

@Pierre: Could you please check and help, here?

thanks so much for the help, helmut. the xnview tip is helpful.
it's the nconvert issue, though, that is the real hindrance to the
things i'm trying to get done.

helmut wrote: Auto-correction in nconvert: Bug?
This might be a bug or might have to do with the options used:
-raw_camerabalance
-brightness 80
-contrast 80

these options should not have a marked effect on the tests as these
same options were applied to all three test images. since the test
images are of varying brightness, the processed images should
reflect these variances because they all get the SAME treatment:

-raw_camerabalance
-brightness 80
-contrast 80

the processed images all look the same, however. this implies that
they are being 'evened out' BEFORE they receive the above commands.
since all three are 'evened out' and then given the same processing,
they naturally all come out looking the same. close examination will,
however, reveal noise level differences in the images, presumably
due to the auto-correcting.

thanks again,
BabaG

I'll add auto brightness as an option in nconvert

xnview wrote:I'll add auto brightness as an option in nconvert

Are you sure that a new option will solve BabaG's problem?

my sense (from a non-programmer's point of view, of course), is that something like an auto-correction already exists, such as what is being used in xnview's thumbnail preview frame, and that possibly some code was copied from one place to another that included a call to that routine or function. if that was the case, it would only need to be found and commented out.

thanks for the attention,
much appreciated,
BabaG