Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How long does it take to convert a raw camera file to "default" JPG?

13 views
Skip to first unread message

Mark F

unread,
Jun 9, 2010, 3:26:44 PM6/9/10
to
How long should it take to convert a "raw" camera file to a
"default" JPG?

My machine is pretty old (Pentium 4, 2.40GHZ)

It takes a minute or two of CPU time to convert a Fujifilm FinePix
S100fs RAF file to JPG taking "default" conversion parameters.

I tried FinePix Viewer that came with the camera and
s7raw (arbitrarily selected from Google searches and located
at www.geocities.co.jp/SiliconValley-PaloAlto/9919/s7raw.html)

The camera can store directly as 3MB JPG files much
faster than it can store 23MB RAW files.

Can someone suggest parameters that are faster than the
defaults in FinePix Viewer or a faster converter and
defaults?

I don't mind spending some money (I have Adobe CS3 Premium
and am willing to upgrade to CS5) but I don't feel like
using all of the space that CS takes compared to even FinePix
Viewer.

ray

unread,
Jun 9, 2010, 3:36:15 PM6/9/10
to

I've found dcraw to be quick for my situation - it's free.

Doug McDonald

unread,
Jun 9, 2010, 3:43:14 PM6/9/10
to

On my old Pentium 4, for Canon CR2 files, both Photoshop CS2 and dcraw take
about 20 seconds to convert to JPEG. This does not seem to depend on the
quality level.

Doug

Floyd L. Davidson

unread,
Jun 9, 2010, 5:20:26 PM6/9/10
to

Dcraw is wonderful for what it is, but its user
interface is not meant for general purpose conversions.
A photographer needs an interface that allows previewing
results in order to select appropriate options for best
results.

UFRAW is probably the best front end for dcraw. It
provides all of the necessary options for a general
purpose RAW converter. It can produce JPEG images
directly (as well as TIFF or PPM images). It can also
be configured to generate only an "ID" file, which
contains the configuration used by the interactive
adjustments so that they can be used by the batch
processor.

For example, I just ran off converstions on 65 RAW files
(14-bit compressed NEF files from a D3S) as a batch.
Since all of these had virtually the same
characteristics, only one image was actually done
interactively. Then ufraw-batch was invoked on the
entire list of files, using the ID file to set the
configuration:

ufraw-batch --conf=DSC_0001.ufraw *.nef

At other times, when each shot requires individual
configuration, I invoke ufraw interactively on the
entire list, and produce an ID file for each image.
Then ufraw-batch is invoked on the ID files:

ufraw-batch *.ufraw

In fact though, I cheat. I use Linux and have a script
that determines how many CPU's the system has and then
feeds a loop that keeps all of the CPU's busy. One box
that I use has 4 CPU's, and another has 8. The script
works them to the max. The 4 CPU box processes images
at 6 seconds per image. (If ufraw-batch is invoked
normally, and uses just 1 CPU serially, it takes 21
seconds per image on that particular system.)

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com

ray

unread,
Jun 9, 2010, 5:55:06 PM6/9/10
to
On Wed, 09 Jun 2010 13:20:26 -0800, Floyd L. Davidson wrote:

> ray <r...@zianet.com> wrote:
>>On Wed, 09 Jun 2010 15:26:44 -0400, Mark F wrote:
>>
>>> How long should it take to convert a "raw" camera file to a "default"
>>> JPG?
>>>
>>> My machine is pretty old (Pentium 4, 2.40GHZ)
>>>
>>> It takes a minute or two of CPU time to convert a Fujifilm FinePix
>>> S100fs RAF file to JPG taking "default" conversion parameters.
>>>
>>> I tried FinePix Viewer that came with the camera and s7raw
>>> (arbitrarily selected from Google searches and located at
>>> www.geocities.co.jp/SiliconValley-PaloAlto/9919/s7raw.html)
>>>
>>> The camera can store directly as 3MB JPG files much faster than it can
>>> store 23MB RAW files.
>>>
>>> Can someone suggest parameters that are faster than the defaults in
>>> FinePix Viewer or a faster converter and defaults?
>>>
>>> I don't mind spending some money (I have Adobe CS3 Premium and am
>>> willing to upgrade to CS5) but I don't feel like using all of the
>>> space that CS takes compared to even FinePix Viewer.
>>
>>I've found dcraw to be quick for my situation - it's free.
>
> Dcraw is wonderful for what it is, but its user interface is not meant
> for general purpose conversions. A photographer needs an interface that
> allows previewing results in order to select appropriate options for
> best results.

I use ufraw for that - but it's not what the OP asked about.

>
> UFRAW is probably the best front end for dcraw. It provides all of the
> necessary options for a general purpose RAW converter. It can produce
> JPEG images directly (as well as TIFF or PPM images). It can also be
> configured to generate only an "ID" file, which contains the
> configuration used by the interactive adjustments so that they can be
> used by the batch processor.
>
> For example, I just ran off converstions on 65 RAW files (14-bit
> compressed NEF files from a D3S) as a batch. Since all of these had
> virtually the same characteristics, only one image was actually done
> interactively. Then ufraw-batch was invoked on the entire list of
> files, using the ID file to set the configuration:
>
> ufraw-batch --conf=DSC_0001.ufraw *.nef
>
> At other times, when each shot requires individual configuration, I
> invoke ufraw interactively on the entire list, and produce an ID file
> for each image. Then ufraw-batch is invoked on the ID files:
>
> ufraw-batch *.ufraw
>
> In fact though, I cheat. I use Linux and have a script that determines
> how many CPU's the system has and then feeds a loop that keeps all of
> the CPU's busy. One box that I use has 4 CPU's, and another has 8. The
> script works them to the max. The 4 CPU box processes images at 6
> seconds per image. (If ufraw-batch is invoked normally, and uses just 1
> CPU serially, it takes 21 seconds per image on that particular system.)

Mine, Ubuntu on single cpu 2.4ghz P4, does my kdc images in five seconds
using ufraw. It will also depend on the camera's resolution - as that
determines how much data must be processed and on the particular raw
format as some are a little more complex than others.

nospam

unread,
Jun 9, 2010, 5:59:15 PM6/9/10
to
In article <grpv061jjnkl35tuh...@4ax.com>, Mark F
<mark...@gmail.com> wrote:

> How long should it take to convert a "raw" camera file to a
> "default" JPG?

depends on the size of the raw file, software and computer.

> My machine is pretty old (Pentium 4, 2.40GHZ)

how much memory?

> It takes a minute or two of CPU time to convert a Fujifilm FinePix
> S100fs RAF file to JPG taking "default" conversion parameters.

that camera is 11 megapixels and 1-2 minutes is absurdly slow. it
shouldn't be than about 10-15 seconds, and even that is long.

> I don't mind spending some money (I have Adobe CS3 Premium
> and am willing to upgrade to CS5) but I don't feel like
> using all of the space that CS takes compared to even FinePix
> Viewer.

upgrading photoshop won't make raw conversions that much faster (but it
may be worth it for other reasons), however, a new computer with a lot
of memory will.

nospam

unread,
Jun 9, 2010, 5:59:32 PM6/9/10
to
In article <87a8pf...@mid.individual.net>, ray <r...@zianet.com>
wrote:

> I've found dcraw to be quick for my situation - it's free.

dcraw is one of the slowest raw converters.

Mike Russell

unread,
Jun 9, 2010, 7:07:44 PM6/9/10
to
On Wed, 09 Jun 2010 15:26:44 -0400, Mark F wrote:

> How long should it take to convert a "raw" camera file to a
> "default" JPG?
>
> My machine is pretty old (Pentium 4, 2.40GHZ)
>
> It takes a minute or two of CPU time to convert a Fujifilm FinePix
> S100fs RAF file to JPG taking "default" conversion parameters.

That's not such a slow system. How much memory do you have? If it's less
than 2 gigs, that's probably the bottleneck. Memory is cheap.
--
Mike Russell - http://www.curvemeister.com

Floyd L. Davidson

unread,
Jun 9, 2010, 7:40:40 PM6/9/10
to
ray <r...@zianet.com> wrote:
>On Wed, 09 Jun 2010 13:20:26 -0800, Floyd L. Davidson wrote:
>
>> ray <r...@zianet.com> wrote:
>>>On Wed, 09 Jun 2010 15:26:44 -0400, Mark F wrote:
>>>
>>>> How long should it take to convert a "raw" camera file to a "default"
>>>> JPG?
...

>>>I've found dcraw to be quick for my situation - it's free.
>>
>> Dcraw is wonderful for what it is, but its user interface is not meant
>> for general purpose conversions. A photographer needs an interface that
>> allows previewing results in order to select appropriate options for
>> best results.
>
>I use ufraw for that - but it's not what the OP asked about.

Then your interpretation of what he asked is different
than mine.

Mine is that until he defines "default", it might mean a
number of things. One definition would be that it
defaults to the in camera JPEG settings... and dcraw
does not do that at all (nor does UFRAW). In that case
though, dcraw (and not UFRAW) could be used to simply
extract the embedded JPEG images from the RAW file, but
what that produces depends on which brand of camera and
on how the camera is configured.

I'm assuming the user wants to define the default
settings, rather than assuming (the absurd notion) that
dcraw has defaults that are somehow "correct".

Generating a user defined default requires UFRAW.

>> In fact though, I cheat. I use Linux and have a script that determines
>> how many CPU's the system has and then feeds a loop that keeps all of
>> the CPU's busy. One box that I use has 4 CPU's, and another has 8. The
>> script works them to the max. The 4 CPU box processes images at 6
>> seconds per image. (If ufraw-batch is invoked normally, and uses just 1
>> CPU serially, it takes 21 seconds per image on that particular system.)
>
>Mine, Ubuntu on single cpu 2.4ghz P4, does my kdc images in five seconds
>using ufraw. It will also depend on the camera's resolution - as that
>determines how much data must be processed and on the particular raw
>format as some are a little more complex than others.

The time values are not useful for across the board
comparison. There are other differences too. Disk i/o
speed over a network for example, the image format of
the output file, the type of compression and the bit
depth of the RAW file, are all significant and will vary
from one set of hardware to another.

With a different camera using 12-bit uncompressed files,
but at lower resolution and generating JPEG rather that
TIFF formatted output files, the single CPU time is 1.9
seconds per image, and the multi-CPU time is 0.7 seconds
per image.

My original point was to show one possible way to
optimize batch processing to get the most out of
available hardware, which essentially indicates that
just asking how long it takes to accomplish a conversion
does not produce answers that are useful.

ray

unread,
Jun 9, 2010, 8:08:01 PM6/9/10
to

Damn - I could have sworn I just said that!

ray

unread,
Jun 9, 2010, 8:09:03 PM6/9/10
to

Doubtful. It shouldn't take 2gb memory to convert a 12mp image!

Floyd L. Davidson

