File Naming Convention (New Hugin Preference)

24 views
Skip to first unread message

Yuval Levy

unread,
Nov 17, 2010, 6:43:18 PM11/17/10
to hugi...@googlegroups.com
Hi all,

by default when saving a project file, Hugin suggest a name based on the names
of the input pictures.

picture names out of the camera are by default just sequential number and not
very meaningful.

I store all individual images related to a panorama in a single folder with a
meaningful name - e.g. if this was a panorama of the New York skyline I'd call
the folder something like NYskyline; and the project NYskyline.pto and the
resulting panorama NYskyline.tiff.

This is very personal. Others are likely to do different things. Some users
may prefer the existing naming convention, some users may like a different
naming convention all together. It's a *preference*.

For a while I maintained a local patch to automatically take the folder name
as base for the project file suggestion. Now I wrapped it in a preference
(disabled by default), so it is available to everybody without changing the
world of those who prefer how Hugin has done this so far.

The next logical step is to fix the names of the intermediate files, e.g. the
remapped images. Currently it is the project file with appended sequence
number starting with 0000. Again, that sequence number is not meaningful.
I'll want to replace it with part of the image file, then it will have a
meaning: a reference to the original image that was remapped. Will make that
part of the preference so that it won't change the expected behavior to those
who prefer how Hugin has done this so far.

Yuv

signature.asc

Luís Henrique Camargo Quiroz

unread,
Nov 17, 2010, 7:53:13 PM11/17/10
to hugi...@googlegroups.com


Em 17/11/2010 20:43, Yuval Levy escreveu:
> Hi all,
    Hi!

> by default when saving a project file, Hugin suggest a name based on the names
> of the input pictures.
>
> picture names out of the camera are by default just sequential number and not
> very meaningful.
>
> I store all individual images related to a panorama in a single folder with a
> meaningful name - e.g. if this was a panorama of the New York skyline I'd call
> the folder something like NYskyline; and the project NYskyline.pto and the
> resulting panorama NYskyline.tiff.
Me too.

> This is very personal.  Others are likely to do different things.  Some users
> may prefer the existing naming convention, some users may like a different
> naming convention all together.  It's a *preference*.
>
> For a while I maintained a local patch to automatically take the folder name
> as base for the project file suggestion.  Now I wrapped it in a preference
> (disabled by default), so it is available to everybody without changing the
> world of those who prefer how Hugin has done this so far.
Nice idea, thanks!

> The next logical step is to fix the names of the intermediate files, e.g. the
> remapped images.  Currently it is the project file with appended sequence
> number starting with 0000.  Again, that sequence number is not meaningful.  
> I'll want to replace it with part of the image file, then it will have a
> meaning: a reference to the original image that was remapped.  Will make that
> part of the preference so that it won't change the expected behavior to those
> who prefer how Hugin has done this so far.
>
> Yuv

--
Luís Henrique Camargo Quiroz - http://luishcq.tripod.com
my chant page - http://www.christusrex.org/www2/cantgreg

Lukáš Jirkovský

unread,
Nov 18, 2010, 3:49:16 AM11/18/10
to hugi...@googlegroups.com
On 18 November 2010 00:43, Yuval Levy <goo...@levy.ch> wrote:
> Hi all,
>
> by default when saving a project file, Hugin suggest a name based on the names
> of the input pictures.
>
> picture names out of the camera are by default just sequential number and not
> very meaningful.
>
> I store all individual images related to a panorama in a single folder with a
> meaningful name - e.g. if this was a panorama of the New York skyline I'd call
> the folder something like NYskyline; and the project NYskyline.pto and the
> resulting panorama NYskyline.tiff.
>
> This is very personal.  Others are likely to do different things.  Some users
> may prefer the existing naming convention, some users may like a different
> naming convention all together.  It's a *preference*.
>
> For a while I maintained a local patch to automatically take the folder name
> as base for the project file suggestion.  Now I wrapped it in a preference
> (disabled by default), so it is available to everybody without changing the
> world of those who prefer how Hugin has done this so far.

Great, I'm using almost exactly the same naming convention. I use
pano_somename for both directory name and project so this comes very
handy.

Lukas

kfj

unread,
Nov 18, 2010, 5:25:27 AM11/18/10
to hugin and other free panoramic software


On 18 Nov., 00:43, Yuval Levy <goo...@levy.ch> wrote:

