[hugin-ptx] Re: Big hugin project.
On Fri, May 1, 2009 at 19:58, rew wrote: > > I'm giving up. The resulting file is 3.4Gb. Apparently it got written > ok, but all "readers" have trouble. This is probably because the > IFD is beyond the 2Gb mark. (I've followed flow of code through > tifftopnm, and it SHOULD fail if it doesn't mmap the file. In practise > however it does mmap the file, and still fails. I haven't figured out > why yet.) > There was an issue with libtiff not being able to read large TIFF files - it tries to mmap and fails. I compiled once a patched version of libtiff for this, and it worked. See the image here: http://www.flickr.com/photos/sbprzd/2722213085/ and the patch described here: http://article.gmane.org/gmane.comp.misc.ptx/8910 Cheers, Seb --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
I've said it before, but I'll say it again: I think we need a "file type" that also tiles the images. There should be a lot less strain on the OS if there is, for example, a folder with an extension (e.g, MyImage.tiles), and within that, a directory structure to implement tiling. The most simple approach would be to choose a standard tile size (e.g, 1024x1024) and then dissect the image into tiles of that size, with the right-most column and bottom row perhaps not being entirely used. Optional support for caching down-sized tiles to speed up viewing could be added. I just don't like the idea of multi-GB TIFF files, because many programs operate on the assumption that the whole, decompressed image will fit into memory. Also, if something like this already exists, let me know! Ryan On May 1, 12:53 pm, Matthias Kabel wrote: > * rew (rew-googlegro...@bitwizard.nl) [090501 20:02]: > > > I'm giving up. The resulting file is 3.4Gb. Apparently it got written > > ok, but all "readers" have trouble. This is probably because the > > IFD is beyond the 2Gb mark. > > Hm, I'm creating panoramas with a resulting tif (with LZW compression) > between 2.3 GB and 2.6 GB. Debian 64bit Linux. Works fine here. The blending > process swaps een with 8GB of RAm, but it's working here. > > Kind regards > Matthias --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
* rew (rew-googlegro...@bitwizard.nl) [090501 20:02]: > I'm giving up. The resulting file is 3.4Gb. Apparently it got written > ok, but all "readers" have trouble. This is probably because the > IFD is beyond the 2Gb mark. Hm, I'm creating panoramas with a resulting tif (with LZW compression) between 2.3 GB and 2.6 GB. Debian 64bit Linux. Works fine here. The blending process swaps een with 8GB of RAm, but it's working here. Kind regards Matthias --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
I'm giving up. The resulting file is 3.4Gb. Apparently it got written ok, but all "readers" have trouble. This is probably because the IFD is beyond the 2Gb mark. (I've followed flow of code through tifftopnm, and it SHOULD fail if it doesn't mmap the file. In practise however it does mmap the file, and still fails. I haven't figured out why yet.) What we need is a file format that has 64-bit offsets allowing much larger files. I would suggest that just modifying tiff to have 8-byte pointers in a few places would be the best way to go. I'd call it bigtiff. Problem is It already exists. http://www.awaresystems.be/imaging/tiff/bigtiff.html http://www.remotesensing.org/libtiff/BigTIFFProposal.html So... has anybody tried compiling the hugin toolset with bigtiff support? I think I'm going to try. libtiff-4.0.0b3 has been compiled, seems to work. (and its tool ppm2tiff doesn't generate bigtiff files. :-( ) Roger. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
Update from my side After upgrading to ubuntu-jaunty-amd64, I can now run nona on bigger images. It used to crash with "out of memory", now it runs merrily along using 3.6G of RAM. Under 32-bit Linux, I had tried stitching this before, and thought it was coming along nicely, but then it crashed just before writing the final image. It seems as if nona mallocs space for the final image before writing it out to disk. This time it went up to 6.6G, made my machine with 8G swap a little, and then wrote out the image! neato! Lets see if enblend will handle big images too.. :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
On Mon, 2009-04-20 at 09:27 -0700, r.e.wolff wrote: > > > On Apr 20, 6:22 pm, "Bart.van.Andel" wrote: > > My first thought about images rendered black was that somehow you are > > (well, Hugin is) using a wrong value for the EV. Normally you can > > tweak the EV value (in the preview window, for instance) to alter the > > brightness of the image. If the EV is set to a very low value, the > > image will be rendered completely white, and if set to a very high > > value, it will be rendered completely black. Is this the case maybe? > > Ah! checked the PTO, and it's set to zero. This is a very low value, > so you > are expecting a completely white image, but it's black. Weird The exposure set in the preview is relative to the exposure set for the images. Check the images have an exposure value around 0 too. > > > Regarding the final image. I don't know if the zoomed in images cover > > the entire low res panorama, but if it does, the simplest solution is > > to remove this image from rendering by clicking the image number once > > in the preview window. If all positions were already correct, this > > will leave you with a high resolution panorama with all the data > > coming from the zoomed in images. > > No, the zoomed images cover only the 10 percent "interesting" areas. > The rest is "grass" and "sky". > > Roger. You could create a pano consisting of just the high res images, remap the low res pano to the same geometry, and then use enfuse to combine the two. If you use enfuse with the parameter --wContrast=1, it should pick the details out of the high resolution panorama. James --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
On 20 apr, 18:27, "r.e.wolff" wrote: > On Apr 20, 6:22 pm, "Bart.van.Andel" wrote: > > > My first thought about images rendered black was that somehow you are > > (well, Hugin is) using a wrong value for the EV. Normally you can > > tweak the EV value (in the preview window, for instance) to alter the > > brightness of the image. If the EV is set to a very low value, the > > image will be rendered completely white, and if set to a very high > > value, it will be rendered completely black. Is this the case maybe? > > Ah! checked the PTO, and it's set to zero. This is a very low value, > so you > are expecting a completely white image, but it's black. Weird Depends. What is really important is the difference between the EV from the input images and the EV as set in the preview window, maybe we are referring to different values (I didn't dive into any PTO files really)... > > Regarding the final image. I don't know if the zoomed in images cover > > the entire low res panorama, but if it does, the simplest solution is > > to remove this image from rendering by clicking the image number once > > in the preview window. If all positions were already correct, this > > will leave you with a high resolution panorama with all the data > > coming from the zoomed in images. > > No, the zoomed images cover only the 10 percent "interesting" areas. > The rest is "grass" and "sky". Hmm... Well, I can think of a workaround. 1. Render the panorama image, excluding the low res panorama as a source. Use a low resolution and no interpolation, to speed things up. Save as TIFF. 2. Use the inverted alpha channel of the generated panorama to generate a mask for the low resolution panorama. Using some convolution (thickening/thinning) to make the gaps a little smaller. 3. Finally, render the panorama at full resolution, including the now masked low resolution panorama. This is just theory, I haven't tried any of this in practice, but I'm pretty sure it will work. Best, Bart --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
On Apr 20, 6:22 pm, "Bart.van.Andel" wrote: > My first thought about images rendered black was that somehow you are > (well, Hugin is) using a wrong value for the EV. Normally you can > tweak the EV value (in the preview window, for instance) to alter the > brightness of the image. If the EV is set to a very low value, the > image will be rendered completely white, and if set to a very high > value, it will be rendered completely black. Is this the case maybe? Ah! checked the PTO, and it's set to zero. This is a very low value, so you are expecting a completely white image, but it's black. Weird > Regarding the final image. I don't know if the zoomed in images cover > the entire low res panorama, but if it does, the simplest solution is > to remove this image from rendering by clicking the image number once > in the preview window. If all positions were already correct, this > will leave you with a high resolution panorama with all the data > coming from the zoomed in images. No, the zoomed images cover only the 10 percent "interesting" areas. The rest is "grass" and "sky". Roger. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Big hugin project.
My first thought about images rendered black was that somehow you are (well, Hugin is) using a wrong value for the EV. Normally you can tweak the EV value (in the preview window, for instance) to alter the brightness of the image. If the EV is set to a very low value, the image will be rendered completely white, and if set to a very high value, it will be rendered completely black. Is this the case maybe? Regarding the final image. I don't know if the zoomed in images cover the entire low res panorama, but if it does, the simplest solution is to remove this image from rendering by clicking the image number once in the preview window. If all positions were already correct, this will leave you with a high resolution panorama with all the data coming from the zoomed in images. I hope this helps a bit. Best, Bart --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
