first attempt at a spherical pano

[Michael Havens]

or at least of a dome pano (half sphere).

I got 34 images and when I first load the images everything seems cool but when I click align I get an error <below>. Then I click continue and it says that none of my images have control points and that I need to put them in manually. Any ideas as to what's wrong?

ASSERT INFO:

/usr/include/wx-3.0/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

BACKTRACE:

[1] MainFrame::RunAssistant(wxWindow*)

[2] GLPreviewFrame::OnAlign(wxCommandEvent&)

[3] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const

[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)

[5] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)

[6] wxEvtHandler::TryHereOnly(wxEvent&)

[7] wxEvtHandler::ProcessEventLocally(wxEvent&)

[8] wxEvtHandler::ProcessEvent(wxEvent&)

[9] wxWindowBase::TryAfter(wxEvent&)

[10] wxWindowBase::TryAfter(wxEvent&)

[11] wxWindowBase::TryAfter(wxEvent&)

[12] wxWindowBase::TryAfter(wxEvent&)

[13] wxEvtHandler::SafelyProcessEvent(wxEvent&)

[14] g_signal_emit_valist

[15] g_signal_emit

[16] g_signal_emit_valist

[17] g_signal_emit

[18] g_closure_invoke

[19] g_signal_emit_valist

[20] g_signal_emit

[21] gtk_propagate_event

[22] gtk_main_do_event

[23] g_main_context_dispatch

[24] g_main_loop_run

[25] gtk_main

[26] wxGUIEventLoop::DoRun()

[27] wxEventLoopBase::Run()

[28] wxAppConsoleBase::MainLoop()

[29] wxEntry(int&, wchar_t**)

[30] main

[31] __libc_start_main

[32] _start

[Greg 'groggy' Lehey]

On Thursday, 15 September 2016 at 19:28:54 -0700, Michael Havens wrote:
>
> I got 34 images and when I first load the images everything seems
> cool but when I click align I get an error <below>. Then I click
> continue and it says that none of my images have control points and
> that I need to put them in manually. Any ideas as to what's wrong?

Not without seeing the images. Where are they? Did you take them at
constant exposure settings?

> ASSERT INFO:
> /usr/include/wx-3.0/wx/strvararg.h(451): assert "(argtype &
> (wxFormatStringSpecifier<T>::value)) == argtype" failed in
> wxArgNormalizer(): format specifier doesn't match argument type

Which version of Hugin is this? And what's the platform, and where
did you get the executable from?

If this is a 2016.* version, I'm not sure that this is serious. I
can't reproduce the message at will, but I've seen something similar
at this juncture. It gave me the option to continue, and when I did,
everything continued normally.

Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[Greg 'groggy' Lehey]

On Friday, 16 September 2016 at 12:46:25 +1000, Greg 'groggy' Lehey wrote:
> On Thursday, 15 September 2016 at 19:28:54 -0700, Michael Havens wrote:
>>
>
>> ASSERT INFO:
>> /usr/include/wx-3.0/wx/strvararg.h(451): assert "(argtype &
>> (wxFormatStringSpecifier<T>::value)) == argtype" failed in
>> wxArgNormalizer(): format specifier doesn't match argument type

I have been able to reproduce this message, clearly with a subtly
different version of wx (see the line number):

/usr/local/include/wx-3.0/wx/strvararg.h(456): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

This appears to be the result of a number of issues:

1. You followed my advice and set the temporary directory path in
preferences/file names.
2. The "temporary directory path" is really a search path for
executables.
3. You missed the message "can't find control point detector".
4. The error message seems to have gone out of its way to be
unclear. Probably it's reporting an error that occurred as a
result.

