Cartola - 

Like you, I agree that Hugin's developers should be thanked and more 
appreciated than they are. I think this is why Hugues' original comment 
touched a nerve with some people - it was an attack on developers who, 
generally speaking, do this for fun and for free, and there was a certain 
lack of understanding in his post, which rubbed people the wrong way, and 
rightly so. Whatever Hugin's shortcomings, it is free, and available, and 
for many people that may be the difference between creating stitched images 
or not. For people who can't afford the commercial alternatives, it is nice 
to have some alternative to recommend, even if that alternative is not 
perfect.

I would be thrilled if Hugin could accomplish everything I needed it to for 
free, and if it could, I would recommend it to anyone in a heartbeat. 

Unfortunately, in my experience, it does not, and I cannot.

GnomeNomad (David) - 

I agree that the UI is not particularly complicated or complex, especially 
if you understand the general principles behind stitching. There are a few 
odd choices here and there, and some power functionality is not as easy to 
access as it should be, but overall, I would call Hugin's UI a fairly good 
open-source clone of PTGui.

I can't speak for everyone, of course, but my stability issues with the 
Windows build haven't really been with the UI (where OpenGL would be the 
culprit), but rather crashes of component programs (Enblend and Enfuse 
commonly give me out of memory errors, even when plenty of memory is free, 
and I've had Nona and HDR_merge crash on multiple occasions for no obvious 
reason). My suspicion is that there are probably some issues with the 
libraries that these programs link to (or more technically the Windows 
ports of the libraries), but given that I often debug software at work, I 
have very little interest in doing so when I get home. I have used the 
Linux version, on occasion, and found it to be more stable, as Cartola 
mentioned. At the same time, I have also encountered some weird bugs there 
as well (issues like excessive disk access, etc.). 

With regard to your "make panoramas with just a click or two 
smartphone/p&s" comment, I don't consider myself to fall into that 
category. The majority of panoramas I stitch are multirow and stacked HDR 
sets, with generally 60-150 component images. I appreciate having as much 
power under the hood as possible, which is why several of my projects 
ultimately end up in PTAssembler - the ability to specify your own 
projection can often be the difference between your shot working out or not 
- a feature, I might mention, which Hugin does not have (nor does PTGui, in 
fairness).

My biggest issue with Hugin, however, is a general "can I trust it to 
work?" concern. After trying to stitch a couple of dozen image sets in 
several packages to get a feel for which package is "best" (note: I don't 
think any of them are), I have very little confidence that Hugin is going 
to give me a successful stitch with a reasonable amount of effort, in a 
reasonable amount of time (see below), on a consistent basis. As I said 
before, I don't consider the "one-click" output from any package to be 
sufficient, but neither do I consider it acceptable for the 
blender/fusion/HDR engine to crash or give a blank output on 30-40% of the 
projects I attempt. True, I can use a different blender and do the 
fusion/HDR merge in a third-party program, but it seems a little unfair to 
give Hugin the credit for "creating my panorama" when I had to use other, 
non-supplied (and definitely not open-source) tools to get the project 
done. 

That might all be forgivable, of course, if Hugin's performance, either in 
terms of processing time or final output quality were heads and shoulders 
above the competition. Unfortunately, they are not.

This morning, after Cartola posted, I thought it might be interesting to do 
a speed comparison between a few packages in terms of how long it took to 
put a panorama together, and how long it took to render it. I selected a 
recent project with 90 images, 18 stacks of 5 exposures. The three packages 
I had installed on my system were PTGui, PTAssembler, and Hugin. For each 
project, I initially did a "Load Images" and "Align" or "Auto-Create," 
which seemed to me to be a reasonable procedure that a typical person might 
take, at least as a starting point. The projects were run on the same 
computer (Core i5 Haswell laptop, SSD, 12GB RAM) with no other activity 
taking place while the various tasks were performed. Timing was performed 
by me, with a stopwatch, meaning there may be a second or two error in the 
times, but as you'll see below, we're not exactly talking about a photo 
finish. 

PTGui was, not surprisingly, the fastest, taking only 1:21 to generate 
control points, and 0:32 to align the panorama. PTAssembler was 
considerably slower, taking 12:40 to generate control points, and 1:51 to 
optimize and align the panorama. Hugin, on the other hand, took 17:48 to 
generate control points. The next step, celeste, took 6:55. The next step 
in the "assistant" is cpclean, which I eventually stopped after 3 hours, 
because honestly it seemed stupid to let it continue after that long. 