unread,
Jun 9, 2010, 9:02:52 PM6/9/10
to

tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -h dsc_7022.nef
real 0m0.131s

You should actually try it before claiming to know
something about how it works.

Floyd L. Davidson

unread,
Jun 9, 2010, 9:23:20 PM6/9/10
to
ray <r...@zianet.com> wrote:
>On Wed, 09 Jun 2010 15:40:40 -0800, Floyd L. Davidson wrote:
>
>> ray <r...@zianet.com> wrote:
>>>On Wed, 09 Jun 2010 13:20:26 -0800, Floyd L. Davidson wrote:
>>>
>>>> In fact though, I cheat. I use Linux and have a script that
>>>> determines how many CPU's the system has and then feeds a loop that
>>>> keeps all of the CPU's busy. One box that I use has 4 CPU's, and
>>>> another has 8. The script works them to the max. The 4 CPU box
>>>> processes images at 6 seconds per image. (If ufraw-batch is invoked
>>>> normally, and uses just 1 CPU serially, it takes 21 seconds per image
>>>> on that particular system.)
>>>
>>>Mine, Ubuntu on single cpu 2.4ghz P4, does my kdc images in five seconds
>>>using ufraw. It will also depend on the camera's resolution - as that
>>>determines how much data must be processed and on the particular raw
>>>format as some are a little more complex than others.
>>
>> The time values are not useful for across the board comparison. There
>> are other differences too. Disk i/o speed over a network for example,
>> the image format of the output file, the type of compression and the bit
>> depth of the RAW file, are all significant and will vary from one set of
>> hardware to another.
>
>Damn - I could have sworn I just said that!

Except you didn't.

ray

unread,
Jun 9, 2010, 10:13:27 PM6/9/10
to
On Wed, 09 Jun 2010 17:23:20 -0800, Floyd L. Davidson wrote:

> ray <r...@zianet.com> wrote:
>>On Wed, 09 Jun 2010 15:40:40 -0800, Floyd L. Davidson wrote:
>>
>>> ray <r...@zianet.com> wrote:
>>>>On Wed, 09 Jun 2010 13:20:26 -0800, Floyd L. Davidson wrote:
>>>>
>>>>> In fact though, I cheat. I use Linux and have a script that
>>>>> determines how many CPU's the system has and then feeds a loop that
>>>>> keeps all of the CPU's busy. One box that I use has 4 CPU's, and
>>>>> another has 8. The script works them to the max. The 4 CPU box
>>>>> processes images at 6 seconds per image. (If ufraw-batch is invoked
>>>>> normally, and uses just 1 CPU serially, it takes 21 seconds per
>>>>> image on that particular system.)
>>>>
>>>>Mine, Ubuntu on single cpu 2.4ghz P4, does my kdc images in five
>>>>seconds using ufraw. It will also depend on the camera's resolution -
>>>>as that determines how much data must be processed and on the
>>>>particular raw format as some are a little more complex than others.
>>>
>>> The time values are not useful for across the board comparison. There
>>> are other differences too. Disk i/o speed over a network for example,
>>> the image format of the output file, the type of compression and the
>>> bit depth of the RAW file, are all significant and will vary from one
>>> set of hardware to another.
>>
>>Damn - I could have sworn I just said that!
>
> Except you didn't.

Ah - I see you have a little reading comprehension problem - that's OK.

nospam

unread,
Jun 9, 2010, 11:00:23 PM6/9/10
to
In article <87k4q7d...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> >> I've found dcraw to be quick for my situation - it's free.
> >
> >dcraw is one of the slowest raw converters.
>
> tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -h dsc_7022.nef
> real 0m0.131s

> You should actually try it before claiming to know
> something about how it works.

i've compared both and dcraw is a lot slower than camera raw on the
same hardware.

Floyd L. Davidson

unread,
Jun 10, 2010, 2:37:17 AM6/10/10
to
ray <r...@zianet.com> wrote:
>
>Ah - I see you have a little reading comprehension problem - that's OK.

You'll have to try harder than that Ray. (Lot's harder... :-)

Floyd L. Davidson

unread,
Jun 10, 2010, 4:21:20 AM6/10/10
to

I'll wait for credible comparisons.

nospam

unread,
Jun 10, 2010, 5:29:21 AM6/10/10
to
In article <87y6enb...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> >> >> I've found dcraw to be quick for my situation - it's free.
> >> >
> >> >dcraw is one of the slowest raw converters.
> >>
> >> tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -h dsc_7022.nef
> >> real 0m0.131s
> >
> >> You should actually try it before claiming to know
> >> something about how it works.
> >
> >i've compared both and dcraw is a lot slower than camera raw on the
> >same hardware.
>
> I'll wait for credible comparisons.

says the person who provided a comparison with only *one* timing! a
comparison needs at least one *other* timing with which to compare.
that's why it's called a comparison.

furthermore, the -h option outputs a half-size image, which the man
page says is twice as fast as the high-speed low-quality option. in
other words, it's bogus and not a real world representation of a
typical workflow, as if about 1/8th of a second was even believable.

there's also no data on the size of the raw file, how many pixels it
has or what type of hardware was used.

Floyd L. Davidson

unread,
Jun 10, 2010, 6:41:28 AM6/10/10
to
nospam <nos...@nospam.invalid> wrote:
>In article <87y6enb...@apaflo.com>, Floyd L. Davidson
><fl...@apaflo.com> wrote:
>
>> >> >> I've found dcraw to be quick for my situation - it's free.
>> >> >
>> >> >dcraw is one of the slowest raw converters.
>> >>
>> >> tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -h dsc_7022.nef
>> >> real 0m0.131s
>> >
>> >> You should actually try it before claiming to know
>> >> something about how it works.
>> >
>> >i've compared both and dcraw is a lot slower than camera raw on the
>> >same hardware.
>>
>> I'll wait for credible comparisons.
>
>says the person who provided a comparison with only *one* timing! a
>comparison needs at least one *other* timing with which to compare.
>that's why it's called a comparison.

I've already provided multiple examples of times for
UFRAW running in various configurations. Pay attention,
eh?

>furthermore, the -h option outputs a half-size image, which the man
>page says is twice as fast as the high-speed low-quality option. in
>other words, it's bogus and not a real world representation of a
>typical workflow, as if about 1/8th of a second was even believable.

Not bogus, just optimized for speed. That actually is
very reasonable for someone (such as the OP) who merely
wants a 'default' image for comparison. For production
purposes it might be used for previewing, for example.

Clearly the speed of dcraw just blows you mind away!

>there's also no data on the size of the raw file, how many pixels it
>has or what type of hardware was used.

The point was that *you* can't get another raw converter
to run that fast.

Here are other options for that same file:

tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -h dsc_7022.nef
real 0m0.131s

tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -q 0 dsc_7022.nef
real 0m0.391s

tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -q 2 dsc_7022.nef
real 0m0.459s

tanana:floyd /u10/p5/2006/jan31a 0>time dcraw -q 3 dsc_7022.nef
real 0m1.042s

It is indeed an interesting file too!

File Name : dsc_7022.nef
File Size : 3.9 MB
File Type : NEF
Camera Model Name : NIKON D1
Bits Per Sample : 12
Compression : Uncompressed

Here are the same options on another NEF file:

tanana:floyd /u5/2010/jun8 0>time dcraw -h d3f_0091.nef
real 0m0.243s

tanana:floyd /u5/2010/jun8 0>time dcraw -q 0 d3f_0091.nef
real 0m0.778s

tanana:floyd /u5/2010/jun8 0>time dcraw -q 2 d3f_0091.nef
real 0m0.857s

tanana:floyd /u5/2010/jun8 0>time dcraw -q 3 d3f_0091.nef
real 0m2.026s

The Exif data:

File Name : d3f_0091.nef
File Size : 8.2 MB
File Type : NEF
Camera Model Name : NIKON D3
Bits Per Sample : 12
Compression : Uncompressed

And from yet another file:

tanana:floyd /u5/2010/jun7 0>time dcraw -h d3s_4936.nef
real 0m0.931s

tanana:floyd /u5/2010/jun7 0>time dcraw -q 0 d3s_4936.nef
real 0m2.139s

tanana:floyd /u5/2010/jun7 0>time dcraw -q 2 d3s_4936.nef
real 0m2.395s

tanana:floyd /u5/2010/jun7 0>time dcraw -q 3 d3s_4936.nef
real 0m4.907s

And Exif data:

File Name : d3s_4936.nef
File Size : 14 MB
File Type : NEF
Camera Model Name : NIKON D3S
Bits Per Sample : 14
Compression : Nikon NEF Compressed


Your complaint about no comparisons is invalid, given
the number of data points that I'd already listed for
UFRAW running on different systems. Obviously at it's
best UFRAW is four times slower than dcraw.

Incidentally, the system for all of the times has been
one running a pair of dual core Opteron AMD 275
processors in 64 bit mode with a 2.2Ghz clock. (The
process of course runs only on one processor as it does
not run in a threaded mode.) Clearly this is no where
near the fastest hardware available.

nospam

unread,
Jun 10, 2010, 7:14:51 AM6/10/10
to
In article <87pqzzb...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> The point was that *you* can't get another raw converter
> to run that fast.

first of all, your timings are not elapsed time, and second, i can
easily process a raw *much* faster than dcraw can.

here's a comparison, using a nikon d700 image (12 mp) on a 2.6 ghz core
2 duo laptop (not the fastest these days either):

% time dcraw DSC_0052.NEF
16.456u 0.374s 0:17.49 96.1% 0+0k 0+21io 1pf+0w

% time dcraw -h DSC_0052.NEF
3.877u 0.116s 0:04.09 97.3% 0+0k 0+0io 0pf+0w

in high speed mode, dcraw is just over 4 seconds, and in default mode,
it's 17.5 seconds!

photoshop & camera raw is about 2 seconds to open the raw. there's no
way to run time on it.

thus, camera raw is twice as fast as the half-size low-quality mode of
dcraw and almost *nine* times as fast as normal mode.

dcraw is *slow* (and worse than i recall too).

> Your complaint about no comparisons is invalid,

it's invalid if you don't have timings from other raw converters.

> given
> the number of data points that I'd already listed for
> UFRAW running on different systems. Obviously at it's
> best UFRAW is four times slower than dcraw.

ufraw is actually a more appropriate comparison with camera raw, so my
test ends up being very biased *for* dcraw, yet it still lost.

> Incidentally, the system for all of the times has been
> one running a pair of dual core Opteron AMD 275
> processors in 64 bit mode with a 2.2Ghz clock. (The
> process of course runs only on one processor as it does
> not run in a threaded mode.)

that's one reason why it's so slow. why isn't it threaded?

> Clearly this is no where
> near the fastest hardware available.

nor was mine.

Floyd L. Davidson