> by default when saving a project file, Hugin suggest a name based on the names
> of the input pictures.
>
> picture names out of the camera are by default just sequential number and not
> very meaningful.

That is true. And using the folder as an umbrella with a meaningful
name is a great healp in organizing things. On the other hand, if the
pto file is in a folder with a meaningful name, the actual file name
might as well refer to the images it works on - it can be cryptic,
since it's location together with it's in- and output in a sensibly
named folder explains what it is. So I think the standard naming
convention isn't that problematic. It has the advantage of sorting
into the group of images. And the image file names are a kind of
umbrella themselves - I often have a RAW file, a JPG for screen and
TIFFs for stitching, all using the same base name.

> I store all individual images related to a panorama in a single folder with a
> meaningful name - e.g. if this was a panorama of the New York skyline I'd call
> the folder something like NYskyline; and the project NYskyline.pto and the
> resulting panorama NYskyline.tiff.

so I feel naming the pto and output while thy are in an aptly named
folder is redundant
(but legitimate, so option = good)
Maybe one could expand on the principle without making the coding much
more complex. How about offering a name template with a bunch of
optional placeholders which could be filled in from, say, the first
image's metadata, the enclosing folder and such?
P_<folder>_<number>.pto -> P_NYskyline_7.pto -> P_NYskyline_7.tif

> The next logical step is to fix the names of the intermediate files, e.g. the
> remapped images.  Currently it is the project file with appended sequence
> number starting with 0000.  Again, that sequence number is not meaningful.  
> I'll want to replace it with part of the image file, then it will have a
> meaning: a reference to the original image that was remapped.  Will make that
> part of the preference so that it won't change the expected behavior to those
> who prefer how Hugin has done this so far.

excellent. fully agree.

Since the topic's up, I'd like to ask for a small feature. What annoys
me is that the project file's name isn't automatically chosen or
proposed as the base name for the output images. Maybe I'm doing
something wrong, but to work around the issue, I usually copy the
project basename to the clipboard when saving it and paste it into the
name entry field when stitching, since that comes up blank. Since
you're at it, maybe you could make the project name, be it meaningful
or image-derived, pop up as default in the name entry field? That'd be
a great help, because often I plain forget to copy it, so I don't have
anything to paste, have to backtrack or use the shell or such to find
somewhere where I can copy the project file's name, which is, per
default, something cryptic like IMG_1234-IMG_1235.pto. The batch
stitcher automatically takes the project file's base name for the
output, and I'd like to see that behaviour also in the 'stitch now'
workflow!

with regards
Kay

Rogier Wolff

unread,
Nov 18, 2010, 6:07:46 AM11/18/10
to hugi...@googlegroups.com

On Wed, Nov 17, 2010 at 06:43:18PM -0500, Yuval Levy wrote:

> This is very personal. Others are likely to do different things.
> Some users may prefer the existing naming convention, some users may
> like a different naming convention all together. It's a
> *preference*.

> For a while I maintained a local patch to automatically take the
> folder name as base for the project file suggestion. Now I wrapped
> it in a preference (disabled by default), so it is available to
> everybody without changing the world of those who prefer how Hugin
> has done this so far.

So while by default the name of the project is:

%F-%L.pto

you are now allowed to set it to

%D.pto

? That'd be great! (%F is first image name, %L last image name, %D:
directory name).

> The next logical step is to fix the names of the intermediate files,
> e.g. the remapped images. Currently it is the project file with
> appended sequence number starting with 0000. Again, that sequence
> number is not meaningful. I'll want to replace it with part of the
> image file, then it will have a meaning: a reference to the original
> image that was remapped. Will make that part of the preference so
> that it won't change the expected behavior to those who prefer how
> Hugin has done this so far.

This doesn't sound so neccesary to me. But then again I don't end up
editing the intermediate files in my workflow.