Could you please try removing the entry for the temporary directory
and see if you still have trouble? As I said (thread "hugin shouldn't
stitch in root"):

On Thursday, 15 September 2016 at 13:41:36 +1000, Greg 'groggy' Lehey wrote:
> 2. How much space was used in /tmp or /var/tmp? None at all! I
> don't know where I got the idea that the intermediate files go to
> /tmp. So the question remains: what is getting written to the
> root file system in Michael's scenario? Michael, can you check
> next time you stitch a pano. The log window will tell you what is
> being written, and where. Maybe it's not /tmp at all.

[Michael Havens]

On Friday, September 16, 2016 at 3:42:08 AM UTC-4, Groogle wrote:

1.  You followed my advice and set the temporary directory path in
    preferences/file names.

Yes sir.... I did.

 

2.  The "temporary directory path" is really a search path for
    executables.

It is  ~/hugintmp 

 

3.  You missed the message "can't find control point detector".

What do I do with that message?

 

4.  The error message seems to have gone out of its way to be
    unclear.  Probably it's reporting an error that occurred as a
    result.

I guess....

 

Could you please try removing the entry for the temporary directory
and see if you still have trouble?  As I said (thread "hugin shouldn't
stitch in root"):

On Thursday, 15 September 2016 at 13:41:36 +1000, Greg 'groggy' Lehey wrote:
> 2.  How much space was used in /tmp or /var/tmp?  None at all!  I
>     don't know where I got the idea that the intermediate files go to
>     /tmp.  So the question remains: what is getting written to the
>     root file system in Michael's scenario?  Michael, can you check
>     next time you stitch a pano.  The log window will tell you what is
>     being written, and where.  Maybe it's not /tmp at

Huh? My issue now appears to be it isn't even looking for control points. It gives me the error right away <https://drive.google.com/open?id=0B2xvsVTZy4y1MzU1QUtKaDE3dFk>. It isn't even trying.

Another thing that may or may not be related is that when it is placing the photos  in the window with the "load images" button some of them are upside down.

[Michael Havens]

On Thursday, September 15, 2016 at 10:46:29 PM UTC-4, Groogle wrote:

Not without seeing the images.  Where are they?  Did you take them at
constant exposure settings?

https://drive.google.com/open?id=0B2xvsVTZy4y1NXBsN1VzV1B1R2s

 

Which version of Hugin is this?  And what's the platform, and where
did you get the executable from?

 

2016.2.0.48cb11a23351

 Platform- Linux 

 

[Greg 'groggy' Lehey]

On Friday, 16 September 2016 at 3:36:56 -0700, Michael Havens wrote:
> On Friday, September 16, 2016 at 3:42:08 AM UTC-4, Groogle wrote:
>>
>> 1. You followed my advice and set the temporary directory path in
>> preferences/file names.
>>
>
> Yes sir.... I did.

... I'll address this and the rest of your replies tomorrow. You've
missed the most important point, which I suspect will solve your
problems:

>> Could you please try removing the entry for the temporary directory
>> and see if you still have trouble? As I said (thread "hugin shouldn't

>> stitch in root"): ...

[Greg 'groggy' Lehey]

On Friday, 16 September 2016 at 3:36:56 -0700, Michael Havens wrote:

> On Friday, September 16, 2016 at 3:42:08 AM UTC-4, Groogle wrote:
>>
>> 1. You followed my advice and set the temporary directory path in
>> preferences/file names.
>
> Yes sir.... I did.

Unfortunately it was bad advice, leading you to a bug.

>> 2. The "temporary directory path" is really a search path for
>> executables.
>
> It is ~/hugintmp

That's not important. The issue is that specifying any temporary
directory invokes a bug whereby hugin doesn't pass the PATH
environment variable to icpfind. I didn't know this when I wrote (2)
above. But this means that icpfind can't find the control point
detector.

>> 3. You missed the message "can't find control point detector".
>
> What do I do with that message?

At the time, you could have reported it.

>> Could you please try removing the entry for the temporary directory
>> and see if you still have trouble? As I said (thread "hugin
>> shouldn't stitch in root"):
>>
>> On Thursday, 15 September 2016 at 13:41:36 +1000, Greg 'groggy' Lehey
>> wrote:
>>> 2. How much space was used in /tmp or /var/tmp? None at all! I
>>> don't know where I got the idea that the intermediate files go to
>>> /tmp. So the question remains: what is getting written to the
>>> root file system in Michael's scenario? Michael, can you check
>>> next time you stitch a pano. The log window will tell you what is
>>> being written, and where. Maybe it's not /tmp at
>
>
> Huh? My issue now appears to be it isn't even looking for control
> points.

Read what I wrote above. It can't.

> It gives me the error right away
> <https://drive.google.com/open?id=0B2xvsVTZy4y1MzU1QUtKaDE3dFk>.

Yes. If you can't find the control point detector, you can't run it,
and that happens immediately.

> It isn't even trying.

Would you please try? As I said:

>> Could you please try removing the entry for the temporary directory
>> and see if you still have trouble?

> Another thing that may or may not be related is that when it is
> placing the photos in the window with the "load images" button some
> of them are upside down.

No, this is in no way related. This is the way your camera is
reporting them. The control point detector, once you find it, should
fix that.

[Michael Havens]

Yipeee! (I guess) I found a bug..... oh joy! I am so glad I don't run out of disk space from stitching a couple of images together because I need to be able to stitc a few images together to simulate a wide angle lens. Did ypou take care of reporting the issue Or do you want me to do it?

[Greg 'groggy' Lehey]

On Friday, 16 September 2016 at 16:51:37 -0700, Michael Havens wrote:
> Yipeee! (I guess) I found a bug..... oh joy! I

Indeed. Most people aren't so happy when they run into bugs :-)

> am so glad I don't run out of disk space from stitching a couple of
> images together because I need to be able to stitc a few images
> together to simulate a wide angle lens.

You still haven't answered my question about the running out of disk
space. We haven't been able to reproduce that.

> Did ypou take care of reporting the issue Or do you want me to do
> it?

I'm still investigating exactly what happens, but then I will either
report it or submit a fix.

For the record: setting that variable (which ends up in ~/.hugin as
tmpDir=/var/tmp, for example) appears to cause hugin pass an empty
PATH environment variable to icpfind, which then fails. It's not the
problem of icpfind, which works fine if started directly. But I
haven't had time to track it down yet.

[Michael Havens]

On Friday, September 16, 2016 at 9:00:17 PM UTC-4, Groogle wrote:

You still haven't answered my question about the running out of disk
space.  We haven't been able to reproduce that.

 

Sorry.... I missed that question. Don't worry so much about that. It is unlikely you will be able to reproduce that error as my root directory isn't that big...

     $ df / -h

     Filesystem      Size  Used Avail Use% Mounted on

     /dev/sdb1        23G   15G  7.2G  67% /

7.2 G seems like a lot of free space to me right now but I guess it isn't when doing a photosphere!

[Michael Havens]

or :

/tmp $ df -h

Filesystem      Size  Used Avail Use% Mounted on

udev            3.8G  4.0K  3.8G   1% /dev

tmpfs           786M  1.5M  785M   1% /run

/dev/sdb1        23G   15G  7.4G  66% /

none            4.0K     0  4.0K   0% /sys/fs/cgroup

none            5.0M     0  5.0M   0% /run/lock

none            3.9G   34M  3.9G   1% /run/shm

none            100M   24K  100M   1% /run/user

/dev/sdb3       201G   45G  147G  24% /home

[Michael Havens]

or:

 $ df /tmp -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/sdb1        23G   15G  7.4G  66% /

[Greg 'groggy' Lehey]

On Saturday, 17 September 2016 at 10:54:06 -0700, Michael Havens wrote:
> or :
>
> /tmp $ df -h
> Filesystem Size Used Avail Use% Mounted on
> udev 3.8G 4.0K 3.8G 1% /dev
> tmpfs 786M 1.5M 785M 1% /run
> /dev/sdb1 23G 15G 7.4G 66% /
> none 4.0K 0 4.0K 0% /sys/fs/cgroup
> none 5.0M 0 5.0M 0% /run/lock
> none 3.9G 34M 3.9G 1% /run/shm
> none 100M 24K 100M 1% /run/user
> /dev/sdb3 201G 45G 147G 24% /home

On Saturday, 17 September 2016 at 14:36:23 -0700, Michael Havens wrote:
> or:
>
> $ df /tmp -h

> Filesystem Size Used Avail Use% Mounted on

> /dev/sdb1 23G 15G 7.4G 66% /

Sorry, I don't understand. What are you referring to? I was
expecting an answer on my question as to where the files were being
written, based on the logs.

[Michael Havens]

On Saturday, September 17, 2016 at 7:19:14 PM UTC-4, Groogle wrote:

  I was
expecting an answer on my question as to where the files were being
written, based on the logs.

I am so sorry but I can't answer that. I don't know where hugin stores the logs if their not in /var/log .

[Greg 'groggy' Lehey]

When you select "Create panorama" or "Stitch", you get asked for a
name of the resultant panorama. Then a log window pops up and shows
what's going on. When it's finished, it conveniently goes away. Take
a look at
http://www.lemis.com/grog/photos/Photos.php?dirdate=20160918&imagesizes=4
for an example. Here you'll see it writing to
/photowork/Hugin-build-eureka/ . My question is what pathnames you
find in your log window.

The documentation says that if you select "Copy log messages to
clipboard" in the Preferences/General tab, you will get log messages,
well, in the clipboard. That doesn't work for me, but it might for
you.

[David W. Jones]

On 09/17/2016 04:28 PM, Greg 'groggy' Lehey wrote:
> On Saturday, 17 September 2016 at 18:33:46 -0700, Michael Havens wrote:
>> On Saturday, September 17, 2016 at 7:19:14 PM UTC-4, Groogle wrote:
>>>
>>> I was expecting an answer on my question as to where the files were
>>> being written, based on the logs.
>>
>> I am so sorry but I can't answer that. I don't know where hugin
>> stores the logs if their not in /var/log .
>
> When you select "Create panorama" or "Stitch", you get asked for a
> name of the resultant panorama. Then a log window pops up and shows
> what's going on. When it's finished, it conveniently goes away. Take
> a look at
> http://www.lemis.com/grog/photos/Photos.php?dirdate=20160918&imagesizes=4
> for an example. Here you'll see it writing to
> /photowork/Hugin-build-eureka/ . My question is what pathnames you
> find in your log window.
>
> The documentation says that if you select "Copy log messages to
> clipboard" in the Preferences/General tab, you will get log messages,
> well, in the clipboard. That doesn't work for me, but it might for
> you.

I think that log window only appears if you select Verbose(?) in the
stitcher GUI.

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

[Greg 'groggy' Lehey]

Where's that? When I select the stitcher, I don't get that option.
It's also not in preferences. I thought it might be related to the
Interface (Simple/Advanced/Expert), but I get it in Simple mode as
well. Do you not see the window?

[Michael Havens]

Okay, I'm running the stitcher now even though no control points were found. 

I found the  "Copy log messages to 

clipboard" setting sand checked and I believe it will take a long time so I made a copy of what is in the 'stitching' window here: (let me know if I need to let the 'stitching' window finish.

============================================

Stitching panorama...

============================================

Platform: Linux 3.19.0-32-generic x86_64

Version: 2016.2.0.48cb11a23351

Working directory: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3

Output prefix: DSC_0493 - DSC_0526

Blender: enblend 4.1.3

Exposure fusion: enfuse 4.1.3

ExifTool version: 9.46

Number of active images: 34

Output exposure value: 13.7

Canvas size: 20360x10180

ROI: (0, 0) - (20360, 10180) 

FOV: 360x180

Projection: Equirectangular(2)

Using GPU for remapping: false

Panorama Outputs:

* Exposure corrected, low dynamic range

* Exposure fused from any arrangement

First input image

Number: 0

Filename: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0493.JPG

Size: 6016x4000

Projection: Normal (rectilinear)

Response type: custom (EMoR)

HFOV: 66

Exposure value: 13.7

Remapping LDR images...

Multiple images output

loading DSC_0493.JPG

remapping DSC_0493.JPG

[Michael Havens]

here is what is in my clipboard:

 "      "
..... hmmmmmmm....  nothing new was saved to the clipboard!

[Stefan Peter]

Dear Michael Havens

On 20.09.2016 13:32, Michael Havens wrote:
> Okay, I'm running the stitcher now even though no control points were
> found.

Then it is of no use. The task at hand is to find out why there are no
control points produced.

Greg assumed that it has something to do with the temporary directory
path setting. The prudent thing to test this hypothesis would be to
revert this setting and see if the problem persists.

However, I was not able to recreate this problem here. Not even using a
non existent directory as temporary file location interfered with
creating control points.

However, there are other possible reasons for this behaviour. One of
them would be that the files can not be read by icpfind, the program
responsible for creating the control points. Or maybe icpfind could not
be started because of other reasons like missing libraries or execution
permission.

In any case, please re-run the "Create control points" action and then,
send us the resulting log file from you clipboard as you did with this one.

With kind regards

Stefan Peter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
(See https://en.wikipedia.org/wiki/Posting_style for details)

[Michael Havens]

On Wednesday, September 21, 2016 at 3:02:05 PM UTC-4, Stefan Peter wrote:

In any case, please re-run the "Create control points" action and then,
send us the resulting log file from you clipboard as you did with this one.

 

Here is what the clipboard says now:

 

     Searching for control points...

     Could not find "cpfind" in path.

     Maybe you have not installed it properly or given a wrong path in the settings.

 

Perhaps I should use another control point detector.

My take on this problem is that it is associated with the setting that tells it where it's tmp directory is because it works fine when I don't put anything in that field...... I just can't do a massive panorama because I don't have enough space in /tmp for all the temporary files that a huge panorama produces.

[Michael Havens]

On Wednesday, September 21, 2016 at 8:45:29 PM UTC-4, Michael Havens wrote:

Perhaps I should use another control point detector.

That didn't help any! 

[Terry Duell]

If I understand this correctly, perhaps a workaround is to leave the tmp
dir field blank, generate your control points, then save your .pto.
Restart hugin, add your tmp dir, open your saved .pto and continue on.


Cheers,
--
Regards,
Terry Duell

[Greg 'groggy' Lehey]

On Wednesday, 21 September 2016 at 17:45:29 -0700, Michael Havens wrote:
>
>
> On Wednesday, September 21, 2016 at 3:02:05 PM UTC-4, Stefan Peter wrote:
>>
>> In any case, please re-run the "Create control points" action and then,
>> send us the resulting log file from you clipboard as you did with this
>> one.
>
> Here is what the clipboard says now:
>
> Searching for control points...
> Could not find "cpfind" in path.
> Maybe you have not installed it properly or given a wrong path in the
> settings.
>
> Perhaps I should use another control point detector.

*sigh* I've been through this in some detail. This is the bug we
discussed some time ago. Please don't set your temporary directory.
Go to Preferences/Filenames and make sure that "Temporary Dir" is
empty. If you still get the "Could not find "cpfind" in path."
message, please confirm that you have reset this field and post your
~/.hugin file.

> I just can't do a massive panorama because I don't have enough space
> in /tmp for all the temporary files that a huge panorama produces.

And what files are you writing to /tmp? Nobody else sees any written
there. You have confirmed that the logs don't get copied to the
clipboard, but you can still watch the window. If that's too much
difficulty, try repeating this in a shell window while stitching is in
progress:

$ ls -lrt /tmp

That should list any newly created temporary files.

[Greg 'groggy' Lehey]

Good idea, but so far we have no evidence that anything is being
written to /tmp or wherever. That's what I've been trying to find out
for the last week.

[Greg 'groggy' Lehey]

On Wednesday, 21 September 2016 at 21:00:56 +0200, Stefan Peter wrote:
> On 20.09.2016 13:32, Michael Havens wrote:
>> Okay, I'm running the stitcher now even though no control points were
>> found.
>
> Then it is of no use. The task at hand is to find out why there are no
> control points produced.
>
> Greg assumed that it has something to do with the temporary directory
> path setting.

It's more than an assumption. In my installation it's a certainty.

> The prudent thing to test this hypothesis would be to revert this
> setting and see if the problem persists.

Yes, this is what I have repeatedly asked for.

> However, I was not able to recreate this problem here. Not even
> using a non existent directory as temporary file location interfered
> with creating control points.

OK, that's interesting. I thought it once worked for me too. What
platform and version of Hugin?

> However, there are other possible reasons for this behaviour. One of
> them would be that the files can not be read by icpfind, the program
> responsible for creating the control points. Or maybe icpfind could
> not be started because of other reasons like missing libraries or
> execution permission.

I modified icpfind to find what it was looking for. It had an empty
PATH variable, so it couldn't find the control point detector. And
yes, I'm still planning to track the bug down.

[Michael Havens]

I don't know where the intermediate files are saved.... whether it is /tmp or elsewhere. When I was working on this issue 6 months ago someone said it was /tmp so I just went with that.

Tduell's suggestion worked. It is now stitching.

[Michael Havens]

I don't know where the intermediate files are saved.... whether it is /tmp or elsewhere. When I was working on this issue 6 months ago someone said it was /tmp so I just went with that.

Tduell's suggestion worked. It is now stitching.

On Wednesday, September 21, 2016 at 9:43:00 PM UTC-4, Groogle wrote:

[Greg 'groggy' Lehey]

[sequence recovered]

On Wednesday, 21 September 2016 at 19:09:15 -0700, Michael Havens wrote:
> On Wednesday, September 21, 2016 at 9:43:00 PM UTC-4, Groogle wrote:
>>
>> Good idea, but so far we have no evidence that anything is being
>> written to /tmp or wherever. That's what I've been trying to find out
>> for the last week.
>

> I don't know where the intermediate files are saved.... whether it
> is /tmp or elsewhere.

That's why I asked you to look, and told you how.

> Tduell's suggestion worked. It is now stitching.

Where? Take a look in your specified directory and see what's in
there.

[Michael Havens]

In preferences->file name->Temporary directory I typed in "/home/bmike1/hugintmp"

In the same location if /home/bmike1/hugintmp is present when I search for control points it will fail.

On Thursday, September 15, 2016 at 10:28:54 PM UTC-4, Michael Havens wrote:

or at least of a dome pano (half sphere).

I got 34 images and when I first load the images everything seems cool but when I click align I get an error <below>. Then I click continue and it says that none of my images have control points and that I need to put them in manually. Any ideas as to what's wrong?

ASSERT INFO:

/usr/include/wx-3.0/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

BACKTRACE:

[1] MainFrame::RunAssistant(wxWindow*)

[2] GLPreviewFrame::OnAlign(wxCommandEvent&)

[3] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const

[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)

[5] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)

[6] wxEvtHandler::TryHereOnly(wxEvent&)

[7] wxEvtHandler::ProcessEventLocally(wxEvent&)

[8] wxEvtHandler::ProcessEvent(wxEvent&)

[9] wxWindowBase::TryAfter(wxEvent&)

[10] wxWindowBase::TryAfter(wxEvent&)

[11] wxWindowBase::TryAfter(wxEvent&)

[12] wxWindowBase::TryAfter(wxEvent&)

[13] wxEvtHandler::SafelyProcessEvent(wxEvent&)

[14] g_signal_emit_valist

[15] g_signal_emit

[16] g_signal_emit_valist

[17] g_signal_emit

[18] g_closure_invoke

[19] g_signal_emit_valist

[20] g_signal_emit

[21] gtk_propagate_event

[22] gtk_main_do_event

[23] g_main_context_dispatch

[24] g_main_loop_run

[25] gtk_main

[26] wxGUIEventLoop::DoRun()

[27] wxEventLoopBase::Run()

[28] wxAppConsoleBase::MainLoop()

[29] wxEntry(int&, wchar_t**)

[30] main

[31] __libc_start_main

[32] _start

[Michael Havens]

On Wednesday, September 21, 2016 at 10:22:48 PM UTC-4, Groogle wrote:

> Tduell's suggestion worked. It is now stitching.

Where?  Take a look in your specified directory and see what's in
there.

[Greg 'groggy' Lehey]

On Wednesday, 21 September 2016 at 19:33:27 -0700, Michael Havens wrote:
> In preferences->file name->Temporary directory I typed in
> "/home/bmike1/hugintmp"
> In the same location if /home/bmike1/hugintmp is present when I search for
> control points it will fail.

We seem to be going round in circles. I reported this issue nearly a
week ago. What does it write to the root file system when you don't
specify a temporary directory?

[Michael Havens]

I didn't do your ls command because it is stitching in the hugintmp directory right now.

~/hugintmp $ ls /home/bmike1/hugintmp

hec1QPQW  heFan8Hr  heL3W456  huginpto_0vYcMe  huginpto_95itzG  huginpto_UEq4Vb

hee6TKlX  hehyqyzB  heMNMrcf  huginpto_2c8gZv  huginpto_HYTJTG  huginpto_ZuLc6q

[Greg 'groggy' Lehey]

On Wednesday, 21 September 2016 at 19:39:13 -0700, Michael Havens wrote:
> I didn't do your ls command because it is stitching in the hugintmp
> directory right now.
>

>> /hugintmp $ ls /home/bmike1/hugintmp
> hec1QPQW heFan8Hr heL3W456 huginpto_0vYcMe huginpto_95itzG huginpto_UEq4Vb
> hee6TKlX hehyqyzB heMNMrcf huginpto_2c8gZv huginpto_HYTJTG huginpto_ZuLc6q

I did specify 'ls -l'. If you look at those files, I think you'll
find they're in the order of 10 kB each.

[Michael Havens]

On Wednesday, September 21, 2016 at 10:38:36 PM UTC-4, Groogle wrote:

On Wednesday, 21 September 2016 at 19:33:27 -0700, Michael Havens wrote:
> In preferences->file name->Temporary directory I typed in
> "/home/bmike1/hugintmp"
> In the same location if /home/bmike1/hugintmp is present when I search for
> control points it will fail.

We seem to be going round in circles.  I reported this issue nearly a
week ago.  What does it write to the root file system when you don't
specify a temporary directory?

 

after searching for control points:

Searching for control points...

Hugin's cpfind 2016.2.0.48cb11a23351

based on Pan-o-matic by Anael Orlinski

Project contains the following images:

Image 0

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0494.JPG

  Remapped : yes

Image 1

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0495.JPG

  Remapped : yes

Image 2

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0496.JPG

  Remapped : yes

Image 3

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0497.JPG

  Remapped : yes

Image 4

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0498.JPG

  Remapped : yes

--- Analyze Images ---

i0 : Analyzing image...

i1 : Analyzing image...

i3 : Analyzing image...

i2 : Analyzing image...

i4 : Analyzing image...

--- Find matches ---

i3 <> i4 : Found 24 matches

i2 <> i3 : Found 23 matches

i0 <> i1 : Found 25 matches

i1 <> i2 : Found 24 matches

--- Find matches for overlapping images ---

--- Write Project output ---

Written output to /tmp/ap_res2RPWJD

Detection took 42.551 seconds.

Written output to /tmp/haXhtqCX

Statistically cleaning of control points...

Removed 3 control points in step 1

Removed 6 control points in step 2

Written output to /tmp/haXhtqCX

Searching for vertical lines...

linefind is searching for vertical lines

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0494.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0495.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0497.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0496.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0498.JPG

Found 3 vertical lines

Written output to /tmp/haXhtqCX

Opened project /tmp/haXhtqCX

Project contains

5 images

1 lenses

5 stacks

90 control points

Control points statistics

Mean error        : 971.36

Standard deviation: 186.23

Minimum           : 0.56

Maximum           : 1090.06

All images are connected.

Optimizing...

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          982.983793096836 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          41.9359835841126 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          6.63019692569752 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          4.61077632604332 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          3.01981247229104 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.97569382964583 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          2.76688043502161 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          2.74875128077305 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.50387441947329 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.46501866893365 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.46298406887543 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.46288404323768 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.46287903562832 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.46287877868892 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          1870.16827459187 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          1211.92765038268 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          602.088772194531 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          153.723441026673 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          18.7112302680542 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          12.6210226194956 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          8.03622538594012 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          7.06382934411868 units

Strategy 1

Average (rms) distance between Controlpoints 

after 8 iteration(s):          4.84370018630319 units

Strategy 1

Average (rms) distance between Controlpoints 

after 9 iteration(s):          3.72360519941188 units

Strategy 1

Average (rms) distance between Controlpoints 

after 10 iteration(s):          3.33495857754523 units

Strategy 1

Average (rms) distance between Controlpoints 

after 11 iteration(s):          3.25368888767976 units

Strategy 1

Average (rms) distance between Controlpoints 

after 12 iteration(s):          3.22919128957402 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.96933917425114 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.93297838272108 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.91884678098127 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.91392637362141 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.91228690715474 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.91168933451105 units

Strategy 2

Average (rms) distance between Controlpoints 

after 6 iteration(s):          2.91146533621293 units

Strategy 2

Average (rms) distance between Controlpoints 

after 7 iteration(s):          2.91138043556433 units

Strategy 2

Average (rms) distance between Controlpoints 

after 8 iteration(s):          2.91134808174348 units

Strategy 2

Average (rms) distance between Controlpoints 

after 9 iteration(s):          2.91133571999864 units

Strategy 2

Average (rms) distance between Controlpoints 

after 10 iteration(s):          2.91133099042677 units

Strategy 2

Average (rms) distance between Controlpoints 

after 11 iteration(s):          2.91132918088532 units

Strategy 2

Average (rms) distance between Controlpoints 

after 12 iteration(s):          2.91132848938124 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          1224.50663560168 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          849.558266081887 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):           837.72339825065 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          442.797571478775 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          197.553967549668 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):           83.305078374619 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          60.8230551927674 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          15.8844009816788 units

Strategy 1

Average (rms) distance between Controlpoints 

after 8 iteration(s):          6.86453271916768 units

Strategy 1

Average (rms) distance between Controlpoints 

after 9 iteration(s):          3.33264312124252 units

Strategy 1

Average (rms) distance between Controlpoints 

after 10 iteration(s):          2.90160888270834 units

Strategy 1

Average (rms) distance between Controlpoints 

after 11 iteration(s):          2.85983023874743 units

Strategy 1

Average (rms) distance between Controlpoints 

after 12 iteration(s):          2.85983023874743 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.62987246119631 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.56912544263629 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.56514887889879 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.56493984814271 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.56492773612702 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.56492701696016 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):           277.13777557305 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          50.4290961065833 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          30.8934211720977 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          18.9662786673375 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          10.2533024783389 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          4.62313502932562 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          4.22802898300364 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          3.94271642558738 units

Strategy 1

Average (rms) distance between Controlpoints 

after 8 iteration(s):          3.54064927076703 units

Strategy 1

Average (rms) distance between Controlpoints 

after 9 iteration(s):          3.39943495223357 units

Strategy 1

Average (rms) distance between Controlpoints 

after 10 iteration(s):          3.39943495223357 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          3.10863276622406 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          3.05923707817033 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          3.05082378572386 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          3.04960727844624 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          3.04946835147843 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          3.04945340232198 units

Strategy 2

Average (rms) distance between Controlpoints 

after 6 iteration(s):          3.04945175715441 units

Strategy 2

Average (rms) distance between Controlpoints 

after 7 iteration(s):          3.04945157398999 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          3.14243765033195 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):           3.1084705016695 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          3.08562264150855 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.79783458202005 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.75973617480134 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.74035508921397 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.72900089676539 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.72457648263304 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.72139159681708 units

