> I agree that ufraw would be good to add in the > future. Ufraw uses dcraw > internally. Since dcraw isn't a shared library, > ufraw has to compile in > new versions of the dcraw source code. It might be > nice to fix that so > we don't end up maintaining both the dcraw embedded > within ufraw and the > dcraw stand alone.
The dcraw web page FAQ section says: >Why don't you implement dcraw as a library? > I have decided that dcraw shall be a command-line program written in C, > and that any further abstraction layers must be added around this core, not > > inside it. > > Library code is ugly because it cannot use global variables. Libraries are > more difficult to modify, build, install, and test than standalone programs, > and so are inappropriate for file formats that change every day. > There's a simpler way to make dcraw modular and thread-safe: Run it as a > separate process. Eric Raymond explains this technique here. In other words, the originator thinks he can keep life simple, and concentrate on adding formats or output quality by keeping it a standalone program rather than a library. Now, if a conversion took less time than a fork/exec, I might disagree; but given how often dcraw is updated, and that the conversions tend to be pretty slow running anyway, I don't see it matters. OTOH, while there are plugins that just fork/exec dcraw, I can also understand why ufraw embeds the code, for more elaborate control and interaction. But that means its maintainers have to do some extra work. As of this moment, dcraw is at 8.81, while ufraw is based on dcraw 8.80. So ufraw is keeping up well but more than just days behind, at least sometimes. And maintenance is far less if one just tracks the external code rather than going for the grand design, IMO. I expect that the usual "bug" the dcraw author recieves is of the form "please support new camera X", not "please reduce memory usage by 5% when a 100 Sun Ray users are maxing the server's CPU anyway by running this simultaneously". :-) If one really wanted an improvement, one could work hard on the conversion speed for dcraw, and feed that back to the author; not try to convince him to change his design, or fork it. This message posted from opensolaris.org
