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
diff -r 0c30b3184a2f src/hugin_base/algorithms/panorama_makefile/PanoramaMakefilelibExport.cpp
--- a/src/hugin_base/algorithms/panorama_makefile/PanoramaMakefilelibExport.cpp Sat Nov 20 15:02:50 2010 +0100
+++ b/src/hugin_base/algorithms/panorama_makefile/PanoramaMakefilelibExport.cpp Sat Nov 20 21:52:05 2010 -0500
@@ -354,7 +354,7 @@
mgr.own_add(new Comment("the output panorama"));
newVarDef(vldrremappedprefix,
- "LDR_REMAPPED_PREFIX", outputPrefix, Makefile::MAKE);
+ "LDR_REMAPPED_PREFIX", outputPrefix + "_", Makefile::MAKE);
newVarDef(vldrremappedprefixshell,
"LDR_REMAPPED_PREFIX_SHELL", vldrremappedprefix->getValue(), Makefile::SHELL);
@@ -410,9 +410,21 @@
for (UIntSet::const_iterator it = images.begin(); it != images.end(); it++)
{
std::ostringstream fn1, fn2, fn3;
- fn1 << outputPrefix << std::setfill('0') << std::setw(4) << *it << ldrRemappedExt;
- fn2 << outputPrefix << "_hdr_" << std::setfill('0') << std::setw(4) << *it << hdrRemappedExt;
- fn3 << outputPrefix << "_hdr_" << std::setfill('0') << std::setw(4) << *it << hdrgrayRemappedExt;
+// TODO: I wish I could check on the preference naming convention directly
+// bool t = (wxConfigBase::Get()->Read(wxT("ProjectNamingConvention"), HUGIN_PROJECT_NAMING_CONVENTION) != 0);
+// if(t){
+
+// disabled dirty hack: if project folder = output prefix, use new naming convention, else use old one
+// if(outputPrefix == hugin_utils::getFolder(pano.getImage(0).getFilename()).c_str()){
+ fn1 << outputPrefix << "_" << stripExtension(stripPath(pano.getImage(*it).getFilename())).c_str() << "_" << std::setfill('0') << std::setw(4) << *it << ldrRemappedExt;
+ fn2 << outputPrefix << "_hdr_" << stripExtension(stripPath(pano.getImage(*it).getFilename())).c_str() << "_" << std::setfill('0') << std::setw(4) << *it << hdrRemappedExt;
+ fn3 << outputPrefix << "_hdr_" << stripExtension(stripPath(pano.getImage(*it).getFilename())).c_str() << "_" << std::setfill('0') << std::setw(4) << *it << hdrgrayRemappedExt;
+// }else{
+// old naming convention
+// fn1 << outputPrefix << std::setfill('0') << std::setw(4) << *it << ldrRemappedExt;
+// fn2 << outputPrefix << "_hdr_" << std::setfill('0') << std::setw(4) << *it << hdrRemappedExt;
+// fn3 << outputPrefix << "_hdr_" << std::setfill('0') << std::setw(4) << *it << hdrgrayRemappedExt;
+// }
remappedImages.push_back(fn1.str());
remappedHDRImages.push_back(fn2.str());
remappedHDRgrayImages.push_back(fn3.str());
@@ -772,8 +784,8 @@
ruleldr->addCommand(
vnona->getRef() +" "+ vnonaopts->getRef() +" "+ vnonaldr->getRef()
+ " -r ldr -m " + ldrRemappedMode + " -o " + vldrremappedprefixshell->getRef() +
+ + stripExtension(stripPath(pano.getImage(*it).getFilename())).c_str() + "_" +
" -i " + imgnr.str() +" "+ vprojectfileshell->getRef());
-
// hdr part
Rule* rulehdr = mgr.own(new Rule()); rulehdr->add();
rulehdr->addTarget(Makefile::quote(remappedHDRImages[i], Makefile::MAKE));
@@ -781,7 +793,9 @@
rulehdr->addPrereq(vprojectfile);
rulehdr->addCommand(
vnona->getRef() +" "+ vnonaopts->getRef() +" -r hdr -m " + hdrRemappedMode + " -o " +
- vhdrstackremappedprefixshell->getRef() + " -i " + imgnr.str() +" "+ vprojectfileshell->getRef());
+ vhdrstackremappedprefixshell->getRef() +
+ stripExtension(stripPath(pano.getImage(*it).getFilename())).c_str() + "_" +
+ " -i " + imgnr.str() +" "+ vprojectfileshell->getRef());
}
mgr.own_add(new Comment("Rules for exposure layer output"));
signature.asc
Description: This is a digitally signed message part.