Strategy 2

Average (rms) distance between Controlpoints 

after 6 iteration(s):          2.72101462978864 units

Strategy 2

Average (rms) distance between Controlpoints 

after 7 iteration(s):          2.72094216821842 units

Strategy 2

Average (rms) distance between Controlpoints 

after 8 iteration(s):          2.72092742311983 units

Strategy 2

Average (rms) distance between Controlpoints 

after 9 iteration(s):           2.7209241976134 units

Strategy 2

Average (rms) distance between Controlpoints 

after 10 iteration(s):          2.72092341838694 units

*** Adaptive geometric optimisation

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          3.07234153770674 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):           2.3134497293292 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          1.87445339657028 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          1.67834559110978 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          1.57788636304215 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          1.56756627225479 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          1.55680145159351 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          1.54645782373753 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          1.54641630515312 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          1.54641541011857 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          1.54641538348857 units

Skipping automatic leveling because of existing vertical control points.

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0494.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0496.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0497.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0495.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0498.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

Sampling points

sampling points

extracting good points

Selected 833 points

Photometric Optimization

Iteration: 0, error: 10.639909

Iteration: 1, error: 8.943244

Iteration: 2, error: 8.797578

Iteration: 3, error: 8.797578

Iteration: 4, error: 8.797578

Iteration: 5, error: 8.795439

Iteration: 6, error: 8.792865

Iteration: 7, error: 8.791576

Iteration: 8, error: 8.791356

Iteration: 9, error: 8.791048

Iteration: 10, error: 8.791048

Iteration: 11, error: 8.786547

Iteration: 12, error: 8.786410

Iteration: 13, error: 8.786410

Iteration: 14, error: 8.786342

Iteration: 15, error: 8.786308

Iteration: 0, error: 8.786308

Iteration: 1, error: 8.674930

Iteration: 2, error: 8.665746

Iteration: 3, error: 8.665746