unread,
Jun 10, 2010, 7:51:13 AM6/10/10
to
nospam <nos...@nospam.invalid> wrote:
>In article <87pqzzb...@apaflo.com>, Floyd L. Davidson
><fl...@apaflo.com> wrote:
>
>> The point was that *you* can't get another raw converter
>> to run that fast.
>
>first of all, your timings are not elapsed time, and second, i can
>easily process a raw *much* faster than dcraw can.

Eh? If they are not "elapsed time", what are they???

>here's a comparison, using a nikon d700 image (12 mp) on a 2.6 ghz core
>2 duo laptop (not the fastest these days either):
>
>% time dcraw DSC_0052.NEF
>16.456u 0.374s 0:17.49 96.1% 0+0k 0+21io 1pf+0w
>
>% time dcraw -h DSC_0052.NEF
>3.877u 0.116s 0:04.09 97.3% 0+0k 0+0io 0pf+0w
>
>in high speed mode, dcraw is just over 4 seconds, and in default mode,
>it's 17.5 seconds!

Okay, you've got a very slow system.

Incidentally, the 17.5 seconds time that you are using
is *exactly* the same measurement that I provided and
you said above was not elapsed time. (Try reading the
man page for the time command.)

>photoshop & camera raw is about 2 seconds to open the raw. there's no
>way to run time on it.
>
>thus, camera raw is twice as fast as the half-size low-quality mode of
>dcraw and almost *nine* times as fast as normal mode.
>
>dcraw is *slow* (and worse than i recall too).

So you can't show times to support your claims?

Sounds like a personal problem.

>> Your complaint about no comparisons is invalid,
>
>it's invalid if you don't have timings from other raw converters.

Which I had already provided, so what's your problem?

>> given
>> the number of data points that I'd already listed for
>> UFRAW running on different systems. Obviously at it's
>> best UFRAW is four times slower than dcraw.
>
>ufraw is actually a more appropriate comparison with camera raw, so my
>test ends up being very biased *for* dcraw, yet it still lost.

It seems to have won.

>> Incidentally, the system for all of the times has been
>> one running a pair of dual core Opteron AMD 275
>> processors in 64 bit mode with a 2.2Ghz clock. (The
>> process of course runs only on one processor as it does
>> not run in a threaded mode.)
>
>that's one reason why it's so slow. why isn't it threaded?

Do you have a clue?

>> Clearly this is no where
>> near the fastest hardware available.
>
>nor was mine.

Well, we agree on that.

nospam

unread,
Jun 10, 2010, 8:29:24 AM6/10/10
to
In article <87k4q7a...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> So you can't show times to support your claims?

i did.

> > it's invalid if you don't have timings from other raw converters.
>
> Which I had already provided, so what's your problem?

where are the timings for the other raw converters, namely camera raw,
so we can see how fast or slow it is on your system?

so far, all you've posted is dcraw timings.

Floyd L. Davidson

unread,
Jun 10, 2010, 9:02:31 AM6/10/10
to
nospam <nos...@nospam.invalid> wrote:
>In article <87k4q7a...@apaflo.com>, Floyd L. Davidson
><fl...@apaflo.com> wrote:
>
>> So you can't show times to support your claims?
>
>i did.

No you didn't.

>> > it's invalid if you don't have timings from other raw converters.
>>
>> Which I had already provided, so what's your problem?
>
>where are the timings for the other raw converters, namely camera raw,
>so we can see how fast or slow it is on your system?
>
>so far, all you've posted is dcraw timings.

I posted several articles with a variety of times for
UFRAW.

I take it you do now also realize that the times that I
gave *are* elapsed time, and were exactly the same
elapsed time measurements that you posted?

Whatever, this thread has run its length. Whether dcraw
is actually faster or not is of very little
significance, particularly when you seem to be comparing
it to something you can't time, and therefore can't run
individually or in a batch process without a GUI
invoked. That pretty much negates any significance of
speed in the terms the OP was asking about.

If you have nothing more useful to discuss, I'm not likely
to respond further.

ray

unread,
Jun 10, 2010, 11:40:43 AM6/10/10
to
On Wed, 09 Jun 2010 22:37:17 -0800, Floyd L. Davidson wrote:

> ray <r...@zianet.com> wrote:
>>
>>Ah - I see you have a little reading comprehension problem - that's OK.
>
> You'll have to try harder than that Ray. (Lot's harder... :-)

Not really. You paraphrased what I said and then said I didn't say it.
Seems you have the problem - but we can work with that.

nospam

unread,
Jun 10, 2010, 1:43:59 PM6/10/10
to
In article <87fx0va...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> >> So you can't show times to support your claims?
> >
> >i did.
>
> No you didn't.

yes i most certainly did.


>
> >> > it's invalid if you don't have timings from other raw converters.
> >>
> >> Which I had already provided, so what's your problem?
> >
> >where are the timings for the other raw converters, namely camera raw,
> >so we can see how fast or slow it is on your system?
> >
> >so far, all you've posted is dcraw timings.
>
> I posted several articles with a variety of times for
> UFRAW.

that uses dcraw! what kind of comparison is that?

compare it to something *else*, like camera raw, nikon's software
(which is slow), bibble, capture one, raw therapee, etc.

as i said, camera raw is *much* faster than dcraw, and subsequently,
anything that uses it.

> I take it you do now also realize that the times that I
> gave *are* elapsed time, and were exactly the same
> elapsed time measurements that you posted?

your version of time outputs it differently than mine, and the man page
on my system makes no mention of the word 'real,' however, i googled a
linux version of it and it looks like that man page is *very* different
and does use the word real for elapsed. nevertheless, i find 0.131
seconds to be unusually slow and suspicious, but that isn't even the
issue.

> Whatever, this thread has run its length. Whether dcraw
> is actually faster or not is of very little
> significance, particularly when you seem to be comparing
> it to something you can't time,

i can and i did. i used the equivalent of a stopwatch. it's not as
accurate but it's no more than 1 second off at the most, and even so,
it's still much faster.

i don't even need a stopwatch, because i can *see* the image appear in
a couple of seconds versus significantly longer for dcraw.

> and therefore can't run
> individually or in a batch process without a GUI
> invoked.

i can do a batch process via the gui simply by opening multiple images.

> That pretty much negates any significance of
> speed in the terms the OP was asking about.

he said he was using photoshop cs3, not anything that used dcraw.

> If you have nothing more useful to discuss, I'm not likely
> to respond further.

good.

Ray Fischer

unread,
Jun 10, 2010, 1:53:06 PM6/10/10
to
Floyd L. Davidson <fl...@apaflo.com> wrote:
>nospam <nos...@nospam.invalid> wrote:
>>furthermore, the -h option outputs a half-size image, which the man
>>page says is twice as fast as the high-speed low-quality option. in
>>other words, it's bogus and not a real world representation of a
>>typical workflow, as if about 1/8th of a second was even believable.
>
>Not bogus, just optimized for speed. That actually is
>very reasonable for someone (such as the OP) who merely
>wants a 'default' image for comparison. For production
>purposes it might be used for previewing, for example.
>
>Clearly the speed of dcraw just blows you mind away!

Clearly you have little more than bullshit and bluster.

--
Ray Fischer
rfis...@sonic.net

Alfred Molon

unread,
Jun 10, 2010, 3:02:43 PM6/10/10
to
In article <grpv061jjnkl35tuh...@4ax.com>, Mark F says...

> My machine is pretty old (Pentium 4, 2.40GHZ)
>
> It takes a minute or two of CPU time to convert a Fujifilm FinePix
> S100fs RAF file to JPG taking "default" conversion parameters.

How about buying a new computer, very cheap these days?
--

Alfred Molon
------------------------------
Olympus E-series DSLRs and micro 4/3 forum at
http://tech.groups.yahoo.com/group/MyOlympus/
http://myolympus.org/ photo sharing site

ray

unread,
Jun 10, 2010, 9:43:39 PM6/10/10
to
On Wed, 09 Jun 2010 15:26:44 -0400, Mark F wrote:

> How long should it take to convert a "raw" camera file to a "default"
> JPG?
>

> My machine is pretty old (Pentium 4, 2.40GHZ)
>
> It takes a minute or two of CPU time to convert a Fujifilm FinePix
> S100fs RAF file to JPG taking "default" conversion parameters.
>

> I tried FinePix Viewer that came with the camera and s7raw (arbitrarily
> selected from Google searches and located at
> www.geocities.co.jp/SiliconValley-PaloAlto/9919/s7raw.html)
>
> The camera can store directly as 3MB JPG files much faster than it can
> store 23MB RAW files.
>
> Can someone suggest parameters that are faster than the defaults in
> FinePix Viewer or a faster converter and defaults?
>

> I don't mind spending some money (I have Adobe CS3 Premium and am
> willing to upgrade to CS5) but I don't feel like using all of the space
> that CS takes compared to even FinePix Viewer.

For the record, I downloaded a sample raf file taken with that particular
camera. Running on a system with 1.5ghz VIA C7 processor, 2gb ddr2 ram -
using Debian Linux, the file opens in 20 seconds using ufraw.

Jon Smid

unread,
Jun 12, 2010, 2:18:25 PM6/12/10
to
nospam schreef:

I leave the fight about the exact numbers for you guys, but some aspects
to take into consideration :


- Size and compression of input file.
- Interpolation used. No interpolation (halfsize option of dcraw) will
be obviously the fastest. AHD will be the slowest.
- Whether or not threading is used. Standard dcraw does not use
multithreading. Ufraw's dcraw *does* use multithreading on some
interpolation mechanisms.
- Whether or not some 'preloading' is done. I.e. If your image is loaded
already in memory or not on the moment you start timing. (I /suspect/
that camera raw for instance does preload images).
- Operations done on the image. Just converting to jpeg ? Or applying
curves, sharpening, leveling or whatever ... ?

I guess it will be very difficult giving a decent answer if you don't
define what you exactly mean with 'to convert'.

Better Info

unread,
Jun 12, 2010, 3:09:58 PM6/12/10
to
On Sat, 12 Jun 2010 20:18:25 +0200, Jon Smid <Varke...@hotmail.com>
wrote:

>
>- Interpolation used. No interpolation (halfsize option of dcraw) will
>be obviously the fastest. AHD will be the slowest.

VNG Cubic is the slowest, but gives some of the best results in almost all
instances. Few editors, however, support this interpolation method. I use
Photoline for its 6 different RAW interpolation algorithms. Donation-ware
RAWTherapee also has the VNG algorithm available but their own EAHD
algorithm is even better when it comes to very fine aliasing artifacts. You
might want to check out their interpolation comparison page to see if your
RAW editor is performing up to your needs. Adobe Camera RAW, Bibble,
Capture One, DxO, LightZone, and SilkyPix all pale in comparison to the
better interpolation methods available in other editors.

http://www.rawtherapee.com/RAW_Compare/

