Re: [hugin-ptx] Automatic stitch scans of engineering drawings hopeless?
Frederic Da Vitoria wrote: 2019-02-20 9:55 UTC+01:00, bugbear : Frederic Da Vitoria wrote: I believe horizontal control points should only be used when assembling an actual landscape panorama, to mark the horizon itself. I never assembled flatbed or microscope images, but I did some mosaic mode stitches. My remark could be wrong... I use horizontal and vertical control points routinely when sitiching mosaic scans, most commonly on the straight edges of rectangles (e.g. maps). Hugin is then able to use pitch and yaw, roll to correct any perspective distortion of the stitch, as well as using X,Y,Z to perform the tesselation of the sub-images. OK, good to know. Thanks. I'll try this next time I do this type of stitch. I posted a suitable sample set (and pto file) to this list under the subject line "Mosaic mode test set" BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5C6D30E7.8000308%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Automatic stitch scans of engineering drawings hopeless?
Frederic Da Vitoria wrote: I believe horizontal control points should only be used when assembling an actual landscape panorama, to mark the horizon itself. I never assembled flatbed or microscope images, but I did some mosaic mode stitches. My remark could be wrong... I use horizontal and vertical control points routinely when sitiching mosaic scans, most commonly on the straight edges of rectangles (e.g. maps). Hugin is then able to use pitch and yaw, roll to correct any perspective distortion of the stitch, as well as using X,Y,Z to perform the tesselation of the sub-images. Optimising something with this many variables MUST (IME) be done incrementally. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5C6D15F7.8010106%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] How to stitch a map divided into 32 scans...
Edward Carnby wrote: Hi all, I've used Hugin for some time and I encounter no problem stitching old maps I scanned from libraries. They usually were divided into four or six parts. I have now to stitch a very large map of Italy divided into 32 scans (eight rows, four columns). I followed the tutorial (stitching flat scanned images) but I wasn't able to achieve a decent result. The optimizer always stitch it in a bad way. I tried to stitch some parts and than stitch them again with others but the result was pretty unacceptable because of bad alignment. Besides I have a Win 64 system and cannot install autopano sift C. Hints are appreciated. Do the sub-images overlap (like photographs) or do they tessalate edge to edge? I've done maps both ways, and can advise. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5C13840F.2080804%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: parallax error in a rig of cameras
Erik Krause wrote: Am 14.11.2018 um 17:54 schrieb giuseppe.porci...@gmail.com: I also read that some manufacterers of 360 degree cameras consisting of a number of sensors and lenses claim their included stitching software can, partially, deal with the parallax error. Seam optimization can hide the errors sometimes. The only purpose of shooting from different viewpoints is to get stereo images. Indeed. But there may be a purpose to having multiple cameras, e.g. to get full full spherical coverage at one moment. In this case the multiple viewpoints is a consequence, not a purpose. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5BED4687.8030301%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Aligning scanned PCB images.
Igor P wrote: I tried too many times, but even if i manually add control points to the two images, the output of registration/stack is incorrect. The holes are not well aligned. Can somebody try to align the images for me with some steps to do other layers correctly? I am sending the layer files link here https://files.fm/u/sbbhrtdf in attachement, also a look at how badly the results are aligned. (Holes are not matched well). OK - nerd time. Working in 1 dimension on the bottom row of holes, on the unaltered images, in Gimp, aligned left-right These are the X offsets, in pixels, of the hole centres, under zoom. L1 L6 First hole 366, 366 Last hole 3496,3496 mid hole 2117, 2125 In other words, on NON modified images, the extreme holes align, but the mid ones don't. It's a non linear scan!!! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5BB383CF.6050708%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Aligning scanned PCB images.
Igor P wrote: I tried too many times, but even if i manually add control points to the two images, the output of registration/stack is incorrect. The holes are not well aligned. Can somebody try to align the images for me with some steps to do other layers correctly? Followup - when I added carefully placed control point to the areas that visually didn't line up well (28 points in all), the project will NOT OPTIMISE well. average control point distance: 4.199018 standard deviation: 2.232713 maximum: 8.827131 This confirms my observations from aligning the two images with a small number of CPs and checking the output (layer mode in Gimp). BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5BB3811B.9000504%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Aligning scanned PCB images.
Igor P wrote: I tried too many times, but even if i manually add control points to the two images, the output of registration/stack is incorrect. The holes are not well aligned. Can somebody try to align the images for me with some steps to do other layers correctly? I am sending the layer files link here https://files.fm/u/sbbhrtdf in attachement, also a look at how badly the results are aligned. (Holes are not matched well). I believe you have a scanning error. I aligned the 2 images using 11 careful manual control points, 2 lenses, and ONLY rotate, X/Y shift and second lens focal length (AKA zoom) as optimisation parameters. Despite this simple model, along the low edge, I have perfect hole alignment at far left and far right, but poor hole alignment in the middle, very much as you did. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5BB37F15.5000309%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: incomplete lens correction model - it bites
klaus.fo...@gmail.com wrote: For the latter cases, when CPs become dodgy, hugin is good enough. It is in good cases that its limitations get apparent. Have you actually encountered these limitations? - none of your examples are anywhere near these limits; their "realworld" problems greatly exceed the theoretical limitations you've described. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5B5EC955.2040807%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: incomplete lens correction model - it bites
Erik Krause wrote: Am 26.07.2018 um 12:18 schrieb klaus.fo...@gmail.com: https://mab.to/DNe8WRQgF Entrance pupil positions should not be more than 5 millimetres apart. I managed to get this result: http://erik-krause.de/align-foehl.gif misalignment is in the magnitude of image blur in the corners. In the very corners there are no control points possible. It might improve if there where, but that's of no relevance for panorama stitching at all. The corners should be cut anyway due to lens blur. So the panotools lens correction model is able to align these images perfectly. BTW.: without using a and c the result was much, much worse. I'm slightly confused by this thread; I have no reason (or qualification!) to doubt the maths that Klaus has posted, but the examples seem to be more like normal stitching difficulties than high-falutin' mathematical ones. If the fault is as fundamental as claimed, it ought to be quite glaring. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5B5AD169.203%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Newbie question - Focal length
Daniel Md wrote: I just started using Hugin, it works great. I usually take a set of photos for landscape panoramas with my Pentax K20 using an 18-50mm zoom, set to 18mm. When I load the resulting images into Hugin, the Focal length is usually reported as something else, e.g.20.402, although the Focal length multiplier is correctly reported as 1.5x. I have confirmed the 18mm focal length from the image metadata using other tools. My question is should I correct the value displayed on the GUI? Focal length is "just a number" on the way to FOV, which is what REALLY matters. Take a quick/rough 360 pano, let hugin work out the FOV, and take it from there. Bugbear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5B5740D4.1060601%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: RAW support with hugin ?
Greg 'groggy' Lehey wrote: Note that the Unix (and thus Linux) way is to have multiple programs, each able to perform one function and perform it well. It looks like you're looking for the opposite. Agreed - making a monolith is not the Unix way. But allowing programs to work together in a convenient and efficient manner is very much the Unix way (c.f. pipelines!!). I would be interested to have Hugin able to INVOKE a separate program, with command line arguments, as an importer, in the same way that it already does for both control point detection and blending. Unix being Unix, the "external" program could in fact be a wrapper script, calling an actual program with an arbitrary command and/or list of control/parameter files. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5B45C98D.8090708%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: RAW support with hugin ?
Marcel Brouillet wrote: so merging RAW files seems to have sense to me. How (on earth) does one perform spatial interpolation on raw data that hasn't been de-mosaic'd ?! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5B436098.5060609%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Aligning scanned PCB images.
Igor P wrote: Hello, is there any imaging specialist that could help me? I need to align scanned images of PCB layers to exatly match. But the scanned images has some distortion, every image is a little stretched compared to each other and tiny bit rotated. I have experimented with hugin but i cant succesfully set it up to make as output aligned images. Is there someone who would help me with this? I wanted to overlay the component side of a (single sided) board with the track side. I needed to use 2 techniques over and above the basic mosaic mode of Hugin 1) On the component side, parallax is an issue - so take the shot from as far as you can get, using your longest lens 2) Assuming you want to view from the component side, you will need to mirror flip the track side image; Hugin cannot do this. Other than that, mosaic mode, and manual control points should do the task nicely. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5B3F2BB3.6030005%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Raw image support with hugin
David W. Jones wrote: On July 5, 2018 1:57:18 PM HST, Greg 'groggy' Lehey wrote: On Thursday, 5 July 2018 at 0:33:45 -1000, David W. Jones wrote: So when you add a bunch of RAW files to Hugin, it proceeds to popup a bunch of windows, one for each frame? No. It displays a window "Could not decode (file name). Abort". And I think that's correct. I agree that's correct. I only mentioned it to point out how tedious and annoying it would be to have Hugin do that. I hate how Gimp does it, too. So my vote is to leave RAW processing to programs designed to do that, and use Hugin for what it does that they don't. Not every program needs to do everything. Would there be any merit in supporting some kind of "meta" extension, so that an external program would be invoked to perform the conversion? All the complexity could be hidden inside the script at the user's discretion. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5B3F2117.6040009%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Improving scan quality
Toolforger wrote: Scantailor assumes a single image of each page. I need a way to have multiple images for each page to average out speckles and noise. If there are speckles on the page, averaging won't get rid of them. If there is noise in the scan, using a longer exposure will most likely eliminate it at source. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5A8A93F3.1060808%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Nona crashing on simple images
T. Modes wrote: Thanks for testing. Bugbear has send me his files. I could reproduce the crash with them. It is related to an embedded ICC profile (without ICC profile it works fine). I found the bug and fixed it in the repository. Wow - you said you would fix it "later". This is the promptest "later" I've seen in a while!!! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5A587D0A.8010009%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Nona crashing on simple images
T. Modes wrote: Am Donnerstag, 11. Januar 2018 14:06:39 UTC+1 schrieb bugbear: And found this command: nona -m TIFF_multilayer -o multi_layer.tif project.pto I ran it, and got a Segmentation fault (core dumped) This is not reproducible here. The stack trace show that it crashes during saving. The multilayer output works fine here. Can you provide the pto file? Attached. It's trivial! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5A578DCD.7030102%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout. # hugin project file #hugin_ptoversion 2 p f2 w3000 h2633 v16 k1 E0 R0 S159,2858,300,2243 n"TIFF_m c:LZW r:CROP" m g1 i0 f0 m2 p0.00784314 # image lines #-hugin cropFactor=1 i w923 h306 f0 v10.018052996583 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX-0.0296358981454483 TrY0.0016130258085403 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 Vm5 n"mere_sq.jpg" #-hugin cropFactor=1 i w870 h546 f0 v10.5421091543524 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 Vm5 n"valentine.jpg" # specify variables that should be optimized v v0 v Ra0 v Rb0 v Rc0 v Rd0 v Re0 v Eev0 v TrX0 v TrY0 v Vb0 v Vc0 v Vd0 v Ra1 v Rb1 v Rc1 v Rd1 v Re1 v Vb1 v Vc1 v Vd1 v # control points c n0 N1 x193.8 y97.92 X56 Y223 t0 c n0 N1 x625 y120 X442 Y251 t0 c n0 N1 x450 y126 X261 Y265 t0 #hugin_optimizeReferenceImage 1 #hugin_blender internal #hugin_remapper nona #hugin_enblendOptions -m 3500 #hugin_enfuseOptions #hugin_hdrmergeOptions -m avg -c #hugin_verdandiOptions #hugin_outputLDRBlended true #hugin_outputLDRLayers true #hugin_outputLDRExposureRemapped false #hugin_outputLDRExposureLayers false #hugin_outputLDRExposureBlended false #hugin_outputLDRStacks false #hugin_outputLDRExposureLayersFused false #hugin_outputHDRBlended false #hugin_outputHDRLayers false #hugin_outputHDRStacks false #hugin_outputLayersCompression LZW #hugin_outputImageType jpg #hugin_outputImageTypeCompression LZW #hugin_outputJPEGQuality 90 #hugin_outputImageTypeHDR exr #hugin_outputImageTypeHDRCompression LZW #hugin_outputStacksMinOverlap 0.7 #hugin_outputLayersExposureDiff 0.5 #hugin_optimizerMasterSwitch 0 #hugin_optimizerPhotoMasterSwitch 21
Re: [hugin-ptx] Align image stack, warp only one image
J Harvey wrote: I'd like to use align image stack (either command line or in Hugin), but only warp the second of two images. All the implementation I've tried yields me two mutually warped images. I'd like the base image to remain unchanged, and warp the second to the first. I have a couple of expensive windows science programs that can do it, but I'd like something for a Linux box. Any ideas? Hugin can do this, at least in the GUI. It's pretty much the norm to leave the anchor image alone, although it's technically optional. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5A0D5941.20403%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Getting Hugin interface to display decimal angular values ( not truncated) in assembly tab
Fabrice Kerzerho wrote: @Sean : Many thanks, I'll try it asap . Would be great to be a display option in expert mode; how can I ask for it? @Gunter : Cool to discover that someone else need it ; I would increase it to work with hundredth of degrees : the farthest the objects are in my panoramas the accuratest I have to be. Perhaps the angular resolution should be dynamic - the increment should be (about) the angle subtended by a single pixel at the edge on the panorama. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5A042DDD.2030409%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Simple rotation/translation stitching
Roger Broadie wrote: Adding all control-points by hand hardly bears thinking about. What would you think of 2114 hand placed CPs on 173 8Mp images? It's optimised under YPR/XYZ, and an optimisation run takes around an hour on my laptop. I don't like to talk about the stitch time. In a bid to stay sane, I did a lock of locking of some image, whilst adding and optimisation new images. At any one time, only a few (20-30) images were visible, of which the older ones were locked. :-) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/59AD1959.5080804%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Simple rotation/translation stitching
Roger Broadie wrote: Of course, long linear features can offer control-point detectors difficulties if there are no distinguishing details on or near them. But in the case of your image showing the discontinuities the seam clearly passes near or even through plot numbers and they should give control-point detectors something to bite on. Thus you could try dragging a rectangle around them and selecting that great standby "create control points here": see e.g. I often (ish) use my camera and a pano head as a substitute for the A0 scanner I don't own, usually for maps and newspapers. In both cases I do NOT use automatically generated CPs. There is so much fine scale repetition in text (all the printed characters are identical) and a map (symbols, text again) that false hits are inevitable. For truly large items, I don't use a pano head, but move the entire tripod and camera over the item, grid-fashion. This is laborious to do, and laborious in hugin too. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/59A6798D.9080006%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Images rotated on Hugin Control Points tab
John Eklund wrote: Hugin apparently has a "feature" that visually rotates input images on the Control Points tab if they have a Roll value 45 degrees or greater. It seems this behavior can't be turned off?! Although it might be helpful in some situations, there are many situations where it makes editing control points virtually impossible. One of my common uses for Hugin is stitching together a cylindrical panorama (what used to be called a "panoramic photograph" :-) ). To maximise resolution, I set the camera to portrait mode, and rotate it on a vertical axis; you don't even need a pano head to do this, a normal tripod head is fine. The feature you dislike so much is of great value when working with such a photograph. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/59915D06.4030901%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: align_image_stack with any exposure but move/drag
'dkloi' via hugin and other free panoramic software wrote: I'd import all the images into a single project. Image align stack each set of exposure. Stitch together one image from each exposure stack into a panorama (e.g. the middle exposures). Thus the others in the stack will also be aligned. Then I would export each exposure separately (light, mid, and dark), finally enfusing them. This is my usual procedure for doing exposure fused panos, e.g. https://www.360cities.net/image/glasgow-nelson-mandela-place Interesting - I do the exact opposite, due to performance limitations on my box. The FIRST thing I do (using a small perl script) is identify each bracketed set and enfuse them from the command line. From then on, it's just (from Hugin's POV) a simple pano. This gives a minimum RAM usage - initial enfuse is small, and final stitch is smaller. If you do it stitch-then-fuse, the final enfuse is very RAM hungry; it's effectively ALL the source images handled simultaneously. In theory, the low-RAM method could lead to edge effects, since the enfuse is being done without global knowledge, but in practice, decent amounts of overlap (needed for good alignment and stitching in any case) render this problem vanishingly small. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5981950A.1090309%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Two problems with a map
Oh. Dear. I just loaded one of the shots into a fresh project, and Hugin shows Hfov(v) 38. It looks like the fault may well be all of my own making, and not Hugin's at all. I'm wondering if I did an ill advise optimise that included the FOV early on, and forgot about it. BugBear (off to hang his head in shame) paul womack wrote: Paul Womack wrote: I think you (and T Modes) may have found the issue. The camera was pointing STRAIGHT DOWN when the shots were taken, so its angle sensor reading would have been meaningless. I shall check the exif of these images against more "normal" samples from other shooting sessions, and see what I find. If needed, I will force the vert/port sensor reading in the files to tell the truth (or at least my version of the truth). Thanks to both - I shall report back. OK; I have some info. In the original (flawed) set, the Hfov(v) was 16.5; this show in the GUI on the Photos tabs as Focal Length: 25.03, Focal length multiplier 4.769 I attempted to optimise Hfov(v), but nothing came of it. I then simply tweaked it, and fairly rapidly converged on 38 as the angle that gives the straightest borders. (I had other issues with blending, which I'll post separately). I've cut and pasted the result of exiftool -S on one of the images. I note (with interest) the "FOV: 38.4 deg" -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/595624B8.6090501%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Two problems with a map
T. Modes wrote: Am Donnerstag, 22. Juni 2017 18:26:30 UTC+2 schrieb bugbear: My current pto is attached. I had a short look on it, the main problem is probably the wrong fov. (really shoot with a 35 mm equivalent focal length of 120 mm from 1 m distance?). It really was shot that way, to get high resolution. 1m is as high above the table as my tripod would go. It is possible I have parallax errors, since my pano head is built (literally) for my lens at "full wide" (around 35mm equiv), but since the map is pretty much a 2D item, this should have minimal consequences. When I increase the fov the horizontal and vertical lines better line up. Intriguing. I'm happy to do "whatever it takes" to get a good result, but it seems wrong that I have to lie to hugin in such a (I think) simple circumstance. I would have thought (perhaps wrongly) that the maths should "just work". BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/594CCC37.50104%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Two problems with a map
Roger Broadie wrote: Hello Paul, I was a little surprised at the idea that Hugin could output a panorama defined to be rectilinear but which would show with the barrel distortion apparent in your stitch. I attached my pto file as evidence in my defence :-) So I tried converting your output from all the list of allowable output formats to rectilinear. Assuming the starting point was a fisheye seems to work well, at least as far as the side (long) edges are concerned.. There was still curvature in the top (short) edges, which I cured with a panini general projection, adjusting the top and bottom sliders. Whether the horizontal/vertical aspect ratio is correct, I cannot say, but the writing in the tables looks unstretched in either dimension as far as one can see at the available resolution. The pto file and output are attached. I chose an hfov of 59 degrees, but there may be a better angle. So my question would be, whatever you may have thought, did you actually choose a rectilinear output projection? My current pto is attached. I don't find the rotation behaviour you mention surprising. Surely, optimising will allow the horizontal and vertical lines you have defined to reassert themselves and undo your hand rotation. The moral would appear to be, either to swap all the horizontal and vertical line-types, or, it that's too boring, to do all your optimisation first and then rotate by hand, which is probably what you did. No - since I wanted hugin to optmise "properly" I allowed it to move the "anchor" image in YPR; in conjunction with H and V CP pairs, this has always (up until now) worked well to regularise images of 2D rectangular objects, compensating for the camera either being off-centre, or pointing off centre. I have successfully captured maps before using this approach and am currently rather baffled as to my current failure. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/594BEFAF.6040907%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout. estate_map.pto Description: application/ptoptimizer-script
Re: [hugin-ptx] Two problems with a map
Greg 'groggy' Lehey wrote: On Monday, 19 June 2017 at 11:01:10 +0100, paul womack wrote: I took a pano set of a map recently, using a pano head, from only 3 feet away from the map. The control points and optimisation aren't perfect, but they're OK (for the moment). My real show stoppers are: 1) Barrel distortion http://i48.photobucket.com/albums/f234/bugbear33/misc/barrel.jpg Sorry, it seems that this site wants me to disable my ad blocker. Can you put it elsewhere? Does this one work? http://woodworkinfo.site88.net/barrel.JPG BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/594BCE9E.4070905%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] enfuse/enblend discussions?
Greg 'groggy' Lehey wrote: On Thursday, 9 February 2017 at 17:18:10 +0000, bugbear wrote: Greg 'groggy' Lehey wrote: On Wednesday, 8 February 2017 at 9:28:53 +, paul womack wrote: Is this the right list for enfuse/enblend questions? Until proof of the contrary, yes. Fire away. Well, I was a little worried by this: http://www.stackrail.info/index.php/webshop/product/189-snapfuse-image-fusion-software SnapFuse Image Fusion Software The capabilities sound ... familiar, it's on sale at $52.00, and I don't see any reference to source. http://www.mjkzz.com/product-page/snapfuse-image-fusion-software There's not much information there. What makes you think it could be a ripoff of enfuse/enblend? I didn't see him asking any questions (on any forum) about developing such software, algorithms etc. Snapfuse suddenly appeared, fully formed. It also does both HDR and Focus stacking. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/58A178E9.8020305%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] enfuse/enblend discussions?
Greg 'groggy' Lehey wrote: On Wednesday, 8 February 2017 at 9:28:53 +, paul womack wrote: Is this the right list for enfuse/enblend questions? Until proof of the contrary, yes. Fire away. Well, I was a little worried by this: http://www.stackrail.info/index.php/webshop/product/189-snapfuse-image-fusion-software SnapFuse Image Fusion Software The capabilities sound ... familiar, it's on sale at $52.00, and I don't see any reference to source. http://www.mjkzz.com/product-page/snapfuse-image-fusion-software BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/589CA452.1070504%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] increase/decrease exposure on all images at once
Caetano Veyssières wrote: I can change the EV value on all selected images, but they all get the same value, what I want is to increase or decrease their individual values at once. Is that possible ? Not that I'm aware of. But you could alter the EV of the anchor and do an exposure optimise on all the others! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/586BDB5D.3000909%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Why is part of the stitched image black?
Peter Cooper wrote: > Based on my experiences I am documenting my photography process <http://mapping4ops.org/raster-map-technicalities/photographing-maps/> and my stitching process <http://mapping4ops.org/raster-map-technicalities/stitching-images-into-a-map/> for future reference, and will continue to develop these documents as I learn more.) http://mapping4ops.org/m4ops-for-those-responsible-for-an-ops/using-photography-to-get-a-good-enough-quality-image-of-a-map/ The camera doesn't need to be dead square to the map - Hugin can easily correct that, given straight line control points on a rectangle (as in te example PTO I sent you) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/586B8FE4.5080005%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Why is part of the stitched image black?
Peter Cooper wrote: The input files, and output, project and log files are all my DropBox folde <https://www.dropbox.com/sh/su6axe2h76ty2om/AABkH1hGTGzAS5KSASpuY_asa?dl=0>r. When I preview the project within Hugin I cannot see any black area, but in the tiff the lower right section is black. This area corresponds in part to image 4. (This is a project to stitch together photos of parts of a map, so I have given each image its own lens.) Any idea why part of the stitched image is black? I've downloaded and reworked the project (no major changes). Looking more generally at the resulting stitched map, I think you need to change your shooting slightly. The aperture is wide open, resulting in distinct softness at the edges of the images; experiment with small apertures to see where the sweet spot for sharpness is. Since you're using a tripod and timer-release, long exposure times aren't a problem. And the images are quite under exposed; the whites are showing as 56% in Gimp! I'm guessing you shot on a table, near a window; the folds and creases in the map have been made quite visible by a *very* low raking light; try (somehow) to arrange diffuse and/or multiple light sources for your next shoot. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/585CF64D.9030107%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Stitching photographs of a large map into a whole map
Peter Cooper wrote: * I had not appreciated the need to treat optimisation as a step by step process - now I do This is only true for mosaic stitches - a spherical "pano head" stitch, where only YPR are optimised will pretty much work "in one hit". A full YPR/XYZ stitch must be done very carefully, and in stages, because some of the parameters have "similar" effects. In particular, a small mosaic could be feasibly stitched (with some errors) in YPR mode. One tip I will offer - save your pto file VERY regularly; you never know when a new optimisation will become degenerate! When I did my VERY large mosaic (173 image) I started by adding images one (or 2) at a time, and optimising. As the mosaic grew, I was forced to set existing images parameters to be "fixed" because the optimsation time became very high (60 minutes, at the end). I would add a row of images, 1 at a time, then allow the previous row to be optimised against the new row, then allow the whole image to be optimised, then start on the next row. I was also setting X-Y manually for each added image (based on arithmetic interpolation "guessing") so that my desired optimisation minimum was nearby in the search space. (because my map was large, and some of my images had poor focus, my stitching took around 2 weeks of intermittent work!) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/58590452.9050008%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Stitching photographs of a large map into a whole map
Peter Cooper wrote: Thank you for your encouraging responses. This prompted me to thoroughly re-read the manual and tutorials, do further experimentation, and write lots of notes for myself. I have also carefully retaken my photographs of the map, so there is more overlap. I wanted to make sure I could get as far as I could without help. Following the "Stitching flat scanned images" tutorial to the letter (and making notes along the way about aspects I could not follow, or questions I had), and adding in some steps of my own, I have managed to produce a stitched map that I am quite pleased with. Could you send your project file (the .pto) to the list? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/58581957.1030203%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Control points editor / Line detection / Projection of a single image
In that case I recommend a script. BugBear Abrimaal wrote: How many? Hundreds in every folder and hundreds of folders :) On Wednesday, December 7, 2016 at 9:52:18 AM UTC+1, bugbear wrote: Abrimaal wrote: > No, taken with various cameras, in differe nt years, seasons, various objects (mainly architecture) How many photographs do you have? This would affect the degree to which automation is worth the time (and trouble) to implement. BugBear -- 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+unsubscr...@googlegroups.com <mailto:hugin-ptx+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/54927a80-6730-48a5-bf63-c507f62fb490%40googlegroups.com <https://groups.google.com/d/msgid/hugin-ptx/54927a80-6730-48a5-bf63-c507f62fb490%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/58492781.9090506%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Control points editor / Line detection / Projection of a single image
Abrimaal wrote: No, taken with various cameras, in different years, seasons, various objects (mainly architecture) How many photographs do you have? This would affect the degree to which automation is worth the time (and trouble) to implement. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5847CDB7.9060107%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Control points editor / Line detection / Projection of a single image
Abrimaal wrote: Now I have a lot of single photos to straighten. Every time I load a new image, the projection is changed to Equirectangular, when I need Rectilinear. Repeating it too many times is uncomfortable. Can I save the settings, that are not included in the Preferences to .ini file? or start Hugin from a .bat file with desired parameters: rectilinear projection, control point detector set to vertical lines etc. ? Are your single photos that need straightening all taken in the same way way ? If so, this could help: http://hugin.sourceforge.net/docs/manual/Panorama_scripting_in_a_nutshell.html#Simple_command-line_stitching BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5846F535.1050706%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Aligning photos of the same scene with a moving body of water
Carlos Eduardo G. Carvalho (Cartola) wrote: You can remove the Control Points (CP) found at the water. You can easily do that visually at the fast preview window using the "Edit CP" button at the preview tab (second tab). After activating this button you can drag rectangles over the image to create new CPs or remove them. You could also mask, and then use "remove control points in masks" BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/584026C1.2060707%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Grid / Projection modification - customize
Abrimaal wrote: This projection will be useful for straightening architecture, below an example. Where equirectangular / mercator are not suitable, because of curved horizontal lines. *A* is the original photo *B *is after straightening the || vertical lines in the rectilinear projection. The upper part, the tower is too tall because of the grid that consists of identical squares *C* is after rescaling, still not good. The lower part became too small. The interface in Hugin does not use grids in the Gui - that's how Photoshop and/or Gimp present it. But it can certainly do projection correction; indeed it's a KEY part of its fucntionality, since the multiple shots of a stitched panorama have different perspectives. You may find these tutorials helpful: http://hugin.sourceforge.net/docs/manual/Perspective_correction.html http://hugin.sourceforge.net/tutorials/perspective/en.shtml http://hugin.sourceforge.net/tutorials/architectural/en.shtml BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/582EC688.6030008%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: optimizer tab
John Muccigrosso wrote: Thanks. It's just that I didn't see that meaning in the OED, so I was curious. It's very common for "normal" dictionaries not to have highly technical or trade/craft specific meanings. I take part in discussions on pre 1950 woodwork, and many words (some of them apparently common) have specific meanings in the craft which you won't find in a normal dictionary, regardless of its size/scope. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5804907A.1070508%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: IPTC fields?
T. Modes wrote: Am Montag, 10. Oktober 2016 11:26:34 UTC+2 schrieb bugbear: I have now downloaded the source, and done some searching; I think this is a list of all the Exif and Xmp tags used by Hugin; This list is far from complete. Some important information are missing. Please reread my last post. I mentioned the important pieces there. Your post provided valuable outline guidance, but did not provide actual Tag names that I can use in Exiftool. If you would care to add the tag names you know about to my list, I would be very grateful. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57FC9D6C.1090909%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: IPTC fields?
T. Modes wrote: Am Donnerstag, 6. Oktober 2016 10:23:06 UTC+2 schrieb bugbear: What (IPTC) fields do I need to transfer to get the best behaviour from Hugin? Hugin does not read IPTC fields. I have now downloaded the source, and done some searching; I think this is a list of all the Exif and Xmp tags used by Hugin; "Exif.Photo.ExposureMode" "Exif.Photo.PixelXDimension" "Exif.Photo.PixelYDimension" "Exif.Photo.FocalLengthIn35mmFilm" "Exif.Photo.DateTimeOriginal" "Exif.Photo.FocalPlaneResolutionUnit" "Exif.Photo.FocalPlaneXResolution" "Exif.Photo.FocalPlaneYResolution" "Exif.Photo.LensModel" "Xmp.GPano.ProjectionType" "Xmp.GPano.CroppedAreaImageWidthPixels" "Xmp.GPano.CroppedAreaImageHeightPixels" "Xmp.GPano.FullPanoWidthPixels" "Xmp.GPano.FullPanoHeightPixels" "Xmp.GPano.CroppedAreaTopPixels" BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57FB5EC4.1020904%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Aerial images stitching
Terry Duell wrote: Your UAV is flying at constant altitude, but is the ground surface planar, i.e. flat? You are essentially collecting images to stitch in mosaic mode, in which case the surface should ideally be planar, but that does depend on the altitude and the variation in elevation of the surface. If the variation in elevation is small and altitude is large, stitching in mosaic mode should give a reasonable result. Unless the UAV is maintaining a perfect horizontal position you may need to optimise all of X,Y,Z,Pitch,yaw,roll. Doing this in a stable fashion is more difficult than you'd like. Others who frequent this forum have done quite a bit of work in perfecting methods of stitching shots of large maps which are not exactly flat due to creases from folds. Some of the experience with that may be applicable, not sure. Indeed. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57F36B96.80103%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Pretty new at Hugin...can't figure out how to get images into proper order
Lucinda Q. Lovelace wrote: I think I found what I need, it's in the Move/Drag area under 'displayed images' there are boxes with 0 and 1...I figured out how to move the images around using those. It HAS been too long since I used Hugin, lol, some things have changed. Now to try and get the control points in again You need to trust Hugin more... If you do the control points, Hugin will sort everything out for you automatically (most of the time...) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57ECD1CF.6060808%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mirror?
bugbear wrote: Bruno Postle wrote: On 27 September 2016 08:57:55 BST, paul womack wrote: I wish to align some 2D images, some taken from the rear of an item, some from the front. "Clearly" one set of image will need to be mirror reversed. Does hugin's model support this? Had to think about this, but I'm pretty sure that it isn't possible. The mosaic mode could support it by rotating images more than 90°, but this data is discarded (haven't actually tested so may be wrong). Followup - does anyone know of any Linux software that will mirror flip a photo whilst retaining all meta-data (notably EXIF)? jpegtran -flip horizontal -copy all image.jpg > flipped_image.jpg works (confirms by diffing the output of exiftool) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57EA3CAC.2090401%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mirror?
Bruno Postle wrote: On 27 September 2016 08:57:55 BST, paul womack wrote: I wish to align some 2D images, some taken from the rear of an item, some from the front. "Clearly" one set of image will need to be mirror reversed. Does hugin's model support this? Had to think about this, but I'm pretty sure that it isn't possible. The mosaic mode could support it by rotating images more than 90°, but this data is discarded (haven't actually tested so may be wrong). Followup - does anyone know of any Linux software that will mirror flip a photo whilst retaining all meta-data (notably EXIF)? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57EA3A57.8080903%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Stitching untypical photo objects (reflective, people, analog scans)
Sean Greenslade wrote: This comes back down to the parallax issue: image transforms can't alter the parallax of the image, so there will be some oddities in any output if the input picture isn't of something completely flat. The subject doesn't need to be very 3D to cause this; I took an off-axis photo of a gothic carved panel in a church, to avoid a reflection. Skewing the panel back to rectlinear caused the carving too look "odd" in a non-obvious way. http://galootcentral.com/components/cpgalbums/userpics/10152/gothic.JPG BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57CE7F11.9050904%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Hmm, no Hugin news lately?
David W. Jones wrote: Just wondering ... keep expecting announcement of the Magic Fractal Image Expansion projection that uses fractal image processing techniques to turn an old 300x200px GIF into a super-hirez gigapixel panorama. ;) That's on the secret PPA. Were you not told? Awkward :-( BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57B41A1F.50005%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] new image stitching software
Forex Valdes wrote: Hi all I am launching a new image stitching software. You can get it here http://molanisvr.com/78-molanis-vr/85-360-vr-image-stitching-download This version does not have any watermarks. It is fully functional. What problem, that Hugin does *not* solve, does your software solve? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5799C042.5010206%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Can Hugin change the projection of a video?
Robert Giordano wrote: First, thanks to everyone for their suggestions and tips!! I'm going to describe my procedure and test results in detail for the benefit of people reading this post in the future. Excellent write up. Thank you. May the Karma be returned. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5785F46C.1080807%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Distortion parameters "a, b, c" to "k_1, k_2, p_1, p_2[, k_3[, k_4, k_5, k_6]]" (OpenCV)
'Bruno Postle' via hugin and other free panoramic software wrote: Yes, there is no direct conversion possible unless you limit the parameters. However given the two formulas, this is a curve fitting problem - it ought to be possible to get a very good approximation with a spreadsheet solver. If they are both good and useful models of the same distortions, they should indeed map onto each other, "somehow", at least for realistic and/or common cases. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57763005.3010306%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Batch-automagically find picture groups
Nicolas Ecarnot wrote: Hello, Though being Linux and Hugin (happy) user for years, a friend of mine showed me the commercial software Kolor Autopano. In a directory containing a thousand of pictures, there were 5 groups of pictures that were panoramas. Using Hugin and Autopano, I was very surprised to witness that the results were very similar (so I'm confirming I'm happy with Hugin). One major comfort point on the Autopano side is its ability to scan a whole directory, and detect the sets of pictures that will take part of a pano. Then the software prepares those sets in the same "project way" we know in Hugin, and lets the user play with the settings and the rendering. This feature sounds basic to code, as it's merely based on time stamps (closest time stamps are likely to be panoramas - the offset is adjustable). I was wondering if such a feature could exist in the Hugin world? Thank you, Nicolas Ecarnot I wrote a Unix tool a while ago to batch up sets of photographs, not for panoramas, but for HDR. I suspect it's similar. It's 174 lines of Perl, but I suspect it may rely on some particularities on my Camera and/or its Exif. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5770E032.4090104%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Enfuse v4.2 question
Frederic Da Vitoria wrote: 2016-06-08 10:03 UTC+02:00, bugbear : Didn't there used to be a semi interactive GUI for enfuse, which would make such experimentation, if not simpler, quicker and easier? BugBear Do you mean EnfuseGUI? A quick google says "no", since the enfuseGui site says: ✓Multi platform (Windows and Mac) And I'm on Linux. It looks out of date too - the site speak of Windows 7. http://software.bergmark.com/enfusegui/Main.html BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57580890.8040902%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Enfuse v4.2 question
twalp wrote: I'm replying again to post the results of "reducing the number of pyramid levels" -- in case a future reader is curious. It should be noted that my using Enfuse options like this are akin to me randomly flipping switches in a jet cockpit, but there definitely is a visible pattern. Baseline Enfuse using --saturation-weight=0 --exposure-cutoff=0%%:95%% --contrast-weight=0 Didn't there used to be a semi interactive GUI for enfuse, which would make such experimentation, if not simpler, quicker and easier? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5757D16A.4010907%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] 360° Stitching??
Kai N wrote: Hi folks, maybe this topic were already posted / requested. Is it possible to create a 360° jpg using hugin? I am a newbie on huginlet's assume I will take a bunch of photos; taken from a fixed stand; round view 360° / overlapping (of course) How to use hugin for test / start? looking forward to get some good tips Tip; RTFM. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5732FE20.30906%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: night panorama
'dkloi' via hugin and other free panoramic software wrote: If you can't place manual control points then it doesn't sound promising. Any chance of uploading the source images? Perhaps it would be possible to make a super-enhanced set of images, optimise, and re-use the project file for the real images. BugBea -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/57149EF4.3000305%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Records office preparation
Battle wrote:
My experience with this kind of thing is to maximize the distance to the object
using a longer lens when possible which reduces the angles and amount of
variation from image to image which in the end tends to overcome the variation
of handheld image capture. For example, can you put the maps on a floor, and
stand on a chair? That would increase the distance from camera to object from
2 feet to 8 feet. Is there a balcony in the room that you could shoot down to
a table on the lower level?
Now we're talking 15 feet or more.
Yes - back in 2014 (which is when this thread is from) I worked the following
out:
https://groups.google.com/forum/#!topic/hugin-ptx/nynP68FT5WA
BugBear
> Would they let you put the camera on a monopole and hold it above your head
to shoot down to the table? That might get you 4 to 6 feet away. Even if all
this were not permissible, maybe you could shoot tethered, and just hold the
camera above your head looking at the computer screen to frame the shot. If you
can shoot the map in two images, then you can probably hold the camera in place
close enough to use the bracket feature to get 3-9 shots from each
position with one shutter press. Chances of getting usable images when
shooting handheld this way increase as others have pointed out.
Also any relief change (from a flat plane) will lead to parallax issues.
Getting the maps to lay flat as possible is more critical the closer you are to
the maps. Do they have a display (drafting) case or table, or other table
large that has a tilting top which will tilt 45 degrees? This would allow you
to stand back from the maps far enough to shoot handheld.
On Tuesday, May 6, 2014 at 4:20:43 AM UTC-4, bugbear wrote:
I am about to visit a record office. Their rules
permit cameras, but not tripods (let alone pano heads!)
I wish to capture the image of some 18th c maps, which are large,
in good detail. The obvious strategy is to take multiple
shots and stitch, but the shots will all be taken from different
position and angles (since they'll be taken freehand).
But since the maps are 2D a stitch should still be possible.
I have tested this approach at home (cheating using a tripod!)
and a road atlas.
I would welcome advice.
BugBear
--
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+unsubscr...@googlegroups.com
<mailto:hugin-ptx+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/19de5c19-a669-43f1-b114-cc343845f6c1%40googlegroups.com
<https://groups.google.com/d/msgid/hugin-ptx/19de5c19-a669-43f1-b114-cc343845f6c1%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/56DD4C58.5080102%40papermule.co.uk.
For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mildly off topic - rephotography?
bugbear wrote: (see attached diagram, which is 2D, concerned with placing the camera correctly on a plane) Here's the diagram I was obviously referring to, but was too stupid to attach! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56C33E1B.2020604%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mildly off topic - rephotography?
Rogier Wolff wrote: I think that to gather enough information you would need to build a 3D model from the environment by taking a bunch of pictures with several viewpoints in the general area of where the old one was taken. Then, by matching the remaining buildings in th eold photograph to the 3D model you can calculate the camera position of the old photograph compared to the new images. Provided you've kept a precise log of where you took the "set of photographs for the 3D model", you should be able to calculate where to stand for the "NOW" picture... That's way more complex than I was thinking of. (see attached diagram, which is 2D, concerned with placing the camera correctly on a plane) I think it is obvious that if the landmarks in an old photo lined up so perfectly as the top left example, it would be easy to simply walk to the right place; to be formal, you could put yourself on the line defined by the left hand pair of landmarks, and then walk up and down it, until you're also on the line formed by the right hand pair. The top right example is a little more complex. Instead of the landmarks simply lining up, you have place each "near" landmark of the landmark triples exactly between the pair of "far" landmarks. Other than that, it's the same as the first example. The bottom left example generalises still further, so that the "near" landmarks are now at different distances from their respective "far" landmark base lines. We generalise this further, so that instead of the "near" mark being centred between the two "far" marks, it simply has to be placed (or, more accurately, the camera placed) so that the gaps between the "left far", "near", and "right far" are in some ratio other than 1:1 In the bottom right case, these ratios are 2:1 and 3:1. All of this clearly works. So - in this last, most general case, it seems plausible that "all" we have to do is pick out some "well chosen" landmarks and ratios from the original target image. So - what's the MINIMUM set of landmarks and ratios and what criteria do they need to fulfil such that 2D placement of the camera is possible? (and, having taken a trial photograph and calculated your new ratios from it, how do you calculated the "move" the camera needs to make ? ) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56C33DE1.5080103%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Enblend performance on mosaics?
Luís Henrique Camargo Quiroz wrote: Hi BugBear, Thanks for sharing all that with us! I was hoping someone with a little (or more) knowledge of the internals of enblend to explain some of this. I've been effectively black box/reverse engineering, based on my own intuition. It certainly appears that using enblend "naively" for a mosaic is catastrophic. But (to say the least) one way and another, I "owe" the hugin/panotools community, so this thread is perhaps a little karmic payback. I will now attempt to refine and polish my test script for general purpose use (it's currently got my pano name, and image/row numbers hard coded...) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56702672.4080208%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Enblend performance on mosaics?
bugbear wrote: I will check today wether the row trick effects low-res blending. Having set the pano to be total width 1, I allowed enblend 4.5 Gb of RAM, the output tiff is only 9444x4940, 180 Mb. blending to create 11 subrows: 188 Seconds; blending 11 subrows together: tree style: 75 seconds, single call to enblend; 73 seconds. Single pass (175 small images, single call to enblend) 661 seconds. So - the "row trick" seems to affect enblend seam behaviour (for want of a better word) as well as memory handling. Summary - use a row based sequence when stitching mosaic/gigapixel images with enblend. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56701CD2.5020808%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Enblend performance on mosaics?
Terry Duell wrote: > I note that you have had some success stitching rows. Further to my question, above re OpenCl, I was on the wrong track with that. Whilst the current source does support OpenCL it is for use with exposure weighting functions. One thing that has since crossed my mind, but I don't think was discussed in relation to your problem, is the use of OpenMP. Is your version of Enblend built with OpenMP enabled? My build is GPU yes, OpenMP no. Sadly, GPU doesn't work, since left with single thread, main CPU!! I will check today wether the row trick effects low-res blending. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/566E909C.3000100%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Enblend performance on mosaics?
Short version - row based blending RULES! Long version: I've re-done the stitch in my "best practice" manner, for a stitch with a pano size at 35000 (actual image 33054x17290) mapping 17:26:11 to 17:46:34, around 20 minutes, similar previous test, as expected Pano is 15x11, so I stitched to exactly 11 sub rows, not 8 as before; Stitching to 11 "subrows" each sub-row took roughly 150 seconds, 1721 in total (29 minutes). Stitching the sub-row, nested-pairwise: 2883 seconds (48 minutes). This is a bit longer than the pair-wise stitch of 8 sub-runs of the first test, 2408, but the sub-row-creating benefits outweigh this. Total enblend time is 1271+2883 = 4154 = 69 minutes. (The best result from the previous test was 2525 + 2408 = 4933 - 82 minutes) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56694821.2020503%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Enblend performance on mosaics?
Harry Saffren wrote: You can get greatly decreased blend times by using the older version of enblend 4.0. and using sRGB color space, (not CIECAM color space). The current version of enbled, 4.1.3, seems to be optimized for CIECAM color space, but at the expense of working in sRGB color space. I routinely blend 45 to 60 images with very acceptable render times using enblend 4.0 that shipped with Hugin 2012. Here are some times of test blends that I made from the command line using enblend 4.0 and enblend 4.1.3 with both CIECAM color space and sRGB color space (CIECAM set to off). Note that enblend 4.0 defaults to sRGB (CIECAM=off) and enblend 4.1.3 defaults to CIECAM=on. And the two versions use different flag to turn CIECAM on or off. Enblend Render Times for 31 images (3474x5211 pixels each, 8 bit Tifs) for a final image at 21322x16345 pixels (Windows 7-64bit, 16 Gigs Ram, i7-2600k @ 4.2GHz) Times are for Enblend run from the command line on the same set of images remapped by nona Enblend 4.0 CIECAM=off (default) render time: 5.5 minutes Enblend 4.0 CIECAM=on render time: 97.5 minutes Enblend 4.1.3 CIECAM=off render time: 21.0 minutes Enblend 4.1.3 CIECAM=on (default) render time: 62.0 minutes (Hugin 2015 Builtin Blender + GPU for remapping in Nona the render time is 3 minutes including time for remapping) As you can see Enblend 4.0 CIECAM=off is 5.5 minutes versus 62 minutes for Enblend 4.1.3 CIECAM=on Also, on my system using the GPU for remapping in Nona yields a big time reduction for remapping the images. I'm running (on Ubuntu 14.04) Enblend 4.1.3 Compiled on lgw01-14 by Build Daemon user on Sun, Mar 19 2015, 14:37:40 GMT+0. It is compiled with Extra feature: GPU acceleration: yes, Extra feature: OpenMP: no. Sadly, on a test, the GPU support doesn't work; many warning messages, and it eventually hangs. Moving to your point about ciecam I performed a low-res (final output 9444x4940) test, using my "row" strategy. My ciecam args versus times in seconds were: ARG --ciecam; TIME 4758 ARG --no-ciecam; TIME 241 ARG; TIME 245 It looks like my ciecam default is "off"; just as well, ciecam seems to slow things down by a factor of about 19!! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56680C59.7000306%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Enblend performance on mosaics?
bugbear wrote: It appears on testing so far that blending the images into rows first, then blending the rows, so that the vertical seams are small, gives a great saving on CPU. I will do the "near the limit" memory test tonight, when I don't need my laptop to be responsive to me... BugBear Short version: blend in a row-based manner for best performance. Long Version: OK; I've upped the test size; the output is now 33054x17290, (~0.5 GigaPixel) The mapped TIFFs are 3.2 G, the pano roughly 15 columns x 11 rows of 8 MegaPixel images.. Mapping took from 17:24:16 until 17:44:39, around 20 minutes. Blending: 1st run was done by creating 8 "row" panos; blending the rows took: 159,146,*728,154,164,*522,140,*512 seconds for a total 2525 seconds, or 42 minutes. Since the "true" pano has 11 rows, the longer times are where 2 rows where merged. Note that the time goes up by more than a factor of 2, more like 3.5. Worse than linear degradation. Merging the rows into a final pano was done in 2 ways; first, by combing a tree of pairs, and then "in one go"; Tree of pairs took 2408 second, "in one go" took 3552 seconds. So; best blend time would be use the "pairs" tree, for a total of 2525 + 2408 = 4933 - 82 minutes. I finally did a control run, simply letting enblend loose; It had loaded 140 of 173 image after 45610 seconds (12 hours), when I killed it. My enblend args are: /usr/bin/enblend -m 4500 --compression=packbits Any details about my system and software that are needed to interpret these results - just ask. My "take home" is that performing sub-blends in a row orientated fashion is a MASSIVE win. I do not know if this is due to better memory usage (rowed/striped access to memory is hugely better than columnar), or wether is influences the seam calculations. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5667F062.70600%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Enblend performance on mosaics?
bugbear wrote: Terry Duell wrote: Hello Paul, Is there any way to perform the blend in stages (either row at a time, column at a time, or quarters/eighths at a time), that will improve performance in the special case of a gigapix/mosaic? I can't see a way to do that with enblend, but others may know some tricks. Another approach, is to split the stitch up into quarters/eighths, stitch and blend each, then stitch and blend those results. Just a quick thought. Also...does your laptop gpu support opencl? I've written a perl script to "chop up" the blend; unfortunately, doing a quick low res test run, one of the quadrants reported: enblend: info: loading next image: mapped/big0103.tif 1/1 enblend: info: loading next image: mapped/big0102.tif 1/1 enblend: warning: failed to detect any seam enblend: mask is entirely black, but white image was not identified as redundant enblend: info: remove invalid output image "1x0sub.tif" So I didn't get my quadrant output. And yet the "full set" of images blends OK. I've been testing (on medium res images) that fit easily within my current RAM. It appears on testing so far that blending the images into rows first, then blending the rows, so that the vertical seams are small, gives a great saving on CPU. I will do the "near the limit" memory test tonight, when I don't need my laptop to be responsive to me... BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5666E3BC.8050108%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Enblend performance on mosaics?
Terry Duell wrote: Hello Paul, Is there any way to perform the blend in stages (either row at a time, column at a time, or quarters/eighths at a time), that will improve performance in the special case of a gigapix/mosaic? I can't see a way to do that with enblend, but others may know some tricks. Another approach, is to split the stitch up into quarters/eighths, stitch and blend each, then stitch and blend those results. Just a quick thought. Also...does your laptop gpu support opencl? I've written a perl script to "chop up" the blend; unfortunately, doing a quick low res test run, one of the quadrants reported: enblend: info: loading next image: mapped/big0103.tif 1/1 enblend: info: loading next image: mapped/big0102.tif 1/1 enblend: warning: failed to detect any seam enblend: mask is entirely black, but white image was not identified as redundant enblend: info: remove invalid output image "1x0sub.tif" So I didn't get my quadrant output. And yet the "full set" of images blends OK. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5666B3EB.40207%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Shooting and stitching to make Giclee prints
Terry Duell wrote: I just tried that with my 150-450 lens and the image of the diaphragm is in quite different positions at 150mm FL, depending on which end of the lens I'm viewing. My guess is a difference of about 75mm. The locations come much closer together and move towards the camera as the FL is increased. Does that sound sensible, or am I on the wrong track with this? I found my NPP empirically. I had already made the baseboard of my pano head (which is just a piece of wood with a hole for a 1/4" bolt, which is what the camera fixes to). http://s48.photobucket.com/user/bugbear33/media/pano_head.jpg.html I'd pencilled the line of the axis of the lens (which is physically obvious) onto the board. (see attached diagram) I put a panel pin into a piece of scrap, leaving just the head sticking out, and put two AA batteries roughly in line, a couple of feet from the camera, and 6 inches different in distance. In other words, a subject with worst case parallax. I then placed the board+camera onto the pin head, somewhere on the line, and twisted the camera right-left. There was, of course, lots of parallax movement of the two batteries, visible in the viewfinder. I simply moved the camera+board backward and forward on the line, doing test pivots, until parallax was at a minimum. Admittedly, a fully adjustable pano head would allow you to find the NPP with more accuracy, but this was easy and cheap. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56430537.9070304%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Shooting and stitching to make Giclee prints
panostar wrote: All that is required in this case is a simple plate or bar adapter to shift the camera back (or possibly forwards) to align the entrance pupil of the lens with the axis of rotation. That would virtually eliminate horizontal parallax. Any minor shift of the entrance pupil in the vertical direction can be can be compensated for by a small adjustment in the height of the centre column. Should cost next to nothing and take no more than an hour or two to make. My first panorama head was just such a design and consisted of a strip of wood to shift the camera back, and an L-bracket ( an old flash bracket) to hold the camera in portrait orientation, but the latter would not be needed for the painting panorama. The wooden bar fitted into the QR of the pan&tilt head of the cheap Velbon tripod. Panohead: http://www.johnhpanos.com/panhead.jpg First panorama shot with it 10 years ago: http://www.johnhpanos.com/spherical/zane5000/zane5000.html I love that you bothered to paint it black! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5641B94F.9080409%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
Bruno Postle wrote: On 21 October 2015 11:25:38 BST, bugbear wrote: As such, the lighting (just an archive room) was not only non uniform, but the map was in a different place (relative to the lighting) for each session. In this example, the visual discontinuity "just happens" to be on a session boundary. So - what's the best that can be done with this flawed data? In this situation you need to calibrate vignetting and camera response separately - then only optimise exposure and white balance in a project where shadows move around. I'm not sure how that would work; the "vignette" (AKA non uniform lighting) is much larger than a single image. Surely vignette calibration applies to (correct) a single image? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56276D58.8040201%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
bugbear wrote: But this capture fault applies (sadly) to the whole pano, but the particular difficulty only arises in one corner. So - how good should I expect the result to be? I have cut the problem down to a 4 image pano, which can be downloaded (for the next week) from this link: https://www.hightail.com/download/bXBaK2VqRnc1Ujd2WnRVag?cid=tx-020022073402&s=19102 I suspect my problem is caused by the fact that the (11 foot x 5 foot) map was actually captured in 4 sessions, moving and/or rotating the map to render successive quarters accessible to my tripod/camera. As such, the lighting (just an archive room) was not only non uniform, but the map was in a different place (relative to the lighting) for each session. In this example, the visual discontinuity "just happens" to be on a session boundary. So - what's the best that can be done with this flawed data? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56276822.6060507%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
bugbear wrote: T. Modes wrote: Thanks for stripping down. That makes debugging a lot easier. I found the issue and fixed in changeset daffca65ed45. It was an issue with the translation parameters and the center pano horizontal function, so on the first look total unrelated to the the photometric optimizer. Looks like my project is throwing up several bugs - I must be doing something unusual. Many thanks for this (and previous) bug fixes. The new version definitely fixed my reported bug. However, I have a more general difficulty. In my large panorama (173 images), after exposure and colour optimisation I still have a severe, localised, discontinuity in tone/colour. And yet, if I use the preview to select ONLY those two images, and optimise, they match each other nicely. Now, my data has at least one property which exposure optimisation may well not handle nicely. My image were captured as a mosaic using a moving tripod, which cast a shadow in a different place on the subject at each instance. Many areas of the pano do indeed have different pixel value on different sub-images. But this capture fault applies (sadly) to the whole pano, but the particular difficulty only arises in one corner. So - how good should I expect the result to be? Does the exposure optimiser work like the usual geometric optimiser, using (complex) alorithms to minimise overall error? If so I really would not expect what I'm seeing (unless there's a bug...). Or is it more direction/piecemeal, matching up successive pairs? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56275D6D.8050509%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
T. Modes wrote: Thanks for stripping down. That makes debugging a lot easier. I found the issue and fixed in changeset daffca65ed45. It was an issue with the translation parameters and the center pano horizontal function, so on the first look total unrelated to the the photometric optimizer. Looks like my project is throwing up several bugs - I must be doing something unusual. Many thanks for this (and previous) bug fixes. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56274CF2.8040307%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
bugbear wrote: bugbear wrote: I will now try my 173 image (*) "big map" That worked too (took a while though...) I hereby declare the bug fixed ;-) "Darn" I was premature. The optimisation was indeed (as of 7/10/2015) much better. But whilst trying to tweak it, I discovered another instance of the "no overlapping points found, Photometric optimisation aborted" bug. I have re-checked that the version of Hugin I'm running (2015.1.0.1e9a3ac68d2a) does indeed fix the original fault I reported. But the attached file shows a similar fault. (I've cut this down from 195 files to 2) BugBear Operating System: Linux 3.13.0-65-generic x86_64 Architecture: 64 bit Free memory: 5922844 kiB Hugin Version: 2015.1.0.1e9a3ac68d2a Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Hugins camera and lens database: /home/bugbear/.hugindata/camlens.db Multi-threading using C++11 std::thread and OpenMP Monitor profile: LIFEBOOK AH532 Libraries wxWidgets: wxWidgets 3.0 wxWidgets Library (wxGTK port) Version 3.0.0 (Unicode: wchar_t, debug level: 1), compiled at Dec 2 2013 15:56:33 Runtime version of toolkit used is 2.24. Compile-time GTK+ version is 2.24.22. libpano13: 2.9.19 Boost: 1.54.0 Exiv2: 0.23 SQLite3: 3.8.2 Vigra: 1.10.0 LittleCMS2: 2.5 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/562636F8.4090606%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout. exp2.pto Description: application/ptoptimizer-script
Re: [hugin-ptx] Paid Help Wanted with Hugin OSX 2014
Carlos Eduardo G. Carvalho (Cartola) wrote: Hi John, I've downloaded your images and I've made a fast successfull stitch here. You must first tell Hugin the correct lens parameters. Here the steps I've made in Hugin 2015 (which can probably be repeated at the 2014): - Loaded images in the wizard first button - Certified that the lens is a "circular fisheye" - Met "8" at the "Focal lenght" - Certified that the "Focal lehght multiplier" is "1" If everyonein the class/group is using the same (or identical) cameras, it might be worth talking a preliminary shot, rather carefully, with lots of overlaps, stitching it carefully, and using the (optimised) camera specs for all the other shots. In other words, do a calibration run. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/56210140.7040708%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
bugbear wrote: I will now try my 173 image (*) "big map" That worked too (took a while though...) I hereby declare the bug fixed ;-) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5614E2BB.2000204%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
Stefan Peter wrote: Please check it out and let the list know if your problems are fixed. With kind regards I have downloaded that version, and ran it on a small failure case (I deliberately had my camera on aperture priority mode, since light levels in the room could change - it had windows!) However I also had my camera on auto white balance, which was going crazy as I moved to different areas of the map. I can confirm that, in my 16 image "small map" the exposure optimise worked beautifully on both EV and Er/Eb, to the extent that the GL preview now appears seamless. I will now try my 173 image (*) "big map" BugBear (*) The map is around 5 feet by 10 feet, the archive had no table big enough to handle it in its entireity, I was using a cantilevered tripod (Benbo) with a 30 inch reach. I was taking around A4 size section with an 8Mpixel camera, to achieve 300 dpi. Each frame involved reposition the tripod. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5614D78C.4030807%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
bugbear wrote: I've added this to launchpad; #1500342 exposure optimiser incorrectly ignoring some pairs I note that this is now "Fixed in changeset f2e38d537544" Can anyone tell me (or estimate) how long such a fix will take to emerge in the packagers PPA? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/560E68F2.8050107%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] N pics, one non-interactive run, sane defaults
Thomas Güttler wrote: Hi Tduell, I use the shell daily, but only for interactive usage. I stopped scripting with the shell some years ago. I don't like the shell for scripting since: - The shell does not know the concept of exceptions or stacktraces. It knows about exit statuses (see next) - The shell goes to the next line if something is wrong. I want the programm to stop, not to proceed. Use the -e flag. -e Exit immediately if a pipeline (which may consist of a single simple command), a list, or a com‐ pound command (see SHELL GRAMMAR above), exits with a non-zero status. - The shell has major problems handling filenames which contain special characters. Use quotes. does this answer your question? Feel free to ask more details :-) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/560A590A.3050803%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
bugbear wrote: I had a look at your project, to see if I could learn something. I see the same behaviour here. I experimented a bit, and found that by dragging the images so they both have much smaller pitch values, the exposure optimises OK. I know it's not an answer to your question. Sounding a lot like a bug. Perhaps the pre-check doesn't implement the full transform model? I've added this to launchpad; #1500342 exposure optimiser incorrectly ignoring some pairs BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5608FAC7.80207%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Exposure tab - troubles
Terry Duell wrote: Hello Paul, On Tue, 22 Sep 2015 23:28:52 +1000, paul womack wrote: [snip] When I try to optimise the exposure I get the error message "no overlapping points found, Photometric optimisation aborted", but the preview clearly shows an extensive overlap area between the two images. Have I hit a bug, or have I misunderstood something? I had a look at your project, to see if I could learn something. I see the same behaviour here. I experimented a bit, and found that by dragging the images so they both have much smaller pitch values, the exposure optimises OK. I know it's not an answer to your question. Sounding a lot like a bug. Perhaps the pre-check doesn't implement the full transform model? BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5603BE13.4050605%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] How to best use Hugin/enfuse for super-resolution imaging
Terry Duell wrote: Further to this discussion, for information of any who are interested, I have been playing about with super-resolution (SR) imaging on and off for a while now, not with any Hugin tools but using bespoke software in Octave. Presumably there is no benefit to SR, until the limit of camera resolution and lens magnification is reached. Below this limit, simple tessalation (which hugin is rather good at) will give a reliable increase in subject resolution. bugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55E7FC98.70807%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] cylinder (not cylindrical) projection
Battle wrote: I would like to shoot a high resolution panorama of a circular room with vertical walls in rows moving from the floor to the ceiling. The ideal way to do this is to place the camera in the center and pan around the room for a complete row of images the full 360 degrees around, and then move the camera vertically for the next row of images. This is effectively a partial matrix panorama. Unless the room is tremendously high (like a ruined, empty, castle tower) I don't the advantage of this over a normal "single point" spherical high res pano. A single point (NPP) pano can still be extremely high res, if you use a long lens. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55DC28CF.2010801%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Minor triumph
David Haberthür wrote: I thought if maybe the final result is somewhere publicly available, so we can admire what has been done without having access to old maps ourselves :) ??? Old maps are readily available: http://www.oldmapsonline.org BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5592654E.4090804%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Minor triumph
David Haberthür wrote: Ciao Paul. This sounds like something I’d love to look at, being a bit of a mapping nerd myself. Do you have the images available somewhere publicly? I've attached the project file, which shows how the tieing together was done. To use the result, I output a multi layer tiff using nona, and did final image generation in Gimp. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5590FA92.80400%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout. modern10.pto Description: application/ptoptimizer-script
Re: [hugin-ptx] Re: which part of hugin removes the fish eye distorsion when creating a 360 panorama?
Forex Valdes wrote: Thanks Terry Let me see if I got it right. I am using equirectangular. ... or you do two steps in one projecting and removing distorsion? That's how it works. it's analagous to wanting to multiply by 2 and then by 3. Hugin multiplies by 6. :-) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5575B194.2070901%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] ptomorph
Bruno Postle wrote: On Mon 01-Jun-2015 at 23:59 +0100, Bruno Postle wrote: On 1 June 2015 13:15:59 BST, bugbear wrote: OK. Ptomorph has a tiny bug in its path handling. it uses the same path prefix for its output files as its PTO file. The upshot is, the path must be either absolute, or current. I'm creating my morphs in a sub-directory (snapily called morph). Oops, yes this needs fixing, the paths in the PTO file should be absolute or relative to the folder the PTO file is in. Thanks for the bug report, this should now be fixed in Mercurial. Note that ptomorph could still use testing and feedback since it is a prototype for possible future Hugin functionality. Yes - so far I have found that "it works", but for resolving the particular effects of creased/wrinkled maps I need a VERY large number of CPs. This may simply speak of the complexity of my creases, and that "simpler" creases would require less CPs. And these CPs, by the very nature and need cannot be optimised by Hugin. So you really need two classes of CP which hugin doesn't support. At the moment, while experimenting, I have to set the "stitch" CPs, optimise, and then NEVER OPTIMISE again. I then add lots of "morph" CPs, (which by their very nature are placed on points that show high errors) and use ptomorph, nona. By default it uses the 'Shepards' morph from ImageMagick, this is very stable and forces _all_ control points to line up - I could see this being integrated in the nona stitcher as a single option. http://www.imagemagick.org/Usage/distorts/#shepards ptomorph also has an option to approximate a fit for the whole image with a 'polynomial' distortion - this is smoother, but isn't as stable. It potentially could be integrated into the entire panotools optimisation/remapping stack, but this would be a bad idea if it isn't useful. http://www.imagemagick.org/Usage/distorts/#polynomial BTW, Nona is dramatically faster! BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/556EB6CB.3080200%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosaic mode - numerical effect of parallax
OK. Ptomorph has a tiny bug in its path handling. it uses the same path prefix for its output files as its PTO file. The upshot is, the path must be either absolute, or current. I'm creating my morphs in a sub-directory (snapily called morph). but: ptomorph -o ./morph/morph.pto orig.pto doesn't work, because the resulting morph.pto contains references to morph/morph_.png (etc). I have to (in Unix); ( cd morph; ptomorph -o morph.pto ../manual4morph.pto ) which works nicely. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/556C4CFF.6000405%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosaic mode - numerical effect of parallax
paul womack wrote: Practical conclusion; I need a means to deal with these errors in post processing, since it is not reasonable to eliminate them at shooting time. If only there were some way to map-out localised parallax errors. :-) http://www.bruno.postle.net/2012/ptomorph/ Announced to the list: https://groups.google.com/forum/#!topic/hugin-ptx/UripOuuYXCQ This is IDEAL for my purpose. However, when using this ALL control points must be "good", in that they truly indicate corresponding visual entities on the images. Whereas for Panotools, the effect of all the CPs are averaged into a small number of transform parameters; for ptomorph, each and every CP is acted on fairly directly. I suspect this means: "manual CPs only" I am discovering that you also need a LOT of CPs for ptomorph to give a truly perfect result for localised bumps. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/556C4977.8060304%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosiac model - convergence, accuracy?
Roger Broadie wrote: Isn't the answer to the situation shown in your diagram, where there is an isolated area of crumpling (and yes, I know it's only a diagram, but the situation does arise in reality), to take an extra photo from directly above the crumpled area and looking straight down on it and then force the use of that version with an Include mask. It's probably better to avoid control points in the actual crumpled area because of the parallax they embody. The situation is thus analogous to taking a photomosaic of a church elevation, where, for instance, it's vital to take images of protruding features like buttresses and receding features like windows from straight-on and then select those versions with masking. I think there was an early tutorial on the topic. This sounds extraordinarily plausible. Since the mosaic features only work on a 2D plane, any 3D features need special handling. I note from this tutorial: https://panospace.wordpress.com/2010/09/19/linear-panoramas-mosaic-tutorial/ that: "It is paramount that all CPs are on the same plane and no currently existing CP detector known to me meets the condition. Even small depth errors (e.g. relief on a wall) has big impact." I will go back and revue Terry Duell's super-successful stitch; (email of 27/05/15 03:34; avg: 0.48, std: 0.332, max 1.98). Terry says he (mainly) achieved this by removing bad control points; I suspect that CPs on 3D items might well fulfil a numeric definition of "bad". BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55681E20.6080806%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosiac model - convergence, accuracy?
Don Johnston wrote: Have you thought of using a piece of glass over the section you are photographing to get rid of the 3rd dimension (flatten the folds). Then you have to light it from an angle to ensure there is no glare. Take a look at this article on building a cheap book scanner. They aren't using any special type of glass. I am not allowed to touch the map at all in the achive - it's a hand drawn original from 1816. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55673A3F.6090200%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosiac model - convergence, accuracy?
Roger Broadie wrote: > grid-square P25, where the different shapes of the square as captured in e.g. images 17 and 23 illustrate graphically the problems of the parallax present in places in your images. You may have a point ;-) (see attached) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5566CE58.1070608%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosiac model - convergence, accuracy?
Roger Broadie wrote: Hello Paul, I thought your panorama was pretty good, but I don’t think you have fully overcome the problems of parallax resulting from creases and folds. The main cause, I suspect, is the camera tilt of 6 deg plus or minus from the vertical that the pitch values of the optimiser imply. I think that 3D items can cause trouble, even if the camera is shooting perfectly vertical. While the camera may be perfectly vertical w.r.t item directly beneath it, it is (of course) at an angle to items at the edge of its FOV. When the camera is translated in X,Y, (possibly Z), the item is now at a different point in the new FOV. Diagram attached. So while I would not normally expect to include the Plane Yaw and Pitch parameters in a truly planar photomosaic, it did seem worth trying them here. They do seem to help. Yes - if the map is NOT a true plane, but compose of multiple planes (or at least may be thought of as such) the sub-plane parameters may help, at least "on average". I attach panoa.pto, based on your file, which takes that approach and also includes some tuning of the control points and fuller lens optimisation. But I hung on to the h and v points, because I think they are one of Hugin’s strengths. I have resolved some remaining glitches, either with added control points – automatic control point finders seem to find otherwise featureless areas of grid-lines difficult to deal with – or with masking, but have not tried fully to resolve problems with the grid-square P25, where the different shapes of the square as captured in e.g. images 17 and 23 illustrate graphically the problems of the parallax present in places in your images. The end result yields an average error of 1.2 pixels and a maximum of 3.2, for a panorama matching that of pano.pto in size. Thanks for the observation - I'll go look! Broadly, I agree with Terry Duell (Wed, 27 May 2015 at 10:13:42 +1000) that the mosaic mode is working OK. He has given us a pto file (Wed, 27 May 2015 at 12:34:56 +1000) that does not use the Plane Yaw and Pitch parameters. It has an error of 0.5 average and 2.9 maximum, but is for a panorama of only about half the width of yours. Still pretty good, though, even at the full size. Agreed - thank for you effort and thoughts. My problem of how to best capture a 1816 map remains, of course. :-) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5566CCBF.2070501%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosiac model - convergence, accuracy?
Terry Duell wrote: Hello Paul, On Wed, 27 May 2015 08:40:18 +1000, Terry Duell wrote: I'll have a look at your project. I think it all boils down to 'good' and 'less good' control points. I did a little editing of control points, and removed the vertical and horizontal CPs, and the optimisation now looks pretty good. I did have to correct roll using 'move/drag' in the fast preview window. My project file is attached. Automatically finding good CPs on maps can be a bit problematic. For some projects it can end up being less work manually adding the CPs. I did use the new 'EditCP' tool in hugin-2015.0.0, which made finding and removing the worst of the CPs an easy task. How did you do this? Each image on the preview is tiny (since I have 30 images), so I don't see how you got benefit from the tool. You clearly know something I don't. Teach me, oh master! (in general I suspect people don't use the CP editor much; on my laptop, with a 1366x768 display, the image windows are only 669x381 pixels in full screen mode. (and see my other request for a "don't show the contrast enhanced square in this window") option. This result would suggest to me that the mosaic mode is working OK. Cheers, > Adding just one vertical line, in the one image, is all that is needed to fix it. Mean error 0.5, max 2.9. Perfect! The result is also surprisingly square, given the lack of all but 1 vertical and horizontal CPs. Well, except it's upside down... For purely cosmetic reasons, I gave it a 180 degree rotate (in move/drag), and centred it (in move/drag via X/Y edit) Anyway - I tried to center the pano, using mosaic move/drag to alter the X Y. I just though I'd do an optimise, just to be sure this "finished" pano was stable. And after 213 iterations, it converged again, upside down, pretty much back where it started. There is "some kind" of optimisation attractor which I don't understand, such that X Y are interacting with Y P R. I had thought (till now) that X Y Z only really had meaning realtive to each other (so that the position of the anchor was entirely arbitrary), but given the existence of such an attractor, it seemed there must be a "best position" for the anchor (which implies that X Y coordinates are not just relative to each other), so I added X and Y for the anchor to the optimisation variables and let the optimiser loose. It converged: avg: 0.008403 std: 0006875 max: 0.0617 with (anchor) X=-85, Y=0.7 which sounds suspiciously similar to the sort of optimisation that results in a tiny FOV (massive focal length). It just puts all the images in a tiny dot. It looks like the mosaic model makes the mapped images smaller (and hence CP pixel distances smaller) as X and Y are further from the origin. I believe this is the driver of the bogus attractor I'm seeing. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55659252.7030705%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mosiac model - convergence, accuracy?
paul womack wrote: (more experiments below) My more significant concern is that my "final" optimisation, has a disappointingly large error, and (indeed) shows stitching glitches on final output. Since my map is nigh 2 dimensional, and I went to considerable pains to shoot a narrow FOV from a good distance above the map, I believe that the mosaic model should be able to get VERY close to perfect on this image set, and yet it doesn't. For my project as uploaded the optimisation is: avg: 2.28 std: 1.80 max: 16.2 Suspecting that my map might be poorly printed, I removed all the horiz and vert control points, and just left the anchor with a fixed roll, to keep the pano "right way up". avg: 2.21 std: 2.18 max: 43.8 Which, despite being less constrained (more optimised) gives a worse result?! But If I now allow the anchor roll to be optimised (rotating the whole panorama, of course) I get the rather better: avg: 0.79 std: 0.57 max: 4.00 and it has swung the whole pano around 180 degrees. If anyone can explain what's going on, I'd be grateful. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/556467DB.3040607%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] sources, transcriptions, spelling mistakes, deductions
paul womack wrote: There seems to a underlying, unspoken theme in the recent discussions on variant/nested data. Wrong list (obviosuly). Nothing to see here :-) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/555D932B.2040607%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Tutorial on the new features in hugin-2015.0.0
Terry Duell wrote: Hello All, I have prepared a tutorial which highlights the new features in hugin-2015.0.0. It should show up here <http://hugin.sourceforge.net/tutorials/index.shtml> shortly. It probably isn't an essential tutorial, but it doesn't hurt to spread the gospel. If anyone has any suggested corrections/additions/deletions etc, please report them here. Reading this reminded me of an omission that was causing me some pain recently. I was making a big 'ol mosaic, and to keep the optimisation stable was selecting images in the preview (25 in total) 1 at a time, then optimising, with "Only use control points between image selected in preview window" enabled. This meant I had to keep toggling between the preview window and the Panorama editor window. It would have been (ahem) *MUCH* more convenient if I could have used the "ctrl T" shortcut to commence optimisation directly in the preview window. BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5559C01F.3060501%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Photographing maps - advanced mosaicing
Roger Broadie wrote: Paul Womack (BugBear) wrote on Wed, 13 May 2015 at 17:14:48 +0100, with a follow-up on Fri, 15 May 2015 at 09:01:07 +0100, about the procedure he intends to follow in photographing an historic map in an archive. I agree that the FOV is not a big problem; however I was having trouble with the preview window, including the Layout tab. Setting the Z to -0.5 (not -5!!) helped this. But I too hit the "optimal size" issue you note. BugBear Hello, Paul, Given that we have discussed this topic in the past, I should certainly be interested to hear how you get on when you visit your archive. I am not convinced that the total field of view creates a problem in this type of stitch. Since we need a rectilinear reproduction of a flat (or nominally flat) original, the total fov can never exceed 180deg, as I think you agree in your follow-up message. Originally I wondered if the very wide total fov that is possible with photomosaics might lead to degradation at the edges, but to my surprise I could detect none, and achieved no significant improvement by adjusting the settings to reduce the total field of view. I suspect that the calculations include so many decimal places that the necessary precision is retained. But if you do want to use an artificially small total fov, I don’t think setting an anchor Z at -5 is the answer. As I tried to explain in a post in this group on 1 Oct 2014, despite an apparent suggestion otherwise in the tutorial, the subject plane is at Z=-1. The imaginary panorama camera at the centre of the panosphere is at the origin (0,0,0). So Z=-5 implies that the camera for the anchor image is on the other side of the subject plane. I have just tried making that change on one of my old stitches and I found that the image concerned was ignored and there were no changes to the other parameters. To achieve what you want, I suggest you should set Z for the anchor image much closer to the subject plane than the panorama camera, but still on the same side. That suggests the anchor Z should be at, say, -0.8. I attach the pto file for the stitch I used to test the above. The images were taken hand-held and are rather old, so the lens introduces more distortion than might be the case nowadays. The set of images probably contain more overlap than is desirable, or indeed is needed if one is using the translation model, as we are here. I’ve updated the pto file using the 2014.0.0.5 version of hugin for 64-bit Windows and added in optimisation of Plane yaw and Plane pitch for the non-anchor images, though it makes very little difference. Sorry I can’t table the individual images. As it stands, the fov for the individual images is 52.7deg and the total fov is some 94deg, depending on where the boundaries are drawn. So this is not an extremely wide field of view, but that does not affect the principle. Setting Z=-5 for the anchor image had the effect I described above, although the stitch still looked OK in the fast preview window, since there was sufficient overlap to mask the absence of the anchor image. Setting Z for that image at -0.8 (and leaving the fov for the individual lenses non-optimisable and still at 52.7deg) reduced the overall fov after optimisation to 26deg. The stitch was still good and comparable to the unshrunk case. Probably the total field of view does not have a decisive effect on the stitch. However, reducing the fov did throw up one problem. For consistency and comparability I like to evaluate the error having set the canvas size in the stitcher tab to the optimal size. But I notice that changing the anchor Z to -0. 8 causes hugin to give a much smaller optimal size than when Z was 0 – a width of 1458 pixels instead of the original 6774 pixels – and a correspondingly small error. I’ve met this problem before. For some reason, the calculation does not seem to be based purely on the resolution of the original images, which is what I would expect. Maybe someone knows what is going on or what I might be doing wrong. At any rate, one work-around would be to enter the desired size by hand, perhaps using the value from the unshrunk fov as a guide. Roger Broadie -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55560C75.8050008%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Photographing maps - advanced mosaicing
Apologies; The net mosaic is limited to 180 degrees FOV, since you're using Rectilnear projection. But. Do NOT set the FOV "falsely narrow". If you do, the amount of yaw/pitch needed to correct skew in the image becomes artificially inflated. DAMHIKT. If the mosaic comes out with a very large FOV (being the aggregate of many sub-images with a reasonable FOV), simply set the Z of the anchor (the one image that doesn't have an optimised Z) to be less than 0; say -.5. Then reoptimise. Everything shrinks nicely. BugBear paul womack wrote: Still preparing to visit an archive, and capture a historic local map (1816) I think I'm ready! I took a load of photos of a test map, simply moving a Benbo tripod with its central column horizontal, camera pointing down onto my kitchen table. I had to tilt the camera up a bit to get the far side of the map. The images were pulled into hugin and a (false) narrow field of view set on the lens (this reduces the FOV of the final mosaic, avoiding projection difficulties). Control points were set using CPFind (multirow + stacked). I set one of the central images as anchor, "custom parameters" for optimise, and then optimised all X,Y (except the anchor). This gives a good first approx tessalation, which tends to be stable for the subsequent ops. I then added in Z, plane Yaw, plane Pitch, and re-optimised. I then added in YPR and re-optimised. (the anchor, of course, stays put during all this). I then added a full perimeter of horizontal and vertical control points around the map. I then (finally) did a full "optimise all" including the anchor, which (in effect) YPR'd the entire mosaic, so that it was (at last!) rectilinear. This (pretty much) worked out. I was missing some control points in tricky areas (revealed by the Layout view in preview) so I added those by hand, and there were some false control matches (which I simply deleted). The only issues in the final resulting stitch are where the map wasn't lying flat on the table, meaning that my target wasn't truly 2D. This can be resolved by taking smaller FOV images, thus more nearly approximating all pixels being taken from "infinity". (this concept, taken to its extreme, is the "line scan" technique) BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/A7C3.2060105%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Assertion error; Hugin 2014.0.0 on Lubuntu 14.04
bugbear wrote: Stefan Peter wrote: Hi BugBear I have updated the hugin and enblend/enfuse packages in ppa:hugin/next to the versions used in debian jessie. This should cure quite some problems with failing asserts. Please have a look, if these versions fix your problems I will move them over to ppa:hugin/latest But (see my previous post) my current "working" scenario was already to have ppa:hugin/next but NOT ppa:hugin/hugin-builds What PPA's should I have set up for your test? Just tried it with and without "hugin-builds" With: 2014.0.0.5da69bc383dd Without: 2014.0.0.5da69bc383dd Both work (no errors in About dialog or when viewing control points). BugBear -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/553501DE.4050002%40papermule.co.uk. For more options, visit https://groups.google.com/d/optout.