Iteration: 4, error: 8.665448

Iteration: 5, error: 8.665448

Iteration: 6, error: 8.665448

Iteration: 7, error: 8.665448

Iteration: 8, error: 8.665448

Iteration: 9, error: 8.661520

Iteration: 10, error: 8.659719

Iteration: 11, error: 8.659111

Iteration: 12, error: 8.659094

Iteration: 13, error: 8.659094

Iteration: 0, error: 8.659094

Iteration: 1, error: 8.450615

Iteration: 2, error: 8.450615

Iteration: 3, error: 8.437719

Iteration: 4, error: 8.437719

Iteration: 5, error: 8.436530

Iteration: 6, error: 8.436530

Iteration: 7, error: 8.434317

Iteration: 8, error: 8.434222

Iteration: 9, error: 8.434222

Iteration: 10, error: 8.434222

Iteration: 11, error: 8.434222

Iteration: 12, error: 8.434155

Iteration: 13, error: 8.434068

Iteration: 14, error: 8.433866

Iteration: 15, error: 8.433672

Iteration: 16, error: 8.433613

Iteration: 17, error: 8.433610

Searching for best crop...

Calculate optimal size of panorama

Setting canvas size to 11713 x 5329

Searching for best crop rectangle

Run called

Inner 1024 19502737: 1536 10177 - 1536 3793

Starting 1024: 1536 10177 - 1536 3793

Starting 512: 1536 11201 - 1536 3793

Starting 256: 1536 11201 - 1024 3793

Starting 128: 1536 11457 - 1024 4049

Starting 64: 1408 11457 - 1024 4049

Starting 32: 1344 11457 - 960 4049

Starting 16: 1312 11457 - 960 4049

Starting 8: 1296 11457 - 960 4049

Starting 4: 1288 11465 - 960 4049

Starting 2: 1288 11469 - 960 4049

Starting 1: 1288 11471 - 960 4049

Set crop size to 1287,960,11471,4049

Written output to /tmp/haXhtqCX

 

after stitching:

Searching for control points...

Hugin's cpfind 2016.2.0.48cb11a23351

based on Pan-o-matic by Anael Orlinski

Project contains the following images:

Image 0

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0494.JPG

  Remapped : yes

Image 1

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0495.JPG

  Remapped : yes

Image 2

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0496.JPG

  Remapped : yes

Image 3

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0497.JPG

  Remapped : yes

Image 4

  Imagefile: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0498.JPG

  Remapped : yes

--- Analyze Images ---

i0 : Analyzing image...

i1 : Analyzing image...

i3 : Analyzing image...

i2 : Analyzing image...

i4 : Analyzing image...

--- Find matches ---

i3 <> i4 : Found 24 matches

i2 <> i3 : Found 23 matches

i0 <> i1 : Found 25 matches

i1 <> i2 : Found 24 matches

--- Find matches for overlapping images ---

--- Write Project output ---

Written output to /tmp/ap_res2RPWJD

Detection took 42.551 seconds.

Written output to /tmp/haXhtqCX

Statistically cleaning of control points...

Removed 3 control points in step 1

Removed 6 control points in step 2

Written output to /tmp/haXhtqCX

Searching for vertical lines...

linefind is searching for vertical lines

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0494.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0495.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0497.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0496.JPG

Working on image /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0498.JPG

Found 3 vertical lines

Written output to /tmp/haXhtqCX

Opened project /tmp/haXhtqCX

Project contains

5 images

1 lenses

5 stacks

90 control points

Control points statistics

Mean error        : 971.36

Standard deviation: 186.23

Minimum           : 0.56

Maximum           : 1090.06

All images are connected.

Optimizing...

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          982.983793096836 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          41.9359835841126 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          6.63019692569752 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          4.61077632604332 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          3.01981247229104 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.97569382964583 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          2.76688043502161 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          2.74875128077305 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.50387441947329 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.46501866893365 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.46298406887543 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.46288404323768 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.46287903562832 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.46287877868892 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          1870.16827459187 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          1211.92765038268 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          602.088772194531 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          153.723441026673 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          18.7112302680542 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          12.6210226194956 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          8.03622538594012 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          7.06382934411868 units

Strategy 1

Average (rms) distance between Controlpoints 

after 8 iteration(s):          4.84370018630319 units

Strategy 1

Average (rms) distance between Controlpoints 

after 9 iteration(s):          3.72360519941188 units

Strategy 1

Average (rms) distance between Controlpoints 

after 10 iteration(s):          3.33495857754523 units

Strategy 1

Average (rms) distance between Controlpoints 

after 11 iteration(s):          3.25368888767976 units

Strategy 1

Average (rms) distance between Controlpoints 

after 12 iteration(s):          3.22919128957402 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.96933917425114 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.93297838272108 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.91884678098127 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.91392637362141 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.91228690715474 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.91168933451105 units

Strategy 2

Average (rms) distance between Controlpoints 

after 6 iteration(s):          2.91146533621293 units

Strategy 2

Average (rms) distance between Controlpoints 

after 7 iteration(s):          2.91138043556433 units

Strategy 2

Average (rms) distance between Controlpoints 

after 8 iteration(s):          2.91134808174348 units

Strategy 2

Average (rms) distance between Controlpoints 

after 9 iteration(s):          2.91133571999864 units

Strategy 2

Average (rms) distance between Controlpoints 

after 10 iteration(s):          2.91133099042677 units

Strategy 2

Average (rms) distance between Controlpoints 

after 11 iteration(s):          2.91132918088532 units

Strategy 2

Average (rms) distance between Controlpoints 

after 12 iteration(s):          2.91132848938124 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          1224.50663560168 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          849.558266081887 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):           837.72339825065 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          442.797571478775 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          197.553967549668 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):           83.305078374619 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          60.8230551927674 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          15.8844009816788 units

Strategy 1

Average (rms) distance between Controlpoints 

after 8 iteration(s):          6.86453271916768 units

Strategy 1

Average (rms) distance between Controlpoints 

after 9 iteration(s):          3.33264312124252 units

Strategy 1

Average (rms) distance between Controlpoints 

after 10 iteration(s):          2.90160888270834 units

Strategy 1

Average (rms) distance between Controlpoints 

after 11 iteration(s):          2.85983023874743 units

Strategy 1

Average (rms) distance between Controlpoints 

after 12 iteration(s):          2.85983023874743 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.62987246119631 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.56912544263629 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.56514887889879 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.56493984814271 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.56492773612702 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.56492701696016 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):           277.13777557305 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):          50.4290961065833 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          30.8934211720977 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          18.9662786673375 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          10.2533024783389 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          4.62313502932562 units

Strategy 1

Average (rms) distance between Controlpoints 

after 6 iteration(s):          4.22802898300364 units

Strategy 1

Average (rms) distance between Controlpoints 

after 7 iteration(s):          3.94271642558738 units

Strategy 1

Average (rms) distance between Controlpoints 

after 8 iteration(s):          3.54064927076703 units

Strategy 1

Average (rms) distance between Controlpoints 

after 9 iteration(s):          3.39943495223357 units

Strategy 1

Average (rms) distance between Controlpoints 

after 10 iteration(s):          3.39943495223357 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          3.10863276622406 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          3.05923707817033 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          3.05082378572386 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          3.04960727844624 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          3.04946835147843 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          3.04945340232198 units

Strategy 2

Average (rms) distance between Controlpoints 

after 6 iteration(s):          3.04945175715441 units

Strategy 2

Average (rms) distance between Controlpoints 

after 7 iteration(s):          3.04945157398999 units

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          3.14243765033195 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):           3.1084705016695 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          3.08562264150855 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          2.79783458202005 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          2.75973617480134 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          2.74035508921397 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          2.72900089676539 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          2.72457648263304 units

Strategy 2

Average (rms) distance between Controlpoints 

after 5 iteration(s):          2.72139159681708 units

Strategy 2

Average (rms) distance between Controlpoints 

after 6 iteration(s):          2.72101462978864 units

Strategy 2

Average (rms) distance between Controlpoints 

after 7 iteration(s):          2.72094216821842 units

Strategy 2

Average (rms) distance between Controlpoints 

after 8 iteration(s):          2.72092742311983 units

Strategy 2

Average (rms) distance between Controlpoints 

after 9 iteration(s):           2.7209241976134 units

Strategy 2

Average (rms) distance between Controlpoints 

after 10 iteration(s):          2.72092341838694 units

*** Adaptive geometric optimisation

Optimizing Variables

Strategy 1

Average (rms) distance between Controlpoints 

after 0 iteration(s):          3.07234153770674 units

Strategy 1

Average (rms) distance between Controlpoints 

after 1 iteration(s):           2.3134497293292 units

Strategy 1

Average (rms) distance between Controlpoints 

after 2 iteration(s):          1.87445339657028 units

Strategy 1

Average (rms) distance between Controlpoints 

after 3 iteration(s):          1.67834559110978 units

Strategy 1

Average (rms) distance between Controlpoints 

after 4 iteration(s):          1.57788636304215 units

Strategy 1

Average (rms) distance between Controlpoints 

after 5 iteration(s):          1.56756627225479 units

Optimizing Variables

Strategy 2

Average (rms) distance between Controlpoints 

after 0 iteration(s):          1.55680145159351 units

Strategy 2

Average (rms) distance between Controlpoints 

after 1 iteration(s):          1.54645782373753 units

Strategy 2

Average (rms) distance between Controlpoints 

after 2 iteration(s):          1.54641630515312 units

Strategy 2

Average (rms) distance between Controlpoints 

after 3 iteration(s):          1.54641541011857 units

Strategy 2

Average (rms) distance between Controlpoints 

after 4 iteration(s):          1.54641538348857 units

Skipping automatic leveling because of existing vertical control points.

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0494.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0496.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0497.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0495.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

loading: /home/bmike1/Documents/Business/Photography/PropertyPhotographing/Test/Panorama/3/DSC_0498.JPG

downscaling: 6016x4000  3008x2000  1504x1000  

Sampling points

sampling points

extracting good points

Selected 833 points

Photometric Optimization

Iteration: 0, error: 10.639909

Iteration: 1, error: 8.943244

Iteration: 2, error: 8.797578

Iteration: 3, error: 8.797578

Iteration: 4, error: 8.797578

Iteration: 5, error: 8.795439

Iteration: 6, error: 8.792865

Iteration: 7, error: 8.791576

Iteration: 8, error: 8.791356

Iteration: 9, error: 8.791048

Iteration: 10, error: 8.791048

Iteration: 11, error: 8.786547

Iteration: 12, error: 8.786410

Iteration: 13, error: 8.786410

Iteration: 14, error: 8.786342

Iteration: 15, error: 8.786308

Iteration: 0, error: 8.786308

Iteration: 1, error: 8.674930

Iteration: 2, error: 8.665746

Iteration: 3, error: 8.665746

Iteration: 4, error: 8.665448

Iteration: 5, error: 8.665448

Iteration: 6, error: 8.665448

Iteration: 7, error: 8.665448

Iteration: 8, error: 8.665448

Iteration: 9, error: 8.661520