Photoline's (32bit, not 64bit version) RAW import times on my old workhorse
photo-editor 1.8GHz machine:

Linear: 2 seconds
Cubic: 2.5 seconds
AHD: 5 seconds
PPG: 3 seconds
VNG Linear: 8 seconds
VNG Cubic: 9 seconds

nospam

unread,
Jun 12, 2010, 3:57:07 PM6/12/10
to
In article <obQQn.65445$0A4....@newsfe01.ams2>, Jon Smid
<Varke...@hotmail.com> wrote:

> - Size and compression of input file.
> - Interpolation used. No interpolation (halfsize option of dcraw) will
> be obviously the fastest. AHD will be the slowest.

yep.

> - Whether or not threading is used. Standard dcraw does not use
> multithreading. Ufraw's dcraw *does* use multithreading on some
> interpolation mechanisms.

why isn't dcraw threaded? multicore processors are very common, if not
the norm.

> - Whether or not some 'preloading' is done. I.e. If your image is loaded
> already in memory or not on the moment you start timing. (I /suspect/
> that camera raw for instance does preload images).

it does cache images, so if you *re* open an image, it's even faster. i
cited only the first time opening to avoid any caching.

> - Operations done on the image. Just converting to jpeg ? Or applying
> curves, sharpening, leveling or whatever ... ?

only until it appears on screen or in the case of dcraw, outputs a file.

> I guess it will be very difficult giving a decent answer if you don't
> define what you exactly mean with 'to convert'.

exactly.

Jon Smid

unread,
Jun 12, 2010, 4:08:26 PM6/12/10
to
Better Info schreef:

You are right, my mistake. VNG is the slower one.
(I was not discussing quality in this context, that's another topic)
But bottom line it only proves my point more strong : define what you
mean with 'to convert' before speaking about speed of it.

Jon Smid

unread,
Jun 12, 2010, 4:24:22 PM6/12/10
to
nospam schreef:

> In article <obQQn.65445$0A4....@newsfe01.ams2>, Jon Smid
> <Varke...@hotmail.com> wrote:
>
>> - Size and compression of input file.
>> - Interpolation used. No interpolation (halfsize option of dcraw) will
>> be obviously the fastest. AHD will be the slowest.
>
> yep.
>
>> - Whether or not threading is used. Standard dcraw does not use
>> multithreading. Ufraw's dcraw *does* use multithreading on some
>> interpolation mechanisms.
>
> why isn't dcraw threaded? multicore processors are very common, if not
> the norm.
>

That's because the author has a very particular opinion of what dcraw
should be. That does not include :

- being readable (and thus maintainable except for the author)
- being modular
- being a library
- being multithreaded

>> - Whether or not some 'preloading' is done. I.e. If your image is loaded
>> already in memory or not on the moment you start timing. (I /suspect/
>> that camera raw for instance does preload images).
>
> it does cache images, so if you *re* open an image, it's even faster. i
> cited only the first time opening to avoid any caching.

Except if the code is open source, you can't know for sure.

>
>> - Operations done on the image. Just converting to jpeg ? Or applying
>> curves, sharpening, leveling or whatever ... ?
>
> only until it appears on screen or in the case of dcraw, outputs a file.

Irrelevant. Unless you define what should be the characteristics of
what's on screen. I guess a quick and dirty thumbnail doesn't qualify
for that ? If not, what does qualify ?

nospam

unread,
Jun 12, 2010, 7:36:14 PM6/12/10
to
In article <s1SQn.27088$g76.26183@hurricane>, Jon Smid
<Varke...@hotmail.com> wrote:

> >> - Whether or not threading is used. Standard dcraw does not use
> >> multithreading. Ufraw's dcraw *does* use multithreading on some
> >> interpolation mechanisms.
> >
> > why isn't dcraw threaded? multicore processors are very common, if not
> > the norm.
>
> That's because the author has a very particular opinion of what dcraw
> should be. That does not include :
>
> - being readable (and thus maintainable except for the author)
> - being modular
> - being a library
> - being multithreaded

in other words, it's crap.

> >> - Whether or not some 'preloading' is done. I.e. If your image is loaded
> >> already in memory or not on the moment you start timing. (I /suspect/
> >> that camera raw for instance does preload images).
> >
> > it does cache images, so if you *re* open an image, it's even faster. i
> > cited only the first time opening to avoid any caching.
>
> Except if the code is open source, you can't know for sure.

of course i can, simply by watching cpu activity. dcraw only uses one
core and camera raw uses more than one core.

adobe has stated that photoshop will use as many cores as available,
depending on the operation.

> >> - Operations done on the image. Just converting to jpeg ? Or applying
> >> curves, sharpening, leveling or whatever ... ?
> >
> > only until it appears on screen or in the case of dcraw, outputs a file.
>
> Irrelevant. Unless you define what should be the characteristics of
> what's on screen. I guess a quick and dirty thumbnail doesn't qualify
> for that ? If not, what does qualify ?

to the point where the user can start making adjustments.

Jon Smid

unread,
Jun 13, 2010, 4:16:45 AM6/13/10
to
nospam schreef:

> In article <s1SQn.27088$g76.26183@hurricane>, Jon Smid
> <Varke...@hotmail.com> wrote:
>
>>>> - Whether or not threading is used. Standard dcraw does not use
>>>> multithreading. Ufraw's dcraw *does* use multithreading on some
>>>> interpolation mechanisms.
>>> why isn't dcraw threaded? multicore processors are very common, if not
>>> the norm.
>> That's because the author has a very particular opinion of what dcraw
>> should be. That does not include :
>>
>> - being readable (and thus maintainable except for the author)
>> - being modular
>> - being a library
>> - being multithreaded
>
> in other words, it's crap.

That's your conclusion and I don't share it.

dcraw and its author Dave Coffin do a wonderful job in
reverse-engineering and decoding all those undocumented and unspecified
raw formats out there.

In terms of decoding raw image formats it simply is beyond any competition.

By the way, next to sure Adobe does use dcraw (at least the decoding
part of it) under the hood. As does a zillion of other programs.

>
>>>> - Whether or not some 'preloading' is done. I.e. If your image is loaded
>>>> already in memory or not on the moment you start timing. (I /suspect/
>>>> that camera raw for instance does preload images).
>>> it does cache images, so if you *re* open an image, it's even faster. i
>>> cited only the first time opening to avoid any caching.
>> Except if the code is open source, you can't know for sure.
>
> of course i can, simply by watching cpu activity. dcraw only uses one
> core and camera raw uses more than one core.
>
> adobe has stated that photoshop will use as many cores as available,
> depending on the operation.

I was referring to the preloading or not.

The fact that (an unmodified) dcraw uses only one core I could tell you
from in the beginning.

>
>>>> - Operations done on the image. Just converting to jpeg ? Or applying
>>>> curves, sharpening, leveling or whatever ... ?
>>> only until it appears on screen or in the case of dcraw, outputs a file.
>> Irrelevant. Unless you define what should be the characteristics of
>> what's on screen. I guess a quick and dirty thumbnail doesn't qualify
>> for that ? If not, what does qualify ?
>
> to the point where the user can start making adjustments.

You seem to have no clue what tricks software, especially gui, might do
to increase the apparent speed.

For instance putting a quick and dirty preview that's updated during the
time that you are searching the sliders and buttons while fiddling with
it. What's the conversion time ? It's nearly undefinable (and is
probably irrelevant as well).

I see where your discussion with Floyd is coming from. I'm not going to
redo it.

nospam

unread,
Jun 13, 2010, 4:45:29 AM6/13/10
to
In article <gt0Rn.33448$D81.26382@hurricane>, Jon Smid
<Varke...@hotmail.com> wrote:

> >>> why isn't dcraw threaded? multicore processors are very common, if not
> >>> the norm.
> >> That's because the author has a very particular opinion of what dcraw
> >> should be. That does not include :
> >>
> >> - being readable (and thus maintainable except for the author)
> >> - being modular
> >> - being a library
> >> - being multithreaded
> >
> > in other words, it's crap.
>
> That's your conclusion and I don't share it.

that's fine.

> dcraw and its author Dave Coffin do a wonderful job in
> reverse-engineering and decoding all those undocumented and unspecified
> raw formats out there.

yes he has but the code is awful, which you admit.

> In terms of decoding raw image formats it simply is beyond any competition.

not really. many other raw conversion utilities do a much better job,
although some of that (not all) is subjective.

> By the way, next to sure Adobe does use dcraw (at least the decoding
> part of it) under the hood. As does a zillion of other programs.

adobe camera raw does *not* use dcraw code. that's a huge myth.

> >>>> - Operations done on the image. Just converting to jpeg ? Or applying
> >>>> curves, sharpening, leveling or whatever ... ?
> >>> only until it appears on screen or in the case of dcraw, outputs a file.
> >> Irrelevant. Unless you define what should be the characteristics of
> >> what's on screen. I guess a quick and dirty thumbnail doesn't qualify
> >> for that ? If not, what does qualify ?
> >
> > to the point where the user can start making adjustments.
>
> You seem to have no clue what tricks software, especially gui, might do
> to increase the apparent speed.

i'm well aware of what tricks can be done, and all that matters is how
fast a user can start working with an image and produce a final result.
camera raw is fast, dcraw isn't.

Floyd L. Davidson

unread,
Jun 13, 2010, 5:11:20 AM6/13/10
to
Jon Smid <Varke...@hotmail.com> wrote:
>nospam schreef:
>> In article <s1SQn.27088$g76.26183@hurricane>, Jon Smid
>> <Varke...@hotmail.com> wrote:
>>
>>>>> - Whether or not threading is used. Standard dcraw
>>>>> does not use multithreading. Ufraw's dcraw *does*
>>>>> use multithreading on some interpolation mechanisms.
>>>> why isn't dcraw threaded? multicore processors are very common, if not
>>>> the norm.
>>> That's because the author has a very particular
>>> opinion of what dcraw should be. That does not
>>> include :
>>>
>>> - being readable (and thus maintainable except for the author)
>>> - being modular
>>> - being a library
>>> - being multithreaded
>> in other words, it's crap.
>
>That's your conclusion and I don't share it.
>
>dcraw and its author Dave Coffin do a wonderful job in
>reverse-engineering and decoding all those undocumented and unspecified
>raw formats out there.
>
>In terms of decoding raw image formats it simply is beyond any competition.
>
>By the way, next to sure Adobe does use dcraw (at least the decoding
>part of it) under the hood. As does a zillion of other programs.

Which of course does suggest some of your description
cannot be correct either! Coffin's code most certainly
is readable, and there are "a zillion" other programs
that use it because it is!

One example of the degree to which other programmers
find Coffin's code readable would be to look at how Udi
Fuchs uses the dcraw code in ufraw. Fuchs converts the
original C code to C++, and is easily able to do so
because Coffin *designed* his code to make that easy.
(And, note here that he made it thread safe too.)

It is intended to be a module itself, and that is
exactly what it is when used in other programs.

The business of being a module, rather than a library is
one of preference, and is neither a plus nor a minus.
Note that libRaw is a library based on dcraw.

The reason it is not multi-threaded is one of the more
significant points about Coffin's intent. It is a
program written absolutely in strict ISO/ANSI Standard C
for *portability*, which means that in 40 years or 400
years it will be possible to generate a compiler that
will produce a useful binary for whatever hardware
exists. Threads are *not* part of the C Standard, and
never will be (it is an innately platform specific and
non-portable functionality).

The code in dcraw.c is written to be thread safe so that
others can incorporate it into platform specific
programs and make their program multi-threaded without
difficulty.

>>> Except if the code is open source, you can't know for sure.
>> of course i can, simply by watching cpu
>> activity. dcraw only uses one
>> core and camera raw uses more than one core.
>> adobe has stated that photoshop will use as many cores
>> as available,
>> depending on the operation.
>
>I was referring to the preloading or not.
>
>The fact that (an unmodified) dcraw uses only one core I could tell you
>from in the beginning.

What of course can only be known about open source code
is that, as stated above, dcraw is written to be thread
safe; and therefore if chosen to be the basis for
another program that program can easily be written to
take advantage of multiple core CPU's.

>>>> only until it appears on screen or in the case of dcraw, outputs a file.
>>> Irrelevant. Unless you define what should be the
>>> characteristics of what's on screen. I guess a quick
>>> and dirty thumbnail doesn't qualify for that ? If
>>> not, what does qualify ?
>> to the point where the user can start making
>> adjustments.
>
>You seem to have no clue what tricks software, especially gui, might do
>to increase the apparent speed.

That's an understatement!

>For instance putting a quick and dirty preview that's updated during the
>time that you are searching the sliders and buttons while fiddling with
>it. What's the conversion time ? It's nearly undefinable (and is
>probably irrelevant as well).
>
>I see where your discussion with Floyd is coming from. I'm not going to
>redo it.

It's based on the "no clue" above.

There is a *huge* difference in what a program like
/ufraw/ is intended to do, compared to a program like
/dcraw/. Apples and oranges... both of which are
wonderful fruit (either to eat or to photograph).

nospam

unread,
Jun 13, 2010, 5:27:18 AM6/13/10
to
In article <877hm39...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> The reason it is not multi-threaded is one of the more
> significant points about Coffin's intent. It is a
> program written absolutely in strict ISO/ANSI Standard C
> for *portability*, which means that in 40 years or 400
> years it will be possible to generate a compiler that
> will produce a useful binary for whatever hardware
> exists. Threads are *not* part of the C Standard, and
> never will be (it is an innately platform specific and
> non-portable functionality).

give me a break. there are platform agnostic libraries for threading.

Floyd L. Davidson

unread,
Jun 13, 2010, 6:14:50 AM6/13/10
to

Give you a break: demonstrate how a program can be
ISO/ANSI C Standard portable if it requires linking to
*any* library for threading.

Jon Smid

unread,
Jun 13, 2010, 6:37:02 AM6/13/10
to
Floyd L. Davidson schreef:

I respectfully disagree.

A zillion other programs use it because it does a wonderful job in
decoding nearly all relevant raw formats out there.
A zillion other programs use it because the source is available and can
be tweaked and tuned as you like.
A zillion other programs use it for above reasons *despite* all of the
disadvantages I described earlier.

>
> One example of the degree to which other programmers
> find Coffin's code readable would be to look at how Udi
> Fuchs uses the dcraw code in ufraw. Fuchs converts the
> original C code to C++, and is easily able to do so
> because Coffin *designed* his code to make that easy.
> (And, note here that he made it thread safe too.)

Again I respectfully disagree ;)

