Re: [hugin-ptx] Lens calibrating in comparison with JPG-out-of-cam and uncorrected RAW-processing
On 4 Jul 2013 13:48, Florian H wrote: So yesterday I asked myself: Is it possible to figure out the camera-intern control parameters for lens correction with out-of-the-box-JPGs? The Idea is to shot for each focal length ONE photo and let it save by the camera as RAW and (lens-corrected) JPG. Then process the RAW image without any distortion-correction. After that, the big question: Can Hugin stack these two images about each other, so that the uncorrected image is deformed (with the needed correction parameters) on top of the other? Yes this will definitely work: just load both photos and make sure they have different lens 'numbers'; set lots of control-points; then optimise a,b,c,d,e,v for the distorted photo only. This stacking technique should be foolproof, though I would still expect to get better results using the standard Hugin technique of stitching partially overlapping photos. -- Bruno -- 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/CAJV99ZgycSDjQdYBuS3WFBnzWVBOEmNMBBfodDhuVCnYqnuprg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] enblend/FreeBSD: can't blend more then 9 images
On 07/04/2013 07:58 PM, Thomas Zenker wrote: Am Freitag, 5. Juli 2013 01:46:19 UTC+2 schrieb Groogle: On Sunday, 30 June 2013 at 6:18:23 -0700, Thomas Zenker wrote: Am Sonntag, 30. Juni 2013 14:27:24 UTC+2 schrieb Cartola: 2013/6/29 Thomas Zenker t...@zenker.tk javascript: Running enblend 4.1.1 on FreeBSD 9.1 amd64 stable, it cannot blend more then 9 images. Vigra library throws an exception: enblend: cannot load image 20120702-125206-125507-09.tif enblend: Precondition violation! did not find a matching file type. (/usr/ports/graphics/vigra/work/vigra-1.9.0/src/impex/codecmanager.cxx:234) This message is misleading, as I can break the panorama in pieces of 9 images, blend them and blend the resulting partial panoramas without problem. This happens with all panoramas, no problem with 9 images, 10 are too much. Cache is enabled, 8G Ram. Did you use the option -m to increase the amount of memory used? Like -m 7000 in your 8GB system? Just not sure if that is what you meant when said Cache is enabled. I wanted to say, it is built with image cache enabled, and yes I tried it with -m 7000 also. I'm the maintainer for the FreeBSD enblend port, and I use exactly the same configuration as you: FreeBSD eureka.lemis.com http://eureka.lemis.com 9.1-STABLE FreeBSD 9.1-STABLE #0 r246254M: Sun Feb 3 10:40:40 EST 2013 groog...@gmail.com:/usr/obj/src/FreeBSD/svn/stable/9/sys/EUREKA amd64 I also have 8 GB of memory, though I'm coming to the conclusion that I should upgrade to at least 16 GB. But I don't have this particular problem, and I regularly blend up to 60 images. With only 8 GB this can take a while, but I don't see the problems you describe. enblend: cannot load image 20120702-125206-125507-09.tif enblend: Precondition violation! did not find a matching file type. This looks to me like this specific file is corrupt, though that doesn't fit what the remainder of the report. I occasionally end up with empty input files which trigger this kind of message. The images are not corrupt, I do the partial panos from a shell script taking the files which leaves nona. What kind of blending are you doing? Are you doing it from the stitcher tab or from the Makefile? Tried both ways. Can you reduce the size of the images and still reproduce the problem? If so, I could take a look. If not, how big are the images? The originals are 2000x3000 16bit tifs. For the pano, I'm doing at the moment, the intermediate files (nona output) have file sizes of 20-60 Mbytes. This problem arises with all panos with more than 9 images I have done. Also tried a different computer with similar setup at work, same result. Have changed TMPDIR pointing to a disk with plenty free disk space (250G). Very odd. I've stitched panos using more than 40 2Kx3K 16-bit TIFs, from Hugin, on 32-bit Linux (Debian Sid) with only 2GB RAM, without any problems beyond it taking about 6 hours (1.5GHz Celeron M, single-core processor). Even generated a 784MB 16-bit TIFF image once, but I don't remember how many 2Kx3K frames were in that one. Not helpful, I know, other than it makes me wonder if the difference is Linux vs FreeBSD. -- David W. Jones gnomeno...@gmail.com wandering the landscape of god http://dancingtreefrog.com http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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/51D69343.4040703%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Lens calibrating in comparison with JPG-out-of-cam and uncorrected RAW-processing
On 07/04/2013 10:44 PM, paul womack wrote: Bruno Postle wrote: On 4 Jul 2013 13:48, Florian H wrote: So yesterday I asked myself: Is it possible to figure out the camera-intern control parameters for lens correction with out-of-the-box-JPGs? The Idea is to shot for each focal length ONE photo and let it save by the camera as RAW and (lens-corrected) JPG. Then process the RAW image without any distortion-correction. After that, the big question: Can Hugin stack these two images about each other, so that the uncorrected image is deformed (with the needed correction parameters) on top of the other? Yes this will definitely work: just load both photos and make sure they have different lens 'numbers'; set lots of control-points; then optimise a,b,c,d,e,v for the distorted photo only. This stacking technique should be foolproof, though I would still expect to get better results using the standard Hugin technique of stitching partially overlapping photos. Why not just make a pano from RAW images, using lots of overlapping CP's, and let the good ol' optimiser both assemble the pano, AND calibrate your lens at the same time? That's what I did with my new (Panasonic TZ8) camera when I first got it. That's what I've always done. Never bothered to calibrate my lens(es) because they're all zoom lenses, so I suspect distortion changes as zoom changes, perhaps also as aperture changes. I've not shot both RAW and JPG. I'd be really surprised if in-camera processing can do any correction for lens distortion. Does the camera contain a full database of the possible lenses you could put on the camera (I use a DSLR)? If it does any kind of software distortion correction in camera, I can't imagine how it could do anymore correction than Hugin does, and quite possibly doesn't do it as well. Maybe new cameras are fancier now, but I'm highly doubtful that any of them can do any correction for lens distortion. Of course, probably someone knows different. Or some camera makers marketing departments are run by lunatics ... -- David W. Jones gnomeno...@gmail.com wandering the landscape of god http://dancingtreefrog.com http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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/51D69541.1060404%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Lens calibrating in comparison with JPG-out-of-cam and uncorrected RAW-processing
On 5 Jul 2013 10:43, Gnome Nomad wrote: Maybe new cameras are fancier now, but I'm highly doubtful that any of them can do any correction for lens distortion. Of course, probably someone knows different. Or some camera makers marketing departments are run by lunatics ... My (getting elderly now) lumix lx3 pocket camera does barrel distortion correction in-camera for JPEG files. I've never tried comparing it to RAW output, and clearly this approach wouldn't work for cameras that take generic lenses. -- Bruno -- 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/CAJV99ZiFrVzZ2v%3DppLYzDDWnzLP75EaXFTP%2Be6adPA6gEO%3DULQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Lens calibrating in comparison with JPG-out-of-cam and uncorrected RAW-processing
On 07/04/2013 11:51 PM, Bruno Postle wrote: On 5 Jul 2013 10:43, Gnome Nomad wrote: Maybe new cameras are fancier now, but I'm highly doubtful that any of them can do any correction for lens distortion. Of course, probably someone knows different. Or some camera makers marketing departments are run by lunatics ... My (getting elderly now) lumix lx3 pocket camera does barrel distortion correction in-camera for JPEG files. I've never tried comparing it to RAW output, and clearly this approach wouldn't work for cameras that take generic lenses. Apparently some Nikon DSLRs can do it, but only with Nikkor lenses: http://www.dpreview.com/forums/post/50461788 The process sacrifices some sharpness, crops the image somewhat, and doesn't necessarily do as good a job as outside-the-camera software processing does. I'd rather keep the sharpness and full image and do corrections outside the camera. But I never shoot JPG, just RAW. -- David W. Jones gnomeno...@gmail.com wandering the landscape of god http://dancingtreefrog.com http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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/51D69E0B.80105%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Lens calibrating in comparison with JPG-out-of-cam and uncorrected RAW-processing
Bruno Postle schrieb am 05.07.13 11:51: On 5 Jul 2013 10:43, Gnome Nomad wrote: Maybe new cameras are fancier now, but I'm highly doubtful that any of them can do any correction for lens distortion. Of course, probably someone knows different. Or some camera makers marketing departments are run by lunatics ... My (getting elderly now) lumix lx3 pocket camera does barrel distortion correction in-camera for JPEG files. I've never tried comparing it to RAW output, and clearly this approach wouldn't work for cameras that take generic lenses. Some high end cameras do this, although only for their own set of newer lenses. Hasselblad has DAC lens correction but I'm not sure if this is in-camera or provided by their Phocus software. The Leica M9 does it internally, Leica also provides coding of their older lenses. I bet these systems don't work with lenses from other manufacturers (e.g. Zeiss, Cosina and others have lenses with Leica M mount). Carl -- 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/51D6ADFF.1000106%40einem.net. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Lens calibrating in comparison with JPG-out-of-cam and uncorrected RAW-processing
On Fri, Jul 05, 2013 at 10:51:03AM +0100, Bruno Postle wrote: On 5 Jul 2013 10:43, Gnome Nomad wrote: Maybe new cameras are fancier now, but I'm highly doubtful that any of them can do any correction for lens distortion. Of course, probably someone knows different. Or some camera makers marketing departments are run by lunatics ... My (getting elderly now) lumix lx3 pocket camera does barrel distortion correction in-camera for JPEG files. I've never tried comparing it to RAW output, and clearly this approach wouldn't work for cameras that take generic lenses. The processing in the camera is getting cheaper and cheaper. In the old days you had to buy hardware to get for instance the magnification for the RED, BLUE and GREEN light rays to be the same. Nowadays, you can grab the image, and then just scale the resulting subimages in software on the camera. Much cheaper than expensive lenses. I wouldn't be surprised if barrel correction is also already done in the camera. As is already reported by Bruno as well. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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/20130705135308.GD15367%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
[hugin-ptx] Re: Hugin 2013.0rc1 released
Am Mittwoch, 3. Juli 2013 20:39:09 UTC+2 schrieb paolobenve: Bug (?): In simple interface, load images and wait till the align process end, than press crl-q or, from menu, file - close: hugin exits without loosing the work done, no confirmation is asked. Thanks for bug report. (The official link for bug reports is https://bugs.launchpad.net/hugin In the mailing list they can more easily forgotten.) This is fixed in the repository. Will be in RC2. Thomas -- 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/a6abb137-1473-42aa-9d86-24d3d9153825%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Re: bug cpclean and line control points
Am Dienstag, 2. Juli 2013 23:57:14 UTC+2 schrieb Jim Watters: I think the worst cp should always be removed. But would be happy with a flag to have this ability. In the default branch cpclean has now an option to include line cp for filtering. Thomas -- 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/bebe2d24-1f98-4b50-bb72-822cc05cbe49%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] enblend/FreeBSD: can't blend more then 9 images
Am Freitag, 5. Juli 2013 07:58:18 UTC+2 schrieb Thomas Zenker: Am Freitag, 5. Juli 2013 01:46:19 UTC+2 schrieb Groogle: On Sunday, 30 June 2013 at 6:18:23 -0700, Thomas Zenker wrote: Am Sonntag, 30. Juni 2013 14:27:24 UTC+2 schrieb Cartola: 2013/6/29 Thomas Zenker t...@zenker.tk javascript: Running enblend 4.1.1 on FreeBSD 9.1 amd64 stable, it cannot blend more then 9 images. Vigra library throws an exception: enblend: cannot load image 20120702-125206-125507-09.tif enblend: Precondition violation! did not find a matching file type. (/usr/ports/graphics/vigra/work/vigra-1.9.0/src/impex/codecmanager.cxx:234) This message is misleading, as I can break the panorama in pieces of 9 images, blend them and blend the resulting partial panoramas without problem. This happens with all panoramas, no problem with 9 images, 10 are too much. Cache is enabled, 8G Ram. Did you use the option -m to increase the amount of memory used? Like -m 7000 in your 8GB system? Just not sure if that is what you meant when said Cache is enabled. I wanted to say, it is built with image cache enabled, and yes I tried it with -m 7000 also. I'm the maintainer for the FreeBSD enblend port, and I use exactly the same configuration as you: FreeBSD eureka.lemis.com 9.1-STABLE FreeBSD 9.1-STABLE #0 r246254M: Sun Feb 3 10:40:40 EST 2013 groog...@gmail.com:/usr/obj/src/FreeBSD/svn/stable/9/sys/EUREKA amd64 I also have 8 GB of memory, though I'm coming to the conclusion that I should upgrade to at least 16 GB. But I don't have this particular problem, and I regularly blend up to 60 images. With only 8 GB this can take a while, but I don't see the problems you describe. enblend: cannot load image 20120702-125206-125507-09.tif enblend: Precondition violation! did not find a matching file type. This looks to me like this specific file is corrupt, though that doesn't fit what the remainder of the report. I occasionally end up with empty input files which trigger this kind of message. The images are not corrupt, I do the partial panos from a shell script taking the files which leaves nona. What kind of blending are you doing? Are you doing it from the stitcher tab or from the Makefile? Tried both ways. Can you reduce the size of the images and still reproduce the problem? If so, I could take a look. If not, how big are the images? The originals are 2000x3000 16bit tifs. For the pano, I'm doing at the moment, the intermediate files (nona output) have file sizes of 20-60 Mbytes. This problem arises with all panos with more than 9 images I have done. Also tried a different computer with similar setup at work, same result. Have changed TMPDIR pointing to a disk with plenty free disk space (250G). now I have tried it with reduced pano size of 4000x2000. The output of nona is really small. But same behaviour. of enblend. hugin and nona have no problems, so I had look at hugin sources: they are using a internal version of vigra! Could this be a hint? Thomas -- 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/02e8141a-4fde-41ea-b072-b9a3489eb0c6%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[hugin-ptx] Problem with Tortoise HG?
I've just tried synchronising and Tortoise is reporting that the last update/change was 8 weeks ago. I do not believe thsi is correct. Is there something wrong preventing the latest changes from being pulled? (Windowes XP 32 bit). Creating a cloned directory does not make any difference Cheers -- 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/187bd9b0-3dba-419e-ac46-b91cd6efac15%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Re: bug cpclean and line control points
On 2013-07-05 12:59 PM, T. Modes wrote: Am Dienstag, 2. Juli 2013 23:57:14 UTC+2 schrieb Jim Watters: I think the worst cp should always be removed. But would be happy with a flag to have this ability. In the default branch cpclean has now an option to include line cp for filtering. Thank you. I think this is the right way to do it. -- Jim Watters http://photocreations.ca -- 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/51D760F7.3040205%40photocreations.ca. For more options, visit https://groups.google.com/groups/opt_out.
