How long does it take to convert a raw camera file to "default" JPG?
in [Digital Cameras]
|
Prev: Forget Dpreview's B.S., "diplomatic language" NEX 16mm lensis not good
Next: How long does it take to convert a raw camera file to "default"JPG?
From: nospam on 13 Jun 2010 07:10 In article <87wru38ad7.fld(a)apaflo.com>, Floyd L. Davidson <floyd(a)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?
From: Floyd L. Davidson on 13 Jun 2010 07:28 nospam <nospam(a)nospam.invalid> wrote: >In article <8739wr9r39.fld(a)apaflo.com>, Floyd L. Davidson ><floyd(a)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. The purpose is *portability*. The mechanism is ISO Standard C. Despite what you seem to think, threading is not portable. -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: Floyd L. Davidson on 13 Jun 2010 07:35 nospam <nospam(a)nospam.invalid> wrote: >In article <87wru38ad7.fld(a)apaflo.com>, Floyd L. Davidson ><floyd(a)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? Sigh... Because threads are not portable. -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: Floyd L. Davidson on 13 Jun 2010 07:44 Jon Smid <Varkensvoer(a)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. -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: Floyd L. Davidson on 13 Jun 2010 14:26
Jon Smid <Varkensvoer(a)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. -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com |