It's not because the code contains some "CLASS" macro that can be
switched on/off it all of a sudden becomes a (decent) C++ program.
Dave just added some gear to his code to turn the syntax into C++.
Further he couldn't care less about (decent) C++ concepts such as
encapsulation, isolation etc.

And no, dcraw is *not* thread safe. I even doubt - but didn't check
recently - if the ufraw transformation of it is thread safe.
Wait a moment, I'm sure it isn't. It's noted in the source at several
occasions.


>
> It is intended to be a module itself, and that is
> exactly what it is when used in other programs.
>
> The business of being a module, rather than a library is
> one of preference, and is neither a plus nor a minus.
> Note that libRaw is a library based on dcraw.
>

That's correct. libRaw is an effort of bypassing some of the issues
dcraw has. It's one of those efforts to overcome the unbelievable bad
software design of dcraw. Patchwork however.

A more decent effort, bottom-up, is done in libopenraw which is not
based on dcraw. But that one is by far not up to date with respect to
camera support.

> The reason it is not multi-threaded is one of the more
> significant points about Coffin's intent. It is a
> program written absolutely in strict ISO/ANSI Standard C
> for *portability*, which means that in 40 years or 400
> years it will be possible to generate a compiler that
> will produce a useful binary for whatever hardware
> exists. Threads are *not* part of the C Standard, and
> never will be (it is an innately platform specific and
> non-portable functionality).

There are for sure possibilities to keep above intent intact (to the
extent it is relevant) *and* have threading. OpenMP would be such a
framework. One can perfectly parallelize and thread loops by #pragma
statements in the code. #pragma statements that become no-ops for a
strict compiler without OpenMP support.

>
> The code in dcraw.c is written to be thread safe so that
> others can incorporate it into platform specific
> programs and make their program multi-threaded without
> difficulty.

No it isn't. See above. static variables within functions, global
variables all of it is in dcraw.

>
>>>> Except if the code is open source, you can't know for sure.
>>> of course i can, simply by watching cpu
>>> activity. dcraw only uses one
>>> core and camera raw uses more than one core.
>>> adobe has stated that photoshop will use as many cores
>>> as available,
>>> depending on the operation.
>> I was referring to the preloading or not.
>>
>> The fact that (an unmodified) dcraw uses only one core I could tell you
>>from in the beginning.
>
> What of course can only be known about open source code
> is that, as stated above, dcraw is written to be thread
> safe; and therefore if chosen to be the basis for
> another program that program can easily be written to
> take advantage of multiple core CPU's.

No :)

>
>>>>> only until it appears on screen or in the case of dcraw, outputs a file.
>>>> Irrelevant. Unless you define what should be the
>>>> characteristics of what's on screen. I guess a quick
>>>> and dirty thumbnail doesn't qualify for that ? If
>>>> not, what does qualify ?
>>> to the point where the user can start making
>>> adjustments.
>> You seem to have no clue what tricks software, especially gui, might do
>> to increase the apparent speed.
>
> That's an understatement!

:)

>
>> For instance putting a quick and dirty preview that's updated during the
>> time that you are searching the sliders and buttons while fiddling with
>> it. What's the conversion time ? It's nearly undefinable (and is
>> probably irrelevant as well).
>>
>> I see where your discussion with Floyd is coming from. I'm not going to
>> redo it.
>
> It's based on the "no clue" above.
>
> There is a *huge* difference in what a program like
> /ufraw/ is intended to do, compared to a program like
> /dcraw/. Apples and oranges... both of which are
> wonderful fruit (either to eat or to photograph).
>

Agreed.

Floyd L. Davidson

unread,
Jun 13, 2010, 7:01:24 AM6/13/10
to

You've missed the point entirely. Dave Coffin *didn't*
make it into C++ code. He merely wrote it in such a way
that others could do that easily enough. The people you
claim can't read the code... can, and do, and have
converted it to C++ with relative ease.

Claiming it is written so that only the original author
can maintain it is clearly not valid. Ufraw is a very
good example that shows how well other coders are able
to work with the the original code, and repeatedly make
updates to their modifications of it.

>And no, dcraw is *not* thread safe. I even doubt - but didn't check
>recently - if the ufraw transformation of it is thread safe.
>Wait a moment, I'm sure it isn't. It's noted in the source at several
>occasions.

You are correct. I misstated that. What Coffin has
done is annotate the code showing where problems with
threads would be a problem.

It's the same as the C++ conversion, which Coffin does
not do, but he does code in such a way which accomodates
other coders who may wish to do that.

>> It is intended to be a module itself, and that is
>> exactly what it is when used in other programs.
>> The business of being a module, rather than a library
>> is
>> one of preference, and is neither a plus nor a minus.
>> Note that libRaw is a library based on dcraw.
>>
>
>That's correct. libRaw is an effort of bypassing some of the issues
>dcraw has. It's one of those efforts to overcome the unbelievable bad
>software design of dcraw. Patchwork however.
>
>A more decent effort, bottom-up, is done in libopenraw which is not
>based on dcraw. But that one is by far not up to date with respect to
>camera support.

Whining about dcraw is a bit pointless when it is
clearly the best of what it is intended to be.

>> The reason it is not multi-threaded is one of the more
>> significant points about Coffin's intent. It is a
>> program written absolutely in strict ISO/ANSI Standard C
>> for *portability*, which means that in 40 years or 400
>> years it will be possible to generate a compiler that
>> will produce a useful binary for whatever hardware
>> exists. Threads are *not* part of the C Standard, and
>> never will be (it is an innately platform specific and
>> non-portable functionality).
>
>There are for sure possibilities to keep above intent intact (to the
>extent it is relevant) *and* have threading. OpenMP would be such a
>framework. One can perfectly parallelize and thread loops by #pragma
>statements in the code. #pragma statements that become no-ops for a
>strict compiler without OpenMP support.

That is not and never was Coffin's intent, which he
makes very clear. I see no need for anyone else to
complain that he has no intention of doing something
that is unnecessary to accomplish his stated goal.

>> The code in dcraw.c is written to be thread safe so
>> that
>> others can incorporate it into platform specific
>> programs and make their program multi-threaded without
>> difficulty.
>
>No it isn't. See above. static variables within functions, global
>variables all of it is in dcraw.

Yes. But you know that because Coffin put notes in the
code to tell you that.

>>>>> Except if the code is open source, you can't know for sure.
>>>> of course i can, simply by watching cpu
>>>> activity. dcraw only uses one
>>>> core and camera raw uses more than one core.
>>>> adobe has stated that photoshop will use as many cores
>>>> as available,
>>>> depending on the operation.
>>> I was referring to the preloading or not.
>>>
>>> The fact that (an unmodified) dcraw uses only one core I could tell you
>>>from in the beginning.
>> What of course can only be known about open source code
>> is that, as stated above, dcraw is written to be thread
>> safe; and therefore if chosen to be the basis for
>> another program that program can easily be written to
>> take advantage of multiple core CPU's.
>
>No :)

Not thread safe, but easily done because Coffin points
out what the problems will be.

nospam