Iteration: 10, error: 8.659719

Iteration: 11, error: 8.659111

Iteration: 12, error: 8.659094

Iteration: 13, error: 8.659094

Iteration: 0, error: 8.659094

Iteration: 1, error: 8.450615

Iteration: 2, error: 8.450615

Iteration: 3, error: 8.437719

Iteration: 4, error: 8.437719

Iteration: 5, error: 8.436530

Iteration: 6, error: 8.436530

Iteration: 7, error: 8.434317

Iteration: 8, error: 8.434222

Iteration: 9, error: 8.434222

Iteration: 10, error: 8.434222

Iteration: 11, error: 8.434222

Iteration: 12, error: 8.434155

Iteration: 13, error: 8.434068

Iteration: 14, error: 8.433866

Iteration: 15, error: 8.433672

Iteration: 16, error: 8.433613

Iteration: 17, error: 8.433610

Searching for best crop...

Calculate optimal size of panorama

Setting canvas size to 11713 x 5329

Searching for best crop rectangle

Run called

Inner 1024 19502737: 1536 10177 - 1536 3793

Starting 1024: 1536 10177 - 1536 3793

Starting 512: 1536 11201 - 1536 3793

Starting 256: 1536 11201 - 1024 3793

Starting 128: 1536 11457 - 1024 4049

Starting 64: 1408 11457 - 1024 4049

Starting 32: 1344 11457 - 960 4049

Starting 16: 1312 11457 - 960 4049

Starting 8: 1296 11457 - 960 4049

Starting 4: 1288 11465 - 960 4049

Starting 2: 1288 11469 - 960 4049

Starting 1: 1288 11471 - 960 4049

Set crop size to 1287,960,11471,4049

Written output to /tmp/haXhtqCX

[Michael Havens]

On Wednesday, September 21, 2016 at 10:50:10 PM UTC-4, Groogle wrote:

I did specify 'ls -l'.  If you look at those files, I think you'll
find they're in the order of 10 kB each.

$  ls -l /home/bmike1/hugintmp 

total 100

-rw------- 1 bmike1 bmike1   419 Sep 20 17:59 hec1QPQW

-rw------- 1 bmike1 bmike1   419 Sep 20 17:59 hee6TKlX

-rw------- 1 bmike1 bmike1   419 Sep 20 10:13 heFan8Hr

-rw------- 1 bmike1 bmike1   419 Sep 20 07:14 hehyqyzB

-rw------- 1 bmike1 bmike1   419 Sep 20 17:59 heL3W456

-rw------- 1 bmike1 bmike1 14082 Sep 20 07:14 huginpto_0vYcMe

-rw------- 1 bmike1 bmike1 14082 Sep 20 17:59 huginpto_2c8gZv

-rw------- 1 bmike1 bmike1 14082 Sep 20 17:59 huginpto_95itzG

-rw------- 1 bmike1 bmike1 14082 Sep 20 10:13 huginpto_UEq4Vb

-rw------- 1 bmike1 bmike1 14082 Sep 20 17:59 huginpto_ZuLc6q

[Michael Havens]

I cancelled my large stitcch and stitched something small together.

this is before I started the stitch: 

bmike1@MikesBeast ~/hugintmp $  ls -l /tmp 

total 16

srwxr-xr-x 1 bmike1 bmike1    0 Sep 21 15:15 gedit.bmike1.2619256144

drwx------ 2 bmike1 bmike1 4096 Sep 21 17:04 ksocket-bmike1

drwxrwxrwx 2 bmike1 bmike1 4096 Sep 21 15:15 mintUpdate

srwx------ 1 bmike1 bmike1    0 Sep 21 22:52 PTBatcherGUI-bmike1.ipc

-rw------- 1 bmike1 bmike1    5 Sep 21 22:52 PTBatcherGUI-bmike1.lock

drwx------ 2 bmike1 bmike1 4096 Sep 21 15:15 ssh-fScB19FrJCn6

this is after I started the stitch 

bmike1@MikesBeast ~/hugintmp $  ls -l /tmp 

total 32

srwxr-xr-x 1 bmike1 bmike1     0 Sep 21 15:15 gedit.bmike1.2619256144

-rw------- 1 bmike1 bmike1   136 Sep 21 22:58 heUYjJTx

-rw------- 1 bmike1 bmike1 10542 Sep 21 22:58 huginpto_xjbSeN

drwx------ 2 bmike1 bmike1  4096 Sep 21 17:04 ksocket-bmike1

drwxrwxrwx 2 bmike1 bmike1  4096 Sep 21 15:15 mintUpdate

srwx------ 1 bmike1 bmike1     0 Sep 21 22:58 PTBatcherGUI-bmike1.ipc

-rw------- 1 bmike1 bmike1     5 Sep 21 22:58 PTBatcherGUI-bmike1.lock

drwx------ 2 bmike1 bmike1  4096 Sep 21 15:15 ssh-fScB19FrJCn6

[Greg 'groggy' Lehey]

Right. That's not going to use up 7+ GB in a hurry.

[Greg 'groggy' Lehey]

On Wednesday, 21 September 2016 at 19:53:25 -0700, Michael Havens wrote:
> On Wednesday, September 21, 2016 at 10:38:36 PM UTC-4, Groogle wrote:
>>
>> On Wednesday, 21 September 2016 at 19:33:27 -0700, Michael Havens wrote:
>>> In preferences->file name->Temporary directory I typed in
>>> "/home/bmike1/hugintmp"
>>> In the same location if /home/bmike1/hugintmp is present when I
>>> search for control points it will fail.
>>
>> We seem to be going round in circles. I reported this issue nearly a
>> week ago. What does it write to the root file system when you don't
>> specify a temporary directory?
>
> after searching for control points:
>
> Searching for control points...
> Hugin's cpfind 2016.2.0.48cb11a23351
> based on Pan-o-matic by Anael Orlinski
>

> Written output to /tmp/ap_res2RPWJD
>
> Written output to /tmp/haXhtqCX

OK, these are just the small PTO files, which you showed in more
detail in your other post.

> after stitching:

Is this your comment? It confuses the issue. But after stitching
there's nothing left to do.

At least I have the information now, but unless nona or enblend are
hiding something, there's no evidence of any large files being written
to the temporary directory, so you might as well reset the preference
so that you don't have to start Hugin twice. If you do run into the
root file system filling up again, take a look in the /tmp directory
and see what you can find. My guess is that whatever the problem was,
it has gone into hiding.

[Michael Havens]

but the problem is that when I give it a custom temporary directory none of the control point detectors work.

[Michael Havens]

On Wednesday, September 21, 2016 at 11:12:55 PM UTC-4, Groogle wrote:

  My guess is that whatever the problem was,
it has gone into hiding.

but the problem is that when I give it a custom temporary directory none of the control point detectors work.

 And I meant before/after stitching has started

 

[Greg 'groggy' Lehey]

[resequenced]

On Wednesday, 21 September 2016 at 20:24:31 -0700, Michael Havens wrote:
> On Wednesday, September 21, 2016 at 11:12:55 PM UTC-4, Groogle wrote:
>>
>> At least I have the information now, but unless nona or enblend are
>> hiding something, there's no evidence of any large files being written
>> to the temporary directory, so you might as well reset the preference
>> so that you don't have to start Hugin twice.
>

> but the problem is that when I give it a custom temporary directory
> none of the control point detectors work.

I'm sure that much of your issues relate to the fact that you write
your reply away from what you're replying to. In case it's my
terminology, that recommendation is to leave the temporary directory
specification empty (default).

[Greg 'groggy' Lehey]

On Thursday, 22 September 2016 at 13:12:51 +1000, Greg 'groggy' Lehey wrote:
>
> If you do run into the root file system filling up again, take a
> look in the /tmp directory and see what you can find. My guess is
> that whatever the problem was, it has gone into hiding.

One thing that occurs to me is that this might be swap space. Do you
have swap to file enabled? If so it could be that that is filling up
your root file system. Try:

$ swapon -s

On my Linux box I get:

Filename Type Size Used Priority
/dev/sda2 partition 2000084 5064 -1

I assume a swap file would have type "file".

[Markku Kolkka]

22.9.2016, 6.12, Greg 'groggy' Lehey kirjoitti:
>
> At least I have the information now, but unless nona or enblend are
> hiding something, there's no evidence of any large files being written
> to the temporary directory, so you might as well reset the preference
> so that you don't have to start Hugin twice. If you do run into the
> root file system filling up again, take a look in the /tmp directory
> and see what you can find.

If some program uses the tmpfile() function to create temporary files
they will not show in directory listings because they are unlinked
during the tmpfile() call. The filesystem usage should be visible with
the "du" command.

--
Markku Kolkka
markku...@iki.fi

---
Avast Antivirus on tarkistanut tämän sähköpostin virusten varalta.
https://www.avast.com/antivirus

[Michael Havens]

On Wednesday, September 21, 2016 at 11:30:02 PM UTC-4, Groogle wrote:

I'm sure that much of your issues relate to the fact that you write
your reply away from what you're replying to.  In case it's my
terminology, that recommendation is to leave the temporary directory
specification empty (default).

Now we are running in circles. If I do that the intermediate files created while stitching fill up the root partition. No problem though.  I'll just do as was suggested and fin control points with  the "temporary directory specification empty (default)" and then set the "temporary directory specification" to the larger directory  that can handle the intermediate files created while stitching. 

[Michael Havens]

On Thursday, September 22, 2016 at 12:00:32 AM UTC-4, Groogle wrote:

One thing that occurs to me is that this might be swap space.  Do you
have swap to file enabled?  If so it could be that that is filling up
your root file system.  Try:

 $ swapon -s

~ $ swapon -s

Filename Type Size        Used Priority

/dev/sdb5                         partition 5855656 0 -1

 

[Stefan Peter]

Hi Greg

On 22.09.2016 03:46, Greg 'groggy' Lehey wrote:
> On Wednesday, 21 September 2016 at 21:00:56 +0200, Stefan Peter wrote:
>> On 20.09.2016 13:32, Michael Havens wrote:
>>> Okay, I'm running the stitcher now even though no control points were
>>> found.
>>

>> Greg assumed that it has something to do with the temporary directory
>> path setting.
>
> It's more than an assumption. In my installation it's a certainty.

It is not on mine, see below.

>> However, I was not able to recreate this problem here. Not even
>> using a non existent directory as temporary file location interfered
>> with creating control points.
>
> OK, that's interesting. I thought it once worked for me too. What
> platform and version of Hugin?

