Hi KFJ, to start from the end: > I don't mean to offend anyone, but I felt I just had to vent my > frustration - I wonder if there's going to be any echo?
I don't feel your experience report offends anyone: you describe your experience and your concerns without pointing fingers or saying that there is something wrong with those who have made Hugin the way it is. Hugin is not perfect. No software is. Hugin can't be everything to everybody. Hugin is to you what you make it for yourself, and to other users what they make it for themselves, which is not necessarily the same thing. On September 23, 2010 04:06:39 pm kfj wrote: > I'm just back from browsing the PanoToolsNG newsgroup, and if you've > got some time to spare, look at the thread 'Newbie question - is PTGui > the best?' > > http://tech.groups.yahoo.com/group/PanoToolsNG/message/44594 I've stopped reading PanoToolsNG long ago. I miss some of the information shared there, but I don't miss this kind of toxic threads. I did not read the thread any further than the poisonous question. To answer it in a non-poisonous way: the best choice *for you* is what works *for you*, and it is completely up to you how much time and effort you want to invest into making something work for you. *YMMV*. > The thread above starts with a 'newbie question': what is better, > hugin or PTGui. Now I can't give an opinion on the issue since I'm a > hugin user, but I am a bit saddened by the state of affairs. Having used PTGui, Autopano Pro, Hugin, and a number of other stitchers in the past seven years, I can say that there is no absolute best choice. Each of them will appeal to a different user base. Each has a learning curve and I've had to work hard to make each of them work for me. But in the end they all did and I love them all, I don't regret spending time to understand them. > I'm a > hugin user, and judging from the discussion in the other newsgroup, I > can be one since I'm a competent computer user who can wrangle the > thing into submission by doing all kinds of stuff an 'ordinary user' > would be unable or unwilling to do. It is not up to a third party to tell who can be a Hugin user and who can't. Every user decides for themselves. I find the above definition of 'ordinary user' blurry at best. I claim that buyers of an HP or Dell notebook with Ubuntu pre-installed can be considered 'ordinary users'. A fully working installed version of Hugin is only a matter of a few mouse clicks for them, and I'm pretty sure they have to click less times than a Windows or Mac user. Of course it is not the bleeding edge, nor is it the latest release. But it is tested by the Debian quality assurance team and is known to work. Assuming that Dell and HP only ship LTS (long term support) Ubuntu versions, users who bought their machine until a few months ago got 0.7beta4 [0] and users of the most recent LTS (assuming Dell and HP updated their builds - 10.4 LTS was released in April 2010) have access to a fully working 2009.2.0 [1] - no wrangling, no CLI typing or esoteric license messages to read. If said users are slightly more adventourous, they can switch from LTS to a more current Ubuntu release. These happen every six months, and the Debian maintainers try to keep up with our release cycles. So users who update their Ubuntu every six months (granted, not 'ordinary' Ubuntu users) have access to more recent releases with the same, simple process. Is this 'wrangling'? Still not bleeding edge. Hugin 2010.0.0 will be shipped with Ubuntu 10.10 [2] in October. By then we've probably released 2010.2.0 and in the current trunk 2010.3.0 there are even more bleeding edge features. The problem I see here is not with 'ordinary users' but with 'demanding users' - users who expect the features of a bleeding edge, the stability of a release. The pricetag of Open Source. The support of paid software. > Hard as it may seem one has to meet the users where they are and give > them something that works from where they can start and maybe proceed > to more complex things. Sure, and not hard at all. Now define which users you want to meet. There is a big difference between CAE's flight simulator and Microsoft's flight simulator - not only in the price tag, but also in the target audience. Even if they are both flight simulators. In its most basic incarnation (that I dare say applies to Hugin), Open Source is made from users for themselves. Somebody had a problem. They had the skill and time to solve it, so they did. And they were generous enough to share their solution with the general public. No intention to solve other people's problems. No resources to offer any kind of support. No plans to achieve fame, money, market share, conquer the world. Just: here it is, as- is. If it is useful for you, good. If not, good too. Obviously in the case of Hugin others found it useful and built on top of it. Always with the same underlying philosophy: The user identified something that in his opinion is a problem. The user had the skill and time to fix it. The user solved it for himself. The user lived up to the moral value of Open Source and shared back his solution with the general public. > Now if I look at my experience with hugin > where nothing ever seems to work 'out of the box' and the first thing > one has to do once one's found something at all to install is to edit > command lines and install third party software, I can sympathise with > users being frustrated and not bothering any more. From what you write it seems that your experience with Hugin has not been a positive one. My sympathies. I am sometimes the frustrated user as well (and indeed I still use mostly Photoshop and not Gimp). But there is a big difference between "sympathizing" and "solving other people's problems". I know it is of little comfort to you, but to most Ubuntu users I've dealt with over the past few years Hugin worked as advertised out of the box. Hugin's contributors have never promised to solve other people's problems. It would be a promise impossible to keep with the scant resources available. Hugin can't be everything for everybody. If it does not work for you, after you have made the effort you are willing/able to, my advice is: find something else that works for you. > for example [...] it took me half a day or so to get the CPGs I > usually use to run properly again. good example... > One cannot recommend something like that to a 'newbie' whith a clean > conscience. And I'd much rather spend a day working with the software > than trying to work around it's inadequacies. As much as this sounds like an obstacle to ease of use and looks on the surface as an inadequacy of the software, it is not. Unless you are using `cpfind` (introduced into the main repository less than a week ago), or a CPG not known to me, all of the CPGs mentioned on this mailing list (or the NG newsgroup) until today are: a) encumbered by patents b) not part of Hugin (b) is a consequence of (a). Of course integrating the CPGs would make Hugin more user-friendly, but have you considered the consequences of such a move? Would you risk a legal liability just to fix a problem that is not affecting you personally? No Linux binary distribution known to me carries panomatic. No US-based mainstream Linux binary distribution carries autopano or any of its variations. Ubuntu, based in the UK, is the exception because a European contributor prepared a binary package of an old autopano version. AFAIK the SIFT patent does not apply in those jurisdictions but don't take my word for advice. I trust Ubuntu / Canonical to have legal counsel, the same way that legal counsel discouraged US-based distributors from carrying it. > Currently I am making an attempt to see if I can help make things > better by looking at the code and maybe contribute something or find > the odd bug. Thank you, this is very much appreciated. > I really appreciate all the development work taking place for > the good cause of making hugin a better program, but does it have to > be so hostile to the casual from-source approach? Where do find *hostility* (as opposed to *difficulty*)? I was in a similar situation as you four years ago. I was missing a binary distribution of Hugin (I was using Windows back then). Lacking that, my second choice was 'casual from-source building'), and I was missing instructions there too. I did not find any hostility. I did find a steep learning curve. But I also found *help, not hostility* all along the way. In return for that help I documented the building from-source, contributed the InnoSetup installer for 0.7.0, made some binary installers available, catalized the effort of other users on other platforms to document the building process on their platforms. We got pretty much everything covered. Two things happened since: (a) Hugin moved on (b) I moved on As Hugin moved on, the instructions required updating. Also some of the upstream dependencies / libraries moved on, requiring even more updating, more difficult on Windows (SDK) than on Linux (where they come automatically with the distribution). If you look at the wiki [3] you will find instructions for some platforms have been kept current, while others have stayed behind. Specifically in my case I got curious by the dissonance between my (Windows) experience and the much more positive experience reported by Linux users on this list. I took the plunge and found Ubuntu to be much more friendly to the 'casual from source approach' and a better match to my needs. I stopped trying to code on Windows. Over time I spent more and more time with Ubuntu than with Windows and for the last 18 months I have been using almost exclusively a Kubuntu desktop. I found it liberating to build from tarball rather than waiting for outdated binaries. They are outdated on Ubuntu too [4], but at least I am empowered to do something about it. Over time I learned to go to the repositories for bleeding edge if released tarballs were not enough. And using wine or VirtualBox to run Windows software I get the best of both worlds. > I mean, it's fine if > it uses cmake, but I don't want to have to learn cmake just to get it > to compile on my system. What alternative to cmake would you suggest? We need a build system and frankly, cmake is one of the most user friendly build systems out there, especially dealing with multi-platform. Also, very frankly, you don't have to learn cmake to get it to compile on most mainstream platforms, including Windows/MSVC. MinGW is just not a mainstream platform (yet). Nobody has been there in recent times. On mainstream platforms you don't need to know much about cmake, the documentation in the wiki is up to date and all you need is typographical skills. If you can't type, or if you don't want to type, there is not much that can help you. > I feel any work on new features is wasted, if > a new user fails to get it to run at all because the out-of-the-box > configuration does just not work. If this is what itches you, go ahead. Scratch your own itch and try to make it work out-of-the-box. Many have tried before you. Maybe you'll find the silver bullet. Maybe you'll find that the itch is gone before you've achieved the perfect solution you envision. Maybe you'll find that the perfect solution you envision is not practicable. You have every right to feel that your time is wasted. Obviously users who contribute new features don't feel the same way. What has purpose for them may not have purpose for you, and the other way around. The key to survival here is to accept that this is a personal preference and not an absolute choice. > And, yes, I'm using it on Windows. Nothing wrong with that. Please understand that not everybody uses Windows. Users who do not use Windows are not aware of the Windows-specific issues, nor can they be expected to solve Windows-specific problems. The project has a policy of integrating code in the main repository only after it is known to build on all major platforms. This includes Windows and Mac. It is not perfect, but given the resources available to the project *over time*, this is what can be done. Sorry if you feel it is not enough. For example, most of the work on the Mac has been done by Harry in the past three years. Imagine for a moment that Harry stops doing such work (it almost happened when his Mac died). What should the project do? stop moving forward on all other major platforms just because we can't test for the Mac? The definition of 'major platforms' is given by the resources available to the project, i.e. the platforms on which the skills and time are contributed. Not by the market share of those platforms. It changes over time as contributors come and go. > And so are a lot of other people, I reckon. Not because I like that > OS, but because you get more software running on Windows than on any > other platform (correct me if I'm wrong). I don't expect anybody to adopt any other platform than the one they are comfortable with. Personal choice. Symmetrically, I don't think users are justified in expecting contributors to adopt a specific platform / give it preferred treatment based on popularity or any other criteria. Personally I find quality more important than quantity. I can run the Windows sofware I need in Linux with wine - this is how I use Photoshop. I could not care less for the number of available software titiles, even less so when they come with a price tag that makes it prohibitively expensive to buy them all. > When I read the (probably > outdated) tutorial on how to compile libpano12 on windows, Why outdated? Maybe because nobody uses it? Or because those who do use it did not think it worth their time to update it as Hugin moved on? If you hit the 'history' link on the tutorial to compile Hugin and related tools for Ubuntu [5], you'll see that it has evolved over time as new dependencies were added. > From whatever angle I approach hugin, it's an uphill struggle. While I agree with you that it has a steep learning curve (it has become much less steep in the past four years), whether you see it negatively or positively all depends on your attitude. > And I > really want to like it and use it and recommend it, because I'm all > for free software, and because I know there is a really good program > inside hugin that is struggling to come out! Maybe it is because I've grown accustomed to its quirk (see the recent report about overwriting files), but in my eyes it is already a good program. Sure it can be improved, and I have witnessed a lot of improvements over time, but I do love it, I do use it, I do recommend it. Not because it is Free (as in speech) software, nor because it is free (as in beer), but because I get things done with it. > Okay, so now I've had my good rant. I apologize if I have been injust; if you've read so far, it is my time to apologize for the long, read-time- consuming write up. I don't think you've been injust. I do see your perspective and understand where some of the criticism you express comes from. You have shown that you are trying hard to make Hugin work for you. The minGW build is something for which you can be very proud of yourself! I hope that my long write up has been equally good at showing you where the current state of Hugin comes from; and I hope to see you elevating minGW to the status of major platform soon. Yuv [0] http://packages.ubuntu.com/hardy/hugin [1] http://packages.ubuntu.com/lucid/hugin [2] http://packages.ubuntu.com/maverick/hugin [3] http://wiki.panotools.org/Development_of_Open_Source_tools [4] http://panospace.wordpress.com/2010/04/08/update-that-dcraw-in-ubuntu- please/ [5] http://wiki.panotools.org/wiki/index.php?title=Hugin_Compiling_Ubuntu&action=history
signature.asc
Description: This is a digitally signed message part.
