16bit editiing and auto-whitebalance

Hi

I just bought a Nikon D60 and started to experiment with Raw photos, so
I have two questions/suggestions (I'm on a gentoo box using latest beta):

- Why is 16bit dcraw decoding not enabled by default? 16bit is one of
the major reasons to use raw, so I would expect to have 16bit unless
instructed otherwise
- I've created just very few raw photos, but one thing struck me: Take
the following raw: http://n.ethz.ch/~bschindl/fotos/DSC_0033.NEF. The
embedded jpeg (which I assume is the one visible in the album view)
looks nicely vivid. But when opening the image, it looks _very_ bad. I
know cameras apply their set of improvements, but I have left the camera
with the default settings, so it shouldn't be this bad. Why is this so?
I know I can just do some color corrections to get this, but it would be
great if this would be the starting point for editing!

On another note - I read the comments on the raw workflow on dot.kde.org
which were posted on the digikam lookahead. I kinda have to agree - a
workflow as used in rawstudio for example would be extremely nice.

Cheers!
Benjamin
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2008/4/15, Benjamin Schindler <[hidden email]>:
> Hi
>
>  I just bought a Nikon D60 and started to experiment with Raw photos, so
>  I have two questions/suggestions (I'm on a gentoo box using latest beta):
>
>  - Why is 16bit dcraw decoding not enabled by default? 16bit is one of
>  the major reasons to use raw, so I would expect to have 16bit unless
>  instructed otherwise

8 bits by default because there is no auto-gamma with 16 bits color
depth with digiKam <= 0.9.3

>  - I've created just very few raw photos, but one thing struck me: Take
>  the following raw: http://n.ethz.ch/~bschindl/fotos/DSC_0033.NEF. The
>  embedded jpeg (which I assume is the one visible in the album view)
>  looks nicely vivid. But when opening the image, it looks _very_ bad. I
>  know cameras apply their set of improvements, but I have left the camera
>  with the default settings, so it shouldn't be this bad. Why is this so?
>  I know I can just do some color corrections to get this, but it would be
>  great if this would be the starting point for editing!

Done in 0.9.4. auto-gamma is implemented with 16 bits color depth

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Arnd Baecker]

On Tue, 15 Apr 2008, Gilles Caulier wrote:

> 2008/4/15, Benjamin Schindler <[hidden email]>:
> > Hi
> >
> >  I just bought a Nikon D60 and started to experiment with Raw photos, so
> >  I have two questions/suggestions (I'm on a gentoo box using latest beta):
> >
> >  - Why is 16bit dcraw decoding not enabled by default? 16bit is one of
> >  the major reasons to use raw, so I would expect to have 16bit unless
> >  instructed otherwise
>
> 8 bits by default because there is no auto-gamma with 16 bits color
> depth with digiKam <= 0.9.3

Should we now switch to 16 Bit as default ?

> >  - I've created just very few raw photos, but one thing struck me: Take
> >  the following raw: http://n.ethz.ch/~bschindl/fotos/DSC_0033.NEF. The
> >  embedded jpeg (which I assume is the one visible in the album view)
> >  looks nicely vivid. But when opening the image, it looks _very_ bad. I
> >  know cameras apply their set of improvements, but I have left the camera
> >  with the default settings, so it shouldn't be this bad. Why is this so?
> >  I know I can just do some color corrections to get this, but it would be
> >  great if this would be the starting point for editing!
>
> Done in 0.9.4. auto-gamma is implemented with 16 bits color depth

Well, even with current svn it just does not look good
enough to me.
Most likely this is not digikams fault (i.e., ufraw's output
looks similary dull to me) as no one (in open source) knows
the secret methods of raw to jpg conversion used by Nikon
(same with Canon of course, but there the results
looked much better, in the cases we looked at together, Gilles).

I am not sure if much can be done, though ....

Best, Arnd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Hi

Sorry, I wasn't specific enough. I was testing this on 0.9.4-beta3...

Cheers
Benjamin

Gilles Caulier wrote:

> 2008/4/15, Benjamin Schindler <[hidden email]>:
>  
>> Hi
>>
>>  I just bought a Nikon D60 and started to experiment with Raw photos, so
>>  I have two questions/suggestions (I'm on a gentoo box using latest beta):
>>
>>  - Why is 16bit dcraw decoding not enabled by default? 16bit is one of
>>  the major reasons to use raw, so I would expect to have 16bit unless
>>  instructed otherwise
>>    
>
> 8 bits by default because there is no auto-gamma with 16 bits color
> depth with digiKam <= 0.9.3
>
>  
>>  - I've created just very few raw photos, but one thing struck me: Take
>>  the following raw: http://n.ethz.ch/~bschindl/fotos/DSC_0033.NEF. The
>>  embedded jpeg (which I assume is the one visible in the album view)
>>  looks nicely vivid. But when opening the image, it looks _very_ bad. I
>>  know cameras apply their set of improvements, but I have left the camera
>>  with the default settings, so it shouldn't be this bad. Why is this so?
>>  I know I can just do some color corrections to get this, but it would be
>>  great if this would be the starting point for editing!
>>    
>
> Done in 0.9.4. auto-gamma is implemented with 16 bits color depth
>
> Gilles Caulier
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>  

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone-3]

Bugzilla from [e-mail] wrote

On Tue, 15 Apr 2008, Gilles Caulier wrote:

Should we now switch to 16 Bit as default ?

> Done in 0.9.4. auto-gamma is implemented with 16 bits color depth

Most likely this is not digikams fault (i.e., ufraw's output
looks similary dull to me) as no one (in open source) knows
the secret methods of raw to jpg conversion used by Nikon
(same with Canon of course, but there the results
looked much better, in the cases we looked at together, Gilles).

I am not sure if much can be done, though ....

Best, Arnd

Hi, all,

I think it's very true that Canon and presumably Nikon have some kind of "secret sauce" that they use to produce really good-looking images, whether straight out of the camera as jpegs, or whether as the result of using the proprietary Canon/Nikon raw developer software.  The "secret sauce" has two parts - color (hue and saturation) and tonality (distribution of lights and darks).  

Canon DPP, the "not for linux" Canon proprietary raw development software, is based on the same "picture styles" that Canon uses for in-camera jpegs.  Most Canon picture styles automatically add a heavy S-curve and extra color saturation to give the picture more "pop".  Even if you (1)choose "neutral" (the Canon picture style that gives you the most accurate "scene-referred" colors); and (2)select "less contrast", "less saturation", "no noise reduction", and "no sharpening" in the DPP raw development dialog, you will find, if you know what to look for, that an S-curve and also shadow denoising has been applied to your image.

Dcraw gives you the lights and darks that are actually recorded by the CCD.  According to Tindeman (http://21stcenturyshoebox.com; alas the site is down at present), dcraw is one of only a very few raw developers that actually gives you the "scene-referred" tonality.  And it IS flat-looking, because the camera CCD records light linearly, whereas our eyes are constantly interacting with our brain to accomodate dim and bright areas in a scene.

Color fidelity is a different story.  Color is where the Canon (and presumably Nikon) secret sauce really comes into play.  With the latest dcraw, you can apply Canon's camera-model-specific color profile(s) to the 16-bit dcraw output tiff during the raw development process, and the colors will still NOT be exactly the same as what Canon produces.  I've checked extensively, using an "eyedropper", comparing the output of various raw developers using various camera profiles - a very tedious though instructive process.  Canon default jpeg and DPP colors are really good.  (If you want to hear some belly-aching about Canon colors being "better", try a google search on what Adobe Camera Raw does to Canon colors - NObody likes the default ACR output for Canon raw files.)  It seems to me that the only way to "do better" color-wise than what Canon produces with their "secret sauce" is to produce your own color profile for your camera, using Argyll, for example, and give your custom color profile to dcraw/digikam,ufraw/etc.  I haven't taken that step yet (next on my "learning the digital darkroom" agenda).  

So why on earth would anyone want to use dcraw to develop a raw file, only to have an image with rather flat tonality (no S-curve), noise in the shadows (no noise reduction unless you specifically choose the wavelet denoising, which I never do), and colors that are not as accurate as what Canon can produce "in-camera"?  

The answer is artistic control.  When you take a picture, presumably you have an idea of what you want the final image to look like.  It is much easier to achieve that final image if you don't have to "undo" stuff that has already been done to your image.  Once Canon (or Nikon, or Bibble, or etc) has applied their proprietary S-curves and shadow-denoising, sharpening, etc to your image, then your shadows (highlights, edge detail, etc) are already squashed, clipped, chopped, and otherwise altered and mangled.  You've thrown information away and you can't get it back.  Especially in the shadows, even with 16-bit images (actually, 12- or 14-bits, depending on the camera, but it's encoded as 16-bits for the computer's convenience), there just isn't that much information to begin with, as explained in Ron Bigelow's excellent article,  http://www.ronbigelow.com/articles/raw/raw.htm.  

Anyway, I hope my long-winded discussion of why dcraw output looks "flat" helps cast some light on a confusing subject.  "Flat is good" if you'd rather give your images your own artistic interpretation.  The alternative is to let the canned, proprietary algorithms produced by Canon, Nikon, Bibble, etc interpret your images for you.  Which is not entirely a bad idea - for most images, most of the time, those canned alrorithms are really pretty good!  

If I've made mistakes in my explanation, please correct me!

Elle

Hi Elle

Thanks for the very detailled reply. You are of course right that an unmanipulated tif is better than the one with the secret sauce to work with when doing manipulations.
The thing is... I don't know in advance which picture I'm going to manipulate. This means that I'll shoot everything in raw which makes processing every picture using dcraw extremely time-consuming. So - to me at least, but I guess for many others as well - the ideal workflow would be:

- Develop all raw files as a batch process using the secret sauce. Gives a good starting point
- Throw away bad pictures
- Reprocess pictures that need manual processing

To me, it seems this first step is kinda hard to do nicely on linux atm. I wasn't able to get ViewNX/CaptureNX to work in wine, lightroom isn't available either. Rawstudio does not really do anything by default (which is good in it's own way) and doesn't have any exif support (in the works, but not released) and the kipi-plugin doesn't do the secret sauce thing. There is rawtherapee and lightzone - both of which are closed source and don't contain support for my D60 (yet)

So this is kinda bad atm

Cheers, Benjamin
elle stone wrote:

>
> Bugzilla from [hidden email] wrote:
>> On Tue, 15 Apr 2008, Gilles Caulier wrote:
>>
>> Should we now switch to 16 Bit as default ?
>>
>>> Done in 0.9.4. auto-gamma is implemented with 16 bits color depth
>> Most likely this is not digikams fault (i.e., ufraw's output
>> looks similary dull to me) as no one (in open source) knows
>> the secret methods of raw to jpg conversion used by Nikon
>> (same with Canon of course, but there the results
>> looked much better, in the cases we looked at together, Gilles).
>>
>> I am not sure if much can be done, though ....
>>
>> Best, Arnd
>>
>>
>
> Hi, all,
>
> I think it's very true that Canon and presumably Nikon have some kind of
> "secret sauce" that they use to produce really good-looking images, whether
> straight out of the camera as jpegs, or whether as the result of using the
> proprietary Canon/Nikon raw developer software.  The "secret sauce" has two
> parts - color (hue and saturation) and tonality (distribution of lights and
> darks).  
>
> Canon DPP, the "not for linux" Canon proprietary raw development software,
> is based on the same "picture styles" that Canon uses for in-camera jpegs.
> Most Canon picture styles automatically add a heavy S-curve and extra color
> saturation to give the picture more "pop".  Even if you (1)choose "neutral"
> (the Canon picture style that gives you the most accurate "scene-referred"
> colors); and (2)select "less contrast", "less saturation", "no noise
> reduction", and "no sharpening" in the DPP raw development dialog, you will
> find, if you know what to look for, that an S-curve and also shadow
> denoising has been applied to your image.
>
> Dcraw gives you the lights and darks that are actually recorded by the CCD.
> According to Tindeman
> (http://21stcenturyshoebox.com/tools/ACRcalibrator.html; alas the site is
> down at present), dcraw is one of only a very few raw developers that
> actually gives you the "scene-referred" tonality.  And it IS flat-looking,
> because the camera CCD records light linearly, whereas our eyes are
> constantly interacting with our brain to accomodate dim and bright areas in
> a scene.
>
> Color fidelity is a different story.  Color is where the Canon (and
> presumably Nikon) secret sauce really comes into play.  With the latest
> dcraw, you can apply Canon's camera-model-specific color profile(s) to the
> 16-bit dcraw output tiff during the raw development process, and the colors
> will still NOT not be exactly the same as what Canon produces.  I've checked
> extensively, using an "eyedropper", comparing the output of various raw
> developers using various camera profiles - a very tedious though instructive
> process.  Canon default jpeg and DPP colors are really good.  (If you want
> to hear some belly-aching about Canon colors being "better", try a google
> search on what Adobe Camera Raw does to Canon colors - NObody likes the
> default ACR output for Canon raw files.)  It seems to me that the only way
> to "do better" color-wise than what Canon produces with their "secret sauce"
> is to produce your own color profile for your camera, using Argyll, for
> example, and give your custom color profile to dcraw/digikam,ufraw/etc.  I
> haven't taken that step yet (next on my "learning the digital darkroom"
> agenda).  
>
> So why on earth would anyone want to use dcraw to develop a raw file, only
> to have an image with rather flat tonality (no S-curve), noise in the
> shadows (no noise reduction unless you specifically choose the wavelet
> denoising, which I never do), and colors that are not as accurate as what
> Canon can produce "in-camera"?  
>
> The answer is artistic control.  When you take a picture, presumably you
> have an idea of what you want the final image to look like.  It is much
> easier to achieve that final image if you don't have to "undo" stuff that
> has already been done to your image.  Once Canon (or Nikon, or Bibble, or
> etc) has applied their proprietary S-curves and shadow-denoising,
> sharpening, etc to your image, then your shadows (highlights, edge detail,
> etc) are already squashed, clipped, chopped, and otherwise altered and
> mangled.  You've thrown information away and you can't get it back.
> Especially in the shadows, even with 16-bit images (actually, 12- or
> 14-bits, depending on the camera, but it's encoded as 16-bits for the
> computer's convenience), there just isn't that much information to begin
> with, as explained in Ron Bigelow's excellent article,
> http://www.ronbigelow.com/articles/raw/raw.htm.  
>
> Anyway, I hope my long-winded discussion of why dcraw output looks "flat"
> helps cast some light on a confusing subject.  "Flat is good" if you'd
> rather give your images your own artistic interpretation.  The alternative
> is to let the canned, proprietary algorithms produced by Canon, Nikon,
> Bibble, etc interpret your images for you.  Which is not entirely a bad idea
> - for most images, most of the time, those canned alrorithms are really
> pretty good!  
>
> If I've made mistakes in my explanation, please correct me!
>
> Elle
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone-3]

Benjamin Schindler wrote:

> The thing is... I don't know in advance which picture I'm going to
> manipulate. This means that I'll shoot everything in raw which makes
> processing every picture using dcraw extremely time-consuming.
> To me, it seems this first step is kinda hard to do nicely on linux atm. I
> wasn't able to get ViewNX/CaptureNX to work in wine,
> So this is kinda bad atm
>
Quoted from:
http://www.nabble.com/16bit-editiing-and-auto-whitebalance-tp16701397p17143601.html

Hi, Benjamin,

I have a few suggestions regarding previewing images before selecting the "good ones" - I'm a Canon user, so some suggestions might not be applicable to you.

1. My Canon 400d offers the option of shooting each picture both in raw and as a low, medium, or high quality jpeg.  Does the Nikon have a similar option?  

2. Also, my canon raw files all contain a very low res jpeg embedded in the file.  I use dcraw to extract the jpeg.  The command is:  /usr/local/dcraw/dcraw -e /media/process/ingest/*.CR2

That is, I have dcraw installed locally, so the first part of the command is the path to the local installation executable "/usr/local/dcraw/dcraw" then the option "-e" for "extract" and then the path to where the raw images are stored "/media/process/ingest/", then the files themselves, "*.CR2" or ".NEF" in your case (this command is case-sensitive).  These embedded jpegs are very low res, but look exactly like the default secret sauce end product and are perfect for quick review as they load MUCH faster than a raw file.  Do the *.nef files have an embedded jpeg?

3.  Xnview is a great little image viewer, available both in a linux and windows version.  Apparently the windows version under wine works better than the linux version (I use xnview under wine).  Xnview can show you the embedded jpeg as a thumbnail, and then show you a larger version.  Xnview's renditions are very good.  I just checked and Xnview says it reads *.nef files.

4. If you have a windows CD you can install windows in a VirtualBox - W2K actually runs much better for me in a VirtualBox under linux than it ever did on "bare metal".  But this is a stop-gap measure, of course, I'm slowly weaning myself away from windows altogether.  

Elle

[Lawrence Plug]

Hi Benjamin and Elle,

Digikam* displays the low-res jpeg that is embedded in raw files,
both as a thumbnail and as a single-click enlarged preview. At
least it does for Nikon D300 and D70 NEFs and for Oly E-1 and E-3
ORFs. Those are all the cameras I've tried.  So I'm not sure why
Elle's step 2 is necessary? Am I missing something? Besides
digikam, many other apps display the lowres jpeg as well. As elle
notes, the embedded jpeg does have the camera's gamma and
'cookbook' recipe applied, and in my experience composition,
exposure, and gross sharpness/focus problems can be detected from
this lowres image.

Regarding step 1 --raw + jpeg-- I usually do that too, even
though the raw preview is available. It is a better criteria for
selecting which to develop.

cheers
L

(*applies to digikam 0.9.2  to 0.9.4)


On Fri, May 09, 2008 at 04:51:57AM -0700, elle stone wrote:

>
> Benjamin Schindler wrote:
>
> > The thing is... I don't know in advance which picture I'm going to
> > manipulate. This means that I'll shoot everything in raw which makes
> > processing every picture using dcraw extremely time-consuming.
> > To me, it seems this first step is kinda hard to do nicely on linux atm. I
> > wasn't able to get ViewNX/CaptureNX to work in wine,
> > So this is kinda bad atm
> >
> Quoted from:
> http://www.nabble.com/16bit-editiing-and-auto-whitebalance-tp16701397p17143601.html
>
> Hi, Benjamin,
>
> I have a few suggestions regarding previewing images before selecting the
> "good ones" - I'm a Canon user, so some suggestions might not be applicable
> to you.
>
> 1. My Canon 400d offers the option of shooting each picture both in raw and
> as a low, medium, or high quality jpeg.  Does the Nikon have a similar
> option?  
>
> 2. Also, my canon raw files all contain a very low res jpeg embedded in the
> file.  I use dcraw to extract the jpeg.  The command is:
> /usr/local/dcraw/dcraw -e /media/process/ingest/*.CR2
>
> That is, I have dcraw installed locally, so the first part of the command is
> the path to the local installation executable "/usr/local/dcraw/dcraw" then
> the option "-e" for "extract" and then the path to where the raw images are
> stored "/media/process/ingest/", then the files themselves, "*.CR2" or
> ".NEF" in your case (this command is case-sensitive).  These embedded jpegs
> are very low res, but look exactly like the default secret sauce end product
> and are perfect for quick review as they load MUCH faster than a raw file.
> Do the *.nef files have an embedded jpeg?
>
> 3.  Xnview is a great little image viewer, available both in a linux and
> windows version.  Apparently the windows version under wine works better
> than the linux version (I use xnview under wine).  Xnview can show you the
> embedded jpeg as a thumbnail, and then show you a larger version.  Xnview's
> renditions are very good.  I just checked and Xnview says it reads *.nef
> files.
>
> 4. If you have a windows CD you can install windows in a VirtualBox - W2K
> actually runs much better for me in a VirtualBox under linux than it ever
> did on "bare metal".  But this is a stop-gap measure, of course, I'm slowly
> weaning myself away from windows altogether.  
>
> Elle
>
> --
> View this message in context: http://www.nabble.com/16bit-editiing-and-auto-whitebalance-tp16701397p17146376.html
> Sent from the digikam-users mailing list archive at Nabble.com.
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

--
   | Lawrence Plug         Earth Sciences, Dalhousie Univ |    
   |  [hidden email]           t:902.494.1200  f:902.494.6889 |    

...
You are capable of planning your future.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gerhard Kulzer-3]

On Friday 09 May 2008 Lawrence Plug wrote:

> Hi Benjamin and Elle,
>
> Digikam* displays the low-res jpeg that is embedded in raw files,
> both as a thumbnail and as a single-click enlarged preview. At
> least it does for Nikon D300 and D70 NEFs and for Oly E-1 and E-3
> ORFs. Those are all the cameras I've tried.  So I'm not sure why
> Elle's step 2 is necessary? Am I missing something? Besides
> digikam, many other apps display the lowres jpeg as well. As elle
> notes, the embedded jpeg does have the camera's gamma and
> 'cookbook' recipe applied, and in my experience composition,
> exposure, and gross sharpness/focus problems can be detected from
> this lowres image.

This holds true, and if you have a recent libkdcraw the D60 is supported. I always work with digiKam for reviewing the raw image quality, no need to extract thumbnails by another application, digiKam does it.

Best regards
Gerhard

>
> Regarding step 1 --raw + jpeg-- I usually do that too, even
> though the raw preview is available. It is a better criteria for
> selecting which to develop.
>
> cheers
> L
>
> (*applies to digikam 0.9.2  to 0.9.4)
>
>
> On Fri, May 09, 2008 at 04:51:57AM -0700, elle stone wrote:
> >
> > Benjamin Schindler wrote:
> >
> > > The thing is... I don't know in advance which picture I'm going to
> > > manipulate. This means that I'll shoot everything in raw which makes
> > > processing every picture using dcraw extremely time-consuming.
> > > To me, it seems this first step is kinda hard to do nicely on linux atm. I
> > > wasn't able to get ViewNX/CaptureNX to work in wine,
> > > So this is kinda bad atm
> > >
> > Quoted from:
> > http://www.nabble.com/16bit-editiing-and-auto-whitebalance-tp16701397p17143601.html
> >
> > Hi, Benjamin,
> >
> > I have a few suggestions regarding previewing images before selecting the
> > "good ones" - I'm a Canon user, so some suggestions might not be applicable
> > to you.
> >
> > 1. My Canon 400d offers the option of shooting each picture both in raw and
> > as a low, medium, or high quality jpeg.  Does the Nikon have a similar
> > option?  
> >
> > 2. Also, my canon raw files all contain a very low res jpeg embedded in the
> > file.  I use dcraw to extract the jpeg.  The command is:
> > /usr/local/dcraw/dcraw -e /media/process/ingest/*.CR2
> >
> > That is, I have dcraw installed locally, so the first part of the command is
> > the path to the local installation executable "/usr/local/dcraw/dcraw" then
> > the option "-e" for "extract" and then the path to where the raw images are
> > stored "/media/process/ingest/", then the files themselves, "*.CR2" or
> > ".NEF" in your case (this command is case-sensitive).  These embedded jpegs
> > are very low res, but look exactly like the default secret sauce end product
> > and are perfect for quick review as they load MUCH faster than a raw file.
> > Do the *.nef files have an embedded jpeg?
> >
> > 3.  Xnview is a great little image viewer, available both in a linux and
> > windows version.  Apparently the windows version under wine works better
> > than the linux version (I use xnview under wine).  Xnview can show you the
> > embedded jpeg as a thumbnail, and then show you a larger version.  Xnview's
> > renditions are very good.  I just checked and Xnview says it reads *.nef
> > files.
> >
> > 4. If you have a windows CD you can install windows in a VirtualBox - W2K
> > actually runs much better for me in a VirtualBox under linux than it ever
> > did on "bare metal".  But this is a stop-gap measure, of course, I'm slowly
> > weaning myself away from windows altogether.  
> >
> > Elle
> >
> > --
> > View this message in context: http://www.nabble.com/16bit-editiing-and-auto-whitebalance-tp16701397p17146376.html
> > Sent from the digikam-users mailing list archive at Nabble.com.
> >
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Hi Elle


elle stone wrote:

> Benjamin Schindler wrote:
>
>  
>> The thing is... I don't know in advance which picture I'm going to
>> manipulate. This means that I'll shoot everything in raw which makes
>> processing every picture using dcraw extremely time-consuming.
>> To me, it seems this first step is kinda hard to do nicely on linux atm. I
>> wasn't able to get ViewNX/CaptureNX to work in wine,
>> So this is kinda bad atm
>>
>>    
> Quoted from:
> http://www.nabble.com/16bit-editiing-and-auto-whitebalance-tp16701397p17143601.html
>
> Hi, Benjamin,
>
> I have a few suggestions regarding previewing images before selecting the
> "good ones" - I'm a Canon user, so some suggestions might not be applicable
> to you.
>
> 1. My Canon 400d offers the option of shooting each picture both in raw and
> as a low, medium, or high quality jpeg.  Does the Nikon have a similar
> option?  
>  

The D60 only has Raw + jpeg Basic. basic might be okay, but then again -
if I could use i.e. the viewnx extractor, there would be no need for it.
I don't like doing the jpeg+raw thing, because it eats a lot of space on
the flash card which is especially a problem when on vaction
> 2. Also, my canon raw files all contain a very low res jpeg embedded in the
> file.  I use dcraw to extract the jpeg.  The command is:
> /usr/local/dcraw/dcraw -e /media/process/ingest/*.CR2
>  
I know I can use the preview. The Preview of the nikon isn't all that
bad actually. It is a full 10mp file (on bare resolution, not on
quality) so it's actually quite usable.
But you know - I'm a prefectionist.. I'm seeking the optimum :)

> That is, I have dcraw installed locally, so the first part of the command is
> the path to the local installation executable "/usr/local/dcraw/dcraw" then
> the option "-e" for "extract" and then the path to where the raw images are
> stored "/media/process/ingest/", then the files themselves, "*.CR2" or
> ".NEF" in your case (this command is case-sensitive).  These embedded jpegs
> are very low res, but look exactly like the default secret sauce end product
> and are perfect for quick review as they load MUCH faster than a raw file.
> Do the *.nef files have an embedded jpeg?
>
> 3.  Xnview is a great little image viewer, available both in a linux and
> windows version.  Apparently the windows version under wine works better
> than the linux version (I use xnview under wine).  Xnview can show you the
> embedded jpeg as a thumbnail, and then show you a larger version.  Xnview's
> renditions are very good.  I just checked and Xnview says it reads *.nef
> files.
>
> 4. If you have a windows CD you can install windows in a VirtualBox - W2K
> actually runs much better for me in a VirtualBox under linux than it ever
> did on "bare metal".  But this is a stop-gap measure, of course, I'm slowly
> weaning myself away from windows altogether.
>  

That's what I'm planning on doing. If Windows installation just wouldn't
bring down vmware... :(

Thanks again!

Benjamin
> Elle
>
>  

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone-3]

Gerhard Kulzer-3 wrote

This holds true, and if you have a recent libkdcraw the D60 is supported. I always work with digiKam for reviewing the raw image quality, no need to extract thumbnails by another application, digiKam does it.

Hi Lawrence and Gerhard,

Does digikam extract the jpeg as a separate file, or display it as a substitute for the decoded raw file, or both?  I extract the embedded jpeg as a separate file (from the command line - it's just easier for my particular workflow) and use it for storing metadata and also for quick reviews regarding sharpness, etc, as Gerhard suggests.  The Canon 400d embedded jpegs are around 700kb, more than big enough for emailing to friends, so useful to have as separate files.

[Gerhard Kulzer-3]

On Monday 12 May 2008 elle stone wrote:

>
> Gerhard Kulzer-3 wrote:
> >
> >
> > This holds true, and if you have a recent libkdcraw the D60 is supported.
> > I always work with digiKam for reviewing the raw image quality, no need to
> > extract thumbnails by another application, digiKam does it.
> >
> >
> Hi Lawrence and Gerhard,
>
> Does digikam extract the jpeg as a separate file, or display it as a
> substitute for the decoded raw file, or both?  I extract the embedded jpeg
> as a separate file (from the command line - it's just easier for my
> particular workflow) and use it for storing metadata and also for quick
> reviews regarding sharpness, etc, as Gerhard suggests.  The Canon 400d
> embedded jpegs are around 700kb, more than big enough for emailing to
> friends, so useful to have as separate files.

digiKam extracts the embedded thumbnail in the RAW image on the fly, not as a separate file (but a separate file can be easily created with: dcraw -e .*CR2 for example).

Gerhard
 

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users