On 10 Feb., 03:59, Robert Krawitz <[email protected]> wrote: > Combining enfuse > and enblend (enmeld?) would solve my last big problem with extended > dynamic range panoramas. This is an example (look at the sky near the > horizon):http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=1079376498&...
I suppose you mean there's a bit of low-frequency vaiation in the sky colour? Not too bad, though. > GIMP really needs to stop messing around with single window mode and the > like, and get its act together with high bit depth. Indeed. It's a big nuisance they aren't getting it together. It actually drove me to put up with cinepaint which I had to compile myself (it was in such bad nick that I had to fix an error in the source code within seconds of starting the compile but then it ran through), the documentation is awful, and the UI is awkward. Their attitude isn't particularly gentle or user-friendly, it's sort of take- it-or-leave-it. But it does 16bit and is fast. I'd much prefer gimp, though. What I end up doing now is to keep everything in 16bit and then just use gimp to 'mix it down' to the final version to be used for presenting on-screen, which can't use more than 8 bits anyway - but it's a crutch. I see in gimp what seems a common trait in FOSS software. People come along and contribute great features, but they aren't documented. Every feature is realized in a slightly different way. Eventually the software ends up bloated and unmanageable, and necessary changes are impossible because noone knows how to apply them to the heterogeneous underlying code, and noone cares for boring mainatinance work, because all the merit goes to the next guy who introduces a cool new feature. Eventually some adventurous new project pops up who have realized that all they need is already out there, and by cleverly putting together a few building blocks which would have been just what the makers of the dinosaur project would have created back then if they had had today's resources, they manage to launch everyone's new darling program. It looks like the only successful FOSS projects are those which have a single person driving the thing, best is a BDFL, like Guido van Rossum for python. Someone has to make rules about what's acceptable and what is not, and rules are best made by someone who's got deep insight into the scope, concept and implementation of the project, which is typically the person who started it. Letting 'the community' decide what should be done results in what you see in the gimp - and all I've seen from them recently is littke more than stagnation. I feel in hugin we have a fundamental problem: the whole thing rests on libpano, which is a thing from the past and very hard to approach, since it's largely undocumented (the attitude is 'the code is the documentation') and it's creator seems to have abandoned it (good code, though - really, it's a shame it's only C and not more transparent). On top of that is a layer of C++ which is quite confusing, because it encapsulates all the libpano library code in a plethora of objects which is, yet again, sparsely documented (and looks overdone to me at times), and on top of the C++ layer is another layer of GUI code, which isn't really separated from the backend, so that backend functionality has made it's way into the GUI code. Finally, the whole show relies on helper programs which sometimes exhibit great inertia when it comes to problems, and the interfacing with the slave programs is awkward. If you want anything done in hugin, you may have to penertrate these four different layers. This is a real show-stopper. It makes it very hard for people to contribute. Well, I'll stop my rant here and go do something useful (I'm trying to help introduce a general coordinate remap function into vigra and vigranumpy after having convinced Ullrich Koethe that it's a good idea, but vigra's generic code is very demanding, and currently I'm struggling with the boost.python interface to get the C++ routine, which works already, to run in python...) Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