unread,
Jun 13, 2010, 7:07:36 AM6/13/10
to
In article <8739wr9...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> Give you a break: demonstrate how a program can be
> ISO/ANSI C Standard portable if it requires linking to
> *any* library for threading.

why limit oneself to ansi c? nevertheless, there's grand central, and
for c++, boost::thread.

nospam

unread,
Jun 13, 2010, 7:10:21 AM6/13/10
to
In article <87wru38...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> Not thread safe, but easily done because Coffin points
> out what the problems will be.

if it's so easy, why didn't he do it rather than just point out the
problems?

Jon Smid

unread,
Jun 13, 2010, 7:26:15 AM6/13/10
to
Floyd L. Davidson schreef:

<snip>


>
> You've missed the point entirely. Dave Coffin *didn't*
> make it into C++ code. He merely wrote it in such a way
> that others could do that easily enough. The people you
> claim can't read the code... can, and do, and have
> converted it to C++ with relative ease.

Been there. Everything is possible. Understanding dcraw is a reverse
engineering effort in its own.

>
> Claiming it is written so that only the original author
> can maintain it is clearly not valid. Ufraw is a very
> good example that shows how well other coders are able
> to work with the the original code, and repeatedly make
> updates to their modifications of it.

As I said : *despite* the bad code quality of dcraw.
And with considerable more effort (and risk on errors) than needed.

>
>> And no, dcraw is *not* thread safe. I even doubt - but didn't check
>> recently - if the ufraw transformation of it is thread safe.
>> Wait a moment, I'm sure it isn't. It's noted in the source at several
>> occasions.
>
> You are correct. I misstated that. What Coffin has
> done is annotate the code showing where problems with
> threads would be a problem.

Even that is not the case ... The team around Udi Fuchs and ufraw has
done so.

The original code contains no clue about that.

<snip>

>
> Whining about dcraw is a bit pointless when it is
> clearly the best of what it is intended to be.
>

I think I'm making a balanced statement about dcraw.
It does a wonderful job. All respect.
But the code quality is substandard and makes reading / reusing /
extending / maintaining it more difficult than it should be.

>>> The reason it is not multi-threaded is one of the more
>>> significant points about Coffin's intent. It is a
>>> program written absolutely in strict ISO/ANSI Standard C
>>> for *portability*, which means that in 40 years or 400
>>> years it will be possible to generate a compiler that
>>> will produce a useful binary for whatever hardware
>>> exists. Threads are *not* part of the C Standard, and
>>> never will be (it is an innately platform specific and
>>> non-portable functionality).
>> There are for sure possibilities to keep above intent intact (to the
>> extent it is relevant) *and* have threading. OpenMP would be such a
>> framework. One can perfectly parallelize and thread loops by #pragma
>> statements in the code. #pragma statements that become no-ops for a
>> strict compiler without OpenMP support.
>
> That is not and never was Coffin's intent, which he
> makes very clear. I see no need for anyone else to
> complain that he has no intention of doing something
> that is unnecessary to accomplish his stated goal.

Here I lost your reasoning.
The intent is to write a portable ANSI-C program.
You praise Coffin for allowing it to be a C++ program as well.
(the technique basically being to incorporate CLASS macros that are
defined empty in case of ANSI-C).
But doing something equal with #pragma omp for OMP (and thus threading
support) would defeat dcraws intent ?


>
>>> The code in dcraw.c is written to be thread safe so
>>> that
>>> others can incorporate it into platform specific
>>> programs and make their program multi-threaded without
>>> difficulty.
>> No it isn't. See above. static variables within functions, global
>> variables all of it is in dcraw.
>
> Yes. But you know that because Coffin put notes in the
> code to tell you that.

If he only would have done that ... see above.

<snip>

>
> Not thread safe, but easily done because Coffin points
> out what the problems will be.
>

See above.

Floyd L. Davidson

unread,
Jun 13, 2010, 7:28:57 AM6/13/10
to

The purpose is *portability*. The mechanism is ISO Standard C.

Despite what you seem to think, threading is not portable.

Floyd L. Davidson

unread,
Jun 13, 2010, 7:35:01 AM6/13/10
to

Sigh...

Because threads are not portable.

Floyd L. Davidson

unread,
Jun 13, 2010, 7:44:30 AM6/13/10
to
Jon Smid <Varke...@hotmail.com> wrote:
>Floyd L. Davidson schreef:
>> You are correct. I misstated that. What Coffin has
>> done is annotate the code showing where problems with
>> threads would be a problem.
>
>Even that is not the case ... The team around Udi Fuchs and ufraw has
>done so.
>
>The original code contains no clue about that.

This is the clue:

"Note that a thread-safe C++ class cannot have non-const
static local variables."
from draw.c by Dave Coffin (VERSION "8.63")

>> Whining about dcraw is a bit pointless when it is
>> clearly the best of what it is intended to be.
>>
>
>I think I'm making a balanced statement about dcraw.

It's a whine.

>It does a wonderful job. All respect.

So stop whining about unreadable code. That's just an
all too common whine about anyone who uses a different
coding style. Get over it.

>But the code quality is substandard and makes reading / reusing /
>extending / maintaining it more difficult than it should be.

Apparently not, given the number of people who use it.

>>> There are for sure possibilities to keep above intent intact (to the
>>> extent it is relevant) *and* have threading. OpenMP would be such a
>>> framework. One can perfectly parallelize and thread loops by #pragma
>>> statements in the code. #pragma statements that become no-ops for a
>>> strict compiler without OpenMP support.
>> That is not and never was Coffin's intent, which he
>> makes very clear. I see no need for anyone else to
>> complain that he has no intention of doing something
>> that is unnecessary to accomplish his stated goal.
>
>Here I lost your reasoning.
>The intent is to write a portable ANSI-C program.
>You praise Coffin for allowing it to be a C++ program as well.

No, for doing what is easy to make it possible for *others* to
make it a C++ program.

He doesn't go outside the C Standard to do that.

>(the technique basically being to incorporate CLASS macros that are
>defined empty in case of ANSI-C).
>But doing something equal with #pragma omp for OMP (and thus threading
>support) would defeat dcraws intent ?

That is outside the C Standard.

>>> No it isn't. See above. static variables within functions, global
>>> variables all of it is in dcraw.
>> Yes. But you know that because Coffin put notes in the
>> code to tell you that.
>
>If he only would have done that ... see above.

See above indeed.

Jon Smid

unread,
Jun 13, 2010, 8:26:19 AM6/13/10
to
Floyd L. Davidson schreef:

<snip>

> This is the clue:


>
> "Note that a thread-safe C++ class cannot have non-const
> static local variables."
> from draw.c by Dave Coffin (VERSION "8.63")

This is about as helpful as stating "Note that a C++ program must
declare variables before them being used".

<snip>

>
>> It does a wonderful job. All respect.
>
> So stop whining about unreadable code. That's just an
> all too common whine about anyone who uses a different
> coding style. Get over it.

You miss the point. This is not about coding style.
Any software engineering book will tell you (and why) to avoid global
variables, to avoid strongly coupled routines with weak cohesion.
Any software engineering book will tell you about the importance of
readable variable names etc.
Style would be about underscores, capitalization, indentation and more
of those issues that belong to the personal preference department rather
than to the engineering department.

>
>> But the code quality is substandard and makes reading / reusing /
>> extending / maintaining it more difficult than it should be.
>
> Apparently not, given the number of people who use it.

Once more : *despite*.
Main reason that many people use it is that there's no alternative.

>
>>>> There are for sure possibilities to keep above intent intact (to the
>>>> extent it is relevant) *and* have threading. OpenMP would be such a
>>>> framework. One can perfectly parallelize and thread loops by #pragma
>>>> statements in the code. #pragma statements that become no-ops for a
>>>> strict compiler without OpenMP support.
>>> That is not and never was Coffin's intent, which he
>>> makes very clear. I see no need for anyone else to
>>> complain that he has no intention of doing something
>>> that is unnecessary to accomplish his stated goal.
>> Here I lost your reasoning.
>> The intent is to write a portable ANSI-C program.
>> You praise Coffin for allowing it to be a C++ program as well.
>
> No, for doing what is easy to make it possible for *others* to
> make it a C++ program.
>
> He doesn't go outside the C Standard to do that.

Correct.

>
>> (the technique basically being to incorporate CLASS macros that are
>> defined empty in case of ANSI-C).
>> But doing something equal with #pragma omp for OMP (and thus threading
>> support) would defeat dcraws intent ?
>
> That is outside the C Standard.

It isn't.

#pragma is part of the standard.
Compilers without OMP support skip the part behind the #pragma.

Besides, from dcraw :
#pragma comment(lib, "ws2_32.lib")

>
>>>> No it isn't. See above. static variables within functions, global
>>>> variables all of it is in dcraw.
>>> Yes. But you know that because Coffin put notes in the
>>> code to tell you that.
>> If he only would have done that ... see above.
>
> See above indeed.
>

Indeed.

Floyd L. Davidson

unread,
Jun 13, 2010, 2:26:12 PM6/13/10
to
Jon Smid <Varke...@hotmail.com> wrote:
>Floyd L. Davidson schreef:
>> This is the clue:
>> "Note that a thread-safe C++ class cannot have
>> non-const
>> static local variables."
>> from draw.c by Dave Coffin (VERSION "8.63")
>
>This is about as helpful as stating "Note that a C++ program must
>declare variables before them being used".

You were wrong to say such comments were not there, just
admit it and go on.

>>> It does a wonderful job. All respect.
>> So stop whining about unreadable code. That's just an
>> all too common whine about anyone who uses a different
>> coding style. Get over it.
>
>You miss the point. This is not about coding style.

Yeah, sure.

>Any software engineering book will tell you (and why) to avoid global
>variables, to avoid strongly coupled routines with weak cohesion.

And yet you want it threaded...

>Any software engineering book will tell you about the importance of
>readable variable names etc.

And what is a "readable variable name" depends on
personal perceptions (i.e., style).

You're proving my point rather well!

>Style would be about underscores, capitalization, indentation and more
>of those issues that belong to the personal preference department rather
>than to the engineering department.

Exactly... things like variable naming conventions.

>>> But the code quality is substandard and makes reading / reusing /
>>> extending / maintaining it more difficult than it should be.
>> Apparently not, given the number of people who use it.
>
>Once more : *despite*.
>Main reason that many people use it is that there's no alternative.

And why do you supposed after all these years there is
no alternative? Could it just happen to be that dcraw
is such a killer implementation that nobody wants to
waste their time writing a "replacement" that will never
be more than an obscure "almost an alternative"?

>>> (the technique basically being to incorporate CLASS macros that are
>>> defined empty in case of ANSI-C).
>>> But doing something equal with #pragma omp for OMP (and thus threading
>>> support) would defeat dcraws intent ?
>> That is outside the C Standard.
>
>It isn't.
>
>#pragma is part of the standard.
>Compilers without OMP support skip the part behind the #pragma.
>
>Besides, from dcraw :
>#pragma comment(lib, "ws2_32.lib")

