Re: [hugin-ptx] Help First Time User - Won't stich/Batch Processor not working

1,174 views
Skip to first unread message

Frederic Da Vitoria

unread,
Nov 18, 2012, 6:51:12 AM11/18/12
to hugin-ptx

2012/11/18 hugin learner <bronw...@gmail.com>

Hi, i was wondering if someone could help out.

I am new to hugin and using the 2012.0.0 version which just downloaded recently. I find photos, create points, align and create reasonable images then go to stitch it using the stitch! button on the sticher tab and it creates pto file and asks me to save output image and then does absolutely nothing. Read some of the other forums on this topic and I think my problem is that the batch processor does not work. As it opens in my toolbar for 10sec then just disappears. I can't open it from the hugin file either nor the windows file programs and when i go to the appdata folder there is a crash dumper folder created there with all the failed attempts to run the batch processor. I have unistalled, reinstalled several times to no avail either. Could someone provide me with any information on how to do this. Am trying to create a panorama for a present so trying to get it done quickly!

Any assistance would be greatly appreciated!

thanks


Hello,

I never use the batch processor, because I started to use Hugin before it was introduced and also probably because it is not really useful for the kind of panoramas I do (usually less than a dozen of source images). I suggest, until someone helps you find out how to solve the batch processor issue, that you go to Preferences, Stitching tab and switch the processor to Hugin_stitch_project. Hugin will do the stitching himself so you will avoid the problem.

HTH

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

Mistral2099

unread,
Nov 4, 2013, 9:00:12 AM11/4/13
to hugi...@googlegroups.com
Thanks Fredric -- have been struggling with this same problem for months and no joy. Your suggestion solved it for me. <<go to Preferences, Stitching tab and switch the processor to Hugin_stitch_project.<<

Very much appreciated!

Frederic Da Vitoria

unread,
Nov 4, 2013, 9:19:15 AM11/4/13
to hugin-ptx
2013/11/4 Mistral2099 <primal...@gmail.com>
Thanks Fredric -- have been struggling with this same problem for months and no joy. Your suggestion solved it for me. <<go to Preferences, Stitching tab and switch the processor to Hugin_stitch_project.<<

Very much appreciated!

You are welcome.

On Sunday, November 18, 2012 7:51:32 PM UTC+8, Frederic Da Vitoria wrote:

2012/11/18 hugin learner <bronw...@gmail.com>

Hi, i was wondering if someone could help out.

I am new to hugin and using the 2012.0.0 version which just downloaded recently. I find photos, create points, align and create reasonable images then go to stitch it using the stitch! button on the sticher tab and it creates pto file and asks me to save output image and then does absolutely nothing. Read some of the other forums on this topic and I think my problem is that the batch processor does not work. As it opens in my toolbar for 10sec then just disappears. I can't open it from the hugin file either nor the windows file programs and when i go to the appdata folder there is a crash dumper folder created there with all the failed attempts to run the batch processor. I have unistalled, reinstalled several times to no avail either. Could someone provide me with any information on how to do this. Am trying to create a panorama for a present so trying to get it done quickly!

Any assistance would be greatly appreciated!

thanks

Hello,

I never use the batch processor, because I started to use Hugin before it was introduced and also probably because it is not really useful for the kind of panoramas I do (usually less than a dozen of source images). I suggest, until someone helps you find out how to solve the batch processor issue, that you go to Preferences, Stitching tab and switch the processor to Hugin_stitch_project. Hugin will do the stitching himself so you will avoid the problem.

I have been wondering: why not use Hugin_stitch_project as default? How often do Hugin users really need to batch assemble several panoramas at the same time or shut off their computer when the panorama is finished assembling?

T. Modes

unread,
Nov 4, 2013, 11:05:25 AM11/4/13
to hugi...@googlegroups.com
Hi Frederic,


Am Montag, 4. November 2013 15:19:15 UTC+1 schrieb Frederic Da Vitoria:
I have been wondering: why not use Hugin_stitch_project as default? How often do Hugin users really need to batch assemble several panoramas at the same time or shut off their computer when the panorama is finished assembling?

