[hugin-ptx] Re: enfuse: feature proposal to evaluate 'technical' qualities
On 10 Feb., 03:59, Robert Krawitz r...@alum.mit.edu 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: enfuse: feature proposal to evaluate 'technical' qualities
On Fri, 10 Feb 2012 00:14:28 -0800 (PST), kfj wrote: On 10 Feb., 03:59, Robert Krawitz r...@alum.mit.edu 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. More than a bit, to my mind. It doesn't look very natural. 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. The problem with GIMP -- IMHO -- is that they're letting themselves get sucked into UI details, while ignoring what's really needed for high-end graphics work. They put a lot of effort into single window mode to try to make it feel more comfortable to Photoshop users, but meanwhile GEGL is lagging. Cinepaint always crashes on me when I try to use it, and it's so out of date that I find it impossible to do anything of any sophistication. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: enfuse: feature proposal to evaluate 'technical' qualities
On 02/10/2012 02:35 AM, Robert Krawitz wrote: On Fri, 10 Feb 2012 00:14:28 -0800 (PST), kfj wrote: On 10 Feb., 03:59, Robert Krawitzr...@alum.mit.edu 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. More than a bit, to my mind. It doesn't look very natural. 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. The problem with GIMP -- IMHO -- is that they're letting themselves get sucked into UI details, while ignoring what's really needed for high-end graphics work. They put a lot of effort into single window mode to try to make it feel more comfortable to Photoshop users, but meanwhile GEGL is lagging. As long as they don't support 48-bit color, they won't get many Photoshop users. Cinepaint always crashes on me when I try to use it, and it's so out of date that I find it impossible to do anything of any sophistication. Haven't tried Cinepaint in years. I'm doing more panos now as 16-bit TIF, then converting the final product down to 8-bit using RawTherapee. -- Gnome Nomad gnomeno...@gmail.com wandering the landscape of god http://www.cafepress.com/otherend/ -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: enfuse: feature proposal to evaluate 'technical' qualities
On 9 Feb., 15:44, Robert Krawitz r...@alum.mit.edu wrote: In regards focal length of source image: this would have been very useful to me when preparing this image:http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=450968307k... (read the writeup) This sounds very familiar to me. I have developed a few tricks to deal with multi-lens panoramas. The first thing you need is lots, and I mean lots of good control points. That's why I wrote the woa plugin, which warps the images, looks for CPs and then unwarps their coordinates. This usually gives me such an even spread and good quality of CPs, even between images from different lenses, that the optimizer produces very good results. The next plugin which I find very useful is the crop-cp plugin, which looks at the crop area of the panorama (as set in the preview) and throws out all CPs either inside or outside it. This allows me to throw out all CPs which aren't really crucial for the match (forground, for example - let the stitcher deal with it best it can). Once I've lots of CPs in useful places left, I optimize for 'everything but translation' and also do a photometric optimization. Then I can proceed to stitch each set of images separately, and I have to do the final composition in another tool, as well. Lots of work, but, for example in mountaintop 360 degree panoramas, the extra crispness around the horizon can be worth it. BTW - a panorama head is a good thing - if most of my photography wasn't done somewhere in the mountains I'd sure carry on all the time, and they aren't even dear. I've built my own which was fun and it does the trick, but out in the wild I rely on a walking stick and a technique I've evolved over time which works well enough for natural subjects. Having tools like enfuse deal with a situation like the one you describe would be very welcome, hence my proposal. Especially the layering is annoying for me, because in cinepaint I usually get annoyed very quickly by how awkward everything is (maybe I've just not done it enough...), the gimp only does 8 bits, digiKam just isn't quite there yet and I can't accustom myself to fotoxx either... but at least on Linux I was able write the plugin interface and the plugins I need most. 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: enfuse: feature proposal to evaluate 'technical' qualities
On Thu, 9 Feb 2012 11:39:35 -0800 (PST), kfj wrote: On 9 Feb., 15:44, Robert Krawitz r...@alum.mit.edu wrote: In regards focal length of source image: this would have been very useful to me when preparing this image:http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=450968307k... (read the writeup) This sounds very familiar to me. I have developed a few tricks to deal with multi-lens panoramas. The first thing you need is lots, and I mean lots of good control points. That's why I wrote the woa plugin, which warps the images, looks for CPs and then unwarps their coordinates. This usually gives me such an even spread and good quality of CPs, even between images from different lenses, that the optimizer produces very good results. The next plugin which I find very useful is the crop-cp plugin, which looks at the crop area of the panorama (as set in the preview) and throws out all CPs either inside or outside it. This allows me to throw out all CPs which aren't really crucial for the match (forground, for example - let the stitcher deal with it best it can). Once I've lots of CPs in useful places left, I optimize for 'everything but translation' and also do a photometric optimization. Then I can proceed to stitch each set of images separately, and I have to do the final composition in another tool, as well. Lots of work, but, for example in mountaintop 360 degree panoramas, the extra crispness around the horizon can be worth it. I'll have to try this next time I do one of those. This isn't really my panorama season now. Extra sharpness in more important areas was exactly my reason for the one above. BTW - a panorama head is a good thing - if most of my photography wasn't done somewhere in the mountains I'd sure carry on all the time, and they aren't even dear. I've built my own which was fun and it does the trick, but out in the wild I rely on a walking stick and a technique I've evolved over time which works well enough for natural subjects. For the things I shoot panos of, I'm not sure how much it would really help. In a typical situation with grass or the like in the foreground, with a lot of high frequency texture but no low frequency, it doesn't matter even if things are way off, as long as the background is good. One of my panos (from a low mountain top, with our dog in the lower left foreground) it really would have helped (I wound up having to do a fair bit of manual work to fix up a big crack in the rock). Having tools like enfuse deal with a situation like the one you describe would be very welcome, hence my proposal. Especially the layering is annoying for me, because in cinepaint I usually get annoyed very quickly by how awkward everything is (maybe I've just not done it enough...), the gimp only does 8 bits, digiKam just isn't quite there yet and I can't accustom myself to fotoxx either... but at least on Linux I was able write the plugin interface and the plugins I need most. Fotoxx looks like it's really just for simple things. It has an interesting approach to panorama stitching, but it's a lot less flexible than Hugin, and by now I've done enough panos to establish a good workflow in Hugin. Your crop control points plugin is fantastic, and the last few panos I did it saved me a lot of time. 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=1079376498k=Gyg2x GIMP really needs to stop messing around with single window mode and the like, and get its act together with high bit depth. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: enfuse: feature proposal to evaluate 'technical' qualities
On 02/09/2012 04:59 PM, Robert Krawitz wrote: GIMP really needs to stop messing around with single window mode and the like, and get its act together with high bit depth. It sure does. Are they still insisting that no one needs 48-bit color - then wondering why the pro graphics market considers GIMP a joke? -- Gnome Nomad gnomeno...@gmail.com wandering the landscape of god http://www.cafepress.com/otherend/ -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
