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

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.
.

Relevant Pages