That is a disagreement inside itself. How should the issues fixed, if nobody tests it and help so to improve it.

You have often advised new users to use hugin_stitch_project instead. That is not helpful at all. This should be the last step, if all other solutions don't work.
I advised the users some steps to try to solve the issue (because I think in most cases it is a  special configuration or the issue is behind the keyboard.)
But with your advise to use hugin_stitch_project there was never a substantial feedback to improve the behaviour of PTBatcherGUI.

You never used PTBatcherGUI and have therefore not contributed active to its improvement as you always demand.

Thomas

PS: If you reduce PTBatcherGUI to a batch stitcher you have not leashed its full power. It contains a lot more functions.

Frederic Da Vitoria

unread,
Nov 5, 2013, 4:41:19 AM11/5/13
to hugin-ptx
2013/11/4 T. Modes <Thomas...@gmx.de>

Hi Frederic,

Am Montag, 4. November 2013 15:19:15 UTC+1 schrieb Frederic Da Vitoria:
I have been wondering: why not use Hugin_stitch_project as default? How often do Hugin users really need to batch assemble several panoramas at the same time or shut off their computer when the panorama is finished assembling?

That is a disagreement inside itself. How should the issues fixed, if nobody tests it and help so to improve it.

You have often advised new users to use hugin_stitch_project instead. That is not helpful at all. This should be the last step, if all other solutions don't work.
I advised the users some steps to try to solve the issue (because I think in most cases it is a  special configuration or the issue is behind the keyboard.)
But with your advise to use hugin_stitch_project there was never a substantial feedback to improve the behaviour of PTBatcherGUI.

OK, I'll refrain from advising this from now on. But you realize that similar problems have been going on for several months (more than a year?), that it generates frustrated Windows users (I have a hunch this is a Windows-specific issue) and that in the Windows world, the general user behavior is: "if the software doesn't work, then use another one"? Windows users who know what a bug tracker is (I am not even saying "who know how to use a bug tracker") are few. So that letting users get hit by PTBatcherGUI problems might achieve getting less Hugin users instead of solving the PTBatcherGUI issue.

 
You never used PTBatcherGUI and have therefore not contributed active to its improvement as you always demand.

Thomas

PS: If you reduce PTBatcherGUI to a batch stitcher you have not leashed its full power. It contains a lot more functions.

You are right, I had never looked at all it could do. Checking the documentation... Sorry, I just checked, it still does not contain any option I would use. And I don't expect this to change because:
- I never do panoramas with more than a dozen pictures (usual number is 3 - 4), so that the assembly time is usually much lower than my patience, and I don't have the time to start a new panorama during the batch phase,
- I do many panoramas in mosaic mode, often also "time lapse", and a little exposure or focus blending, while PTBatcherGUI seems to make most sense if you use the assistant,
- I always shoot hand held (I don't even own a tripod) so that automatic assembling is often hopeless, while post-processing individual images generated with Hugin allows me to get acceptable results. I don't expect any software, even one which I would have paid big sums of money for, to be smart enough to make something usable out images with parallax errors. I know, I should change my methods, but I don't even want to buy a SLR because of the weight, so a tripod is completely out of my scope.

I understand that other users can find PTBatcher useful. But this is simply currently not true for me. All that PTBatcher would do for me is add an unnecessary and useless step, with all the risks of something going wrong and the added complexity of finding if that problem would come from Hugin or from PTBatcherGUI.

If it helps you to find what is going on, I can do a test, though. I can even file a bug, provided I can reproduce the issue, of course.

T. Modes

unread,
Nov 5, 2013, 11:36:10 AM11/5/13
to hugi...@googlegroups.com
Hi Frederic,


Am Dienstag, 5. November 2013 10:41:19 UTC+1 schrieb Frederic Da Vitoria:
OK, I'll refrain from advising this from now on. But you realize that similar problems have been going on for several months (more than a year?), that it generates frustrated Windows users (I have a hunch this is a Windows-specific issue) and that in the Windows world, the general user behavior is: "if the software doesn't work, then use another one"? Windows users who know what a bug tracker is (I am not even saying "who know how to use a bug tracker") are few. So that letting users get hit by PTBatcherGUI problems might achieve getting less Hugin users instead of solving the PTBatcherGUI issue.

It would be nice if all would always works.
There is always a conflict between adding new features (with maybe new bugs) and rock-solid stability. If you prefer always rock-solid stability, we can not add new features, because we have not the man power to test them before release to this extent.
So in the scope of our little project with hobby people we need the feedback from the user (with a wide variety of systems and wide variety of use case, not to mention the big variety of image format..) to fix the issues and make it more stable. So features can become more stable with time - but only when they get tested and issues reported and fixed.

Big software team can do that testing more extensive before release - but they have the man power, time and money.

But here it often goes:
1.) Does not work!
2.) Try to identify the culprit and give ideas to try.