It's worth pausing here to emphasize this point: PTGui had a reasonably 
well aligned panorama in just under two minutes. PTAssembler took almost 15 
minutes. Hugin was still mucking about with control points and trying to 
align the panorama *three and a half hours* later using the automated 
"align" functionality - *and it wasn't finished when i cancelled it*.

After cancelling the assistant, I decided to see if I could back out and 
run the manual optimizer with the control points generated during the 
"align" step. It completed, but the resulting panorama was garbage. 
Clearly, there were some control point errors. Lots of them, actually. 
Fine, let's start over, go full manual. Load images. Generate control 
points using the multirow/stacked setting. CPfind completed in 17:48, 
almost 5 minutes (40%) slower than PTAssembler and 13x (1300%)! slower than 
PTGui. Geometric optimization took 6:31 to align the panorama, or 3.5x 
slower than PTAssembler, and 12x slower than PTGui. Thankfully, however, we 
at least had reasonable control points and a somewhat aligned panorama 
though, in fairness, one that needed a little more TLC than the other two 
before it was presentable. 

Rendering provided a similar story: Rendering with a Spline16 interpolator, 
PTGui completed in 11:05. PTAssembler took 17:46. Hugin completed... oh, 
wait, did I mention that hdr_merge crashes a lot in Windows? Yes, this 
would be one of those times. But never mind that, we have Linux! 

Booting into Linux (Ubuntu 14.04, default Hugin install from package 
manager), I fired up the project. Everything did eventually render, but 
only after 2:25:01.

Again, it's worth pausing to reiterate just how slow Hugin was for this 
project: PTGui finished the whole thing, input images to final panorama in 
under 15 minutes. Hugin took almost *three hours* (over six, if you count 
the first 3.5 wasted hours from the "Align" debacle), didn't finish the 
project at all in Windows (a supposedly supported operating system), and in 
my personal opinion the output doesn't look as good.

As I mentioned in my first post, you do get what you pay for, and in this 
case, I suppose for the difference in price, many people could live with 
the slow performance, if that were the only problem. Unfortunately, again, 
in my experience, slow performance is *not* the only problem - particularly 
in Windows, Hugin is also beset with crashes, bugs, and general failure to 
generate a good alignment without a reasonable amount of handholding and 
understanding of the underlying phenomena. 

If you're an expert who has a good understanding of the math behind image 
stitching, you'll probably not have a problem understanding Hugin. If 
you're a software developer who is capable of debugging Hugin's various 
crashes and shortcomings, you might be happy you didn't have to pay for a 
more expensive package. If you run Linux only, you'll be glad there is 
*some* option available to you. If you have the patience of Job, you won't 
mind waiting for Hugin to finally produce an output (though you may be as 
old as Methuselah by the time it finishes...).  

Hugin's best quality is that it's free. I appreciate that the developers 
have put the time and effort into Hugin to make it as workable of an 
alternative as it is. You can, with a lot of work, get good results out of 
it, at least for some projects. But back to Joergen's post, just because 
the OP wasn't terribly helpful doesn't mean there wasn't some amount of 
truth to his criticisms. Telling people who've had problems with Hugin (or 
who don't think it is as good as the alternatives) that they "just don't 
know how to use it," or that they are "members of the casual 
smartphone/tablet/P&S camera world" or that they "have very few computer 
abilities," or that they should be using Linux, or that the problem is 
(entirely) "between the monitor and the back of the chair" is not a valid 
defense of Hugin. I have a Ph.D. in Electrical and Computer Engineering and 
work at a Tier I research university... and I firmly believe that using a 
piece of software - even a piece of open source software - shouldn't 
require either of those things. 

I'm glad that many of you find Hugin suitable for your needs. Every year or 
so, I install the new version, play around with it, and conclude that it's 
still not worth using as a daily driver - at least not for me. There are 
too many rough edges, too many crashes, and too much inconsistency in the 
output for me to rely on it, even though I'm no longer doing professional 
photography work. YMMV, of course. Personally, I'm happy to pay for the 
faster, more powerful, and more consistent alternatives.

Best

Jeff