Doing what is required, even with #pragma statements, to
make it functional within the design target is one
thing. Extending the target is distinctly different.

>>
>>>>> No it isn't. See above. static variables within functions, global
>>>>> variables all of it is in dcraw.
>>>> Yes. But you know that because Coffin put notes in the
>>>> code to tell you that.
>>> If he only would have done that ... see above.
>> See above indeed.
>>
>
>Indeed.

And we see, once again, that what you said was not true.
The notes *are* in Coffin's code, and the comments you
cited in ufraw code are merely extenstions to what
Coffin had put there to begin with.

Jon Smid

unread,
Jun 13, 2010, 2:42:13 PM6/13/10
to
Floyd L. Davidson schreef:

<snip>

>

> And why do you supposed after all these years there is
> no alternative? Could it just happen to be that dcraw
> is such a killer implementation that nobody wants to
> waste their time writing a "replacement" that will never
> be more than an obscure "almost an alternative"?

Probably assuming in vain that you really want an answer, yet trying :

The *huge* value of dcraw is in the reverse engineering work that was
put in deciphering all of those raw formats out there. This is a
tremendous achievement. This is what it makes it practically impossible
to come with an alternative. Nobody has a better understanding or track
record in this respect.

But nevertheless the result was put in a program that is crappy in
software engineering terms.

<snip>

Floyd L. Davidson

unread,
Jun 13, 2010, 11:36:03 PM6/13/10
to
Jon Smid <Varke...@hotmail.com> wrote:
>Floyd L. Davidson schreef:

If the program was that crappy there would be half a
dozen alternative programs available within a few
months. Yet for years now nobody has bothered. Not
only that, but efforts such as UFRAW, which could easily
merely lift that "tremendous achievement" in engineering
and write their own code to implement it, don't.
Instead the lift *the code*, modify it only enough to
meet their specific needs, and use it as is.

Your claim of "crappy" software engineering doesn't
wash.

Ray Fischer

unread,
Jun 14, 2010, 2:20:43 AM6/14/10
to
Floyd L. Davidson <fl...@apaflo.com> wrote:
>Jon Smid <Varke...@hotmail.com> wrote:
>>Floyd L. Davidson schreef:
>>> And why do you supposed after all these years there is
>>> no alternative? Could it just happen to be that dcraw
>>> is such a killer implementation that nobody wants to
>>> waste their time writing a "replacement" that will never
>>> be more than an obscure "almost an alternative"?
>>
>>Probably assuming in vain that you really want an answer, yet trying :
>>
>>The *huge* value of dcraw is in the reverse engineering work that was
>>put in deciphering all of those raw formats out there. This is a
>>tremendous achievement. This is what it makes it practically impossible
>>to come with an alternative. Nobody has a better understanding or track
>>record in this respect.
>>
>>But nevertheless the result was put in a program that is crappy in
>>software engineering terms.
>
>If the program was that crappy there would be half a
>dozen alternative programs available within a few
>months. Yet for years now nobody has bothered.

Except for Adobe's RAW converter, and Apple's, and Canon's, and
Nikon's, and all the other graphics programs.

> Not
>only that, but efforts such as UFRAW, which could easily

You're an idiot.

--
Ray Fischer
rfis...@sonic.net

Floyd L. Davidson

unread,
Jun 14, 2010, 3:44:54 AM6/14/10
to

Your exception list doesn't include a single program
that duplicates what Jon and I agree is the purpose of
/dcraw/ as a program. Do you even know what /dcraw/ is?

Plus Adobe used Coffin's /dcraw/ in the development of
their own converter, though because Adobe is proprietary
we don't know to what degree or exactly in what way
even.

nospam

unread,
Jun 14, 2010, 4:43:12 AM6/14/10
to
In article <87sk4r8...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> The purpose is *portability*. The mechanism is ISO Standard C.

c++ is portable, a *far* better choice than c.

> Despite what you seem to think, threading is not portable.

there are portable threading solutions.

nospam

unread,
Jun 14, 2010, 4:47:19 AM6/14/10
to
In article <87eiga9...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

> And why do you supposed after all these years there is
> no alternative? Could it just happen to be that dcraw
> is such a killer implementation that nobody wants to
> waste their time writing a "replacement" that will never
> be more than an obscure "almost an alternative"?

because anyone skilled enough to do it can get paid quite well for it,
rather than wasting their time on something that is given away. that's
why the state of the art converters are commercial products, such as
camera raw, capture one, dxo, etc.

nospam

unread,
Jun 14, 2010, 4:51:33 AM6/14/10
to
In article <87ocfe6...@apaflo.com>, Floyd L. Davidson
<fl...@apaflo.com> wrote:

very little. the raw conversion is completely different.

about all that adobe used from dcraw was some decoding of maker notes.
big deal.

LOL!

unread,
Jun 14, 2010, 9:14:56 AM6/14/10
to

"State of the art"?!?

LOL!

http://www.rawtherapee.com/RAW_Compare/

All the ones you mentioned fail when compared to freeware and donation-ware
software.

LOL!!!!!!

Keep on trolling you pretend-photographer fool!

LOL!

Doug McDonald

unread,
Jun 14, 2010, 10:03:02 AM6/14/10
to
On 6/14/2010 2:44 AM, Floyd L. Davidson wrote:

>
> Your exception list doesn't include a single program
> that duplicates what Jon and I agree is the purpose of
> /dcraw/ as a program. Do you even know what /dcraw/ is?
>
> Plus Adobe used Coffin's /dcraw/ in the development of
> their own converter, though because Adobe is proprietary
> we don't know to what degree or exactly in what way
> even.
>

Both dcraw and the Photoshop RAW converter are, for Canon DSLR
files, far superior to Canon's offering in some ways, especially
the treatment of specular highlights, something I recently
had a big flurry of (waterfalls in the Grand Canyon.) The Canon
convertor simply could not cope with such things unless the
raw file was at least 1 stop less exposed than the exposure necessary for
fine results from Adobe and dcraw.

Doug McDonald

Message has been deleted

nospam

unread,
Jun 14, 2010, 12:27:31 PM6/14/10
to
In article <2010061407245343658-savageduck1@REMOVESPAMmecom>,
Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:

> It is also worth noting, that Adobe has a completely new process for
> ACR 6.1 delivered with CS5 and LR3. The first substantial change to
> their ACR process since 2003.

good point. that's a huge step forward, especially in noise reduction.

you'll never see something like that in dcraw.

Peter

unread,
Jun 14, 2010, 7:58:11 PM6/14/10
to
"Floyd L. Davidson" <fl...@apaflo.com> wrote in message
news:87ocfe6...@apaflo.com...

> Do you even know what /dcraw/ is?
>

I DO!

Arguments like you and Ray are having in this thread, sticks in decraw.

--
Peter

Peter

unread,
Jun 14, 2010, 8:02:18 PM6/14/10
to
"nospam" <nos...@nospam.invalid> wrote in message
news:140620101227313053%nos...@nospam.invalid...

> In article <2010061407245343658-savageduck1@REMOVESPAMmecom>,
> Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:
>
>> It is also worth noting, that Adobe has a completely new process for
>> ACR 6.1 delivered with CS5 and LR3. The first substantial change to
>> their ACR process since 2003.
>
> good point. that's a huge step forward, especially in noise reduction.
>

I haven't played with NR or sharpening in ACR 6.1. In the past I have been
doing all NR and sharpening in PS.

Is there a significant advantage to doing it in ACR?


--
Peter

nospam

unread,
Jun 14, 2010, 8:18:41 PM6/14/10
to
In article <4c16c3a2$0$5491$8f2e...@news.shared-secrets.com>, Peter
<pete...@nospamoptonline.net> wrote:

> >> It is also worth noting, that Adobe has a completely new process for
> >> ACR 6.1 delivered with CS5 and LR3. The first substantial change to
> >> their ACR process since 2003.
> >
> > good point. that's a huge step forward, especially in noise reduction.
>
> I haven't played with NR or sharpening in ACR 6.1. In the past I have been
> doing all NR and sharpening in PS.
>
> Is there a significant advantage to doing it in ACR?

photoshop uses camera raw, so you may already be doing it there, but
definitely look at 6.x (which means upgrading ps or lr).

noise reduction is best done in the raw converter and sharpening should
be done initially in the raw converter and then later specific for the
output. sharpening for print is going to be a little different than for
screen, for example.

Peter

unread,
Jun 14, 2010, 8:28:18 PM6/14/10
to
"nospam" <nos...@nospam.invalid> wrote in message
news:140620102018417739%nos...@nospam.invalid...


I'm using PS 5, now. Formerly I used PS 7, then CS3. I have never found a
satisfactory NR technique, I saw too much color blurring. My workflow has
been to set ACR sharpening to 0 and then use either LAB color sharpening,
high pass filter sharpening, or some combination of both, depending on the
image. I have a feel for what I am doing, but am willing to change if there
is a good reason.

--
Peter

nospam

unread,
Jun 14, 2010, 8:39:36 PM6/14/10
to
In article <4c16c941$0$5496$8f2e...@news.shared-secrets.com>, Peter
<pete...@nospamoptonline.net> wrote:

> I'm using PS 5, now. Formerly I used PS 7, then CS3.

do you mean photoshop elements? photoshop 5 came out in 1998 and
predates camera raw by a few years. or do you mean photoshop cs5, which
supports camera raw 6? photoshop 7 came out in 2002 and photoshop
elements 7 was in 2008, if i recall.

> I have never found a
> satisfactory NR technique, I saw too much color blurring. My workflow has
> been to set ACR sharpening to 0 and then use either LAB color sharpening,
> high pass filter sharpening, or some combination of both, depending on the
> image. I have a feel for what I am doing, but am willing to change if there
> is a good reason.

i would suggest doing as much as possible in camera raw, especially
since it's non-destructive. i never found the high pass sharpening
method to be that useful, but some people like it.

Message has been deleted

nospam

unread,
Jun 14, 2010, 8:45:32 PM6/14/10
to
In article <2010061417420227544-savageduck1@REMOVESPAMmecom>,

Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:

> As Scott Kelby has noted the "Adobe Camera Raw" ACR 2003 process seemed
> to have had little to no effect when it came to noise or sharpening
> correction, and he recommended not wasting time with those adjustments.

the late bruce fraser disagreed, saying there should be some sharpening
initially and then final sharpening later. it's all subjective, when
you get right down to it.

> With ACR 6.1 and the 2010 process, noise reduction and sharpening
> works, and works well. Kelby now recommends it as part of the RAW
> conversion process when needed.

yes, it's all quite a bit better now.

