hugin shouldn't stitch in root.

[Michael Havens]

I am trying to create a 360X180 panorama. As it stitches the images together though it runs out of room. Root in this system is finite. /home in this system is enormous. Why does hugin stitch things together in / rather than /home. How do I get around this problem?

[Michael Havens]

FYI- I killed hugin with the notice that I was running out of space and:

$ df /

Filesystem     1K-blocks     Used Available Use% Mounted on

/dev/sdb1       23638908 14634544   7780532  66% /

[Michael Havens]

My feeling is that te working directory ought to be a setting.

[Sean Greenslade]

If I recall correctly, the only reason Hugin would write files outside
of your destination directory is when temporary files are written. By
default it uses /tmp, however you can change that with the TMPDIR
environment varible like so:

$ cd /home/user/pano
$ TMPDIR=$PWD hugin_executor --stitching rend.pto


--Sean

[Michael Havens]

thanks shawn.... I really appreciate that!

[Michael Havens]

Sean, would I need to enter that whenever I do a big pano?

Or is that the, enter once and your good until the os crashes, thing?

[Michael Havens]

On Wednesday, September 14, 2016 at 4:19:15 PM UTC-4, Michael Havens wrote:

Sean, would I need to enter that whenever I do a big pano?

Or is that the, enter once and your good until the os crashes, thing?

I run linux the os never needs to be reinstalled! More like, you're good until you need to replace the computer! 

[Michael Havens]

$  TMPDIR=$PWD hugin_executor --stitching rend.pto could not open script : /home/bmike1/hugintmp/rend.pto

On Wednesday, September 14, 2016 at 3:29:17 PM UTC-4, Sean Greenslade wrote:

[Michael Havens]

Then I tried it from the directory  the pano is in but the results were the same (with the current directory).

[Gnome Nomad]

Hmm, I've used Hugin on Linux for years now and it has NEVER attempted to do anything in root. It has always written temp files to /tmp, and remapped images to the folder containing the pto file.

On Wed, Sep 14, 2016, 10:53 Michael Havens <havens....@gmail.com> wrote:

Then I tried it from the directory  the pano is in but the results were the same (with the current directory).

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/1836f6b3-3b6a-41a9-a9ed-4042ac3b8247%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sean Greenslade]

On Wed, Sep 14, 2016 at 01:37:31PM -0700, Michael Havens wrote:
> $ TMPDIR=$PWD hugin_executor --stitching rend.pto could not open script :
> /home/bmike1/hugintmp/rend.pto

This was just an example, clearly you'll need to modify the line to run
your specific job. See the hugin_executor man page for details on its
arguments.

The way I've shown here, the environment variable is only set for that
command invocation. If you would like to set it more permanently, add it
to your shell init (e.g. ~/.bashrc for bash).

--Sean

[Sean Greenslade]

On Wed, Sep 14, 2016 at 10:22:56PM +0000, Gnome Nomad wrote:
> Hmm, I've used Hugin on Linux for years now and it has NEVER attempted to
> do anything in root. It has always written temp files to /tmp, and remapped
> images to the folder containing the pto file.

I'm assuming the OP doesn't have /tmp mounted specially, so anything
that goes into /tmp is going onto the root filesystem. I know some
distros behave this way. IIRC, Fedora made /var/tmp a ramdisk but left
/tmp a normal dir.

--Sean

[Gnome Nomad]

I don't have /tmp mounted specially - just however Debian set things up. Perhaps OP tweaked their setup. I can't imagine any Linux distro would ever point a tmp folder at the root.

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20160914222506.GB4487%40coach.home.

[Greg 'groggy' Lehey]

I'll summarize a number of issues. First, terminology. You mean the
root file system, not "in root". That confused me at first.

This would suggest that you have used up nearly 8 GB of storage for
your panorama. That seems excessive. Is it really that big?

On Wednesday, 14 September 2016 at 11:52:06 -0700, Michael Havens wrote:
> My feeling is that te working directory ought to be a setting.

