Preamble.
I find that sometimes when I launch Optimise for the first time on a
new project it will run for a very long time. I think this has only
started being a problem in the last year or so ... sorry I can't be
more specific as to which version it started happening.
Usually I interrupt it and check control points by "human" removing
the outliers and then start it again. However I assume that until
Optimise has run for the first time the distance figures are not so
helpful for finding those outliers.
Sometimes if I am not in a rush I get on with other work and leave
Hugin/Optimise running in the background. If it is the last job of
the day I will leave it running overnight and it will usually have
finished by breakfast time.
Current Project
Last weekend I left an optimise session running and so far it has
clocked up more than 70 hours of processor time. Most of the time it
is keeping one core 100% busy. Hugin is ocupying 500Mb of RAM and 1Gb
of Virtual Memory.
The running-commentary pop-up tells me that Optimise is on Strategy 2
and has completed 18 iterations. I THINK it takes longer for one
iteration the longer it runs ... but that is just an impression I have
not been systematic in recording its progress.
The image set is 8 stacks of 3x bracked-exposures each image is a 70Mb
16-bit TIF.
I am using Harry's recent build for the Mac (2011.5.0.5723) on a Mac
Pro with a 2.8 Ghz Quad Core Xeon processor with 12Gb of RAM. So I
don't think the problem is that it is short of processing power.
Questions, Conclusions, Suggestions
a) do other people notice this? Is it only on 16-bit TIFF files? Is
it only on MacOS-X?
b) would it be possible for Optimise to make some sort of check either
initially or between iterations, perhaps something like:
- if this is the first time it has been run on this project and there
are extreme outliers amongst the control points stop after two or
three iterations and suggest that the user removes the outlying
control points.
OR
- At the end of an iteration if a control point distance is more than
X (more than x% away from the average?) and hasn't changed more than y
% in that iteration then start to ignore it
c) As well as a "Cancel" button could the Optimise running-commentary
pop-up offer an option "Stop after current Iteration" which would tidy
up the processing and update the control point distances at the end of
the current iteration rather than abandon the work done so far ...
which is what I assume happens with "Cancel"
On 25 Jan., 12:58, George R <george...@gmail.com> wrote:
> Preamble.
> I find that sometimes when I launch Optimise for the first time on a
> new project it will run for a very long time.
I had a case recently when I optimized a bunch of panoramas with
autooptimiser. I went for a walk and anticipated coming home to an
optimzed batch, but the process hung on one pano and had made it to
700 (!) iterations. I killed the process so the rest could have a go.
Mind you this was the only time something like that happened, and I
promptly proposed a sanity check for the optimizer:
... as you see noone bothered replying to my proposal, so your chances
probably aren't very good :(
> ...
> The image set is 8 stacks of 3x bracked-exposures each image is a 70Mb
> 16-bit TIF.
> a) do other people notice this? Is it only on 16-bit TIFF files? Is
> it only on MacOS-X?
Apart from the 700-iterations mishap, I do projects like this (8-9
stacks of 16bit TIFFS 70MB each) quite regularly on my Thinkpad (32bit
intel core 2 duo with 3GB RAM, so it's an old box - running Kubuntu
11.4) and never noticed anything undue.
> b) would it be possible for Optimise to make some sort of check either
> initially or between iterations, perhaps something like:
> ...
On my machine, with all versions I can remember, when running
optimization jobs from hugin, if I stop the optimizer by clicking
'cancel', the result of the last iteration of the optimizer is
nevertheless kept and applied, rather than cancelling the run and
leaving everything as it was before. Is that different on the Mac
version?
> - At the end of an iteration if a control point distance is more than
> X (more than x% away from the average?) and hasn't changed more than y
> % in that iteration then start to ignore it
the optimizer algorithm does something similar to that. If it didn't
form a notion of which CPs are outliers, it could never arrive at a
plausible result.
> a) do other people notice this? Is it only on 16-bit TIFF files? Is > it only on MacOS-X?
I have experienced this behaviour under linux, too. However, all panos affected by this had one (ore more) serious flaws that lead to obviously wrong control points. I seem to remember that all hand held shot multi exposure HDR panoramas using stacks that I forgot to unlink have been affected. As I did not see much coverage of this issue on this mailing list, I have taken that as a hint to invest more time in my shooting techniques and to never forget to use unlinked stacks only if shooting hand held 8) .
> b) would it be possible for Optimise to make some sort of check either > initially or between iterations, perhaps something like:
There already is some termination condition in the algorithm, I think. However, my very bad panoramas did not trigger it in due time, so I had to cancel the optimization manually.
However, I strongly support the notion to add another termination condition for pathological cases based upon number of iterations or time spent in the operation in relation to the number of pictures involved. If this time out value was user controllable, it even could be adapted to the skill of the photographer or the complexity of the scene.
> c) As well as a "Cancel" button could the Optimise running-commentary > pop-up offer an option "Stop after current Iteration" which would tidy > up the processing and update the control point distances at the end of > the current iteration rather than abandon the work done so far ... > which is what I assume happens with "Cancel"
I may be wrong, but I seem to remember that cancelling the optimizer run did let you continue with the results achieved thus far.
Regards
Stefan Peter
-- "In summary, I think you are trying to solve a problem that may not need to be solved, using a tool that is not meant to solve it, without understanding what is causing your problems and without knowing how the tool actually works in the first place :)" Jeffrey J. Kosowsky on the backuppc mailing list
I have left it running in the background ... it is now passing 146
hours and is now on its twentieth iteration.
On Jan 25, 7:35 pm, Stefan Peter <s_pe...@swissonline.ch> wrote:
> Hi George
> On 01/25/2012 12:58 PM, George R wrote:
> > Questions, Conclusions, Suggestions
> > a) do other people notice this? Is it only on 16-bit TIFF files? Is
> > it only on MacOS-X?
> I have experienced this behaviour under linux, too. However, all panos
> affected by this had one (ore more) serious flaws that lead to obviously
> wrong control points. I seem to remember that all hand held shot multi
> exposure HDR panoramas using stacks that I forgot to unlink have been
> affected.
This current panorama does include some handheld ground shots that I
have left linked - so perhaps that is the source of the problem.
> > c) As well as a "Cancel" button could the Optimise running-
commentary
> > pop-up offer an option "Stop after current Iteration" which would tidy
> > up the processing and update the control point distances at the end of
> > the current iteration rather than abandon the work done so far ...
> > which is what I assume happens with "Cancel"
> I may be wrong, but I seem to remember that cancelling the optimizer run
> did let you continue with the results achieved thus far.
It is good to hear from both of you that the Cancel button is already
intended to do what I was asking for.
However I have discovered a real problem ... at least on Mac OS X
implementation, the Cancel button does not work. The whole "running
Commentary" dialogue box remains unresponsive and is only updated at
the end of each iteration. I can't tell whether it is responsive when
being updated as I haven't managed to be around at any of those
moments.
So I have realised that usually when I interrupt Optimise I do so by
killing the process and that is why I lose the intermediate work.
> I have left it running in the background ... it is now passing 146 > hours and is now on its twentieth iteration.
> On Jan 25, 7:35 pm, Stefan Peter <s_pe...@swissonline.ch> wrote: > > Hi George
> > On 01/25/2012 12:58 PM, George R wrote: > > > Questions, Conclusions, Suggestions
> > > a) do other people notice this? Is it only on 16-bit TIFF files? Is > > > it only on MacOS-X?
> > I have experienced this behaviour under linux, too. However, all panos > > affected by this had one (ore more) serious flaws that lead to obviously > > wrong control points. I seem to remember that all hand held shot multi > > exposure HDR panoramas using stacks that I forgot to unlink have been > > affected.
> This current panorama does include some handheld ground shots that I > have left linked - so perhaps that is the source of the problem.
> > > c) As well as a "Cancel" button could the Optimise running- > commentary > > > pop-up offer an option "Stop after current Iteration" which would tidy > > > up the processing and update the control point distances at the end of > > > the current iteration rather than abandon the work done so far ... > > > which is what I assume happens with "Cancel"
> > I may be wrong, but I seem to remember that cancelling the optimizer run > > did let you continue with the results achieved thus far.
> It is good to hear from both of you that the Cancel button is already > intended to do what I was asking for.
> However I have discovered a real problem ... at least on Mac OS X > implementation, the Cancel button does not work. The whole "running > Commentary" dialogue box remains unresponsive and is only updated at > the end of each iteration. I can't tell whether it is responsive when > being updated as I haven't managed to be around at any of those > moments.
> So I have realised that usually when I interrupt Optimise I do so by > killing the process and that is why I lose the intermediate work.
I suggest that in a future version this button should display a more exact title, such as "Stop" or even "Stop now", because Cancel means "Do as if nothing had happened".
-- Frederic Da Vitoria (davitof)
Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org
> It is good to hear from both of you that the Cancel button is already > intended to do what I was asking for.
> However I have discovered a real problem ... at least on Mac OS X > implementation, the Cancel button does not work. The whole "running > Commentary" dialogue box remains unresponsive and is only updated at > the end of each iteration. I can't tell whether it is responsive when > being updated as I haven't managed to be around at any of those > moments.
Confirmed. The button is only responsive after each iteration. Then it does work. However, the longer an iteration takes the more unresposive it seems and the more difficult it gets to hit it at the right moment.
> > It is good to hear from both of you that the Cancel button is already
> > intended to do what I was asking for.
> > However I have discovered a real problem ... at least on Mac OS X
> > implementation, the Cancel button does not work. The whole "running
> > Commentary" dialogue box remains unresponsive and is only updated at
> > the end of each iteration. I can't tell whether it is responsive when
> > being updated as I haven't managed to be around at any of those
> > moments.
> Confirmed. The button is only responsive after each iteration. Then it does
> work. However, the longer an iteration takes the more unresposive it seems
> and the more difficult it gets to hit it at the right moment.