I tested this with
o 2015.0.0 cdefc6e53a58 (from packages,ubuntu.com)
o hugin 2016.2.0~rc1 48cb11a23351 (from
https://launchpad.net/~hugin/+archive/ubuntu/next)
o hugin 2016.2.0 be8da0221960 (not released yet)
o 2016.3.0+hg7420 (current development tip from
https://launchpad.net/~hugin/+archive/ubuntu/nightly)

All test were conducted under Ubuntu Xenial (16.04 LTS).

All behaved exactly the same:
o No version tested had any problems finding cpfind
when there was a "Temporary dir" set in the preferences.
o When creating CPs, the system defined /tmp/ was used.
o When stitching (using PTBatcherGUI) I noticed two files
(12k to 16k and 528 bytes) in the /hom/stefan/temp/ directory
I put into the "Temporary dir" settings in the
preferences. All other files were created in the
projects directory.

So, where does this leave us?

Obviously, your FreeBSD and Michaels Linux Mint (?) versions differ in
some respect from the Ubuntu versions. Michaels version tends to clobber
the /tmp/ directory and both of your versions seem to have an issue when
the Temprary dir is set on the preferences.

My first suspicion would be the libraries used. When building for Ubuntu
which itself is based upon the Debian packages, there are quite some
dependency requirements in the form of
libboost-filesystem-dev (>= 1.47)
This means that building Hugin will fail of libboost-filesystem with a
version >= 1.47 is not available. The reason for such version
requirements may be caused by functionality used by Hugin which is not
present in earlier versions. Or known bugs in earlier versions that may
affect Hugins functionality. So, for starters, lets compare the
libraries used in these three versions. Attached you find the output of
ldd $(which hugin)
for the aforementioned hugin 2016.2.0 be8da0221960 (not officially
released by me yet). Would you please be so kind and compare the output
produced on your systems and let me know the differences?

> I modified icpfind to find what it was looking for. It had an empty
> PATH variable, so it couldn't find the control point detector.

Sorry, this I don't get. icpfind _is_ the control point detector. If it
gets found, it should work. If it does not get found, how do you
determine the PATH environment variable it was called with?

> And yes, I'm still planning to track the bug down.

Yes, so do I. After all, it may come back and bite me in a future
version, too.

With kind regards

Stefan Peter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
(See https://en.wikipedia.org/wiki/Posting_style for details)

[Michael Havens]

Okay, I just started a big pano with the custom temp directory set to default and here is ls -l /tmp and ls -l in the directory where all of the intermediate files are being put when I run out of disk space (like ya all said the intermediate files go in the directory the images are in:

a side note- I had to leave for work so I left it running figuring it would just pause when I got the notice that disk space was low. I got home and the panorama was complete. So it looks as if I found a bug that in my case did not matter. Anyways here is the outputs of ls -l after I restart stitching and wait for the low disk space error to occur I also did df for the drives too:

[Michael Havens]

On Thursday, September 22, 2016 at 4:13:12 PM UTC-4, Michael Havens wrote:

Okay, I just started a big pano with the custom temp directory set to default and here is ls -l /tmp and ls -l in the directory where all of the intermediate files are being put when I run out of disk space (like ya all said the intermediate files go in the directory the images are in:

a side note- I had to leave for work so I left it running figuring it would just pause when I got the notice that disk space was low. I got home and the panorama was complete. So it looks as if I found a bug that in my case did not matter. Anyways here is the outputs of ls -l after I restart stitching and wait for the low disk space error to occur I also did df for the drives too:

Sorry, i thought my mouse froze after the large pano so I flipped off the computer but I was messing with the wrong mouse!  (I guess I'll take the dead mouse off of my desk) In any case do you need that information I was going to give you? And I run Mint 17.3 .

[Greg 'groggy' Lehey]

On Thursday, 22 September 2016 at 8:13:17 +0300, Markku Kolkka wrote:
> 22.9.2016, 6.12, Greg 'groggy' Lehey kirjoitti:
>>
>> At least I have the information now, but unless nona or enblend are
>> hiding something, there's no evidence of any large files being written
>> to the temporary directory, so you might as well reset the preference
>> so that you don't have to start Hugin twice. If you do run into the
>> root file system filling up again, take a look in the /tmp directory
>> and see what you can find.
>
> If some program uses the tmpfile() function to create temporary files
> they will not show in directory listings because they are unlinked
> during the tmpfile() call.

That's possible. Hugin does not use tmpfile(), but it's not beyond
the bounds of possibility that some library might.

> The filesystem usage should be visible with the "du" command.

Right.

[Greg 'groggy' Lehey]

On Thursday, 22 September 2016 at 6:34:15 -0700, Michael Havens wrote:
>
>
> On Wednesday, September 21, 2016 at 11:30:02 PM UTC-4, Groogle wrote:
>>
>> I'm sure that much of your issues relate to the fact that you write
>> your reply away from what you're replying to. In case it's my
>> terminology, that recommendation is to leave the temporary directory
>> specification empty (default).
>
> Now we are running in circles. If I do that the intermediate files created
> while stitching fill up the root partition.

Do they? So far you have presented no evidence.

> No problem though. I'll just do as was suggested and fin control
> points with the "temporary directory specification empty (default)"
> and then set the "temporary directory specification" to the larger
> directory that can handle the intermediate files created while
> stitching.

That's exactly what I'm asking you not to do.

On Thursday, 22 September 2016 at 13:13:12 -0700, Michael Havens wrote:
> Okay, I just started a big pano with the custom temp directory set to
> default and here is ls -l /tmp and ls -l in the directory where all of the
> intermediate files are being put when I run out of disk space (like ya all
> said the intermediate files go in the directory the images are in:

I don't see anything.

> a side note- I had to leave for work so I left it running figuring it would
> just pause when I got the notice that disk space was low. I got home and
> the panorama was complete. So it looks as if I found a bug that in my case
> did not matter. Anyways here is the outputs of ls -l after I restart
> stitching and wait for the low disk space error to occur I also did df for
> the drives too:

This, too, is missing.

On Thursday, 22 September 2016 at 14:39:31 -0700, Michael Havens wrote:
>
> Sorry, i thought my mouse froze after the large pano so I flipped
> off the computer but I was messing with the wrong mouse! (I guess
> I'll take the dead mouse off of my desk) In any case do you need
> that information I was going to give you?

If you mean the information you referred to above, definitely. So far
there's no evidence that anything is wrong with Hugin.

[Greg 'groggy' Lehey]

On Thursday, 22 September 2016 at 6:37:57 -0700, Michael Havens wrote:
> On Thursday, September 22, 2016 at 12:00:32 AM UTC-4, Groogle wrote:
>>
>> One thing that occurs to me is that this might be swap space. Do
>> you have swap to file enabled? If so it could be that that is
>> filling up your root file system. Try:
>>
>> $ swapon -s
>
>

>> $ swapon -s
> Filename Type Size Used Priority
> /dev/sdb5 partition 5855656 0 -1

OK, that wasn't it, then. It might still be worth looking at this
towards the end of stitching to see what happens to the "Used" value.

[Greg 'groggy' Lehey]

On Thursday, 22 September 2016 at 17:49:59 +0200, Stefan Peter wrote:
> Hi Greg
>
> On 22.09.2016 03:46, Greg 'groggy' Lehey wrote:
>> On Wednesday, 21 September 2016 at 21:00:56 +0200, Stefan Peter wrote:
>>> On 20.09.2016 13:32, Michael Havens wrote:
>>>> Okay, I'm running the stitcher now even though no control points were
>>>> found.
>>>

>>> However, I was not able to recreate this problem here. Not even
>>> using a non existent directory as temporary file location interfered
>>> with creating control points.
>>
>> OK, that's interesting. I thought it once worked for me too. What
>> platform and version of Hugin?
>
> I tested this with

> ... enough versions

>
> All test were conducted under Ubuntu Xenial (16.04 LTS).
>
> All behaved exactly the same:
> o No version tested had any problems finding cpfind
> when there was a "Temporary dir" set in the preferences.

This is very interesting.

> o When creating CPs, the system defined /tmp/ was used.

What went in there? I see a couple of PTO files, nothing that is
likely to fill the file system.

> o When stitching (using PTBatcherGUI) I noticed two files
> (12k to 16k and 528 bytes) in the /hom/stefan/temp/ directory
> I put into the "Temporary dir" settings in the
> preferences.

That sounds like exactly these files.

> All other files were created in the projects directory.

This also matches my experience.

> So, where does this leave us?
>
> Obviously, your FreeBSD and Michaels Linux Mint (?) versions differ
> in some respect from the Ubuntu versions. Michaels version tends to
> clobber the /tmp/ directory

So far we have no evidence of that. I'm trying hard, but it's an
uphill battle.

> and both of your versions seem to have an issue when the Temprary
> dir is set on the preferences.

Yes.

> My first suspicion would be the libraries used. When building for Ubuntu
> which itself is based upon the Debian packages, there are quite some
> dependency requirements in the form of
> libboost-filesystem-dev (>= 1.47)
> This means that building Hugin will fail of libboost-filesystem with a
> version >= 1.47 is not available. The reason for such version
> requirements may be caused by functionality used by Hugin which is not
> present in earlier versions. Or known bugs in earlier versions that may
> affect Hugins functionality. So, for starters, lets compare the
> libraries used in these three versions. Attached you find the output of
> ldd $(which hugin)
> for the aforementioned hugin 2016.2.0 be8da0221960 (not officially
> released by me yet). Would you please be so kind and compare the output
> produced on your systems and let me know the differences?

I'm prepared to blame libraries for lots of things, but I can't think
of a scenario where one could cause this kind of problem. Still, I've
compared the two ldd outputs (sorted, trimmed path names), and we
have:

--- ldd-freebsd-sorted 2016-09-23 09:03:16.109044000 +1000
+++ ldd-ubuntu-sorted 2016-09-23 09:02:31.692945000 +1000
@@ -1,14 +1,12 @@
- libEGL.so.1
+ /lib64/ld-linux-x86-64.so.2 (0x000055a058713000)
libGL.so.1
- libGLEW.so.1
+ libGLEW.so.1.13
libGLU.so.1
libHalf.so.12
libICE.so.6
libIex-2_2.so.12
- libIexMath-2_2.so.12
libIlmImf-2_2.so.22
libIlmThread-2_2.so.12
- libImath-2_2.so.12
libSM.so.6
libX11-xcb.so.1
libX11.so.6
@@ -23,93 +21,64 @@
libXinerama.so.1
libXrandr.so.2
libXrender.so.1
- libXt.so.6
libXxf86vm.so.1
libatk-1.0.so.0
- libboost_filesystem.so.1.55.0
- libboost_system.so.1.55.0
- libbz2.so.4
- libc++.so.1
- libc.so.7
+ libboost_filesystem.so.1.58.0
+ libboost_system.so.1.58.0
+ libc.so.6
libcairo.so.2
libceleste.so.0.0
- libcxxrt.so.1
+ libdatrie.so.1
+ libdl.so.2
libdrm.so.2
- libelf.so.1
- libenchant.so.1
- libexecinfo.so.1
libexiv2.so.14
libexpat.so.1
libffi.so.6
libfftw3.so.3
libfontconfig.so.1
libfreetype.so.6
- libgbm.so.1
libgcc_s.so.1
- libgcrypt.so.20
libgdk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0
libgio-2.0.so.0
+ libglapi.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
- libgpg-error.so.0
+ libgomp.so.1
libgraphite2.so.3
- libgstapp-1.0.so.0
- libgstaudio-1.0.so.0
- libgstbase-1.0.so.0
- libgstfft-1.0.so.0
- libgstpbutils-1.0.so.0
- libgstreamer-1.0.so.0
- libgsttag-1.0.so.0
- libgstvideo-1.0.so.0
- libgthread-2.0.so.0
libgtk-x11-2.0.so.0
- libharfbuzz-icu.so.0
libharfbuzz.so.0
- libhdf5.so.10
- libhdf5_hl.so.10
libhugin_python_interface.so.0.0
libhuginbase.so.0.0
libhuginbasewx.so.0.0
- libiconv.so.2
libicpfindlib.so.0.0
- libicudata.so.55
- libicui18n.so.55
- libicuuc.so.55
- libintl.so.8
- libjavascriptcoregtk-1.0.so.0
- libjbig.so.2
+ libjbig.so.0
libjpeg.so.8
liblcms2.so.2
liblzma.so.5
- libm.so.5
- libmspack.so.0
- libnvidia-glcore.so.1
- libnvidia-tls.so.1
- liborc-0.4.so.0
+ libm.so.6
+ libnotify.so.4
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpano13.so.3
- libpcre.so.1
+ libpcre.so.3
libpixman-1.so.0
- libpng16.so.16
- libpthread-stubs.so.0
- libpython2.7.so.1
- librpcsvc.so.5
+ libpng12.so.0
+ libpthread.so.0
+ libpython2.7.so.1.0
+ libresolv.so.2
librt.so.1
- libsecret-1.so.0
- libsoup-2.4.so.1
+ libselinux.so.1
libsqlite3.so.0
- libthr.so.3
+ libstdc++.so.6
+ libthai.so.0
libtiff.so.5
- libutil.so.9
+ libutil.so.1
+ libuuid.so.1
libvigraimpex.so.5
- libwebkitgtk-1.0.so.0
- libwebp.so.5
libwx_baseu-3.0.so.0
- libwx_baseu_net-3.0.so.0
libwx_baseu_xml-3.0.so.0
libwx_gtk2u_adv-3.0.so.0
libwx_gtk2u_aui-3.0.so.0
@@ -119,11 +88,13 @@
libwx_gtk2u_qa-3.0.so.0
libwx_gtk2u_xrc-3.0.so.0
libxcb-dri2.so.0
+ libxcb-dri3.so.0
+ libxcb-glx.so.0
+ libxcb-present.so.0
libxcb-render.so.0
- libxcb-shape.so.0
libxcb-shm.so.0
- libxcb-xfixes.so.0
+ libxcb-sync.so.1
libxcb.so.1
- libxml2.so.2
- libxslt.so.1
- libz.so.6
+ libxshmfence.so.1
+ libz.so.1
+ linux-vdso.so.1

That's actually a surprising number of differences. If you have some
reason to suspect libboost, it's interesting to note the difference
there. But it's still way higher than 1.47.

>> I modified icpfind to find what it was looking for. It had an empty
>> PATH variable, so it couldn't find the control point detector.
>
> Sorry, this I don't get. icpfind _is_ the control point detector.

No, icpfind starts the control point detector. In my case it was
looking for panomatic, in Michael's case cpfind.

> If it gets found, it should work. If it does not get found, how do
> you determine the PATH environment variable it was called with?

Here's the function in question
(hugin-2016.2.0/src/hugin1/icpfind/AutoCtrlPointCreator.cpp, round
line 191):

bool CanStartProg(wxString progName,wxWindow* parent)
{
#if defined MAC_SELF_CONTAINED_BUNDLE
if(!GetBundledProg(progName).IsEmpty())
return true;
#endif
wxFileName prog(progName);
bool canStart=false;
if(prog.IsAbsolute())
{
canStart=(prog.IsFileExecutable());
}
else
{
wxPathList pathlist;
#ifdef __WXMSW__
const wxFileName exePath(wxStandardPaths::Get().GetExecutablePath());
pathlist.Add(exePath.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR));
#endif
pathlist.AddEnvList(wxT("PATH"));
wxString path = pathlist.FindAbsoluteValidPath(progName);
if(path.IsEmpty())
canStart=false;
else
{
wxFileName prog2(path);
canStart=(prog2.IsFileExecutable());
};
};
if(!canStart)
CPMessage(wxString::Format(
_("Could not find \"%s\" in path.\nMaybe you have not installed it properly or given a wrong path in the settings."),progName.c_str()),
_("Error"),parent);
return canStart;
};

My modification was:

if(path.IsEmpty())
{
canStart=false;
CPMessage(wxString::Format(_("No path set for executables.\n")),
_("Error"),parent);
}
else
{
wxFileName prog2(path);
canStart=(prog2.IsFileExecutable());
if(!canStart)
CPMessage(wxString::Format(
_("Could not find \"%s\" in path \"%s\".\n"
"Maybe you have not installed it properly or given a wrong path in the settings."),
progName.c_str(), path),
_("Error"),parent);
};

I wanted to display the path, but it's all tied up in wxString and
other complications that I don't understand, so I've given up for the
moment. But the message I got showed that the path was empty.

>> And yes, I'm still planning to track the bug down.
>
> Yes, so do I. After all, it may come back and bite me in a future
> version, too.

Let me know if I can get you any more information.

[Michael Havens]

okay here is a series of issuances of commands spread out over a period of time:

https://drive.google.com/open?id=0B2xvsVTZy4y1RzJlZ2tnRUZsRnM

the panos I am working with this time are the files that begin "DSC_0493 - DSC_0526-5"

I believe what you are looking for is one of the last lines in 'status report'.

[Michael Havens]

Status Report is a copy of the text in the status report window that hugin opens for you when the panorama completes (or fails).

[Greg 'groggy' Lehey]

On Thursday, 22 September 2016 at 19:19:57 -0700, Michael Havens wrote:
> okay here is a series of issuances of commands spread out over a period of
> time:
>
> https://drive.google.com/open?id=0B2xvsVTZy4y1RzJlZ2tnRUZsRnM

Ouch, is that painful. Don't you have the plain text?

[Michael Havens]

I thought it was proper to place large amounts of text on a hosting service rather than on the mailing list. Do you wish for me to place it all on here instead?

[Carl von Einem]

Michael Havens wrote on 23.09.16 07:55:

> I thought it was proper to place large amounts of text on a hosting
> service rather than on the mailing list. Do you wish for me to place it
> all on here instead?

No, please don't attach large documents to your messages.

When someone asks for "plain text" no file format like PDF or DOC is
needed, just a simple .txt file, no formatting.

See https://en.wikipedia.org/wiki/Plain_text

Carl

[Michael Havens]

[Michael Havens]

oh... for anyone who reads this if you don't realize it the numbers in the filenames are the time in 24 hour time. Subtract 1200 from it to get 12 hour time.

On Friday, September 23, 2016 at 9:46:52 AM UTC-4, Michael Havens wrote:

[Stefan Peter]

Hi Greg

I feel that we have two different issues, the first one with the missing
PATH environment when setting the temporary directory, the second one
with the "out of space" message. Let's concentrate on the former here,
as both you and Michael seem to experience this.

On 23.09.2016 01:40, Greg 'groggy' Lehey wrote:
>
> I'm prepared to blame libraries for lots of things, but I can't think
> of a scenario where one could cause this kind of problem. Still, I've
> compared the two ldd outputs (sorted, trimmed path names), and we
> have:
>

[lots of differences cut for brevity ... ]

> That's actually a surprising number of differences.

Actually, I expected more differences. We are talking about two
different operating systems here, not just two distributions or
versions. And believe me, "Linux" is not as homogeneous as it may sound
and differences from one version to the next can be huge. As an example,
the actual Ubuntu xenial replaced upstart with systemd.

> If you have some
> reason to suspect libboost, it's interesting to note the difference
> there. But it's still way higher than 1.47.

Yep, and Ubuntu Trusty (14.04 LTS) used 1.54 compared to FreeBSDs 1.55
so I feel that this should not be a problem. Alas, it was worth a try.

>
>>> I modified icpfind to find what it was looking for. It had an empty
>>> PATH variable, so it couldn't find the control point detector.
>>
>> Sorry, this I don't get. icpfind _is_ the control point detector.
>
> No, icpfind starts the control point detector. In my case it was
> looking for panomatic, in Michael's case cpfind.
>

Thank you for the details, I was not aware of this deviation. But if
your findings are right, this means that icpfind was called with an
empty environment, and this is where the problem originates.

I tried to find out where icpfind was called in hugin, but my C++ foo is
from the 90thies and the liberal sprinkling of libraries used in hugin
does noet really help. I will have to compile a debug version and see if
I can find out more this way.

Please let me know of any progress you make.

[Stefan Peter]

Dear Michael Havens

Thank you for the text files. However, I had some time earlier today,
when the documents on google where still available, and I think I
spotted something. However, the text files you sent are missing the log
file from the Hugin run and there I found the following issues:

Your pto is set up to create both "Exposure corrected, low dynamic
range" output (which succeeds) and "Exposure, fused from any
arrangement" which fails.

There have been plenty of error messages in this log along the lines of
"can not enfuse single file" that made me believe that you either have
not done a proper alignment of the images or have certain areas of the
pano done with varying exposures. But hen, the "Exposure corrected, low
dynamic range" image would have to fail ...

Anyhow, I can not investigate this because the Hugin log file is missing
from the text files you sent.

One other thing I remember from this log file is the fact that the error
messages "no space left on device" originated from enfuse. Now enfuse
4.x actually uses the /tmp/ directory for an image cache, but the docs
only talk about 1024 MBytes which should not be a problem with your
system. However, this "Exposure, fused from any arrangement" seems to
want to enfuse 22 images in your case. I have no idea what space
requirements such an operation would call for.

So, please, could you share the pto you used in this example? Please put
it up somewhere like pastebin.com and just send the link to this mailing
list. And I don't need the images, I can fake them just fine (thanks to
panotools).

And another issue: Could you please let us know (again?) what versions of
hugin
enblend
enfuse
You have installed?

[Michael Havens]

On Friday, September 23, 2016 at 3:05:29 PM UTC-4, Stefan Peter wrote:

So, please, could you share the pto you used in this example? Please put
it up somewhere like pastebin.com and just send the link to this mailing
list.

 

http://pastebin.com/QCX1z8Ra 

And another issue: Could you please let us know (again?) what versions of
hugin

2016.2.0.48cb11a23351

 

enblend

4.1.3

 

enfuse

4.1.3

I have to apologize. I got stupid last night and deleted the  status report.... however, google drive  has a trash bin so I was able to recover it.

The log file I am sending is the last one in te series. It is not named as expected so I don't know...

[Michael Havens]

I understand it now! I started with '1' while hugin starts its numbering with '0',so that is the right one.

[Stefan Peter]

Dera Michael Havens

On 24.09.2016 03:56, Michael Havens wrote:
>
>
> On Friday, September 23, 2016 at 3:05:29 PM UTC-4, Stefan Peter wrote:
>
> So, please, could you share the pto you used in this example? Please
> put

> it up somewhere like pastebin.com <http://pastebin.com> and just

> send the link to this mailing
> list.
>
>
> http://pastebin.com/QCX1z8Ra
>

Thank you for the pro. I managed to get a setup reasonably close to
yours (enfuse 4.1.4 instead of 4.1.3) and this is what I found;

Your project is not yet ready for prime time, hugin reports
2 unconnected image groups found: [0-19,21-33],[20]
I suppose this is where the hole in the center comes from.

Your project is not optimized. When optimizing just for position, I get
an average control distance of 18.26 with a maximum of 241.78, You
should bring down the maximum distance to around 1.0 and optimize for
"positions, view and barrel" at least.

Your shots in the middle two rows do not overlap sufficiently. This will
lead to problems finding control points and to smaller holes in the
"circumference" of the pano.

And finally: I still don't know what file system runs out of space. In
the "Exposure fused from any arrangement" phase of the stitching,
enfuse/enblend use up to 16 GBytes of space in my home directory which
would fill up your root directory (7 GBytes free), but your home
directory has around 140GBytes free and should be able to cope with this.
The maximum space used in my root directory during the stitch was only
64 MBytes and this number may have been influenced by other programs
running at the same time.

So, unless your project used the root partition for its temporary files,
I can not see why you should run out of space. The df listings you sent
to this list unfortunately do not give a clue, maybe because they have
been spaced apart to wide. If you want to, you can try to run the
following in a terminal during the stitch and send me the resulting
log.log to my private eMail:

while [ true ]; do
date +'%s'|tee -a log.log
df -x tmpfs|tee -a log.log
sleep 10
done

On the other hand, you don't need the "fuse from any arrangement" unless
you have bracketed shots.

[Greg 'groggy' Lehey]

On Sunday, 25 September 2016 at 9:50:11 +0200, Stefan Peter wrote:
> Dera Michael Havens
>
> On 24.09.2016 03:56, Michael Havens wrote:
>>
>>
>> On Friday, September 23, 2016 at 3:05:29 PM UTC-4, Stefan Peter wrote:
>>
>> So, please, could you share the pto you used in this example? Please
>> put
>> it up somewhere like pastebin.com <http://pastebin.com> and just
>> send the link to this mailing
>> list.
>>
>>
>> http://pastebin.com/QCX1z8Ra
>>
>
> Thank you for the pro. I managed to get a setup reasonably close to
> yours (enfuse 4.1.4 instead of 4.1.3) and this is what I found;

> ...

Thanks for following up on this. I think I've done as much as I can,
so I'll leave it to you. A couple of thoughts:

> And finally: I still don't know what file system runs out of space.

Yes, I've asked several times for details on this, but none were
forthcoming.

> In the "Exposure fused from any arrangement" phase of the stitching,
> enfuse/enblend use up to 16 GBytes of space in my home directory
> which would fill up your root directory (7 GBytes free),

I think it's reasonable to assume that Michael was partially following
my instructions by removing the temp directory specification, so it's
possible that the files were being written to /tmp or elsewhere on the
root file system. But there's no way to know without the information
I asked for. As you observer, all the df output he sent shows plenty
of space free in both directories, at least because they weren't done
concurrently.

Quite possibly there is an issue here with enfuse. My guess is that
it really does write to the temporary directory. If that's the case,
then setting it to be in /home would probably solve the problem, in
which case the only issue is the bug with the missing PATH variable.

> On the other hand, you don't need the "fuse from any arrangement"
> unless you have bracketed shots.

I suspect this is a problem with the Assistant, which frequently
offers this for what appears to be no good reason. It doesn't happen
if you go via the Stitcher tab.

[Michael Havens]

Please explain to me 2 unconnected image groups found: [0-19,21-33],[20]. 0-19 looks to me like 20 images, as does 21-33 (13 images), while 20 looks like 1 image. Also, how do I find control points in the cloud images?

As for the file system that runs out of space.... the last time I run this through and I was at my computer when the notification that I was running out of disk space appeared the notification appeared about a minute before the stitching was done.

"If that's the case, then setting it to be in /home would probably solve the problem, in 
which case the only issue is the bug with the missing PATH variable."

This is the situation.

"So, unless your project used the root partition for its temporary files, "

I don't know but I think this is what it did because if I find the control points and then reassign hugin's temp file location it does not run out of space.

     while [ true ]; do 

     date +'%s'|tee -a log.log 
     df -x tmpfs|tee -a log.log 
     sleep 10 
     done 

I don't have time to sit in front of my computer until hugun finishes the stitch right now. II'll do this after we connect the unconnected images

[Stefan Peter]

Dear Michael Havens

On 25.09.2016 19:36, Michael Havens wrote:
> Please explain to me 2 unconnected image groups found:
> [0-19,21-33],[20]. 0-19 looks to me like 20 images, as does 21-33 (13
> images), while 20 looks like 1 image.

Yes, exactly. You have one image (number 20) that is neither connected
to the images 0-19 nor to the images 21-33.

> Also, how do I find control points
> in the cloud images?

Sorry, I don't understand the question here. Are you asking how to find
out what control points link to/from image 20? Just set hugin to expert
mode (Interface -> Expert), switch to the control points tab, select
image 20 in the left image tab and try to find a tab in the right image
tab that borders to image 20. And yes, in this mode, you can manually
create CPs from one image to another in order to fix this problem.

> As for the file system that runs out of space.... the last time I run
> this through and I was at my computer when the notification that I was
> running out of disk space appeared the notification appeared about a
> minute before the stitching was done.

You mean that you have been notified a minute after the fact? Are you
aware that notification is dependant on CPU usage and (maybe) free space
on the root drive? Just imagine that enfuse has monopolized the CPU in
order to clean up the mess so all other activities had to wait for this
to have happened?

> "If that's the case, then setting it to be in /home would probably solve
> the problem, in
> which case the only issue is the bug with the missing PATH variable."
>
> This is the situation.

Sorry? What do you want to tell me with this? Please remember that I can
not read your mind and I don't have a link to your system that tells me
what is going on there. Did you intend to let me know that when setting
the tempdir to /home, your problem is solved?

> "So, unless your project used the root partition for its temporary files, "
> I don't know but I think this is what it did because if I find the
> control points and then reassign hugin's temp file location it does not
> run out of space.
>
> while [ true ]; do
> date +'%s'|tee -a log.log
> df -x tmpfs|tee -a log.log
> sleep 10
> done
>
> I don't have time to sit in front of my computer until hugun finishes
> the stitch right now. II'll do this after we connect the unconnected images

Sorry, I can not help you there. And I may not have the time later.

[Michael Havens]

On Sunday, September 25, 2016 at 2:34:33 PM UTC-4, Stefan Peter wrote:

> As for the file system that runs out of space.... the last time I run
> this through and I was at my computer when the notification that I was
> running out of disk space appeared the notification appeared about a
> minute before the stitching was done.

You mean that you have been notified a minute after the fact?

I got the notification a minute or so before the job was complete.

 

> "If that's the case, then setting it to be in /home would probably solve
> the problem, in
> which case the only issue is the bug with the missing PATH variable."
>
> This is the situation.

Sorry? What do you want to tell me with this? Please remember that I can
not read your mind and I don't have a link to your system that tells me
what is going on there. Did you intend to let me know that when setting
the tempdir to /home, your problem is solved?

Yes, this solved the issue. However, I had to find the control points before I set  /home as hugintmp. I have said so much previously..... unless I'm crazy and only said so in my mind and not in type.

[Michael Havens]

On Sunday, September 25, 2016 at 2:34:33 PM UTC-4, Stefan Peter wrote:

Dear Michael Havens

On 25.09.2016 19:36, Michael Havens wrote:
> Please explain to me 2 unconnected image groups found:
> [0-19,21-33],[20]. 0-19 looks to me like 20 images, as does 21-33 (13
> images), while 20 looks like 1 image.

Yes, exactly. You have one image (number 20) that is neither connected
to the images 0-19 nor to the images 21-33.

Thanks for detailing that. 

[Michael Havens]

What does 'optimize' do? I just ran almost the entire process through to the end (2 hours) when I was rereading what I hadn't done when I noticed it was said I did not optimize it. So I stopped, optimized, and started the process again. BUT.... what does it do? 

Further, is there any benefit in running it twice... threee, four times?

[Greg 'groggy' Lehey]

On Friday, 23 September 2016 at 20:33:42 +0200, Stefan Peter wrote:
> On 23.09.2016 01:40, Greg 'groggy' Lehey wrote:
>> No, icpfind starts the control point detector. In my case it was
>> looking for panomatic, in Michael's case cpfind.
>
> Thank you for the details, I was not aware of this deviation. But if
> your findings are right, this means that icpfind was called with an
> empty environment, and this is where the problem originates.

That's maybe jumping to conclusions. It's fairly certain that icpfind
can't find the PATH environment variable using the wx interfaces; it
doesn't mean it wasn't set, nor that the rest of the environment is
missing/inaccessible. I'll continue looking, but it's not a high
priority for me.

[Carl von Einem]

Michael Havens wrote on 26.09.16 01:18:

> What does 'optimize' do? I just ran almost the entire process through to
> the end (2 hours) when I was rereading what I hadn't done when I noticed
> it was said I did not optimize it. So I stopped, optimized, and started
> the process again. BUT.... what does it do?

http://wiki.panotools.org/Hugin_Optimizer_tab

> Further, is there any benefit in running it twice... threee, four times?

I think you should start with a simple horizontal, one row set of images
taken from a tripod (don't forget about overlap) and play with that
through the whole process of creating a 360° panorama without having to
care about nadir and zenith. Once you get familiar with the process,
include nadir and zenith images in the next step.

In the "tutorials" section of http://wiki.panotools.org/ I found a link
to -> Panorama Tools - Using The Optimizer
http://www.johnhpanos.com/optitute.htm
(maybe a bit outdated at several points but I hope you'll get the image)

You can always use the Panotools wiki as a glossary. In Firefox you can
easily add it to your list of search engines.

I also have a feeling that your knowledge of the operating system you're
working with is rather basic. Maybe you can also find tutorials about
that somewhere.

Carl

[Michael Havens]

On Monday, September 26, 2016 at 3:09:51 AM UTC-4, zarl wrote:

Michael Havens wrote on 26.09.16 01:18:
> What does 'optimize' do? I just ran almost the entire process through to
> the end (2 hours) when I was rereading what I hadn't done when I noticed
> it was said I did not optimize it. So I stopped, optimized, and started
> the process again. BUT.... what does it do?

http://wiki.panotools.org/Hugin_Optimizer_tab

Thank you for that. While reading through it I found 'optimizer tab'. I don't have an 'optimizer tab'. Only 'Photos', 'Masks', 'Control Points', and 'Stitcher' tabs. I can optimize with Edit-> optimize.... but no tab.

[Michael Havens]

I get it... they got rid of the optimizer tab and moved the settings into Photos.

[Stefan Peter]

Dear Michael Havens

Am 26.09.2016 um 15:18 schrieb Michael Havens:
> I get it... they got rid of the optimizer tab and moved the settings
> into Photos.

Not exactly. You still get an optimizer tab when you set the Optimize ->
Geometric setting to "Custom parameters" in the Photo tab.