And then it ends. No feedback, no this solved it or so. So we can not fix the issue or make it more robust, because we don't know what goes wrong in specific conditions.

To use an overstressed comparison: When you car does not work correctly, do you then go to the garage and say simply  "The car does not work correctly."? Yes, then you have a very fine garage. But I think in most case they ask you, what exactly does not work and try to isolate the failure.

But here it gets expected that all should work in all user cases on all machines around the world with all different images, and this in the first run.

Thomas

Thomas

Frederic Da Vitoria

unread,
Nov 5, 2013, 12:14:47 PM11/5/13
to hugin-ptx
2013/11/5 T. Modes <Thomas...@gmx.de>

I understand this; I am a software developer myself. I also agree with the open source way of things, I am not saying the average Windows user is right. But I also know the mentality of the average Windows user. After all, Microsoft does not precisely sell Windows as a collaborative OS where each user can help improving it's features :-) So it should be no surprise that Windows users are this way statistically.

David W. Jones

unread,
Nov 6, 2013, 4:56:56 AM11/6/13
to hugi...@googlegroups.com
On 11/04/2013 11:41 PM, Frederic Da Vitoria wrote:
> 2013/11/4 T. Modes <Thomas...@gmx.de <mailto:Thomas...@gmx.de>>
Well, I shoot handheld, with a DSLR, without tripod, with anywhere from
4-12 frames, and never use the assistant. PTBatcherGui works just fine
for me. I know it has other functions than just queueing jobs, but it
doesn't cause any problems.

I've also rendered strips of as many as 72 frames, where things worked
just fine with PTBatcherGui. Those were also handheld shots (well, sort
of - the camera was resting on the rail of a ferry as it chugged the
last 10 miles or so into the harbor at Victoria, British Columbia).

> I understand that other users can find PTBatcher useful. But this is
> simply currently not true for me. All that PTBatcher would do for me is
> add an unnecessary and useless step, with all the risks of something
> going wrong and the added complexity of finding if that problem would
> come from Hugin or from PTBatcherGUI.

I don't think PTBatcherGUI causes any problems. At least not on Linux.
Windows, on the other hand, is enough of a problem all by itself, in my
opinion ... ;-)

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

David Du

unread,
Apr 18, 2014, 10:57:27 AM4/18/14
to hugi...@googlegroups.com
THANKS DUDE!!!!!!!!! I was having the same problem and you really helped me out!!! Thanks :) I had struggle with this for several months and couldnt find a solution. But thanks to you I can now use my hugin properly again. thanks again <3<3<3

Andrew Stanner

unread,
Aug 6, 2014, 6:54:36 PM8/6/14
to hugi...@googlegroups.com
I found that deleting the file C:\Users\[username]\AppData\Roaming\.ptbt0  and/or .ptbt1 got it working again.

Gavin Golden

unread,
Oct 7, 2014, 3:44:09 AM10/7/14
to hugi...@googlegroups.com
Thanks, that fixed it.

James Wheeler

unread,
Feb 8, 2015, 7:59:38 PM2/8/15
to hugi...@googlegroups.com
Holding the CTRL key down while opening the batch processor from the Windows Programs menu is another way to reset the queue - that also works for me.
Reply all
Reply to author
Forward
0 new messages