[hugin-ptx] Re: [OSX] Hugin 32bit vs. 64 bit and the way to go forward
Bruno Postle schrieb: On Mon 19-Apr-2010 at 14:17 -0700, Battle wrote: So where are my bottle necks? The optimization process in hugin proper in the 32 bit build seems slow. On smaller projects of 10 to 20 images the optimization tab can take almost as long as actually stitching the project. I don't know whether a 64 bit version of the Hugin UI would address this or if this is an issue with another sub program. Since I don't know where the optimization is taking place or if it is multithreaded or otherwise optimized for multiple core machines I think its not possible for me to answer whether a 64 bit build of Hugin is useful. Yes for big projects the optimisation is a bottleneck as it is single-threaded. As far as I know there is no plan to make this multi-threaded, or even if it is possible. The best way to speed up the optimisation is to exploit the problem structure when doing the optimisation. Currently a general purpose nonlinear least square minimiser is used in libpano This is very inefficient for large problems where the variables are only sparsely connected. A sparse levenberg marquardt algorithm would work wonders there. There is a fast implementation for 3D reconstruction problems that could be adapted to optimize panoramas http://www.ics.forth.gr/~lourakis/sba/. However, it is too inflexible (all pictures can only have the same number of parameters, no linking of parameters possible) for use within hugin or libpano. ciao Pablo -- 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
Re: [hugin-ptx] Re: Any way to reuse control points on a different set of images?
Oh, forgot to mention. I use panomatic 90% of the time. nick On Tue, Apr 20, 2010 at 4:57 PM, Bruno Postle wrote: > On Tue 20-Apr-2010 at 13:54 -0400, Nicolas Pelletier wrote: > > [snip hugin failing to set control points with >120 photos] > > > Just double checked. Biggest I made was 135 images. I had some problems >> but >> that was because that one was handheld :P Hugin took it all in! >> > > There is a problem with long-command-lines and Windows that messed-up the > way we used to call control point generators on Windows. > > This shouldn't now be a problem if you are using the up-to-date > autopano-sift-c settings - As the list of files is now supplied in a project > file and not on a command-line. > > -- > Bruno > > -- > 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 > -- 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
Re: [hugin-ptx] Re: (Patch-plugin practice) Enfuse and Enblend Gimp Plugins - Gsoc
Thanks for two of your emails. You are right. I used Gimp's plug-in tutorials to start. Because I have some background knowledge, I made the simple plugins in one or two hours, for exercising. Sorry for not documenting the work/reference well. During the recent exam period, I only managed to have less than a week looking at Gsoc organizations, communicating in Hugin list, writing the proposal, and following up. If I had more time, I would do further coding, or implement some image processing algorithms into the Gimp plugin. It is just the matter of time. I will keep in mind your comments for further work. Almost all of my work experience and recent studying is in Computer Vision, and Image Processing areas. I could not use code samples at work, which are more sophisticated and mature. The samples of Canny Edge Detection and K-means clustering for images were done years ago. I can do much better programs now. The other PCHIP C# module is more recent (PCHIP: Piecewise Cubic Hermite Interpolating Polynomial). The PCHIP routines were taken from Hugin lens_calibrate. It was compiled to be DLLs, and used in my C# programs. The C# program is large, with 10,000+ lines. What I uploaded is a small test module. Thank Hugin for the PCHIP C++ implementation. It is very useful. I am confident that I have the skills to accomplish this project: Enfuse and Enblend Gimp Plugins. Elle. On Tue, Apr 20, 2010 at 8:30 AM, Bart van Andel wrote: > Hi, > > I'm sorry, this is just for the crop/blur example. I missed your other > file, which is definitely more impressive. Again, sorry. > > Best, > Bart > > On 20 apr, 13:21, Bart van Andel wrote: > > Hi, > > > > I don't want to sound rude, > > -- > 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 > -- 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
Re: [hugin-ptx] gsoc/hugin/panotools meeting at LGM2010?
On Tue 20-Apr-2010 at 07:41 -0700, Alexandre Prokoudine wrote: As some of you know, there will be Libre Graphics Meeting conference again end of May (27-30) in Brussels. http://libregraphicsmeeting.org/2010/ So what about a group meeting? Are we likely to have students and mentors from Europe who could attend and meet each other face2face? The slot allocation hasn't happened yet, so we don't have a list of students. Last year there was a hugin-ptx GSoC meeting which was quite productive for the LightTwist GSoC project. Also last year we had a mentor/student meeting in London which was very useful, there is no obligation but it would be a good idea to meet up again in Brussels if Pablo can make it. -- Bruno -- 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
Re: [hugin-ptx] Re: Any way to reuse control points on a different set of images?
On Tue 20-Apr-2010 at 13:54 -0400, Nicolas Pelletier wrote: [snip hugin failing to set control points with >120 photos] Just double checked. Biggest I made was 135 images. I had some problems but that was because that one was handheld :P Hugin took it all in! There is a problem with long-command-lines and Windows that messed-up the way we used to call control point generators on Windows. This shouldn't now be a problem if you are using the up-to-date autopano-sift-c settings - As the list of files is now supplied in a project file and not on a command-line. -- Bruno -- 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
Re: [hugin-ptx] Re: [OSX] Hugin 32bit vs. 64 bit and the way to go forward
On Mon 19-Apr-2010 at 14:17 -0700, Battle wrote: So where are my bottle necks? The optimization process in hugin proper in the 32 bit build seems slow. On smaller projects of 10 to 20 images the optimization tab can take almost as long as actually stitching the project. I don't know whether a 64 bit version of the Hugin UI would address this or if this is an issue with another sub program. Since I don't know where the optimization is taking place or if it is multithreaded or otherwise optimized for multiple core machines I think its not possible for me to answer whether a 64 bit build of Hugin is useful. Yes for big projects the optimisation is a bottleneck as it is single-threaded. As far as I know there is no plan to make this multi-threaded, or even if it is possible. -- Bruno -- 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
Re: [hugin-ptx] TIF compression
On Mon 19-Apr-2010 at 14:24 -0700, Battle wrote: Does anyone know how the file compression works in hugin. TIFs are limited to 4GB, but there are compression options in hugin In other words if I'm generating a a 3gb tiff uncompressed and it ends up as 1GB, can I safely triple the size of the panorama or will that cause problems because the final output tif is generated first and then compressed. You should be ok, the TIFF files are written directly to disk, and the limitation is on the file size and not the size of the image. And in a related question if I switched to PNG or JPG ouput, when are those files generated and does this get me past the 4GB TIF file size limit? As far as I know PNG doesn't have this limitation. Hugin still uses TIFF for the intermediate remapped files, but if they are 'cropped' TIFF (the default) this shouldn't be a problem until you are doing _really_ big panoramas. -- Bruno -- 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
Re: [hugin-ptx] Mosaic drag mode + keeping Tr parameters consistency on roll patch (vetting exercise)
On Tue 20-Apr-2010 at 21:06 +0200, Oskar Sander wrote: Any conclusions on including in trunk? I've committed it, as I couldn't have (easily) stitched the mosaic sent to the list a couple of days ago without it. I still think that maybe it should switch automatically instead of having a pull-down menu, but there is no reason why it can't be part of the trunk until then. -- Bruno -- 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
Re: [hugin-ptx] Problem with German Special characte rs (Ü etc.)
On Tue 20-Apr-2010 at 08:45 +0200, ym12de wrote: here is the output of the 'locale' command : LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" ... Looks good to me, sorry no more ideas what the problem might be. -- Bruno -- 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
Re: [hugin-ptx] Re: enblend error: excessive overlap detected; remove one of the images
I would agree with you. I was working from within Hugin when I encountered this error. The preview seemed fine but the stitching piece failed. On Sat, Apr 17, 2010 at 3:51 PM, Erik Krause wrote: > Am 17.04.2010 21:17, schrieb Marques joseph: > > > This is the first time I have ever gotten this error >> > > This is by far the silliest "enhancements" of enblend 4. Apparently it was > introduced to prevent users erroneously use enblend instead of enfuse: > http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/rev/5c2c0a81fcb3 > > This is highly annoying and completeley useless. A stop error is simply > inappropriate in this case. It doesn't even work reliably. I filed a bug > report: http://tinyurl.com/y3fvnmx Feel free to add a comment... > > -- > Erik Krause > http://www.erik-krause.de > > > -- > 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 > -- 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
Re: [hugin-ptx] Mosaic drag mode + keeping Tr parameters consistency on roll patch (vetting exercise)
Any conclusions on including in trunk? Cheers 2010/4/12 Oskar Sander > > > 2010/4/10 Bruno Postle > > It is probably ok as is, but I'm not sure if it needs the option to switch >> modes. My understanding is that rotating the scene makes no sense when >> there are XYZ offsets, similarly XY translation makes no sense when there >> are no XY offsets. I think I need to do some tests, but I don't know when. >> >> > I think it is good to make it an explicit option to the user: > > * One reason is that it would be good for the user (i think) to be able to > start in the drag-mode to make a outline before the first optimization run. > In that case all camera parameters start at zero and a automagic option > would have to guess what the user wants to do. > > * One other reason maybe is that even for a classical panorama, I may > optimize on X&Y in order to compensate for a small change in camera > position, so there may be a small X & Y displacement. (or is this scenario > irrelevant?) > > > Abount Z shift: I'll start a separate thread on this topic, as I have more > queries on how to use it... > > > > -- > /O > -- /O -- 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
Re: [hugin-ptx] Re: Any way to reuse control points on a different set of images?
That... I'm not aware. I'll keep that in the back of my mind as something to try... The biggest I made were... Just double checked. Biggest I made was 135 images. I had some problems but that was because that one was handheld :P Hugin took it all in! nick On Tue, Apr 20, 2010 at 12:15 PM, RickyRicky wrote: > Nicolas, > > That sounds like an awesome option except... Isn't there a limit to > the number of photos that can be in hugin? Something like 120? I've > hit it before which was one of the main reasons I never tried anything > even close to what you're suggesting below... > > Thanks, > Ricardo > > On Apr 19, 7:08 am, Nicolas Pelletier > wrote: > > I don't think it's in the official releases yet, but there is the new > stack > > feature. > > > > Basically, all the images that are different exposures of the same image, > > you assign them the same stack number. Then, whatever the optimization > you > > do, all of them will end up at exactly the same place. > > > > Output your panorama with all exposure layers, and you get all your pano > for > > HDR. > > > > IMHO, it's the best option (and the one I currently use). > > > > nick > > > > > > > > > > > > On Fri, Apr 16, 2010 at 6:16 PM, RickyRicky wrote: > > > cri, > > > > > I had originally renamed all my different exposure files to match up > > > with the original exposure... That's not too bad but I think your > > > "legit" method of just applying a different exposure's .pto file as a > > > template is a bit better and more convenient. > > > > > I'll let you know how it works out! > > > > > BTW - Yes... Using a great tripod is a must when your panorama is 240 > > > photos.. =) > > > > > Ricky > > > > > On Apr 16, 2:33 pm, cri wrote: > > > > Have you tried to use a template? Just load all the photo at the same > > > > exposure level and go through all the needed passages to get the > final > > > > panorama. Then save the project as pto file. Now start a new poject, > > > > load all the images at a different exposure level and select > "File->Apply > > > template". In the dialog select the previously saved pto file > > > > > > and you will get all the parameters loaded on the new exposure level > > > > images. In this way you could save a panorama for every exposure > > > > level. > > > > To get the best out of this procedure you need to take all the images > > > > from a tripod. > > > > > > Regards > > > > Cristian > > > > > > On 16 Apr, 20:52, RickyRicky wrote: > > > > > > > Gents, > > > > > > > I have shot a few high resolution night time 180 degree panorama > but I > > > > > think I've been doing it wrong. > > > > > > > My typical workflow is to shoot from three to six images of each > > > > > frame, then to HDR or exposure blend these photos together and THEN > to > > > > > HDR the resulting images. > > > > > > > That workflow works but if you want to make any changes to how the > > > > > image is HDR'ed or exposure blended, it means you have to start all > > > > > over again from the beginning. > > > > > > > I've been thinking, why don't I create panoramas from each > bracketed > > > > > exposure using hugin, and then HDR and/or exposure blend the > resulting > > > > > panoramas? > > > > > > > The problem is.. Hugin will most likely not select the same > control > > > > > points for the various different panoramas since at varying > exposures, > > > > > some control points will be more visible, and others will not. > > > > > > > Is there any way to force hugin to use the same control points for > a > > > > > different set of images? > > > > > > > Thanks for any help! I'm happy to show my work if y'all are > > > > > interested in seeing what I've been working on so far... > > > > > > >http://www.rickyricky.net/Photography/Panoramas/My-Panoramas > > > > > > > Thanks, > > > > > Ricardo Meleschi > > > > > > > -- > > > > > 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 athttp:// > > > groups.google.com/group/hugin-ptx > > > > > > -- > > > > 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 athttp:// > > > groups.google.com/group/hugin-ptx > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "hugin a
[hugin-ptx] Re: Any way to reuse control points on a different set of images?
Nicolas, That sounds like an awesome option except... Isn't there a limit to the number of photos that can be in hugin? Something like 120? I've hit it before which was one of the main reasons I never tried anything even close to what you're suggesting below... Thanks, Ricardo On Apr 19, 7:08 am, Nicolas Pelletier wrote: > I don't think it's in the official releases yet, but there is the new stack > feature. > > Basically, all the images that are different exposures of the same image, > you assign them the same stack number. Then, whatever the optimization you > do, all of them will end up at exactly the same place. > > Output your panorama with all exposure layers, and you get all your pano for > HDR. > > IMHO, it's the best option (and the one I currently use). > > nick > > > > > > On Fri, Apr 16, 2010 at 6:16 PM, RickyRicky wrote: > > cri, > > > I had originally renamed all my different exposure files to match up > > with the original exposure... That's not too bad but I think your > > "legit" method of just applying a different exposure's .pto file as a > > template is a bit better and more convenient. > > > I'll let you know how it works out! > > > BTW - Yes... Using a great tripod is a must when your panorama is 240 > > photos.. =) > > > Ricky > > > On Apr 16, 2:33 pm, cri wrote: > > > Have you tried to use a template? Just load all the photo at the same > > > exposure level and go through all the needed passages to get the final > > > panorama. Then save the project as pto file. Now start a new poject, > > > load all the images at a different exposure level and select "File->Apply > > template". In the dialog select the previously saved pto file > > > > and you will get all the parameters loaded on the new exposure level > > > images. In this way you could save a panorama for every exposure > > > level. > > > To get the best out of this procedure you need to take all the images > > > from a tripod. > > > > Regards > > > Cristian > > > > On 16 Apr, 20:52, RickyRicky wrote: > > > > > Gents, > > > > > I have shot a few high resolution night time 180 degree panorama but I > > > > think I've been doing it wrong. > > > > > My typical workflow is to shoot from three to six images of each > > > > frame, then to HDR or exposure blend these photos together and THEN to > > > > HDR the resulting images. > > > > > That workflow works but if you want to make any changes to how the > > > > image is HDR'ed or exposure blended, it means you have to start all > > > > over again from the beginning. > > > > > I've been thinking, why don't I create panoramas from each bracketed > > > > exposure using hugin, and then HDR and/or exposure blend the resulting > > > > panoramas? > > > > > The problem is.. Hugin will most likely not select the same control > > > > points for the various different panoramas since at varying exposures, > > > > some control points will be more visible, and others will not. > > > > > Is there any way to force hugin to use the same control points for a > > > > different set of images? > > > > > Thanks for any help! I'm happy to show my work if y'all are > > > > interested in seeing what I've been working on so far... > > > > >http://www.rickyricky.net/Photography/Panoramas/My-Panoramas > > > > > Thanks, > > > > Ricardo Meleschi > > > > > -- > > > > 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 > .com> > > > > For more options, visit this group athttp:// > > groups.google.com/group/hugin-ptx > > > > -- > > > 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 > .com> > > > For more options, visit this group athttp:// > > groups.google.com/group/hugin-ptx > > > -- > > 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 > .com> > > For more options, visit this group at > >http://groups.google.com/group/hugin-ptx > > -- > 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 i
[hugin-ptx] gsoc/hugin/panotools meeting at LGM2010?
Hi, As some of you know, there will be Libre Graphics Meeting conference again end of May (27-30) in Brussels. For those who don't know much about it, links to visit are: http://libregraphicsmeeting.org/2010/ http://www.libregraphicsworld.org/articles.php?article_id=15 Yuv is not coming AFAIK, but Bruno will be in Brussels, and Pablo is not exactly far away in purely geographical terms :) I know that a lot of active community members are in Europe, and even though the bloody Hephaestus is making steampunk coming true, railroads are still somewhat accessible :) So what about a group meeting? Are we likely to have students and mentors from Europe who could attend and meet each other face2face? Last year there was a hugin-ptx GSoC meeting which was quite productive for the LightTwist GSoC project. Would someone even be interested in giving a talk? In that case links to visit would be: http://libregraphicsmeeting.org/2010/signup.php http://create.freedesktop.org/wiki/Conference_2010/Submit_Talk For those who can't attend live video streaming from the venue is planned this year. Alexandre -- 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
Re: [hugin-ptx] Re: [OSX] Hugin 32bit vs. 64 bit and the way to go forward
Hi Battle and others, I mailed Battle in an off-list mail, and now repeated in < http://old.nabble.com/enblend-out-of-memory-error-td28250757.html>, that Ingemar Bergmark also made openmp enabled enblend/enfuse builds. He did this for (Snow)Leopard ppc/i386/x86_64. So no ppc64 (G5) builds. Harry 2010/4/20 Harry van der Wolf > Hi Battle and others, > > Threading is a long standing wish for Hugin on several areas and might > become one of the GSOC 2010 projects, that's all I can say about it. > > Yesterday evening I built the following stand-alone enblend/enfuse > versions: > - (Snow)Leopard Universal 32bit OpenMP enabled. > - (Snow)Leopard Universal 64bit OpenMP enabled. > - (Snow)Leopard Universal 64bit. > > I already had the 32bit dynamically compiled (Snow)Leopard OpenMP enabled > in the bundle and I already had the 32bit Tiger standalone build without > openmp, as Tiger doesn't support OpenMP. It doesn't make sense to make a > (Snow)Leopard non-openmp enabled version as that would be the same as the > Tiger version. > > I'm now thinking of 2 options: > - All these enblend/enfuse versions will be delivered with the future hugin > builds so that everyone can pick his/her favourite version or "hardware > bound" version. (another 25MB boost of the bundle dmg image). > - Deliver the hugin bundle with 32bit openmp enabled and tiger > enblend/enfuse versions, like 5102. And a separate enblend/enfuse package > like I did in the past. > > This week I will (try to) build a 64bit Hugin version. We could at least > see what it does in (Snow)Leopard. > I say try, as it is at least 1½ years ago that I built the last 64bit > version. > Note also that some part of it will remain 32bit as wxmac (for the gui) has > problems on 64bit, at least it had "some time ago" (something else that > needs analysis). I do not know yet whether the optimize step will be 32bit > or 64bit. I think that's one of the steps compiled into the "big"hugin > itself and would therfor be 32bit as well. Nona will be 64bit as it is a > stand-alone part of Hugin. > > > Harry > > > > 2010/4/19 Battle > > HI Harry, >> Likewise, let me say thanks for making the OSX builds. >> >> Here is my experience on an early 2009 Mac Pro Quad xeon (Nehalem) >> 2.93 MHz intel 24GB RAM 10.6 Snow Leopard. This machine will hyper >> thread so it acts like 8 cores. I realize this puts me on the high end >> of the hugin user base in terms of hardware. None the less... >> >> I downloaded enblend-openmp and enfuse-openmp from Source Forge in 64 >> bit versions (part of enblend 4.0 download), moved the folder to my >> applications folder, and set preferences in Hugin to run the openmp >> versions as alternate enblend and enfuse versions. I'm using your 32 >> bit build svn 5102 to do this. This works great for enblend. I >> haven't tried enfuse. In fact I just built a pano resulting in a >> 3.2GB uncompressed tiff that enblend used up about 12GB real and 12GB >> virtual memory use out of the 24GB real memory on the machine >> according to Activity Monitor. So this enblend 64 bit build clearly >> resolves the enblend out of memory error that I wrote about in another >> post. Also nona takes good advantage of the multiple cores/threads >> on this machine. Nona processed just under 100 12MP jpg images to >> tiff in about 7 minutes or so. That's just under 4.5 seconds an image >> on average reading from one drive and writing to another. Not bad. >> Enblend-openmp 64 bit ran and hugin wrote the final output in about 9 >> minutes, for a total of under 17 minutes overall. Again not bad. >> >> So where are my bottle necks? The optimization process in hugin >> proper in the 32 bit build seems slow. On smaller projects of 10 to >> 20 images the optimization tab can take almost as long as actually >> stitching the project. I don't know whether a 64 bit version of the >> Hugin UI would address this or if this is an issue with another sub >> program. Since I don't know where the optimization is taking place or >> if it is multithreaded or otherwise optimized for multiple core >> machines I think its not possible for me to answer whether a 64 bit >> build of Hugin is useful. I can't find anything in activity monitor >> but a couple of threads in Hugin and an increase in the CPU time. So >> it looks like the optimization is single threaded and only uses one >> cpu. But this is the place where I'd get the most improvement at the >> moment, and it seems to me where increasing capability of the the >> hardware is taking us.Maybe someone else in the community can >> respond to how the optimization works, what the possibilities are, and >> whether 64 bit processing would actually help. >> >> I note that from your site http://panorama.dyndns.org/macoverview.php >> that over 80% of your downloads are intel core 2 or better which will >> run Leopard. My oldest machine at this point is a intel core 2 duo >> running Tiger. I'm a bit too lazy to update it Leopard j
Re: [hugin-ptx] TIF compression
Hi Battle and others, Some inevitable history to start this reply. In April/May/June 2009 I worked on patched tiff libraries for enblend/enfuse to overcome the 4GB limit for tiffs on OSX. I brought some of these binaries "in the open" for testing and a dutch profesional photographer (nickname Jannes), making huge panos, has tested these builds. At that moment there were problems with big images (tiff, jpg, png) having horizontal and vertical lines in them and that "patched tiff" development road stopped more or less. It doesn't make sense to create 4+ GB tiffs as the tiffs below that limit already are unusable for another reason. Second, and for me most important reason, was that my MacBook was fried early July 2009 (which most users of this community might remember) and I decided to go back to (cheap) Linux which I had used for many years (since 1993 partly and since 2000 completely until 2007). However, after 2 months I decided to buy a Mac again as nothing can beat the MacOSX (this despite the fact that I hate all the semi-religional, apple-protectionism marketing spam from prophet Steve Jobs). This 4GB+ panos are only for the very few among us. For me it's not a priority at all especially as I won't use them myself (and you may call that selfish). Now that I have built the several enblend/enfuse versions I might as well build another 64bit tiff patched enblend/enfuse in the near future. I don't promise anything, maybe I will. Hoi, Harry 2010/4/19 Battle > Does anyone know how the file compression works in hugin. TIFs are > limited to 4GB, but there are compression options in hugin -- LZW, > deflate, packbits. They yield pretty good compressions around 50 to > 75% reduction. Does this reduction happen prior of the final image > TIF assembly, or after. In other words if I'm generating a a 3gb tiff > uncompressed and it ends up as 1GB, can I safely triple the size of > the panorama or will that cause problems because the final output tif > is generated first and then compressed. In this example that would be > a 9GB uncompressed over double the limit before compression. > > And in a related question if I switched to PNG or JPG ouput, when are > those files generated and does this get me past the 4GB TIF file size > limit? > > Thanks > Battle > > -- > 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 -- 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
Re: [hugin-ptx] Re: [OSX] Hugin 32bit vs. 64 bit and the way to go forward
Hi Battle and others, Threading is a long standing wish for Hugin on several areas and might become one of the GSOC 2010 projects, that's all I can say about it. Yesterday evening I built the following stand-alone enblend/enfuse versions: - (Snow)Leopard Universal 32bit OpenMP enabled. - (Snow)Leopard Universal 64bit OpenMP enabled. - (Snow)Leopard Universal 64bit. I already had the 32bit dynamically compiled (Snow)Leopard OpenMP enabled in the bundle and I already had the 32bit Tiger standalone build without openmp, as Tiger doesn't support OpenMP. It doesn't make sense to make a (Snow)Leopard non-openmp enabled version as that would be the same as the Tiger version. I'm now thinking of 2 options: - All these enblend/enfuse versions will be delivered with the future hugin builds so that everyone can pick his/her favourite version or "hardware bound" version. (another 25MB boost of the bundle dmg image). - Deliver the hugin bundle with 32bit openmp enabled and tiger enblend/enfuse versions, like 5102. And a separate enblend/enfuse package like I did in the past. This week I will (try to) build a 64bit Hugin version. We could at least see what it does in (Snow)Leopard. I say try, as it is at least 1½ years ago that I built the last 64bit version. Note also that some part of it will remain 32bit as wxmac (for the gui) has problems on 64bit, at least it had "some time ago" (something else that needs analysis). I do not know yet whether the optimize step will be 32bit or 64bit. I think that's one of the steps compiled into the "big"hugin itself and would therfor be 32bit as well. Nona will be 64bit as it is a stand-alone part of Hugin. Harry 2010/4/19 Battle > HI Harry, > Likewise, let me say thanks for making the OSX builds. > > Here is my experience on an early 2009 Mac Pro Quad xeon (Nehalem) > 2.93 MHz intel 24GB RAM 10.6 Snow Leopard. This machine will hyper > thread so it acts like 8 cores. I realize this puts me on the high end > of the hugin user base in terms of hardware. None the less... > > I downloaded enblend-openmp and enfuse-openmp from Source Forge in 64 > bit versions (part of enblend 4.0 download), moved the folder to my > applications folder, and set preferences in Hugin to run the openmp > versions as alternate enblend and enfuse versions. I'm using your 32 > bit build svn 5102 to do this. This works great for enblend. I > haven't tried enfuse. In fact I just built a pano resulting in a > 3.2GB uncompressed tiff that enblend used up about 12GB real and 12GB > virtual memory use out of the 24GB real memory on the machine > according to Activity Monitor. So this enblend 64 bit build clearly > resolves the enblend out of memory error that I wrote about in another > post. Also nona takes good advantage of the multiple cores/threads > on this machine. Nona processed just under 100 12MP jpg images to > tiff in about 7 minutes or so. That's just under 4.5 seconds an image > on average reading from one drive and writing to another. Not bad. > Enblend-openmp 64 bit ran and hugin wrote the final output in about 9 > minutes, for a total of under 17 minutes overall. Again not bad. > > So where are my bottle necks? The optimization process in hugin > proper in the 32 bit build seems slow. On smaller projects of 10 to > 20 images the optimization tab can take almost as long as actually > stitching the project. I don't know whether a 64 bit version of the > Hugin UI would address this or if this is an issue with another sub > program. Since I don't know where the optimization is taking place or > if it is multithreaded or otherwise optimized for multiple core > machines I think its not possible for me to answer whether a 64 bit > build of Hugin is useful. I can't find anything in activity monitor > but a couple of threads in Hugin and an increase in the CPU time. So > it looks like the optimization is single threaded and only uses one > cpu. But this is the place where I'd get the most improvement at the > moment, and it seems to me where increasing capability of the the > hardware is taking us.Maybe someone else in the community can > respond to how the optimization works, what the possibilities are, and > whether 64 bit processing would actually help. > > I note that from your site http://panorama.dyndns.org/macoverview.php > that over 80% of your downloads are intel core 2 or better which will > run Leopard. My oldest machine at this point is a intel core 2 duo > running Tiger. I'm a bit too lazy to update it Leopard just because > its a home machine that is only used for email, internet, and > generating light correspondence mostly by other family members. But > if I needed to run hugin on it and could get the the productivity > gains of 64 bit enblend I wouldn't hesitate for a moment to go to > Leopard. > > Thanks again for your OSX builds. > Battle > > > On Apr 17, 5:53 am, Harry van der Wolf wrote: > > Hi mac users, > > > > (A long mail). > > > > I have not
[hugin-ptx] Re: (Patch-plugin practice) Enfuse and Enblend Gimp Plugins - Gsoc
Hi, I'm sorry, this is just for the crop/blur example. I missed your other file, which is definitely more impressive. Again, sorry. Best, Bart On 20 apr, 13:21, Bart van Andel wrote: > Hi, > > I don't want to sound rude, -- 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: (Patch-plugin practice) Enfuse and Enblend Gimp Plugins - Gsoc
Hi, I don't want to sound rude, but how exactly can we see your coding skills from these source files? From what I see: - You have successfully set up a build environment to build plugins for GIMP. - You can make a "hello world" plugin for GIMP, which is basically taken literally from [0] with only a few textual changes. - You can change 0 into height/4, 0 into width/5 and width into width - width/5. Another example taken from [1]. - You cannot create the right diff. The diff you made transforms your file back into the original, so it can't be used to take the original file and transform it into yours. - Where are the credits for the original author? I'm sorry but you haven't convinced me yet. I know I'm not mentoring (nor have I contributed a lot of code) but I don't think this shows the level we need for a GSOC project. Maybe you have something else to show? [0] http://developer.gimp.org/writing-a-plug-in/1/hello.c [1] http://developer.gimp.org/writing-a-plug-in/3/myblur3.c -- Bart On 20 apr, 01:03, Elle Yan wrote: > Hi, > > Sorry for the late reply. I just got a chance to organize some source code > files. I will have plenty of time in the summer (from May). Thank you very > much for all suggestions of getting involved in open source development. It > is really helpful. I am excited to contribute to Hugin and open source > community. I learned quite a lot about open source before, but think taking > some good actions from now is good. > > This Gsoc project will be a wonderful opportunity for me to start. I have > uploaded some source code in Hugin Google Groups: > > http://groups.google.com/group/hugin-ptx/web/Sample%20source%20code.zip > > or, the Sample source code.zip file > at:http://groups.google.com/group/hugin-ptx/files?upload=1 > > I also uploaded another zip file, Hugin patch-screenshots.zip, in the same > directory. That is my patch work to support the application of Hugin Gsoc > project, Enfuse and Enblend Gimp Plugins. I have write a description for > those files in the first email. > > I have shared source code before, and I agree that it is really great to > give back. Thank you. > > Elle. > > > > > > On Thu, Apr 15, 2010 at 9:12 AM, Yuval Levy wrote: > > I should be packing boxes and the computer should be already in one of > > them. > > so concise and to the point: > > > On April 15, 2010 01:24:13 am Elle Yan wrote: > > > I should have asked how to send a patch. > > > or read the messages on this mailing list. I think it was Antoine that > > asked. > > Learning from other peoples questions and answers is an important skill in > > Open Source. > > > > Since everyone in the mailing list can see the email > > > addresses of the senders, why are they private information? > > > everybody can see my phone number in the phone book but it is still private > > information and an unsolicited call on it without permission is not a good > > thing. > > > > > ... maybe you can explain why I didn't notice you in this community > > > > before? > > > > I just started to communicate in the community recently. Before, when I > > > reviewed the code base, and found very useful sources, I made use of > > them, > > > e.g. spline.cpp. > > > OpenSource 101: FEEDBACK. Saying "Thank You" when making use of the code. > > > > > can you share some links to code you committed in the repository of the > > > > mentioned projects? > > > > I am happy to share some. I did not often commit to the repository of > > large > > > software though. > > > I don't expect you to have commit right to the repository of large > > software. > > > OpenSource 102: Contribution starts with communication. > > > Usually forwarding the changes to a maintainer (somebody with access to the > > repository); or publishing a patch somewhere. Subsequently the maintainer > > may > > or may not accept the patch. If the patch is accepted, it leaves a trace in > > a > > commit and most maintainers will credit the contributor in the commit log. > > For > > an example, see [0]. > > > > Usually, I code for the software out of my own interest or > > > goal. For example, I code within the code base, to make and change some > > > features as I needed. Or, I use their routines or libraries. It is not > > the > > > formal commit. > > > OpenSource 103: it is common for people to code out of their own interest. > > It's called "scratch your itches". > > > The spirit of Open Source is that when you make changes you publish them > > for > > the next person in your same situation. Sometimes this spirit is enshrined, > > to > > different extent, in the more or less permissive licenses. > > > > For smaller software, I did have many commits. It is open source projects > > > locally in two universities. They do not currently have commit info on > > line > > > publicly. > > > Do they have the source code published in other form, e.g. a tarball? > > > OpenSource 104: Giving back to the general public is key to be a good Open > > Source citizen. In the days prior
[hugin-ptx] Re: projection math
Thanks, Erik! > On the singleprojectionpages which are linked from there you should > find links to the relevant Mathworld pages or eventually some formulas. Still, it is somehow surprising that this has not been implented in, say Matlab, before. Cheers, max -- 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
