How long does it take to convert a raw camera file to "default"JPG?
in [Digital Cameras]
|
Prev: How long does it take to convert a raw camera file to "default" JPG?
Next: Well worth reading: "I was wondering if anybody on here has had any problems with there Canon 5D MKII" . Web address inside.
From: Jon Smid on 12 Jun 2010 16:24 nospam schreef: > In article <obQQn.65445$0A4.32329(a)newsfe01.ams2>, Jon Smid > <Varkensvoer(a)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 ? > >> I guess it will be very difficult giving a decent answer if you don't >> define what you exactly mean with 'to convert'. > > exactly.
From: Jon Smid on 13 Jun 2010 07:26 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.
From: Jon Smid on 13 Jun 2010 08:26 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.
From: Jon Smid on 13 Jun 2010 14:42 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>
From: Doug McDonald on 14 Jun 2010 10:03
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 |