Same suggestion.... :-) (i.e. now the "intermediate filename is
%D%I.tif (destination filename/index) and would now be (remapped_%s or
%D_%s as required). (%s = source filename.)

Roger.

--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

Yuval Levy

unread,
Nov 18, 2010, 8:11:24 AM11/18/10
to hugi...@googlegroups.com
Thanks all for the positive feedback. If we find later down the line that more
users prefer another convention, changing the default is easy. But not for
the upcoming release.


On November 18, 2010 06:07:46 am Rogier Wolff wrote:
> Same suggestion.... :-) (i.e. now the "intermediate filename is
> %D%I.tif (destination filename/index) and would now be (remapped_%s or
> %D_%s as required). (%s = source filename.)

already started on this, but then came curfew time. hopefully I'll find some
time in the coming days.


On November 18, 2010 05:25:27 am kfj wrote:
> Maybe one could expand on the principle without making the coding much
> more complex. How about offering a name template with a bunch of
> optional placeholders which could be filled in from, say, the first
> image's metadata, the enclosing folder and such?
> P_<folder>_<number>.pto -> P_NYskyline_7.pto -> P_NYskyline_7.tif

Thought of it. We already have some code and a syntax that can probably be
reused in the codebase (the CP generators options). A good idea for after
2010.4


> Since the topic's up, I'd like to ask for a small feature.

Eran Tromer contributed exactly that feature recently. Will be in 2010.4.


> The batch
> stitcher automatically takes the project file's base name for the
> output, and I'd like to see that behaviour also in the 'stitch now'
> workflow!

I have not looked at the batch stitcher yet. The 'stitch now' behavior is
that it starts the prefix entry pre-populated. If you want to skip editing the
pre-fix, we can probably make it into a preference too.

To be perfectly honest: I never used the batch stitcher beyond a few simple
tests during the GSoC project. I run the batch stuff on the command line.
Most often on a headless server. Before Thomas' work on it the batcher lacked
the feature I need most: automatically generate projects from a bunch of
pics. In my scheme of things, the next option/preference to be introduced is
for the batcher to move related images / found projects into individual
subfolders. My naming convention for that would be
%Y%m%d<USER_ENTERED_MEANINGFUL_NAME_FOR_THE_BATCH>%i (%i being an incremental
counter, the rest is self-explanatory). But it is very low priority for me
because my server-side process works well. I do see an advantage to transfer
this task to the GUI since I open the generated projects at least once for
quality control / fine tuning, and the batch stitcher has a button just for
that. I'll have to look into it, and it won't happen any time soon.

Yuv

signature.asc

kfj

unread,
Nov 18, 2010, 8:35:01 AM11/18/10
to hugin and other free panoramic software


On 18 Nov., 14:11, Yuval Levy <goo...@levy.ch> wrote:

> The 'stitch now' behavior is
> that it starts the prefix entry pre-populated.

I beg to differ. If I call 'stitch now', the prefix entry is
unpopulated (like, empty) - and it's been so ever since I've been
using hugin. Maybe I'm doing something wrong, maybe it's just my
version (Pre-Release 2010.3.0.17d7a29f6f95, self-built), if so, please
disregard my complaint. This is probably a good moment to go for the
current 'bleeding edge'...

with regards
Kay

Yuval Levy

unread,
Nov 18, 2010, 8:46:09 AM11/18/10
to hugi...@googlegroups.com
On November 18, 2010 08:35:01 am kfj wrote:
> This is probably a good moment to go for the
> current 'bleeding edge'...

indeed it is [0], committed 17 hours ago and for a while still the utmost
bleeding edge.

Unless I state something different, I always refer to the bleeding edge with my
comments.

Yuv


[0] http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/rev/444152333fbc

signature.asc

bruno.postle

unread,
Nov 18, 2010, 9:00:20 AM11/18/10
to hugin and other free panoramic software


On Nov 18, 11:07 am, Rogier Wolff <rew-googlegro...@BitWizard.nl>
wrote:
> ** R.E.Wo...@BitWizard.nl **http://www.BitWizard.nl/** +31-15-2600998 **

bruno.postle

unread,
Nov 18, 2010, 9:26:46 AM11/18/10
to hugin and other free panoramic software
On Nov 18, 11:07 am, Rogier Wolff <rew-googlegro...@BitWizard.nl>
wrote:

> Same suggestion.... :-) (i.e. now the "intermediate filename is
> %D%I.tif (destination filename/index) and would now be (remapped_%s or
> %D_%s as required). (%s = source filename.)

It's not quite as simple as that, photos in a project can have the
same name but be in different folders, or a single photo can be used
multiple times in a project (yes this is useful).

--
Bruno

Aron H

unread,
Nov 18, 2010, 10:08:52 AM11/18/10
to hugin and other free panoramic software
I wanted to throw this into the mix: I'm using the remapped photo
capability of nona to generate the 6 faces of a cube panorama. This
has been mentioned, and partly documented before, but as part of this
process it would be useful to directly control the naming and type of
the output files of nona. I would like png, not tiff, and to get an
index with 1 digit. Renaming the files after the fact isn't hard, but
format type control would be great. (Unless I missed it?)
Aron

kfj

unread,
Nov 18, 2010, 10:27:58 AM11/18/10
to hugin and other free panoramic software


On 18 Nov., 14:46, Yuval Levy <goo...@levy.ch> wrote:

> indeed it is [0], committed 17 hours ago and for a while still the utmost
> bleeding edge.
>
> Unless I state something different, I always refer to the bleeding edge with my
> comments.

[gulp] - just swallowed my words ;-)
bleeding edge up and running, sorry for the noise, my secret wishes
were yet again fulfilled before I expressed them. If I'm not mistaken,
some libraries were moved around? I couldn't at first do

