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.

Greg
--
Sent from my desktop computer.
Finger g...@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

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

Attachment: signature.asc
Description: PGP signature

Reply via email to