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
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
> 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
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
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
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>
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
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