On Wednesday, May 14, 2014 4:04:23 PM UTC-4, GnomeNomad wrote:
>
> I think in some cases the Windows bug issues appear to be coming from 
> Windows components or libraries that aren't part of Hugin? 
>
> Also, MS is methodically stripping OpenGL support from Windows, because 
> they want to lock everyone into using their proprietary API instead. 
> That impacts Hugin. 
>
> We haven't used Windows at home for over 10 years now. (I use it at the 
> office but don't do any graphics work there.) 
>
> The Hugin UI is very logical when you understand the theoretical 
> framework underlying mapping images and stitching. The UI is also 
> somewhere in the middle of transformation, not necessarily in a 
> direction I agree with. So it can be a bit confusing. 
>
> Personally, if someone wants to make panoramas with just a click or two, 
> it sounds like they're members of the casual smartphone/tablet/P&S 
> camera world. And while it could be nice to have a "Hugin Lite" (a 
> reworked Assistant UI) for such, I certainly hope Hugin doesn't lower 
> its power to accommodate such people. 
>
> On 05/14/2014 02:33 AM, Carlos Eduardo G. Carvalho (Cartola) wrote: 
> > Well, 
> > 
> > I just like hugin, maybe because I am a big fan of opensource software 
> > and as a system analyst I surely have less problems with complex 
> > software than a standard user. And here we are talking about 
> > photographers, that many times have very few computer abilities. What I 
> > am trying to say is that I surely see reason in those comments and it 
> > doesn't mean that I don't see all the merit and effort made by 
> > developers, that do this for fun, for free or whatever, as volunteers. 
> > 
> > I surely see more hugin crashes on Windows and it surely contributes a 
> > lot for hugin being less used, as I see windows as the biggest player in 
> > the market share, at least here in Brazil, but have some feeling that 
> > worldwide it is also the same. 
> > 
> > I have done some workshops using both windows and linux. On Linux I 
> > don't remember having crashes or any other problems, but on Windows, 
> > which is only an option when the lab can't install Linux, I have already 
> > told people to leave their computers and follow the workshop on a 
> > friends desktop, cause there were nothing else we could do in the middle 
> > of the class. 
> > 
> > Maybe we should focus a little bit more on windows versions to stabilize 
> > it. Don't know if there are windows developers motivated for it. 
> > 
> > I also see some effort to change its usability, and recent changes on 
> > the interface show it, but I still see difficulties on new users to use 
> > it. They usually prefer, as Jeff and others said, commercial softwares, 
> > like PTGui. I think PTGui user interface is quite similar to Hugin, but 
> > I have already seen some users preferring it... 
> > 
> > Bests, 
> > 
> > Carlos E G Carvalho (Cartola) 
> > http://cartola.org/360 
> > http://www.panoforum.com.br/ 
> > 
> > 
> > 2014-05-13 16:53 GMT-03:00 Jeff W <jeff.wis...@gmail.com <javascript:> 
> > <mailto:jeff.wis...@gmail.com <javascript:>>>: 
> > 
> >     Unfortunately, I have to agree with Joergen here. 
> > 
> >     Hugues comment wasn't terribly constructive, but that doesn't change 
> >     the reality that Hugin has some significant issues compared to its 
> >     competitors. CPFind and Nona are both painfully slow, and both 
> >     Enblend and Enfuse frequently crash for me on multiple computers, at 
> >     least two of which have 12GB of ram. Hugin's HDR_Merge output can 
> >     sometimes produce nice results, but in my experience that happens 
> >     perhaps 2 out of every 5 times, and the other three border on 
> >     unusable. Add in random crashes of Hugin itself, and occasional 
> >     serious bugs (which do generally get fixed, but there are always new 
> >     ones to take their place), and I have a really difficult time 
> >     recommending Hugin for anyone who is planning to take a lot of 
> >     panoramas, or someone who is planning to take a particularly 
> >     complicated project. I've gotten some nice results out of Hugin, but 
> >     it's always felt like I'm fighting with the software... and frankly 
> >     the time and frustration are worth the price of the other packages 
> >     out there, at least for me. 
> > 
> >     I've stitched dozens of panoramas in most of the major packages on 
> >     the market. I keep Hugin installed because occasionally it's useful, 
> >     but I don't think it's unfair to say that it is the least polished 
> >     and most cantankerous stitching program out there. Of course, it's 
> >     also the free-est stitching program out there, and in some sense you 
> >     get what you pay for, in this case. 
> > 
> >     I could live with the slowness, probably, if I had a high confidence 
> >     that Hugin/Enblend/Enfuse/Nona/Hdr_merge would actually *work* 
> >     without crashing on my project, and deliver acceptable results. Just 
> >     for the heck of it, I pulled up one of my most recent panoramas in 
> >     2014.RC1 (Windows) to see if I could get it to stitch: "C:\Program: 
> >     Interrupt/Exception caught (code = 0xc0000005, addr = 
> >     0x00007FF6DF9CC15F)" 
> > 
> >     So there's that. 
> > 
> >     It's clear, based on reviews, that I may be in the minority. Maybe 
> >     the things I'm trying to do just aren't that common, but I've had 
> >     /very/ bad luck getting Hugin to consistently work on my projects. 
> > 
> >     I've really wanted to like Hugin. But in the end, I haven't. 
> > 
> >     On Saturday, May 10, 2014 11:13:13 AM UTC-4, Joergen Geerds wrote: 
> > 
> >         While Hugues comment is indeed over the top, and in its actual 
> >         content not helpful to provide any help, there is fundamental 
> >         truth in his sentiment. 
> >         The beginning hurdle for me as an end user is finding a 
> >         downloadable binary, since http://hugin.__sourceforge.net 
> >         <http://hugin.sourceforge.net> is the official homepage, but 
> not 
> >         maintained since last year. it takes some serious looking around 
> >         to find a recent binary. I do this process about every 6-9 
> >         months, and in the past it was always the same result: i 
> >         couldn't use it (and this could be very much a PEBKAC). I 
> >         finally found a mac 2014.0rc2 version, installed it, launched 
> >         it, and get confronted with wxwidget error messages... not a 
> >         good start again. then I load a bunch of small fisheye tiffs (no 
> >         exif data), load them, and get asked to enter exif data for each 
> >         of the 18 tiffs, one by one (my mind hovers again next to the 
> >         "should I just delete it again and come back in 6 months?")... 
> >         being confronted with more wx errors, and no way to assign the 
> >         same lens parameters to all source images (at least not in a 
> >         obvious way), I am going to give up today, since no control 
> >         points could be found, and maybe try again tomorrow. as it 
> >         stands right now, I have never in my whole pano life managed to 
> >         get a single panorama out of hugin, and I really tried (please 
> >         don't bash me as a pano beginner). I could maybe try harder to 
> >         get around the quirks hugin is throwing my may, and every time I 
> >         install a new hugin I really want to believe that this is the 
> >         one that finally works, it is not the easiest task for users 
> >         like me. 
> > 
> >         so while Hugues comment is wrong from a bug fixing perspective, 
> >         there is enough truth to his sentiment to not bash it like it 
> was. 
> > 
> >         On Monday, March 24, 2014 3:08:01 PM UTC-4, Cartola wrote: 
> > 
> >             Surely. 
> > 
> >             And the main wrong thing we can see is that instead of 
> >             asking how to do and tell what and how he has done, so we 
> >             could help, he has just made useless comments. Looks like a 
> >             user that deserves the good and old RTFM answer. 
> > 
> >             I have stitched hundreds of panoramas with Hugin, but surely 
> >             other stitchers also work. Just let him buy his proffered 
> >             one or maybe do some piracy crime. 
> > 
> >             Cheers, 
> > 
> >             Carlos E G Carvalho (Cartola) 
> >             http://cartola.org/360 
> >             http://www.panoforum.com.br/ 
> > 
> > 
> >             2014-03-24 15:36 GMT-03:00 Bart van Andel <
> bavan...@gmail.com>: 
> > 
> >                 That's weird. I can stitch whatever I want with this 
> >                 same Hugin program and the results usually come out 
> >                 pretty nicely. Must be me doing something wrong? 
> > 
> >                 On Monday, March 24, 2014 6:08:34 PM UTC+1, Hugues D 
> wrote: 
> > 
> >                     Hi, 
> >                     I just downloaded and installed Hugin. I then loaded 
> >                     15 pictures I have stiched very easily with the free 
> >                     Microsoft ICE giving great results but some stiching 
> >                     errors. I thought that Hugin would be a better tool. 
> >                     Conclusion : Hugin is not even capable of finding 
> >                     two common points between 2 pictures in my set of 
> 15. 
> >                     This is ridiculous and unusable. 
>
>
> -- 
> David W. Jones 
> gnome...@gmail.com <javascript:> 
> wandering the landscape of god 
> http://dancingtreefrog.com 
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/dc385b83-2fdb-4136-b110-678a301877f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to