> Also ACR 6.1 supports lens correction profiles so Distortion, CA, and
> vignette correction for a particular lens can be applied during
> conversion.

that too.

Wolfgang Weisselberg

unread,
Jun 14, 2010, 5:54:34 PM6/14/10
to
ray <r...@zianet.com> wrote:
> On Wed, 09 Jun 2010 16:07:44 -0700, Mike Russell wrote:

>> That's not such a slow system. How much memory do you have? If it's
>> less than 2 gigs, that's probably the bottleneck. Memory is cheap.

> Doubtful. It shouldn't take 2gb memory to convert a 12mp image!

Vista alone uses 2GB, for example ... and the rest of the
system needs RAM as well.

-Wolfgang

Wolfgang Weisselberg

unread,
Jun 14, 2010, 5:38:19 PM6/14/10
to
Alfred Molon <alfred...@yahoo.com> wrote:
> In article <grpv061jjnkl35tuh...@4ax.com>, Mark F says...

>> My machine is pretty old (Pentium 4, 2.40GHZ)

>> It takes a minute or two of CPU time to convert a Fujifilm FinePix
>> S100fs RAF file to JPG taking "default" conversion parameters.

> How about buying a new computer, very cheap these days?

Just buying a bigger hammer won't get screws better into the wall.
Nor will buying a newer camera make someone who can't frame a
shot a better photographer.

It's wise to ask first if the conversion step is unusually slow
and maybe use a faster converter instead of a faster computer,
if said converter is the cause.

-Wolfgang

ray

unread,
Jun 14, 2010, 10:10:34 PM6/14/10
to

Many users are more intelligent than that.

nospam

unread,
Jun 14, 2010, 10:28:25 PM6/14/10
to
In article <87o5oq...@mid.individual.net>, ray <r...@zianet.com>
wrote:

> >>> That's not such a slow system. How much memory do you have? If it's
> >>> less than 2 gigs, that's probably the bottleneck. Memory is cheap.
> >
> >> Doubtful. It shouldn't take 2gb memory to convert a 12mp image!
> >
> > Vista alone uses 2GB, for example ... and the rest of the system needs
> > RAM as well.
>

> Many users are more intelligent than that.

those are the ones that stuck with xp or bought a mac :)

Ray Fischer

unread,
Jun 15, 2010, 3:29:18 AM6/15/10
to

Boo

hoo.

Peter

unread,
Jun 15, 2010, 9:11:00 AM6/15/10
to
"nospam" <nos...@nospam.invalid> wrote in message
news:140620102039363026%nos...@nospam.invalid...

> In article <4c16c941$0$5496$8f2e...@news.shared-secrets.com>, Peter
> <pete...@nospamoptonline.net> wrote:
>
>> I'm using PS 5, now. Formerly I used PS 7, then CS3.
>
> do you mean photoshop elements? photoshop 5 came out in 1998 and
> predates camera raw by a few years. or do you mean photoshop cs5, which
> supports camera raw 6? photoshop 7 came out in 2002 and photoshop
> elements 7 was in 2008, if i recall.

No. I meant CS5.


>
>> I have never found a
>> satisfactory NR technique, I saw too much color blurring. My workflow has
>> been to set ACR sharpening to 0 and then use either LAB color sharpening,
>> high pass filter sharpening, or some combination of both, depending on
>> the
>> image. I have a feel for what I am doing, but am willing to change if
>> there
>> is a good reason.
>
> i would suggest doing as much as possible in camera raw, especially
> since it's non-destructive. i never found the high pass sharpening
> method to be that useful, but some people like it.

It's good only for certain high contrast images. If I wanted to get details
of the feathers on a bird, it doesn't work well. I switch to smart sharpen
on the lightness channel in LAB color, so as not to get the halo effect

--
Peter

Peter

unread,
Jun 15, 2010, 9:16:22 AM6/15/10
to
"Savageduck" <savageduck1@{REMOVESPAM}me.com> wrote in message
news:2010061417420227544-savageduck1@REMOVESPAMmecom...

>
> As Scott Kelby has noted the "Adobe Camera Raw" ACR 2003 process seemed to
> have had little to no effect when it came to noise or sharpening
> correction, and he recommended not wasting time with those adjustments.

> With ACR 6.1 and the 2010 process, noise reduction and sharpening works,
> and works well. Kelby now recommends it as part of the RAW conversion
> process when needed.

You guys have given me reason to try NR in ACR

>
> Also ACR 6.1 supports lens correction profiles so Distortion, CA, and
> vignette correction for a particular lens can be applied during
> conversion.

I have the sticky feeling that Capture NX2 does a better job of correcting
lens aberrations. I am not convinced that Nikon gives all specifications.


--
Peter

Peter

unread,
Jun 15, 2010, 9:24:19 AM6/15/10
to
"nospam" <nos...@nospam.invalid> wrote in message
news:140620102228251870%nos...@nospam.invalid...


If I only used the machine for graphics and Internet BSing, I would probably
have a Mac. But, I also need a machine for business. From a usability
standpoint I have compared my HP with a Mac. At least for Photoshop I see no
significant difference. Though on a Mac I have right click issues.

--
Peter

Message has been deleted
Message has been deleted

Peter

unread,
Jun 15, 2010, 12:07:03 PM6/15/10
to
"Savageduck" <savageduck1@{REMOVESPAM}me.com> wrote in message
news:2010061508494664440-savageduck1@REMOVESPAMmecom...
> Unless you have Windows specific SW at work there is no reason not to
> consider a switch to Mac at home (or work for that matter). Office is
> available for Mac and price difference for total package with any of the
> optional processors is negligible. If you price out Macs, HP, Dell, etc
> with similar specs and SW you will find very little price/value
> differential.
> The right click issues on a Mac have been a thing of the past for many
> years now, and are a relic of Mac naysayers past repertoire.
> Also with Intel Macs you have the option of running, in addition to OSX,
> any version of Windows so you can run any of that Windows specific SW.
>
> Having said that if you are happy with your HP you might as well stay that
> route. As a long time Mac user condemned to use Windows machines at work,
> I think you might be surprised at what the Mac and OSX brings to the
> table.
>

I will look next time. Meanwhile this machine does what I need and does it
well. I thought my laptop was fast until I got that machine.


--
Peter

nospam

unread,
Jun 15, 2010, 12:10:41 PM6/15/10
to
In article <4c177f20$2$5503$8f2e...@news.shared-secrets.com>, Peter
<pete...@nospamoptonline.net> wrote:

> If I only used the machine for graphics and Internet BSing, I would probably
> have a Mac. But, I also need a machine for business. From a usability
> standpoint I have compared my HP with a Mac. At least for Photoshop I see no
> significant difference.

photoshop is the same on both platforms, and you can run any windows
specific software in vmware alongside the mac software (or dual boot
but that's a pain), and that's assuming there isn't an equivalent.

> Though on a Mac I have right click issues.

what issues are those? macs have supported secondary clicks for years.
apple has shipped a multibutton mouse for years, or use any standard
usb or bluetooth mouse you prefer.

Robert Spanjaard

unread,
Jun 15, 2010, 12:25:44 PM6/15/10
to
On Wed, 09 Jun 2010 13:20:26 -0800, Floyd L. Davidson wrote:

> In fact though, I cheat. I use Linux and have a script that determines
> how many CPU's the system has and then feeds a loop that keeps all of
> the CPU's busy. One box that I use has 4 CPU's, and another has 8. The
> script works them to the max. The 4 CPU box processes images at 6
> seconds per image. (If ufraw-batch is invoked normally, and uses just 1
> CPU serially, it takes 21 seconds per image on that particular system.)

Which version do you use? UFRaw has had OpenMP support since version
0.15, so you shouldn't need to handle the multihtreading manually.

--
Regards, Robert http://www.arumes.com

Floyd L. Davidson

unread,
Jun 15, 2010, 4:16:47 PM6/15/10
to

I download a CVS snapshot of the development thread
about once a month.

OpenMP support doesn't hold a candle to processing one
image per CPU with a script. Note the time difference
quoted above, it's just over 3 times faster.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com

Robert Spanjaard

unread,
Jun 15, 2010, 4:31:09 PM6/15/10
to
On Tue, 15 Jun 2010 12:16:47 -0800, Floyd L. Davidson wrote:

>>> In fact though, I cheat. I use Linux and have a script that
>>> determines how many CPU's the system has and then feeds a loop that
>>> keeps all of the CPU's busy. One box that I use has 4 CPU's, and
>>> another has 8. The script works them to the max. The 4 CPU box
>>> processes images at 6 seconds per image. (If ufraw-batch is invoked
>>> normally, and uses just 1 CPU serially, it takes 21 seconds per image
>>> on that particular system.)
>>
>>Which version do you use? UFRaw has had OpenMP support since version
>>0.15, so you shouldn't need to handle the multihtreading manually.
>
> I download a CVS snapshot of the development thread about once a month.
>
> OpenMP support doesn't hold a candle to processing one image per CPU
> with a script. Note the time difference quoted above, it's just over 3
> times faster.

I noticed that. I also noticed the "uses just 1 CPU serially" in the same
quote.

Peter

unread,
Jun 15, 2010, 1:35:58 PM6/15/10
to
"nospam" <nos...@nospam.invalid> wrote in message
news:150620101210418392%nos...@nospam.invalid...


there was no right button on the mouse, However, as I said before, what I
have is working for me.

--
Peter

nospam

unread,
Jun 15, 2010, 5:50:18 PM6/15/10
to
In article <4c17f240$1$5527$8f2e...@news.shared-secrets.com>, Peter
<pete...@nospamoptonline.net> wrote:

> there was no right button on the mouse,

yes there was. macs have shipped with multibutton mice for about five
years and before that you could replace it with whatever mouse you want
(and still can for that matter). plus, the second button is nowhere
near as critical as it is in other operating systems.

> However, as I said before, what I
> have is working for me.

that's what matters.

Floyd L. Davidson

unread,
Jun 15, 2010, 6:17:00 PM6/15/10
to

You're right, those figures were indeed for /ufraw/ compiled
with OpenMP disabled. Here are times with and without, for
various configurations. These are for batch processing 20
NEF files from a D2X (12 bit compressed format) on a machine
with 8 CPU's.

PROGRAM OpenMP Total_Time Time/Image Sys_Load_Avg

ufraw-batch disabled 342 sec 17.1 sec 1.15
ufraw-batch enabled 214 10.7 3.44

script enabled 89 4.5 22.02
script disabled 84 4.2 7.05


There is little doubt that OpenMP is effective, but it
is not nearly as efficient at parceling out CPU time
within a process for a single image as is a script that
invokes unique processes on multiple images
asynchronously.

(Note that load average values for the script are high
values seen when the script is run 3 times
consecutively. All load average values are probably
slightly lower than what would be seen if a much larger
batch were used.)

0 new messages