kfj@Anja:~/src/hugin/hugin.hg-build$ sudo dpkg -i hugin-*-Linux.deb

because

...
dpkg: Fehler beim Bearbeiten von hugin-2010.3.0-Linux.deb (--install):
Kann »/usr/local/lib/hugin/liblocalfeatures.so.0.0.dpkg-new« nicht
anlegen (während der Verarbeitung von »./usr/local/lib/hugin/
liblocalfeatures.so.0.0«): No such file or directory

so had to

kfj@Anja:~/src/hugin/hugin.hg-build$ sudo mkdir /usr/local/lib/hugin

then the moving of some of the libraries to the new location broke my
panomatic which couldn't find liblocalfeatures.so anymore, but it came
round after a configure-make-make install cycle.

with regards
Kay

Yuval Levy

unread,
Nov 20, 2010, 10:27:02 PM11/20/10
to hugi...@googlegroups.com
On November 18, 2010 10:27:58 am kfj wrote:
> sorry for the noise

don't be sorry. your way of making noise is
* respectful: you are not assuming that you are right and the other party is
wrong
* personal: you relate your personal experience and don't expect that
everybody feels the same
* inquisitive: you try to understand why your view differs from the status quo
before you try to change the status quo to suit your views
* useful: in the end you move forward and often you help moving the project
forward too


> dpkg: Fehler beim Bearbeiten von hugin-2010.3.0-Linux.deb (--install):
> Kann »/usr/local/lib/hugin/liblocalfeatures.so.0.0.dpkg-new« nicht
> anlegen (während der Verarbeitung von »./usr/local/lib/hugin/
> liblocalfeatures.so.0.0«): No such file or directory

this is a problem of the CMake version shipped in Ubuntu 10.10 and documented
at [0], coupled with the recent change in libraries location that requires
this extra folder.


> kfj@Anja:~/src/hugin/hugin.hg-build$ sudo mkdir /usr/local/lib/hugin

Bob Bright documented that already in the Wiki instructions [1]. You may have
gone through the instructions before the change and not added that extra
folder. Congratulations on being able to help yourself on this. That's the
kind of noise I like to hear from users. It means you're not far away from
becoming a contributor.

Yuv


[0] <http://wiki.panotools.org/Hugin_Compiling_Ubuntu#What.27s_New>
[1]
<http://wiki.panotools.org/wiki/index.php?title=Hugin_Compiling_Ubuntu&diff=12811&oldid=12810>

signature.asc

Yuval Levy

unread,
Nov 20, 2010, 10:27:15 PM11/20/10
to hugi...@googlegroups.com
Continuing on the naming convention. There is a diminishing utility in
changing the naming of remapped images and intermediate output stacks/layers.

The big win is already taken with the project name. The more flexible syntax
as suggested by Rogier would be the next step, but I have no time before
2010.4.

I see some utility in keeping reference to the input images in the remapped
images if those names are unique. To make sure the name of remapped images is
unique, the sequence number must be maintained.

The attached patch adds the name of the original input image to the remapped
images. It will be <PROJECT>_<IMAGE>_<SEQUENCE>. Unconditional.

I would have wanted to do this as a preference too, but within the Makefilelib
code I have no access to the preferences settings and I don't think it is a
good idea to add GUI-dependency into Makefilelib. Reminds me of an old long
standing idea of storing the preferences outside of wxWidgets so that they can
be accessed also by CLI tools.

