VueScan and Digital Cameras
Ed Hamrick
digital cameras. This would fit nicely with VueScan's Q60
calibration capability, since it would allow very accurate color
correction of digital camera colors. VueScan's automatic color
balance algorithm would also work well with this.
I think I can get VueScan working with the raw files from
almost all digital cameras, possibly by the end of this week.
Does anyone have suggestions for additional features I need
to add to VueScan to work raw files from digital cameras?
For example, do I need to improve the file numbering for
raw files to make it more flexible?
Thanks,
Ed Hamrick
shAf
> I was thinking of adding support for raw files from a variety of
> digital cameras. This would fit nicely with VueScan's Q60
> calibration capability, since it would allow very accurate color
> correction of digital camera colors. VueScan's automatic color
> balance algorithm would also work well with this.
Software for working with d-cam raw files must growing faster than
software for scanning film. I certainly wouldn't mind if it were
incorporated into Vuescan, but if I were you, I separate the 2 projects into
independent softwares. This would also separate software upgrades as they
pertain to hardware issues.
--
cheerios ... shAf :o)
Avalon Peninsula, Newfoundland
www.micro-investigations.com
Ralf R. Radermacher
> ...but if I were you, I separate the 2 projects into
> independent softwares. This would also separate software upgrades as they
> pertain to hardware issues.
Just imagine the deluge of cross-posts from rec.photo.digital into this
nice and friendly newsgroup if Vuescan were to support digicams.
Please make it a separate product, Ed.
Ralf
--
Ralf R. Radermacher - DL9KCG - Köln/Cologne, Germany
private homepage: http://www.fotoralf.de
manual cameras and photo galleries - updated Apr. 11, 2003
Contarex - Kiev 60 - Horizon 202 - P6 mount lenses
Pasi Savolainen
I think You need easier (fassster and more intuitive) interface to edit
color balance and histogram in general. At the moment it requires
switching between two tabs.
If You intend this function to be used, then it needs to give fast
preview of what one's doing. I'm not 100% sure, but at the moment VS
looks like it's recalculating always whole image, not the contents of
window -> slow. Also histogram correction (black & white point) doesn't
work very intuitively and is not very comparable to other programs.
These changes, in my opinion, would benefit scanner users too.
--
Psi -- <http://www.iki.fi/pasi.savolainen>
Jon Bell
Ed Hamrick <use...@hamrick.com> wrote:
>I was thinking of adding support for raw files from a variety of
>digital cameras.
I'd definitely be interested in this. I recently bought a Minolta Dimage
7i, but haven't used raw files yet, partly because of storage issues (due
to their size) and partly because I have the impression (from reading
reviews) that Minolta's conversion utility doesn't do as good a job in
some ways as the camera's internal conversion software. The Bayer
interpolation algorithm in the utility seems to introduce artifacts into
the image.
But I'll be getting a portable hard drive for traveling this summer, so
storage will be less of an issue.
>For example, do I need to improve the file numbering for
>raw files to make it more flexible?
It seems to me that I'd most often want to do the conversion on batches of
images with consecutive file numbers, e.g. PICT0325.MRW through
PICT0400.MRW, but possibly with gaps from deleting duds in the camera's
review mode. So VusScan should at least be able to process them to
something like crop0325.tif to crop0400.tif, skipping over the gaps in the
numbering sequence so that the numbers on the TIFF files match the ones on
the raw files.
--
Jon Bell <jtbe...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
Caleb
be nice. If it is not much more work, support for the Nikon's raw
scanner NEF would be REALLY great too.
I still think the main thing you are missing for post processing
(scans or Digital camera) are the normal histogram and curve tools
(where you do manual/auto adjustments on the histogram and/or curve)
found in PS, PWP, Silverfast, The new PS digital camera raw plug-in,
etc, etc. This stops me from doing much corrections in VS...but I
love it for raw and simultaneous auto tif/jpg bulk scans.
On Tue, 6 May 2003 02:01:28 -0700, "Ed Hamrick" <use...@hamrick.com>
wrote:
Ed Hamrick
> Well Sure if you are doing this...support for Nikon NEF format would
> be nice.
I think it's already working. If you could put one on a
web site where I can download it, I'd be happy to test it.
I just got it working with CRW files, and the source code
I'm using says it works with more than a dozen different
raw scan files, including NEF files.
Even better would be a Nikon NEF file of an IT8 calibration
target - either a Q60 slide or a reflective target.
I can use this to make the colors quite accurate.
> If it is not much more work, support for the Nikon's raw
> scanner NEF would be REALLY great too.
I can probably get this working, but I need a sample.
Regards,
Ed Hamrick
shAf
> "shAf" <nadaya...@bigfoot.com> wrote:
> > Software for working with d-cam raw files must growing faster than
> > software for scanning film.
>
> [...]
>
> The vast majority of people use JPEG from digital cameras,
> and only a tiny minority of people use raw scan files from
> digital cameras. I don't think it's a big enough market
> to merit producing a separate product.
At this point in time, I agree. However, the Photoshop plugin for reading
RAW d-cam images seems to be extremely popular (and expensive), and I read
where more & more people are beginning to opt for raw because their d-cam is
ready for the next shot that much quicker (as if the JPEG algorithm has much
more overhead than writing a larger amount of data)(?) I therefore imagine,
if you give them an easy-to-use and affordable software for their raws, more
& more will use it.
Like I implied ... I don't care if you put into Vs or not, ... except to
say, it's already difficult to know when a Vs update applies to my
particular film (and flatbed) scanner or not.
Caleb
I would love to help you...three problrms though:
1) I do not have a nikon d camera, but do have a 4000Ed scanner. Do
you want a NEF from the scanner?
2) I have not yet gotten to IT8 calibration so cannot sent a slide
scan yet
3) I do not have a website to post the scan NEF to
If anyone has a site for me to post and Ed to dl, let me know. Or if
anyone has an IT8 scan AND a website, maybe you will help Ed out here.
Thanks
--Caleb
I could mail you a On Tue, 6 May 2003 08:30:05 -0700, "Ed Hamrick"
Bart van der Wolf
"Ed Hamrick" <use...@hamrick.com> wrote in message
news:b97tl9$n5m$1...@ngspool-d02.news.aol.com...
> I was thinking of adding support for raw files from a variety of
> digital cameras.
Whoa, talk about radical thinking! You never cease to amaze me.
> This would fit nicely with VueScan's Q60
> calibration capability, since it would allow very accurate color
> correction of digital camera colors. VueScan's automatic color
> balance algorithm would also work well with this.
I occasionally feed a Tiff from my camera to VueScan, it colorbalances fine.
I just found a way of creating Linear gamma output (despite the flaws in the
Canon SDK for the G3 and S45), and was creating profiles based on that. The
issue with the IT8 reflective targets is avoiding reflections from the
(glossy) surface. If you put it on a horizontal surface, you'll see the
clouds or blue sky with a darker backlit image of the camera. Wolf Faust
also has a special target for digicams which might help, he'll love you for
another boost in business ;-).
> I think I can get VueScan working with the raw files from
> almost all digital cameras, possibly by the end of this week.
Calling your bluff.
No, just kidding ;-) I'd really appreciate the possibility to work my
capture devices' raw data from a single application.
> Does anyone have suggestions for additional features I need
> to add to VueScan to work raw files from digital cameras?
You'll need to be able and suppress hot/dead pixels for better quality
conversions.
Digicams require similar exposure precautions as slide film. It is easy to
blow-out the highlights. You could consider a functionality similar to the
"Long exposure" option, but now for keeping the highlights. You could mix a
regular gamma adjusted low-middle brightness with a gamma 1 highlight image
to improve contrast in the highlights (e.g. cloud structure). That could
improve results when trying to squeeze 12-bit/channel input ranges into
8-bit/channel output devices.
An S-shape contrast control could also help.
> For example, do I need to improve the file numbering for
> raw files to make it more flexible?
Most likely, yes. You'd probably also need to be able and parse EXIF and
maker note info, for some sort of automation. But for the time being, I
suspect that being able to distinguish some of the conversion options tagged
to the original filename (but with a different extension) would serve many
purposes.
Ed Hamrick
> Wolf Faust
> also has a special target for digicams which might help
Yes, Wolf sent me one of these. I was primarily planning on
using it to produce ICC profiles for negative film, but it
will also be useful for calibrating digital cameras.
> > I think I can get VueScan working with the raw files from
> > almost all digital cameras, possibly by the end of this week.
>
> Calling your bluff.
<smile> - I win.
You can download a test version from:
http://www.hamrick.com/files/testdcam.exe (Windows)
http://www.hamrick.com/files/testdcam.sit (Mac OS 9/X)
http://www.hamrick.com/files/testdcam.tgz (Linux)
I don't recommend that anyone put links to these files on
a web page, since I plan to delete them in a few days.
Regards,
Ed Hamrick
Jouko Vierumäki
>
> Yes, Wolf sent me one of these. I was primarily planning on
> using it to produce ICC profiles for negative film, but it
> will also be useful for calibrating digital cameras.
You were planning... what? Tell us more about this! [I don't give a damn
about VS supporting digital cameras, but this is interesting :-]
Jouko
ThomasH
I think that the Vuescan has already with its '+' and '='
wildcards lovely mechanisms to control file batches and
their names. Especially I love Vuescan's ability to deal
with missing (non consecutive) raw file numbers. Dealing
with files from a digicam might be quite similar to dealing
with raw files of any other origin.
Two generic problems with file handling are present ever
since you began to use the 3rd party file handling library
on Windows (7.3.NN is my memory serves me):
1) Vuescan takes wrongly the "most recently used dir"
for either *.ini, *.icc or even raw files. This demands
frequently many clicks to change back to the proper place,
sometimes Vuescan starts and can not find its *.ini file
because it points to the most recent dir with raw files.
I suggest that Vuescan maintains the 2-4 path strings
internally and thus avoid any dealing with OS recent
directories.
2) Device|Frane Number=NN should use the same number
NN which is in the suffix of the raw file.
For example, if my 1st raw file is 12-name-02.tif,
the first frame number should be '2' and not '1'.
Than the output file name wildcard '=' would yield
the same frame number as well.
3) The 'next frame'/`prev frame' should automatically
jump to the next existing raw file instead of selecting
a missing frame and printing a popup one preview/scan
is pressed. For example,
...
02-raw-12.tif
02-raw-14.tif
...
Now vuescan would select frame 13 and show a popup about
'missing file or scanner' after the "preview/scan" click.
Thomas.
>
> Thanks,
> Ed Hamrick
Bart van der Wolf
SNIP
> > Calling your bluff.
>
> <smile> - I win.
>
> You can download a test version from:
A few observations:
Based on a limited number of samples, the Windows version works for Canon
1D, 10D, D30, D60 and G3/S45. It seems to not work with the G2 (but maybe my
sample is not good).
Profiling is necessary for reasonable (or better) color.
Selection of the Disk file name currently doesn't offer the choice for file
extentions other than Tiff, Jpeg and IT8 (it8, q60 and txt). The addition of
a *.* all types would avoid having to past or type the name. Color|Scanner
color space Built-in, probably defaults to sRGB but I got very poor colors
until profiling.
Bart
Caleb
--CalebOn Tue, 6 May 2003 23:52:53 +0200, "Jouko Vierumäki"
Caleb
--CalebOn Tue, 6 May 2003 23:52:53 +0200, "Jouko Vierumäki"
<jo...@vierumaki.com> wrote:
Carl Miller
a scanner app that simply scans well, and then uses a photo editor for
post production?
My problem with most of the scanner apps (and indeed, most apps in
general) is that they suffer from advanced feature-itus. Next release
it'll make julian fries!
I'm not picking on VueScan per say, but all I want to do with my
scanning software is scan. Maybe I'm just old fashioned.
--
Carl Miller
cmi...@trellis.net
---------
Using: OUI 1.9.2 Pro from http://www.ouisoft.com
Julian Vrieslander
cmi...@trellis.net (Carl Miller) wrote:
> My problem with most of the scanner apps (and indeed, most apps in
> general) is that they suffer from advanced feature-itus. Next release
> it'll make julian fries!
Cool. I'd like a burger with that, too. :-)
--
Julian Vrieslander
Pasi Savolainen
> Do you guys drive screws with a hammer too? Am I the only one who wants
> a scanner app that simply scans well, and then uses a photo editor for
> post production?
We're not talking apples and oranges here. A digicam RAW image is very
similar (thanks to Ed) to scanner RAW image, and needs same adjusting
_before_ going to photoeditor.
In as sense, you're right, and vuescan could be separated into image
acquiring and processing tools, but as it is a so much
feed-back-and-forward oriented, that wouldn't be a very beautiful
separation (from architechtural point of view).
Ed Hamrick
> You were planning... what? Tell us more about this!
I was thinking about taking a picture of Wolf's camera
target using various negative films, and then producing
ICC profiles that optimally correct the colors.
I'm thinking that I'll use exactly the same routines
I use for slide calibration, except computing the
profile after inverting the image using VueScan's
Generic film type.
This should be quite simple to do, and should correct
for negative film color characteristics.
To do this well, there would need to be a separate
ICC file for every combination of scanner and film,
which is a lot of different ICC files. This is why
I'll probably add this capability to VueScan so users
can do this themselves.
I was also thinking of adding the capability of
scanning a printed test target and producing a
printer ICC file (it's basically the same code as
all the other types of ICC calibration).
Regards,
Ed Hamrick
Ed Hamrick
> 1D, 10D, D30, D60 and G3/S45.
I don't think it works for the EOS-1D or EOS-1DS. I had to strip out
the code for lossless raw JPEG (which is what these scanners use).
> It seems to not work with the G2 (but maybe my
> sample is not good).
It should work with the G2. Could you e-mail this file to
me?
> Selection of the Disk file name currently doesn't offer the choice for
file
> extentions other than Tiff, Jpeg and IT8 (it8, q60 and txt).
Yes, I hadn't gotten to this yet.
Could you send me the list of extensions you know of for raw
digital camera files? I know of .CRW and .NEF.
> Color|Scanner
> color space Built-in, probably defaults to sRGB but I got very poor colors
> until profiling.
Could you send me pictures of IT8 calibration targets in raw
format for various digital cameras? I can then add the default
profiles for these cameras.
Thanks,
Ed Hamrick
Jouko Vierumäki
way. See below...
"Ed Hamrick" <use...@hamrick.com> wrote in message
news:b9a9j1$c1v$1...@ngspool-d02.news.aol.com...
>
> I was thinking about taking a picture of Wolf's camera
> target using various negative films, and then producing
> ICC profiles that optimally correct the colors.
OK; so you mean ICC profiles, not new sensitometric curves?
> I'm thinking that I'll use exactly the same routines
> I use for slide calibration, except computing the
> profile after inverting the image using VueScan's
> Generic film type.
OK, are the curves of "Generic" mathematical or are they based on some
particular film type?
> To do this well, there would need to be a separate
> ICC file for every combination of scanner and film,
> which is a lot of different ICC files. This is why
> I'll probably add this capability to VueScan so users
> can do this themselves.
This is probably the point where I got lost... Shouldn't the scanner's
characteristics be taken into account with the current "slide" profiles? I
mean, as there aren't negative targets around, how shall the users actually
do this themselves?
I'm very, VERY happy to hear you have activities on this area (colors with
negatives). As I have mailed you earlier, I have some difficulties in
getting the colors right - especially when film base color is locked.
Normally, either the red component is clearly too weak or the colors aren't
saturated enough. I have assumed that either the sensitometric curves aren't
correctly applied or the different compensation factors (film base color,
ICC profile, color balance and sensitometric curves) conflict with each
other at some point.
> I was also thinking of adding the capability of
> scanning a printed test target and producing a
> printer ICC file (it's basically the same code as
> all the other types of ICC calibration).
This, again, would be a great feature.
Jouko
Jacek Zagaja
>You could mix a regular gamma adjusted low-middle brightness
> with a gamma 1 highlight image to improve contrast in the highlights
Could you explain more how to use Tone Reproduction Curves for this
case? I thought that spatially variant Tone Reproduction Operators
(eg. Gradient Mask) is more flexible and maybe the only way.
JZ.
uncle sam
> scanning a printed test target and producing a
> printer ICC file (it's basically the same code as
> all the other types of ICC calibration).
>
Hey, now I am getting interested too! These printer
calibration programs are much harder to find, at
reasonable price.
Jacek Zagaja
>I have some difficulties in getting the colors right - especially when film base color is locked.
I noticed some problems when Vue tries to manage orange mask using
exposure setting with different time. I used LED light from Nikon
LS2000 and made densitometric LUTs for Portra 160VC using IT8-1 slide
target from Wolf. However it's accurate Vue produce orange mask with
different luminosity - sometimes RGB100, sometimes RGB190 so I changed
LUTs white point and made set of this film curves for different White
Point:
http://tme.szczecin.pl/~jacek/przyklady/portra400vc.htm
http://tme.szczecin.pl/~jacek/temp/Graphs/Portra400VC_DLUT.gif
So you see that ICC profiles makes you worry about the film base
color. Few years ago when we had LCMS ver. 1.08 I made CLUT with small
resolution. The profile was very good (HP S20 scanner). After this I
never repeated this luck:
http://tme.szczecin.pl/~jacek/temp/Photoshop/superia200.gif
>Normally, either the red component is clearly too weak or the colors aren't
>saturated enough.
Be aware of Fuji's 4th Layer films - they have orange mask R<G>B not
R>G>B.
>I have assumed that either the sensitometric curves aren't
>correctly applied or the different compensation factors (film base color,
>ICC profile, color balance and sensitometric curves) conflict with each
>other at some point.
The best purpose I think is to calculate one LUT for RAW image without
any additional wild ideas. Then you correct scanner light and the
film. You should leave colors (Gamut Mapping) since it's good to have
some film characteristic not changed (that photographers like). The
problems with RAW LUTs is in curve fitting - they are far from
polynomials.
Regards -- Jack,
Bob Shomler
> ...
> Does anyone have suggestions for additional features I need
> to add to VueScan to work raw files from digital cameras?
>
> For example, do I need to improve the file numbering for
> raw files to make it more flexible?
I'd recommend an option to retain raw file name, changing only the file
type for vuescan-produced files. Processing a Canon raw file
xxx-4276.crw could produce xxx-4276.tiff or xxx-4276.jpg.
Bob Shomler
Bart van der Wolf
"uncle sam" <uncle_...@yahoo.nospam.comm> wrote in message
news:3EB8F0AC...@yahoo.nospam.comm...
And printer calibration is like opening a whole new can of worms (printer
driver + ink + paper + scanner + viewing light conditions (metamerism,
fluorescence)). The brand of flatbed scanner also seems to make a huge
difference in success or failure rate (Epsons do very well).
Pricewise you'd want to check out Profile Prism
(http://www.ddisoftware.com/prism). It has a similar high standard of author
support as VueScan. I though that was hardly possible, but apparently it is
(although rare).
I wouldn't mind VueScan supporting printer profile creation by using a
scanner as colorimeter, but I just want to warn Ed that (inkjet/dye sub)
printers apparently need extremely erratic lut's, nothing close to a simple
matrix. It also takes much more detailed sets of color patches to tackle the
intermediate hues.
On the other hand, challenging Ed has resulted in some very useful
solutions...
Bart
Ed Hamrick
> driver + ink + paper + scanner + viewing light conditions (metamerism,
> fluorescence)).
It doesn't have to be perfect, it just has to be an improvement.
I suspect that computing the gamma will get 50% of the way
there, and computing a matrix profile will get another 25%
of the way to perfection. It doesn't have to be perfect, it
just has to be a lot better than most printer drivers to
be useful.
Regards,
Ed Hamrick
Bart van der Wolf
"Jacek Zagaja" <jza...@poczta.onet.pl> wrote in message
news:omqhbvkthjdh5usnf...@4ax.com...
I couldn't agree more, using HDR tone reproduction operators is the best
solution (I particularly like the gradient mask approach with a fine example
on your page). Unfortunately the math involved (as described in the paper
mentioned on http://www.cs.huji.ac.il/~danix/hdr/) seems to be unavailable
as e.g. an HDRshop plugin or other form for the general public.
So, lacking the most promising solution, one could use a combination of a
regular conversion (but lacking highlight detail) and a gamma 1 file for the
highlights only (higher contrast and better density). I occasionally do that
by hand in Photoshop (2 layers, delete or mask the shadows in the gamma 1
layer), but there are also pre-cooked actions available (e.g.
http://www.fredmiranda.com/HRpage/) to speed up the process. A popular raw
converter/viewer such as BreezeBrowser uses this priciple for improved
highlight detail.
The topic of improving highlight detail in Photoshop is perhaps better
explained in that newsgroup.
Bart
Harry
If most of people's d cam use JPEG file how can they benefit from your
integrating Vuescan with "raw file" reading?
Harry
"Ed Hamrick" <use...@hamrick.com> wrote in message
news:b989ac$6ga$1...@ngspool-d02.news.aol.com...
uncle sam
>
> I suspect that computing the gamma will get 50% of the way
> there, and computing a matrix profile will get another 25%
> of the way to perfection. It doesn't have to be perfect, it
> just has to be a lot better than most printer drivers to
> be useful.
That is true. Of course different profiles have to be made for
different papers, but if it can make the colors better than
original, then it is good enough.
If I want "perfect" prints, I send my pics to some photo lab,
where they print them with 100000$ machines. But still, some
printer calibration would be useful.
Ed Hamrick
> "Ed Hamrick" <use...@hamrick.com> wrote:
> > Yes, Wolf sent me one of these. I was primarily planning on
> > using it to produce ICC profiles for negative film, but it
> > will also be useful for calibrating digital cameras.
>
> You were planning... what? Tell us more about this! [I don't give a damn
> about VS supporting digital cameras, but this is interesting :-]
I released this yesterday. VueScan 7.6.37 can create ICC profiles
for negative films.
You need to take a picture of an IT8 target to do this, and then scan
this image. The VueScan User's Guide describes how to do this.
The best target for doing this is one of Wolf Faust's A4-sized
camera targets.
Regards,
Ed Hamrick
Ed Hamrick
> I'd recommend an option to retain raw file name, changing only the file
> type for vuescan-produced files. Processing a Canon raw file
> xxx-4276.crw could produce xxx-4276.tiff or xxx-4276.jpg.
I've added this to my list of things to do. How about something
like "*.tif" or "processed-*-from-crw.tif", where the "*" is
mapped to the file name part of the raw file name?
Regards,
Ed Hamrick
Bart van der Wolf
benefit, thus only a smaller percentage of all users (but still the ones
that would appreciate the benefits most). That would constitute too small a
market for maintaining a separate product, so he chose to integrate it into
the existing VueScan.
Bart
"Harry" <harryliu...@yahoo.com> wrote in message
news:uokua.37110$3n5....@news2.central.cox.net...
wally
I've a an Epson 2200 inkjet and a Cornerston 21" CRT running
1600x1200 on Matrox G450 video card. Tweaked it with Adobe
Gamma, installed Epson drivers and PIM plugin. When I hold up a
print on Epson Premium Glossy photo paper next to the image
displayed on the CRT monitor, the color accuracy is to me
amazingly good! I don't see how it'd be possible to do any
better without instruments more sensitive than my eyeballs to
measure the CRT displayed color vs the printout color in order to
adjust the printout color to be a "better" match.
OTOH my wife's Epson 825 and Viewsonic VA800 17" LCD panel
could be improved, but I'm not sure its the printer color you'd
want to adjust as the 825 printout is a very good match to the
same PSD file displayed on my Cornorstone crt monitor.
From a copy machine perspective your scheme is fine given a good
calibration target to scan since the monitor could be out of the
loop,. But from my "digital darkroom" perspective, I want what I
see on the monitor to match the printout I will get. If the scan
displayed on the monitor matches the silde displayed on the
lightbox I'm ecstatic. VueScan is making me very happy in terms
of minimizing color "corrections" needed before printing --
usually my adjustments are to correct the films rendition on
images with "mixed" light.
--wally.
Ed Hamrick
> This is going to depend a lot on where you start from.
Yes, some people's workflow is already quite accurate, and
these people won't need VueScan's printer calibration feature.
However, many people get dreadful colors when printing, and
these people will benefit from VueScan's printer calibration.
I've been working on this today, and it's almost working
in VueScan 7.6.38. I'll probably release it in a day or two.
Regards,
Ed Hamrick
Jacek Zagaja
>Unfortunately the math involved (as described in the paper
>mentioned on http://www.cs.huji.ac.il/~danix/hdr/) seems to be unavailable
>as e.g. an HDRshop plugin or other form for the general public.
Right as soon as the algorithm will not be shown we can't say much. My
last mail with Dani comes from September '02 - it's time to another.
I've just thinking how use my D60 12EV dynamic range. If I wan t use
only one TRC I would choose LOG. Exponentials applied on RAW image are
quite more popular for peoples because this is the same as "S" film
curve. But the problem is still the same: I can't get the same
Brightness from objetcts with different Luminance. But in most cases -
TRC applied using Middle Gray analysis works good. S-shaping helps to
improve light impression in scene:
http://tme.szczecin.pl/~jacek/temp/Graphs/backyard.jpg
I am very interested in results of GDHDRC on standard 16 bpc RAW
images exposed for highlights (very dark). The examples from Dani are
fine except the Notredam:
http://www.cs.huji.ac.il/~danix/hdr/enhancement.html
The original image (quite good):
ftp://ftp.kodak.com/www/images/pcd/notredam94.pcd
>A popular raw converter/viewer such as BreezeBrowser uses this principle for improved
>highlight detail.
Hmm, no sure. BB using exponential curves for output like other
digital camera software (partly because e.g. Canon G3 has a banding on
shadows):
http://tme.szczecin.pl/~jacek/temp/Graphs/Cat.jpg
JZ.
Bart van der Wolf
SNIP
> >A popular raw converter/viewer such as BreezeBrowser uses this principle
for improved
> >highlight detail.
>
> Hmm, no sure. BB using exponential curves for output like other
> digital camera software (partly because e.g. Canon G3 has a banding on
> shadows):
>
> http://tme.szczecin.pl/~jacek/temp/Graphs/Cat.jpg
Can I assume the conversion was done with BreezeBrowser? Was it a "Combined"
Raw conversion, Linear + Gamma, or a "Normal" one?
Bart
Jacek Zagaja
>Can I assume the conversion was done with Breeze Browser? Was it a "Combined"
>Raw conversion, Linear + Gamma, or a "Normal" one?
Yes the conversion was made by BB using default options:
- White Balance [as shot]
- Photo Effect [Normal, as shot]
- Conversion Method: Normal
BB using perceptual tweaking as many converters. You also have
"Neutral" filter in Photo Effects section but this is not what we
want. ICC makes good reproduction but shows camera limitations.
Another example:
http://tme.szczecin.pl/~jacek/temp/Graphs/Breezebrowser.jpg
BTW: the JPEGs from D60 are similar.
JZ.
Erik Krause
you wrote...
> I couldn't agree more, using HDR tone reproduction operators is the best
> solution (I particularly like the gradient mask approach with a fine example
> on your page). Unfortunately the math involved (as described in the paper
> mentioned on http://www.cs.huji.ac.il/~danix/hdr/) seems to be unavailable
> as e.g. an HDRshop plugin or other form for the general public.
Did you have a look at my free blending solution:
http://www.erik-krause.de/blending
Another example on Jaceks page (bottom right):
http://tme.szczecin.pl/~jacek/hdrc/index.html
(Hey, Jacek, thanks for the link, but it points to the wrong page!)
--
Erik Krause
Digital contrast problems: http://www.erik-krause.de/contrast
Bart van der Wolf
It would be interesting to compare this with Combined Raw conversion
(instead of Normal). Same for the cat image, these seem candidates for
better utilization of the 12EV dynamic range (assuming adequate highlight
exposure).
And to bring the topic back to scanners, I still think that (lacking HDRC)
an option like Highlight Recovery or Combined (whatever one would like to
call it) could help with squeezing the wide dynamic range into the more
limited range of most output devices.
Bart
Bart van der Wolf
"Erik Krause" <erik....@gmx.de> wrote in message
news:MPG.1924d6e14...@ID-18456.user.dfncis.de...
SNIP
Yes, I saw it. I've also tried (and sometimes use) similar approaches. They
all are laborious, require manual intervention, and still lack the sparkle
of HDR radiance recovery and true gradient mask tonemapping. A step in the
right direction is the Reinhard plugin for HDRshop
(http://athens.ict.usc.edu/HDRShop/), but I don't like the saturated and low
contrast highlights (http://www.gregdowning.com/HDRI/tonemap/Reinhard/). I
processed the example exposures from your page in HDRshop, applied the
Reinhard plugin, and got much better shadows and midtones. The highlights
still suck IMHO.
The best approach, and I agree with Jacek, is the method described in the
papers mentioned on http://www.debevec.org/Research/HDR/ and it can even be
used to enhance single exposures (instead of multiple exposures of
stationary objects).
Bart
uncle sam
>
> I've a an Epson 2200 inkjet and a Cornerston 21" CRT running
> 1600x1200 on Matrox G450 video card. Tweaked it with Adobe
> Gamma, installed Epson drivers and PIM plugin. When I hold up a
> print on Epson Premium Glossy photo paper next to the image
> displayed on the CRT monitor, the color accuracy is to me
> amazingly good! I don't see how it'd be possible to do any
> better without instruments more sensitive than my eyeballs to
> measure the CRT displayed color vs the printout color in order to
> adjust the printout color to be a "better" match.
To get your monitor calibrated you would need some hardware which
measures the color output of your monitor, for example Colorvision
Monitor Spyder.
Anyway, it is perfectly possible to get very good results with
new inkjet printers. It is just that I can use the icc profile
of the photo lab printer, the prints are printed in real photographic
paper (they last as long as "real" photos) and last: they are
cheaper than inkjet paper + ink. Occasionally I print some pics
with HP959, which could have some use of calibration.
> OTOH my wife's Epson 825 and Viewsonic VA800 17" LCD panel
> could be improved, but I'm not sure its the printer color you'd
> want to adjust as the 825 printout is a very good match to the
> same PSD file displayed on my Cornorstone crt monitor.
The LCD panel colors are usually much worse than CRT colors. Now
I am planning to experiment on calibrating my new LCD by placing
it on top of my Epson 1650 Scanner, and scanning the picture of
color target on the screen. (I have calibrated my scanner, so that
should be ok.) I don't have faintest idea is it going to work, but
who knows.
Erik Krause
> Yes, I saw it. I've also tried (and sometimes use) similar approaches.
You should try my actions to have an opinion about them ;-)
> They all are laborious, require manual intervention,
provided you create a droplet for the actions the only thing that
is required is to adjust the opacity of some layers. This way you
have absolute control over the result in real time. As far as I
know no other solution has this advantage. And if you get used to
it that takes only a few minutes. Far quicker than most solutions
that try to do all automatically.
> and still lack
> the sparkle of HDR radiance recovery and true gradient mask
> tonemapping.
The guys at Spheron have re-programmed the gradient domain
algorithm and they told me that it works for some images, and does
not work for others. The same is with my actions and some other
solutions. There is no way to do it full automatic till now.
> A step in the right direction is the Reinhard plugin for
> HDRshop (http://athens.ict.usc.edu/HDRShop/), but I don't like the
> saturated and low contrast highlights
> (http://www.gregdowning.com/HDRI/tonemap/Reinhard/).
Reinhard himself says that it is not useful for very high contrast.
> I processed the
> example exposures from your page in HDRshop, applied the Reinhard
> plugin, and got much better shadows and midtones. The highlights still
> suck IMHO.
You will have the possibility to adjust this to your satisfaction,
if you would use a solution that allows manual adjustment ;-)
> The best approach, and I agree with Jacek, is the method described in
> the papers mentioned on http://www.debevec.org/Research/HDR/ and it can
> even be used to enhance single exposures (instead of multiple exposures
> of stationary objects).
Is there anywhere described how I can create contrast compressed
LDR images from HDR radiance maps? AFAIK the Reinhard algorithm is
the first one that tries to actually compress HDRShop output to
LDR.
BTW.: This is a rapidly growing market. In the last few month there
where two new applications to do similar tasks:
Photomatix: http://www.multimediaphoto.com/photomatix/
and Anabuilder: http://anabuilder.free.fr/indexEN.html
and a new scientific approach:
http://www.cs.wright.edu/people/faculty/agoshtas/hdr.html
As I heard Spheron develops a own solution at the moment, based on
human perception research. I think this is the best approach since
HDR compression is not a question of mathematics but of viewing
psychology.
To get on topic: I consider this multiple image HDR as a problem of
digital cameras. I use Fuji Reala for high contrast situations now
and don't have the need to blend multiple exposures any more. Ben
Kreunen has tested Reala for it's HDR capabilities and found a
dynamic range of about 14 f-stops:
http://makeashorterlink.com/?Z23932084
My own small contribution: http://www.erik-krause.de/cn_hdr
Regards
--
Erik Krause
Jacek Zagaja
The manual contrast adjusting i.e. Density Masking is IMHO best option
now and many photographers use it. I made manual image of kitchen
which is very close to real scene.
> Ben Kreunen has tested Reala for it's HDR capabilities and found a
>dynamic range of about 14 f-stops
So It could beat Kodak Porta family :)
The funny thing is that this dynamic range can't be displayed on CRT
if the light impression is a point.
There are two thing I must ask now. In some papers I've found claims
that Cineon Graphic Stations using monitors with ref. white at 1000
cd/m^2. Is it possible?
The HD graphs for Astia and Reala EI500 seems to be made after
drinking:) Some photographers can be wrong thinking that Astia has
10+EV dynamic range:
http://www.fujifilm.com/JSP/fuji/epartners/images/f500d_curves_characteristic.gif
http://www.fujifilm.com/JSP/fuji/epartners/bin/AF3-943E.pdf
Do you see what is wrong with the graphs?
Right graphs:
http://www.tme.szczecin.pl/~jacek/temp/hd.htm
>My own small contribution: http://www.erik-krause.de/cn_hdr
I have had many e-mails with statement "my digicams (DSLRs) are
better. Image is sharper, clearer, colors are vivid etc." and "how to
get this effect". I can only say "scan it right" and your site shows
the effect.
JZ.
Bart van der Wolf
> Hello Bart van der Wolf, you wrote:
>
> > Yes, I saw it. I've also tried (and sometimes use) similar approaches.
>
> You should try my actions to have an opinion about them ;-)
Do you mean that they produce different results than the example results on
your webpages? ;-) I do assume you tried your best to get good results,
because that's the purpose of the exercise, but I'm still not satisfied
about the reduced contrast in shadow and mid tone areas. If you like me to
have a look at the latest version of your PS action(s), feel free to mail
them to me (just replace the nospam part of my address with xs4all, the name
of my ISP).
> > They all are laborious, require manual intervention,
>
> provided you create a droplet for the actions the only thing that
> is required is to adjust the opacity of some layers.
As a photographer, I prefer to get the exposure right from the start (e.g.
with fill-in flash or reflectors, or polarizing filters or wait for better
lighting) and only fix afterwards what couldn't be avoided (you sometimes
don't get the opportunity to set-up the scene lighting). That should in most
cases be possible with 2 or 3 exposures, which restricts the use to
stationary subjects.
I'm skilled enough to Photoshop my way out of most problem situations after
the fact, but as said it is laborious, and it is extremely hard to get
results as good as some mathematical processing can produce. Using HDRshop
to make a reasonable HDR composite is easy, unfortunately the LDR output is
restricted to 8-bit/channel images. I'll probably have to write my own
converter for 16-bit output, which could hold an exposure sequence of 16EV
dynamic range (already a challenge to tonemap into an 8-bit/c image).
Back to the subject line topic, Raw files of the better Digicams currently
offer 12-bit/c image data. It should be possible to at least tonemap that
into a smaller range, almost automatically.
SNIP
> > I processed the
> > example exposures from your page in HDRshop, applied the Reinhard
> > plugin, and got much better shadows and midtones. The highlights still
> > suck IMHO.
>
> You will have the possibility to adjust this to your satisfaction,
> if you would use a solution that allows manual adjustment ;-)
It is almost trivial to replace only the highlights of the Reinhard result
with one of the better exposures. So the procedure would be; With HDRshop,
create an HDR composite (or use a single 12-16 bit raw camera or scanner
file), apply the Reinhard tonemapping plugin and with Photoshop replace the
highlights with one of the better exposures (only having to manipulate 2
layers).
> > The best approach, and I agree with Jacek, is the method described in
> > the papers mentioned on http://www.debevec.org/Research/HDR/ and it can
> > even be used to enhance single exposures (instead of multiple exposures
> > of stationary objects).
>
> Is there anywhere described how I can create contrast compressed
> LDR images from HDR radiance maps? AFAIK the Reinhard algorithm is
> the first one that tries to actually compress HDRShop output to
> LDR.
There are several published methods. The ones I like best sofar are :
http://www.graphics.cornell.edu/academic/ARCH476.6/ward.pdf from Greg Ward
because his tonemapping is based on human perception (constant adaptation as
the eye scans over the image), and the paper from the Debevec.org site
mentioned above. But there are other, IMHO less impressive tonemapping
attempts published.
SNIP
> As I heard Spheron develops a own solution at the moment, based on
> human perception research. I think this is the best approach since
> HDR compression is not a question of mathematics but of viewing
> psychology.
See my remark on the Greg Ward method, but math is an unavoidable means to
get to the goal.
> To get on topic: I consider this multiple image HDR as a problem of
> digital cameras.
Well, they are currently restricted to 12-bit channels per exposure. Slide
film maxes out at 10 EV dynamic exposure range (with horrible shadow color
if pushed to that limit), so at exposure time I'd say digicam Raws have the
edge. Mind you, I'm talking about the exposure range. Print film has a
larger exposure latitude, but the response is not linear, while digicams
have close to linear response to exposure. Scanning introduces other issues
(e.g. high D-max in slides, contrast boost needed for printfilm, graininess
and Gamma adjustment for output), but that is another challenge.
> I use Fuji Reala for high contrast situations now
> and don't have the need to blend multiple exposures any more. Ben
> Kreunen has tested Reala for it's HDR capabilities and found a
> dynamic range of about 14 f-stops:
> http://makeashorterlink.com/?Z23932084
Yes, but Ben also states "Given the extremely broad "shoulder" of the
characteristic curve for this film it is difficult to pinpoint an exact
figure for the dynamic range". But it is true that printfilm spans a large
exposure range in a single exposure, which is useful if dealing with
non-stationary subjects.
> My own small contribution: http://www.erik-krause.de/cn_hdr
I would prefer a combination of the shadow/mid-range of the uncorrected
image at the top (the towels on the radiator look much more 3D than in the
corrected one), and the corrected outside image part.
Thanks for sharing your vision and approach to deal with the HDR tonemapping
issue,
Bart
Bob Shomler
>where the "*" is mapped to the file name part of the raw file name?
The first -- *.tif (or *.jpg) -- is what I use now with BreezeBrowser
and with Photoshop and its camera raw plugin. The second name structure
seems a bit cumbersome.
Bob Shomler
www.shomler.com
[email addr via web]
Ed Hamrick wrote:
> "Bob Shomler" <Bo...@shomler.com> wrote:
>
>>I'd recommend an option to retain raw file name, changing only the file
>>type for vuescan-produced files. Processing a Canon raw file
>>xxx-4276.crw could produce xxx-4276.tiff or xxx-4276.jpg.
>
>
> I've added this to my list of things to do.
>
> Regards,
> Ed Hamrick
>
>
Ed Hamrick
> >How about something like "*.tif" or "processed-*-from-crw.tif",
> >where the "*" is mapped to the file name part of the raw file name?
>
> The first -- *.tif (or *.jpg) -- is what I use now with BreezeBrowser
> and with Photoshop and its camera raw plugin. The second name structure
> seems a bit cumbersome.
The first is the same as the second. For instance, if the raw
file is xyz123.crw, then the output file for "*.tif" would be
"xyz123.tif" and the output file for "processed-*-from-crw.tif"
would be "processed-xyz123-from-crw.tif".
Regards,
Ed Hamrick
wally
>"wally" <wa...@nomail.com> wrote:
>> This is going to depend a lot on where you start from.
>
>Yes, some people's workflow is already quite accurate, and
>these people won't need VueScan's printer calibration feature.
>
>However, many people get dreadful colors when printing, and
>these people will benefit from VueScan's printer calibration.
>
monitor is well calibrated first. This calibration should help
make it obvious when the monitor's calibration is at fault -- if
the print of the scanned target is a good match to the original
but the display on the monitor is a poor match to the original or
the print.
I can now see how it might generally be more useful than I had
first thought
--wally.
Erik Krause
you wrote...
> > You should try my actions to have an opinion about them ;-)
>
> Do you mean that they produce different results than the example results on
> your webpages? ;-)
Yes, of course, if you want. It's up to you ;-)
> I do assume you tried your best to get good results,
I did, then. The images where created with the very first version of
the actions and I'm at version 1.2 now. Unfortunately I didn't find the
time to update the web page. See Jaceks page for an up to date example.
And at least it's a matter of taste what you consider good and what
not.
> If you like me to
> have a look at the latest version of your PS action(s), feel free to mail
> them to me
They are on the way...
> As a photographer, I prefer to get the exposure right from the start (e.g.
> with fill-in flash or reflectors, or polarizing filters or wait for better
> lighting) and only fix afterwards what couldn't be avoided (you sometimes
> don't get the opportunity to set-up the scene lighting). That should in most
> cases be possible with 2 or 3 exposures, which restricts the use to
> stationary subjects.
My actions are mostly used by VR panorama photographers. If you shoot
stitched panos in rooms you always have the problem of blown out
windows. And lighting is almost impossible for that.
> I'm skilled enough to Photoshop my way out of most problem situations after
> the fact, but as said it is laborious, and it is extremely hard to get
> results as good as some mathematical processing can produce.
We'll see ;-)
> Using HDRshop
> to make a reasonable HDR composite is easy, unfortunately the LDR output is
> restricted to 8-bit/channel images. I'll probably have to write my own
> converter for 16-bit output, which could hold an exposure sequence of 16EV
> dynamic range (already a challenge to tonemap into an 8-bit/c image).
That would be interesting.
> > Is there anywhere described how I can create contrast compressed
> > LDR images from HDR radiance maps? AFAIK the Reinhard algorithm is
> > the first one that tries to actually compress HDRShop output to
> > LDR.
>
> There are several published methods. The ones I like best sofar are :
> http://www.graphics.cornell.edu/academic/ARCH476.6/ward.pdf from Greg Ward
> because his tonemapping is based on human perception (constant adaptation as
> the eye scans over the image),
This would be ideal, indeed. A nice example on an adaptive dynamic
range pano is found here: http://www.fieldofview.nl/rd-adr.php
Regards