Agreed entirely. And it is, at least in the version I'm using
(2016.2.0 RC1). Go to preferences/file names and it's at the top of
the window. A good setting would be /var/tmp, assuming that it's on
an appropriate disk.

On Wednesday, 14 September 2016 at 13:21:40 -0700, Michael Havens wrote:
>
> I run linux the os never needs to be reinstalled! More like, you're
> good until you need to replace the computer!

Linux does have updates, and for security's sake you should install
them.

On Wednesday, 14 September 2016 at 22:40:34 +0000, Gnome Nomad wrote:
> I don't have /tmp mounted specially - just however Debian set things up.
> Perhaps OP tweaked their setup. I can't imagine any Linux distro would ever
> point a tmp folder at the root.

My (not quite up-to-date) Ubuntu has the /tmp directory in the root
file system. /var/tmp is there too. Looking at a recent Debian
system, I see:

$ df /tmp /var/tmp
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/sys-tmp 4566 13 4299 1% /tmp
/dev/mapper/sys-var 46803 21771 22633 50% /var

In other words, they're both in their own file system.

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

[Sean Greenslade]

On Thu, Sep 15, 2016 at 09:56:08AM +1000, Greg 'groggy' Lehey wrote:
> On Wednesday, 14 September 2016 at 11:47:18 -0700, Michael Havens wrote:
> > FYI- I killed hugin with the notice that I was running out of space and:
> > $ df /
> > Filesystem 1K-blocks Used Available Use% Mounted on
> > /dev/sdb1 23638908 14634544 7780532 66% /
>
> This would suggest that you have used up nearly 8 GB of storage for
> your panorama. That seems excessive. Is it really that big?

That's not an unreasonable number. Hugin uses uncompressed TIFFs as
intermediary files, so a full sphere at normal SLR focal lengths could
have 30-60 intermediary files. Even more if you do exposure stacks. I
routinely exceeded my 16 GiB of RAM doing 30000x15000 px 3-stack blends.

--Sean

[Greg 'groggy' Lehey]

Yes, but this isn't the sort of thing you do when you start off. I've
just checked and discovered two things:

1. On a 15136x7568 pano with 20 components (the largest I do), the
intermediate files took up 550 MB. It's not clear that your
intermediate files are larger, since there are more of them, but
that could easily mean 2 GB in your scenario.

During stitching, the enblend image grew to about 8 GB, and I
could easily see you heading over the 16 GB in your scenario. But
that's (virtual) memory, not disk space.

At the end of stitching, total disk space (intermediate and final
image) grew to about 800 GB.

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.

[John Muccigrosso]

On Wednesday, September 14, 2016 at 2:43:17 PM UTC-4, Michael Havens wrote:

I am trying to create a 360X180 panorama. As it stitches the images together though it runs out of room. Root in this system is finite. /home in this system is enormous. Why does hugin stitch things together in / rather than /home. How do I get around this problem?

In OS X, the current temp dir can be found at $TMPDIR. So at the command line `echo $TMPDIR` will show it. In El Capitan that's normally somewhere in /var land. For example right now for me it's `/var/folders/yl/xd3tsv2x1959s23ts4k1qt9m0000gr/T/`. In my scripts I use this and then let the system sort it out if I leave files in there (which I try not to when they're really big as with Hugin).

[Greg 'groggy' Lehey]

On Friday, 16 September 2016 at 19:39:48 -0700, Michael Havens wrote:
> 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!

I don't know many root directories that big.

We (mainly Sean Greenslade and I) discussed this, but the only firm
conclusion was that normally nothing gets written to the temporary
directory. That's why I asked you:

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.

On Friday, 16 September 2016 at 17:42:03 +1000, Greg 'groggy' Lehey wrote:
>
> 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.

The fact is that you *have* managed to fill up your root directory,
and so far we have no explanation for it. It's not beyond the bounds
of possibility that you have another bug here.