[Hugin-devs] [Bug 683698] Re: error during stitching
** Changed in: hugin Status: New = Incomplete -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/683698 Title: error during stitching Status in Hugin - Panorama Tools GUI: Incomplete Bug description: OS: windows 7 64bit, Chinese version Hugin: 2010.4.0.95c7c055a9d9 Everything is ok, the Fast Preview is OK too, but when I try to stitch the final photo, got the following error: --- process_begin: CreateProcess(NULL, echo ===, ...) failed. make (e=2): ?? --- ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 679946] Re: ONE number of cotrol points 2 b added
That setting is for the assistant, not for the images tab. Wishlist item: Make these the same anyway. Users expect it. ** Changed in: hugin Status: New = Triaged ** Changed in: hugin Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/679946 Title: ONE number of cotrol points 2 b added Status in Hugin - Panorama Tools GUI: Triaged Bug description: the default number of control points that are added (in the form in the images tab) should be the number which is given in hugin settings, no? (now it's not) ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 679855] Re: Hugin should include control point errors in pto files
I agree, Saving the control point accuracy can benefit some automatic processing. ** Changed in: hugin Importance: Undecided = Wishlist ** Changed in: hugin Status: New = Triaged -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/679855 Title: Hugin should include control point errors in pto files Status in Hugin - Panorama Tools GUI: Triaged Bug description: It would be nice if hugin and autooptimiser would include 'C' lines that give the control point errors after optimization. It is useful information to have in postprocessing to determine which control points to prune by other software and shouldn't make a difference to other programs since PTOptimizer already does this. It would also be useful in that when hugin reloads a PTO file, it would have all the distances already available. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 679854] Re: Multiple Images, same control point
Having different modes to indicate control points would be good. The exact way to implement this has not yet been fixed: What I would suggest is less of a change I think: If you click on a point in the preview (in cp mode) with the control point tab selected it will (try to) add the controlpoint for all images that overlap at that point. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/679854 Title: Multiple Images, same control point Status in Hugin - Panorama Tools GUI: New Bug description: When shooting a large panorama, it's good practice to have fairly large overlap. This means that a given point can appear in 3 or more frames. It would be helpful to be able to be able to a control point that can span all relevant frames, instead of just two of them. This might also be very helpful in figuring out the 3d relationships between points in a panorama, and dealing with camera shift resulting from differing distance from the lens. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 678946] Re: nona: bad allocation with high-resolution panorama
Ad's pano is 0.8 Gigapixels and crashes with a bad alloc on nona, while mine is 0.5 Gpixels, and crashes at the enblend step Bug #685105 . (he's on windows, I use Linux). -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/678946 Title: nona: bad allocation with high-resolution panorama Status in Hugin - Panorama Tools GUI: Confirmed Bug description: Received error message: D:\hugintest\hugin_0.7.0.3113\bin\nona -z PACKBITS -r ldr -m TIFF_m -o sp -i 0 C:\Users\ADHUIK~1\AppData\Local\Temp\hug70AA.tmp caught exception: bad allocation make: *** [sp.tif] Error 1 And a request to report. I tried to run speedtest.pts which outputs 80713*15850 pixel image based on 337 input images, see http://hdview.at/speedtest/index.html. Probably because I only have 2GB of RAM ... My Quad Core 2,4 GHz took over seven hours to create a 4*7855 imagefile from the same speedtest.pts. This is rather slow compared to other software, see resultspage of test: http://hdview.at/speedtest/results.html Now is time for compliments: I like Hugin, I'm using it for at least two years. I'm really impressed by the development of new features in the last year (enfuse!) and just want to say: keep up the good work. Ad Huikeshoven The Hague (aka Dedalus) ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 684826] Re: icpfind reports progress every 250 cross matches.
Tomas, Currently the progress reporting is already much better than before: previously autopano-sift would update the gui continuously and the text output only every now and then. This resulted in lots of CPU time wasted for updating the screen, which could have better been used in working on finding my control points. So, yes, it's quite reasonable, and works fine today. So it's a wishlist item. The thing is, if my computer becomes 10 times faster, it will be updating the screen faster than I can see. That's useless. And even if it is only spending 5% of the time updating the screen, it could become 5% faster on a large pano a few years from now. That's why I suggest to use a time-based update frequency and not a work progress. If we turn it around. Suppose I were to run this on a 100 times slower computer (a 486). It would update at most only twice a minute. This leaves the user in the dark about the progress much too long. So the current every 250 checks works reasonable on reasonably modern hardware. But we can't say anything about the hardware from 10 years ago, or 10 years from now. I would prefer to change the software now to be future proof. ** Tags added: cpfind ** Tags removed: icpfind -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/684826 Title: icpfind reports progress every 250 cross matches. Status in Hugin - Panorama Tools GUI: Triaged Bug description: This is just fine for my current projects. For small projects it might update slightly too fast (too much useless overhead in painting the screen) while for a large project it goes a bit slowly. This means that it depends on the size of the project how fast the updates come. But most of all the updates depend on how fast my CPU is. To make the software future proof, we should make it for example: - set a timer to go off twice a second. - in the timer set a flag. - in the mainloop (e.g. every 1, 10 or 50 matches) check for the flag and print the progress if set. Reset flag. (this is the most sure-fire way to prevent IO concurrency problems. ). ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 684749] Re: makefile generation problems
It seems it depends on something I don't have under control. I just tried 4 times to reproduce this, and it didn't happen. (but I didn't report it the first time it happened. I only reported it when it happened to me again!) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/684749 Title: makefile generation problems Status in Hugin - Panorama Tools GUI: Triaged Bug description: I started a new project, and then went through the assistant up to align. Next I switch to the stitcher tab, and click stitch now. This results in: no way to make target dest.tif needed for target all . Ticking and unticking exposure corrected LDR as remapped output to keep results in the makefile being updated apparently, because restarting the stitch now works This seems to be quite common: I've seen this two or three times while testing 2010.4 beta. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 684859] Re: Nona phase should use all CPUs on big stitch
P.S. And in this case, it's fine to have nona NOT use multiple CPUs. Let make handle the parallelism. - Also a wishlist item for nona: option not to use MP. (if not already, couldn't find it...). -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/684859 Title: Nona phase should use all CPUs on big stitch Status in Hugin - Panorama Tools GUI: Triaged Bug description: Although nona is said to use all available CPUs, my CPU graph shows otherwise. The issue is that when i'm working on a big project (where i'd expect the multi-cpu to be extra useful), the images are downscaled significantly. Thus the phase that nona executes multi-cpu is short. The single-threaded pre and post processing take up about half the time. As I have plenty of memory I'd gladly tell make to start two or three concurrent nona processes to keep my CPU busy. Suggestion: preference setting: how many nona processes should run concurrently ? ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685224] [NEW] save / load CP generator settings doesn't work
Public bug reported: Applies to Harry's new beta2 of Hugin-2010.4.0 bundle as of 4 Dec 2010. - clicking Export in Prefs - CP Detectors if no entry is selected opens a file dialog that assumes that a setting could be exported. Instead, the Export button should be greyed if no entry is selected - the 'Export' file dialog doesn't add the necessary '.setting' to a file name. This extension is needed for the 'import' file dialog to accept a file. Furthermore it might make sense to automatically use the description of the actual setting to name the settings file together with a date/time stamp, e.g. cpfind-101204-1721.settings - Exported settings files are empty, so nothing will be imported yet (I also opened an exported .setting file with a text editor to make sure it's really empty). - What will happen if I import a settings file with the same description (but different arguments) I already have in my prefs? Do I get the chance to rename it (favoured) or will it overwrite an existing setting (bad)? ** Affects: hugin Importance: Undecided Status: New -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/685224 Title: save / load CP generator settings doesn't work Status in Hugin - Panorama Tools GUI: New Bug description: Applies to Harry's new beta2 of Hugin-2010.4.0 bundle as of 4 Dec 2010. - clicking Export in Prefs - CP Detectors if no entry is selected opens a file dialog that assumes that a setting could be exported. Instead, the Export button should be greyed if no entry is selected - the 'Export' file dialog doesn't add the necessary '.setting' to a file name. This extension is needed for the 'import' file dialog to accept a file. Furthermore it might make sense to automatically use the description of the actual setting to name the settings file together with a date/time stamp, e.g. cpfind-101204-1721.settings - Exported settings files are empty, so nothing will be imported yet (I also opened an exported .setting file with a text editor to make sure it's really empty). - What will happen if I import a settings file with the same description (but different arguments) I already have in my prefs? Do I get the chance to rename it (favoured) or will it overwrite an existing setting (bad)? ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 678933] Re: decimal precision
** Changed in: hugin Status: Incomplete = Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/678933 Title: decimal precision Status in Hugin - Panorama Tools GUI: Fix Released Bug description: SVN3245 Windows XP in the camera and lens tab, the values for hfov, a, b, c, d, e and potentially g, t don't show the full precision number even when there is enough space. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 678926] Re: remapping of single HDR image
** Changed in: hugin Status: Incomplete = Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/678926 Title: remapping of single HDR image Status in Hugin - Panorama Tools GUI: Fix Released Bug description: SVN3245, Windows XP. * Load a single HDR image in the Images tab * In the stitcher tab, select only remapped images as output * Set File Format to EXR for both Normal and HDR output * click Stich now! the resulting file has the extension .TIF and not the expected .EXR Also the use of Normal to qualify the Output and File formats on the dialog is quite confusing in this case where the input file is a single HDR rather than a single LDR or a stack of LDRs. After the string freeze is lifted, I would suggest to use the following terminology in the Output section in the Stitcher tab: Single Exposure instead of Normal Merge Exposures to HDR instead of Merge to HDR For the File Formats, I am not sure if we need the HDR Output field when not blending. Replacing Normal Output with Single Exposure Output will make it applicable also to EXR, and correcting the extension under which it is saved would be the icing on the cake. Is there a reason why hugin currently only saves in EXR format and not in radiance HDR? ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 678890] Re: photometric optimisation seems to ignore image settings
** Tags added: crash optimizer photometric -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/678890 Title: photometric optimisation seems to ignore image settings Status in Hugin - Panorama Tools GUI: Confirmed Bug description: concerns: hugin 0.7.0.3113 I don't know if this is a bug or not. Maybe it's not, maybe it's several bugs: Try to run a photometric optimisation of a given panorama with various luminous range ie: the sun is present in the panorama and is 'degradding' it. 1- If you uncheck all option and runs the optimisation, the photometric values will change... I may be wrong, but photometrics values should not change if no settings is checked... 2- If you try to optimize all images except a given few images: The optimizer will ignore your settings and will optimizes all images... If you need a few images showing the problem, I can upload them somewhere. Anyway, it's not specific to images but generic to any photometric optimization ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 678891] Re: SVN: Window with error of autopano exceeds screen size
** Tags added: errormessage usability -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/678891 Title: SVN: Window with error of autopano exceeds screen size Status in Hugin - Panorama Tools GUI: Triaged Bug description: When autopano (called manually from Hugin, tab Images) fails, hugin informs about such event in a pop-up window that lists the original command and the error. If there is a lot of input files, the window may be taller than the screen. As a result, it is impossible to read the error. The window should be resizeable or having scroll functionality. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 678889] Re: recropping does not 'auto update' in preview
Wow..- I commented on this one and I don't recall if it is the old preview or the fast preview? currently we need the old preview because the fast one still can't display HDR images, but sooner or later we'll hopefully get rid of the old preview ** Tags added: preview -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/678889 Title: recropping does not 'auto update' in preview Status in Hugin - Panorama Tools GUI: Confirmed Bug description: Tested with hugin 0.7.0.3113 (windows). I observed this since a while. If you change the settings to crop the resulting panorama, the preview will not update itself, even if the auto button is selected. How to reproduce: * open a panorama. * open the preview window. * crop the panorama, it won't update unless 'update the preview' is pressed. Note: Imo, Minor bug if it is not a feature(I don't know actually, this looks a bug for me, but I could be wrong.) ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685224] Re: save / load CP generator settings doesn't work
- Export saves all cp detector settings, not only the selected one (therefore point 1 and 4 are invalid) - The missing extension is fixed in repository. - I can not reproduce the empty setting file (on windows it is correctly saved). I added a Flush to explicitly save it. This hopefully fixes the issue, but I can not test. ** Changed in: hugin Status: New = Triaged -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/685224 Title: save / load CP generator settings doesn't work Status in Hugin - Panorama Tools GUI: Triaged Bug description: Applies to Harry's new beta2 of Hugin-2010.4.0 bundle as of 4 Dec 2010. - clicking Export in Prefs - CP Detectors if no entry is selected opens a file dialog that assumes that a setting could be exported. Instead, the Export button should be greyed if no entry is selected - the 'Export' file dialog doesn't add the necessary '.setting' to a file name. This extension is needed for the 'import' file dialog to accept a file. Furthermore it might make sense to automatically use the description of the actual setting to name the settings file together with a date/time stamp, e.g. cpfind-101204-1721.settings - Exported settings files are empty, so nothing will be imported yet (I also opened an exported .setting file with a text editor to make sure it's really empty). - What will happen if I import a settings file with the same description (but different arguments) I already have in my prefs? Do I get the chance to rename it (favoured) or will it overwrite an existing setting (bad)? ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 684859] Re: Nona phase should use all CPUs on big stitch
The first can be achieved by setting MAKEFLAGS=-j 2 or higher. The second one is also already possible: run nona with -t 1 See description in the help on panotools: http://wiki.panotools.org/Panorama_scripting_in_a_nutshell#Parallel_make -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/684859 Title: Nona phase should use all CPUs on big stitch Status in Hugin - Panorama Tools GUI: Triaged Bug description: Although nona is said to use all available CPUs, my CPU graph shows otherwise. The issue is that when i'm working on a big project (where i'd expect the multi-cpu to be extra useful), the images are downscaled significantly. Thus the phase that nona executes multi-cpu is short. The single-threaded pre and post processing take up about half the time. As I have plenty of memory I'd gladly tell make to start two or three concurrent nona processes to keep my CPU busy. Suggestion: preference setting: how many nona processes should run concurrently ? ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 679847] Re: Rubber-sheeting, Orthorectification, geo-rectified: kite pic
Just don't optimize the parameters of the fixed photograph. Should be quite doable with the new xyz displacements. ** Changed in: hugin Importance: Undecided = Low ** Changed in: hugin Status: New = Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/679847 Title: Rubber-sheeting, Orthorectification, geo-rectified: kite pic Status in Hugin - Panorama Tools GUI: Fix Released Bug description: overlaying of aerial kite photography in Google Earth/World Wind. Here is a website explaining the painful process in order to kinda do this using hugin. http://bruceowen.com/kap/kap.htm At the very least, if you could add rubber-sheeting to hugin that would be so helpful!!! Or be able to add a pic that can not be distorted and the other pics must match up to the master pic. Thanks -Mike ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