I devised a dirty proxy but it is commented out (see patch).

And since this is not enough tested, I publish this as a patch for others to
test and play with, rather than committing to the repo. Please test,
especially with HDR projects (I don't have any such at hand at the moment).

On November 18, 2010 10:08:52 am Aron H wrote:
> I wanted to throw this into the mix: I'm using the remapped photo
> capability of nona to generate the 6 faces of a cube panorama. This
> has been mentioned, and partly documented before, but as part of this
> process it would be useful to directly control the naming and type of
> the output files of nona. I would like png, not tiff, and to get an
> index with 1 digit. Renaming the files after the fact isn't hard, but
> format type control would be great. (Unless I missed it?)

I had a similar feature request to a proprietary stitching tool before I
adopted Hugin for my workflow. It did not happen for as long as I was using
that other tool.

Some good and some bad news for you.

The good news: it is relatively easy to add what you want to the Makefile,
then run the Makefile again to produce the (newly) requested output. So no
problem on the back end.

Of course manual addition is not what you're looking for.

I've been thinking how to integrate such a wish in the GUI. My old idea is to
make the Stitcher tab into a table, with each line adding an output target.
So each line would have projection, FOV, view, etc., and for your case there
would be six added lines to the table. These lines can be easily auto-
generated with a single button. The cube faces is a special case but it is
important enough to warrant special treatment.

However the Stitcher tab is already overloaded and my thinking as evolved. I
now believe that Hugin should stop at that single task of "putting together
one image from multiple inputs" and leave the task of "extracting multiple
outputs from one image" to another dedicated app, like Panini, because in
between you're likely to want to manually edit the bitmap, e.g. to fix stitch
errors, or add a nadir logo (although adding a nadir logo could be considered
a stitch).

My current thinking is that it would be best for those two apps to share the
.pto / .pto.mk specifications and for the remapper app to add its output
targets to the .pto.mk, however I am not sure how this will work with
integrating manual image editing (read: stitch error correction) in the
process.

Another alternative is to build on Kay's work. He's writing a Python parser.
It is not far fetched to think of wrapping it in some GUI toolkit (wxPython,
to stay not too far away from Hugin) and to use it to add/generate the extra
pto files and Makefile targets.

The bottom line is that I don't think that adding this to the Hugin main GUI
app is the right way to go about solving the problem.

Yuv

outnames.patch
signature.asc

T. Modes

unread,
Nov 21, 2010, 8:20:44 AM11/21/10
to hugin and other free panoramic software
Hi Yuv,


On 21 Nov., 04:27, Yuval Levy <goo...@levy.ch> wrote:
> The attached patch adds the name of the original input image to the remapped
> images.  It will be <PROJECT>_<IMAGE>_<SEQUENCE>.  Unconditional.

The patch needs some more work.
The makefile is generated by using variables for all variable parts of
the makefile, e.g. filenames. This is broken with your patch. You
could say this is cosmetic, but this makes it harder to fix or extend
the makefile, when you put variable parts directly into the command
parts and not into variables.
More critical is that you don't quote correctly the filename. Flo has
done at lot of work to correctly quote all filenames when moving to
the new makefilelib. Your patch does not consider these points. Simply
adding a string to the variable - as your patch does - breaks the
quoting.
(Simply moving the new part into a new variable would not help,
because simply adding filename variables does not quote correctly the
final filename.)

Thomas

PS: We had recently a big substancial modification of the makefile
generation. This is now tested by the community. I'm not sure if it is
a good idea to change it again in this stage.

Yuval Levy

unread,
Nov 21, 2010, 5:09:55 PM11/21/10
to hugi...@googlegroups.com
Hi Thomas,

thanks for the feedback - and for adding the new naming convention to the
batch stitcher too!

On November 21, 2010 08:20:44 am T. Modes wrote:
> The patch needs some more work.

Yes, I knew that, and I was looking for feedback. I have also mixed feelings
about continuing working on it because it is much less important to me (and I
estimate to most users) than the name of the actual project.


> PS: We had recently a big substancial modification of the makefile
> generation. This is now tested by the community. I'm not sure if it is
> a good idea to change it again in this stage.

Agree that it is no good idea, for a number of reasons including all those you
cite. Hence a patch with a feedback request and not a commit.

Yuv

signature.asc
Reply all
Reply to author
Forward
0 new messages