[hugin-ptx] Re: GSoC2009_layout with XYZ for Windows - please test
annoying, one workaround seems to be to: add one image, save, exit, open project, add one image, exite, etc 2009/10/7 allard a...@allardkatan.net I experience the same problem as Oskar. Running binaries straight from the unzipped package. Load one image, all still fine. Load one more image, immediate crash. Reproducible with different sets of images. allard --~--~-~--~~~---~--~~ 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: hugin-mac-2009.4.0-Beta1 for download
Hi all OS X users, 2009/10/6 grow george...@gmail.com: With this new Beta I quite quickly achieved a wonderful stitch at 5,000 x 2500 pixels. I was very pleased with that ... but then I set it running at maximum resolution about 12,000 x 6,000 and had the usual - out of memory crash when Enblend was trying to deal with the three images with Alpha Channel masks. The error message is below. It looks very much like the problem that occurred with earlier versions ... and I don't think anything new has happened in this area in this version ... so it is not really a surprise. Perhaps I will finally get around to installing that extra RAM and see if that helps. :-) all the best George __ Checking nona...[OK] Checking enblend...[OK] Checking enfuse...[OK] Checking hugin_hdrmerge...[OK] Checking exiftool...[OK] /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 0 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 1 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 2 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 3 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 4 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 5 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 6 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 7 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/nona -z PACKBITS -r ldr -m TIFF_m -o FoyleDays_M2_04 -i 8 /private/var/tmp/ folders.501/TemporaryItems/huginpto_5C8AJJ /Applications/QuicktimeTools/Hugin/Hugin_2009_4_Beta1/Hugin.app/ Contents/Resources/HuginStitchProject.app/Contents/MacOS/enblend -- compression NONE -v --fine-mask --fine-mask -w -f12048x6024 -o FoyleDays_M2_04.tif FoyleDays_M2_04.tif FoyleDays_M2_040001.tif FoyleDays_M2_040002.tif FoyleDays_M2_040003.tif FoyleDays_M2_040004.tif FoyleDays_M2_040005.tif FoyleDays_M2_040006.tif FoyleDays_M2_040007.tif FoyleDays_M2_040008.tif enblend: info: loading next image: FoyleDays_M2_04.tif 1/1 enblend: info: loading next image: FoyleDays_M2_040001.tif 1/1 enblend: info: creating blend mask: 1/3 2/3 3/3 enblend: info: optimizing 2 distinct seams enblend: info: strategy 1, s0: enblend: info: strategy 1, s0: 1/4 2/4 3/4 4/4 enblend: info: strategy 2: s0 s0 enblend: info: using 10 blending levels enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 l5 l6 l7 l8 l9 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 l5 l6 l7 l8 l9 enblend: info: blending layers: l0 l1 l2 l3 l4 l5 l6 l7 l8 l9 enblend: info: collapsing Laplacian pyramid: l9 l8 l7 l6 l5 l4 l3 l2 l1 l0 enblend: info: loading next image: FoyleDays_M2_040002.tif 1/1 enblend: info: creating blend mask: 1/3 2/3 3/3 enblend: info: optimizing 2 distinct seams enblend: info: strategy 1, s0: enblend: info: strategy 1, s0: 1/4 2/4 3/4 4/4 enblend: info: strategy 2: s0 s0 enblend: info: using 10 blending levels enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 l5 l6 l7 l8
[hugin-ptx] Re: Oups, I've added two strings!
Am Tuesday 06 October 2009 schrieb Bruno Postle: On Mon 05-Oct-2009 at 19:00 -0400, Yuval Levy wrote: Bruno Postle wrote: I haven't played with this, but does this really need to generate an error message? the fast preview dragging not. but the error can be produced by entering illegal values on the stitcher tab, where the message is required. Fair enough, though I'd like to remove the crop stuff from the Stitcher tab at some point, I can't imagine that anyone uses it there. I am. It is easier here to set exact integer values; Surely just dragging the box to the point that it inverts could just silently flip the coordinates please don't. It is like letting people tilt beyond nadir/zenith when navigating a 360x180 - fine for the expert who knows what he is doing, but not helpful for the occasional user. Well this is how the problem started, you could drag the box so that it looked right but was actually inside out. The answer is surely to make it right if it looks right. Kornel -- Kornel Benko kornel.be...@berlin.de signature.asc Description: This is a digitally signed message part.
[hugin-ptx] Re: [OSX] hugin-mac-2009.4.0-Beta1 for download
Allan, Thanks. I tried the JPEGs on my machine and just as you had found ... Auto-pano-sift created 35 control points and Celeste removed the 32 of them that were on the clouds. So then I created two 8-bit TIFF files and again Auto-pano-sift created 35 control points and Celeste removed the 32 of them that were on the clouds. So then I loaded the original 16-bit TIFF files and Auto-pano-sift again created 35 control points BUT this time Celeste removed only 9 of them. I took screen captures and can see no pattern. The screens are here http://hugin-ptx.googlegroups.com/web/GR__BeforeCeleste.jpg?hl=en-GBgsc=KotfnAsgkA1LQtdhBzYiUCK1XXkP and here: http://hugin-ptx.googlegroups.com/web/GR_after1stCeleste.jpg?hl=en-GBgsc=KotfnAsgkA1LQtdhBzYiUCK1XXkPand as I said I can’t see much pattern to the cloud-control-points removed and those that remain. So it seems that Celeste is not as good at removing control points on 16-bit TIFF images. all the best George On 7 Oct, 03:52, AKS-Gmail-IMAP aksei...@gmail.com wrote: OSX hugin-mac-2009.4.0-Beta1 on this G4 removed all 64 control points autopano-sift-c had matched on the clouds in your two jpg photos. Allan On Oct 6, 2009, at 9:00 PM, grow wrote: OK, Here they are: http://hugin-ptx.googlegroups.com/web/5-of-9_IMG_0052.jpg?hl=en-GB http://hugin-ptx.googlegroups.com/web/4-of-9_IMG_0049.jpg?hl=en-GB As for the other error - the crashing Enblend running out of memory - I re-ran the stitch at 10,000 x 5,000 and it worked OK ... I can live with that. all the best George On 7 Oct, 01:18, Yuval Levy goo...@levy.ch wrote: hi George, try with high quality JPEG. if we can't reproduce the error, you can always upload the heavier TIFFs in a second time. thanks for your effort Yuv grow wrote: Bruno, Can you upload these two photos somewhere? I am happy to do so ... at present they are 16-bit TIFF files and are each 70+Mb ... do you think that their size/resolution/TIFF-ness might would be significant? If so I can upload them onto one of my sites and provide a link ... if not and high-quality JPEGs would do I could make those and upload them here. all the best George On Oct 6, 8:56 pm, Bruno Postle br...@postle.net wrote: On Tue 06-Oct-2009 at 07:18 -0700, grow wrote: This should probably have gone on a thread about Celetse ... but I am working on that panorama I mentioned with the current Beta and have found that I don't seem to to have the sort of clouds that Celeste recognises. This could be a problem with celeste as you say, or something wrong with the build or installation. Can you upload these two photos somewhere? -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] replacing make?
Hello, I've got a quite sound idea. Just to put a bug in your head (czech saying) – to make you think about it. There are numerous bug reports which are caused by using some forbidden characters inside makefile (and some strange bugs too). Sometimes they can be escaped but sometimes it doesn't help or it breaks something. I can imagine using something different instead of makefile. My first thoughts were about using some dynamic language like python or perl but I rejected these thoughts immediately. They would brink need to distribute python/perl/whatever with hugin. So this is no way. They're too big. What I think may be quite nice way to store necessary data is the XML. Although I'm not a huge XML fan (in fact I think it's overused) it could bring some improvements to the current workflow. I've two ideas how it could help. First it wouldn't break just because someone used = (or so) in file name. Second it would allow to create better structured files which would be more readable especially when working with stacks. However it has it's culprits eg someone would have to write some parser which would process this kind of files. The other problem is backward-compatibility. Let the discussion begin. regards, Lukáš --~--~-~--~~~---~--~~ 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] possible memory leak in enblend enfuse? (was: hugin-mac-2009.4.0-Beta1 for download)
2009/10/7 Lukáš Jirkovský l.jirkov...@gmail.com I'm not Mac user (although I find it really cool but very expensive) but I may found solution for out of memory problem. I had a discussion about memory and I mentioned these fragmentation problems on OS. And get interesting advice – use TLSF [1]. It is said that it doesn't suffer from fragmentation much. Maybe some of you want to take a look at it. [1] http://rtportal.upv.es/rtmalloc/ Lukas Hi Lukáš, (You are the one person who I had hoped to react. I started to do tests myself yesterday evening but they take long). Both on 32bit windows, 32bit linux and 32bit OSX, or with the 32bit versions of enblend, we regularly see the error message of enblend crashing due to a memory allocation error. We see this both at hugin-ptx as well as in the bugtracker for large projects. We sometimes see it for enfuse in case of large projects which need to be fused as well. Untill now we blamed it on memory fragmentation, but maybe it's something else. George Row is one of the persons who encounters these errors on OSX. I have received a large set (2.5GB) from George in June, some time before my mac crashed. At that time I did some tests. These results are gone (no backup of test results).Yesterday I took Georges set from my big disk backup server and did some tests myself trying to stich a 12000X6000 (slightly bigger) panorama in hugin-2009.4.0-beta1. My question to you now is: You recently did some memory leak patching on the hugin trunk, using cppcheck, thereby finding some things in celeste. You reported this via http://groups.google.com/group/hugin-ptx/browse_thread/thread/e2b5b09e4706fb80 . Can you do the same for the enblend trunk? If you want to do this and you find the time for it in the near furure, be so kind to publish this on the hugin-ptx list. But please: don't feel obliged. If you don't have time or just do not want to do this: just say so. = If you don't want to do this, you can now stop reading. = If you want to do this or are at least interested: please continue reading. Below you will find my tests on OSX. It's done on the 2.5GB bracked village hotel project of George Row. Below the tail of the enblend error for a very recent 32bit Christoph Spiel build: enblend: info: loading next image: FoyleDays_M2_040007.tif 1/1 enblend: info: creating blend mask: 1/3enblend(11221) malloc: *** vm_allocate(size=580620288) failed (error code=3) enblend(11221) malloc: *** error: can't allocate region enblend(11221) malloc: *** set a breakpoint in szone_error to debug enblend: out of memory enblend: St9bad_alloc gnumake: *** [FoyleDays_M2_04.tif] Error 1 Below the tail of the error for the stable 32bit enblend 3.2 build (This to prove it's not a recent problem. It's already there in the 3.2 stable build). enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend: out of memory St9bad_alloc gnumake: *** [mamaloe_exposure_00.tif] Error 1 Test report for a 64bit enblend: After 6 hours and much further in the process my system crashed. I will rerun tonight. (I can start and monitor remote. I can't start a crashed mac from remote.) Note: I build 32bit binaries by default as they run on every mac. A 64 bit version only runs on Leopard and Snow Leopard on 64bit hardware. 64bit brings hardly performance gain or other benefits, only when making gigapixel pano's.) To me this does NOT mean that the 64 bit behaves better. It only proves IMO that due to the huge 64bit address space, enblend can (might) just continue leaving it 's memory junk without filling the address space that fast and that fragmentation is less an issue within the huge 64bit address space. In other words: it will only crash at a later stage when trying to stitch (even bigger) projects. But that's an assumption which I can't prove right now. Hoi, Harry --~--~-~--~~~---~--~~ 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: [OSX] hugin-mac-2009.4.0-Beta1 for download
Does a change to the Celeste parameters in preferences result in better performance for these images without removing desirable points? There are also people in these images. Sometimes they are also like clouds. By the way, from my perspective I am struck by the total absence of litter and excess body weight in these images. Allan On Wed, Oct 7, 2009 at 6:55 AM, grow george...@gmail.com wrote: Allan, Thanks. I tried the JPEGs on my machine and just as you had found ... Auto-pano-sift created 35 control points and Celeste removed the 32 of them that were on the clouds. So then I created two 8-bit TIFF files and again Auto-pano-sift created 35 control points and Celeste removed the 32 of them that were on the clouds. So then I loaded the original 16-bit TIFF files and Auto-pano-sift again created 35 control points BUT this time Celeste removed only 9 of them. I took screen captures and can see no pattern. The screens are here http://hugin-ptx.googlegroups.com/web/GR__BeforeCeleste.jpg?hl=en-GBgsc=KotfnAsgkA1LQtdhBzYiUCK1XXkP and here: http://hugin-ptx.googlegroups.com/web/GR_after1stCeleste.jpg?hl=en-GBgsc=KotfnAsgkA1LQtdhBzYiUCK1XXkPand as I said I can’t see much pattern to the cloud-control-points removed and those that remain. So it seems that Celeste is not as good at removing control points on 16-bit TIFF images. all the best George On 7 Oct, 03:52, AKS-Gmail-IMAP aksei...@gmail.com wrote: OSX hugin-mac-2009.4.0-Beta1 on this G4 removed all 64 control points autopano-sift-c had matched on the clouds in your two jpg photos. Allan On Oct 6, 2009, at 9:00 PM, grow wrote: OK, Here they are: http://hugin-ptx.googlegroups.com/web/5-of-9_IMG_0052.jpg?hl=en-GB http://hugin-ptx.googlegroups.com/web/4-of-9_IMG_0049.jpg?hl=en-GB As for the other error - the crashing Enblend running out of memory - I re-ran the stitch at 10,000 x 5,000 and it worked OK ... I can live with that. all the best George On 7 Oct, 01:18, Yuval Levy goo...@levy.ch wrote: hi George, try with high quality JPEG. if we can't reproduce the error, you can always upload the heavier TIFFs in a second time. thanks for your effort Yuv grow wrote: Bruno, Can you upload these two photos somewhere? I am happy to do so ... at present they are 16-bit TIFF files and are each 70+Mb ... do you think that their size/resolution/TIFF-ness might would be significant? If so I can upload them onto one of my sites and provide a link ... if not and high-quality JPEGs would do I could make those and upload them here. all the best George On Oct 6, 8:56 pm, Bruno Postle br...@postle.net wrote: On Tue 06-Oct-2009 at 07:18 -0700, grow wrote: This should probably have gone on a thread about Celetse ... but I am working on that panorama I mentioned with the current Beta and have found that I don't seem to to have the sort of clouds that Celeste recognises. This could be a problem with celeste as you say, or something wrong with the build or installation. Can you upload these two photos somewhere? -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
allard wrote: I'm trying to build libpano from svn 1096 but MSVC is giving me some errors. I run into something that is beyond my extremely limited coding abilities. Here's the output from MSVC that keeps showing up: 12pano13.lib(PTcommon.obj) : error LNK2001: unresolved external symbol _optind 12pano13.lib(PTcommon.obj) : error LNK2001: unresolved external symbol _optarg 12pano13.lib(PTcommon.obj) : error LNK2019: unresolved external symbol _getopt referenced in function _panoCroppingMain 12pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external symbol _hDllInstance 12pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external symbol _wndOwner 12pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external symbol _CenterDialog referenced in function _set...@16 12pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external symbol _SetWindowOwner referenced in function _set...@16 Ideas anyone? Allard Have you managed to resolve these errors? _optind and _optarg require the file getopt.c it is in libpano\tools\compat_win32 If PTCommon is using it then the folder compat_win32 should be moved up a level. The errors of hDllInstance, wndOwner, CenterDialog, and SetWindowOwner indicate that you building the CMD version of the tools using sys_ansi but have also included sys_win.h. The tools currently only build as CMD. To do this define MSDOS or _CONSOLE (see panorama.h line 40 and PTDialogs.c line 28) CMD tools are built with sys_ansi GUI tools are built with sys_win (currently broken) -- Jim Watters jwatt...@photocreations.ca http://photocreations.ca --~--~-~--~~~---~--~~ 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: Oups, I've added two strings!
On Wed, Oct 07, 2009 at 02:07:12AM -0700, Bart van Andel wrote: Anyway, instead of a pop up error message box, couldn't we change the color of the text box (into red for example) and add an exclamation mark in front with a tooltip text when entering too high / too low values? Just a suggestion, I reckon it's a matter of taste, but this way it's less obtrusive and will require one click less. People with click-to-focus may have their mouse a mile away. And this would mean you'd have to look at the intermediate results while the user is typing which may annoy people who know what they are doing. (If I want to generate the output image from 1000-9250, I would enter 1000, and then type 9 (ERROR! value lower than 1000!) 2 (error, 92 1000), 5 (error, 9251000), and only on the final 0 the error would go away. If you look at the value in the box only in the end when focus moves away from the box or enter is pressed you're in the current situation, where a popup is most appropriate. 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! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ --~--~-~--~~~---~--~~ 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: hugin-mac-2009.4.0-Beta1 for download
On Tue, Oct 06, 2009 at 11:39:59AM -0700, grow wrote: Perhaps I will finally get around to installing that extra RAM and see if that helps. :-) It will not help. I guarantee you. enblend: info: loading next image: FoyleDays_M2_040007.tif 1/1 enblend: info: creating blend mask: 1/3enblend(11221) malloc: *** vm_allocate(size=580620288) failed (error code=3) enblend(11221) malloc: *** error: can't allocate region enblend(11221) malloc: *** set a breakpoint in szone_error to debug I have debugged this to the point where I am sure that enblend isn't needing more memory than is available, but it is going bonkers and suddenly ends up doing the equivalent of: while (1) malloc (ALOT); The gnu-malloc changes strategies of allocating memory after a while (when the first strategy starts to fail), enblend continues until it completely runs out. On 64 bit systems it allocates WAY more than on a 32 bit system and after a while (a few milliseconds in fact) the system determines that allocating several gigabytes is one thing, but then trying to use it is never going to work, so it starts refusing the alloc requests too, even though it hasn't run out of adressing space yet. I personally suspect the tile cache code. Due to the use it is getting in enblend, somehow getting stuck in a I need more memory to allocate more memory loop or something like that. Rogier. -- ** 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! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ --~--~-~--~~~---~--~~ 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: possible memory leak in enblend enfuse? (was: hugin-mac-2009.4.0-Beta1 for download)
Hi I'd be interested in doing some tests, too. I remember having had memory issues as well, but I was never able to reproduce them reliably here on Linux / Linux_64 and Windows. Is there someplace one could get the project in question? Cheers Stefan Peter --~--~-~--~~~---~--~~ 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: possible memory leak in enblend enfuse? (was: hugin-mac-2009.4.0-Beta1 for download)
To answer my own mail. :-) I just compiled cppcheck on OSX and did a standard run on the enblend trunk. It displays the following [./vigra_impex/jpeg.cxx:132]: (error) Class JPEGCodecImpl which is inherited by class JPEGDecoderImplBase does not have a virtual destructor [./vigra_impex/jpeg.cxx:132]: (error) Class JPEGCodecImpl which is inherited by class JPEGEncoderImplBase does not have a virtual destructor Then I did a full check. That resulted in exactly the same result as mentioned above. This is like giving a monkey an encyclopedia. He has no idea what to do with it. I don't even know if this is usefull. I hope some clever progammers (super monkeys?) know what to do with this. Harry 2009/10/7 Harry van der Wolf hvdw...@gmail.com 2009/10/7 Lukáš Jirkovský l.jirkov...@gmail.com I'm not Mac user (although I find it really cool but very expensive) but I may found solution for out of memory problem. I had a discussion about memory and I mentioned these fragmentation problems on OS. And get interesting advice – use TLSF [1]. It is said that it doesn't suffer from fragmentation much. Maybe some of you want to take a look at it. [1] http://rtportal.upv.es/rtmalloc/ Lukas Hi Lukáš, (You are the one person who I had hoped to react. I started to do tests myself yesterday evening but they take long). Both on 32bit windows, 32bit linux and 32bit OSX, or with the 32bit versions of enblend, we regularly see the error message of enblend crashing due to a memory allocation error. We see this both at hugin-ptx as well as in the bugtracker for large projects. We sometimes see it for enfuse in case of large projects which need to be fused as well. Untill now we blamed it on memory fragmentation, but maybe it's something else. George Row is one of the persons who encounters these errors on OSX. I have received a large set (2.5GB) from George in June, some time before my mac crashed. At that time I did some tests. These results are gone (no backup of test results).Yesterday I took Georges set from my big disk backup server and did some tests myself trying to stich a 12000X6000 (slightly bigger) panorama in hugin-2009.4.0-beta1. My question to you now is: You recently did some memory leak patching on the hugin trunk, using cppcheck, thereby finding some things in celeste. You reported this via http://groups.google.com/group/hugin-ptx/browse_thread/thread/e2b5b09e4706fb80 . Can you do the same for the enblend trunk? If you want to do this and you find the time for it in the near furure, be so kind to publish this on the hugin-ptx list. But please: don't feel obliged. If you don't have time or just do not want to do this: just say so. = If you don't want to do this, you can now stop reading. = If you want to do this or are at least interested: please continue reading. Below you will find my tests on OSX. It's done on the 2.5GB bracked village hotel project of George Row. Below the tail of the enblend error for a very recent 32bit Christoph Spiel build: enblend: info: loading next image: FoyleDays_M2_040007.tif 1/1 enblend: info: creating blend mask: 1/3enblend(11221) malloc: *** vm_allocate(size=580620288) failed (error code=3) enblend(11221) malloc: *** error: can't allocate region enblend(11221) malloc: *** set a breakpoint in szone_error to debug enblend: out of memory enblend: St9bad_alloc gnumake: *** [FoyleDays_M2_04.tif] Error 1 Below the tail of the error for the stable 32bit enblend 3.2 build (This to prove it's not a recent problem. It's already there in the 3.2 stable build). enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend: out of memory St9bad_alloc gnumake: *** [mamaloe_exposure_00.tif] Error 1 Test report for a 64bit enblend: After 6 hours and much further in the process my system crashed. I will rerun tonight. (I can start and monitor remote. I can't start a crashed mac from remote.) Note: I build 32bit binaries by default as they run on every mac. A 64 bit version only runs on Leopard and Snow Leopard on 64bit hardware. 64bit brings hardly performance gain or other benefits, only when making gigapixel pano's.) To me this does NOT mean that the 64 bit behaves better. It only proves IMO that due to the huge 64bit address space, enblend can (might) just continue leaving it 's memory junk without filling the address space that
[hugin-ptx] Re: possible memory leak in enblend enfuse? (was: hugin-mac-2009.4.0-Beta1 for download)
Hi Harry, 2009/10/7 Harry van der Wolf hvdw...@gmail.com: 2009/10/7 Lukáš Jirkovský l.jirkov...@gmail.com I'm not Mac user (although I find it really cool but very expensive) but I may found solution for out of memory problem. I had a discussion about memory and I mentioned these fragmentation problems on OS. And get interesting advice – use TLSF [1]. It is said that it doesn't suffer from fragmentation much. Maybe some of you want to take a look at it. [1] http://rtportal.upv.es/rtmalloc/ Lukas Hi Lukáš, (You are the one person who I had hoped to react. I started to do tests myself yesterday evening but they take long). Thanks for being confident in me. Both on 32bit windows, 32bit linux and 32bit OSX, or with the 32bit versions of enblend, we regularly see the error message of enblend crashing due to a memory allocation error. We see this both at hugin-ptx as well as in the bugtracker for large projects. We sometimes see it for enfuse in case of large projects which need to be fused as well. Untill now we blamed it on memory fragmentation, but maybe it's something else. It is possible that it's something else. The question is: how to find it? George Row is one of the persons who encounters these errors on OSX. I have received a large set (2.5GB) from George in June, some time before my mac crashed. At that time I did some tests. These results are gone (no backup of test results).Yesterday I took Georges set from my big disk backup server and did some tests myself trying to stich a 12000X6000 (slightly bigger) panorama in hugin-2009.4.0-beta1. My question to you now is: You recently did some memory leak patching on the hugin trunk, using cppcheck, thereby finding some things in celeste. You reported this via http://groups.google.com/group/hugin-ptx/browse_thread/thread/e2b5b09e4706fb80. Can you do the same for the enblend trunk? If you want to do this and you find the time for it in the near furure, be so kind to publish this on the hugin-ptx list. But please: don't feel obliged. If you don't have time or just do not want to do this: just say so. The cppcheck is still running but enblend.cc has already been checked. It has not detected any (interesting) problems yet. The major leak of these static analysis tools is that they are not perfect. Even the ones like Coverity uses. It may be interesting to try valgrind. Note: I've just read your post that it doesn't detect anything interesting. = If you don't want to do this, you can now stop reading. = If you want to do this or are at least interested: please continue reading. Below you will find my tests on OSX. It's done on the 2.5GB bracked village hotel project of George Row. Below the tail of the enblend error for a very recent 32bit Christoph Spiel build: enblend: info: loading next image: FoyleDays_M2_040007.tif 1/1 enblend: info: creating blend mask: 1/3enblend(11221) malloc: *** vm_allocate(size=580620288) failed (error code=3) enblend(11221) malloc: *** error: can't allocate region enblend(11221) malloc: *** set a breakpoint in szone_error to debug enblend: out of memory enblend: St9bad_alloc gnumake: *** [FoyleDays_M2_04.tif] Error 1 Below the tail of the error for the stable 32bit enblend 3.2 build (This to prove it's not a recent problem. It's already there in the 3.2 stable build). enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend(50447) malloc: *** mmap(size=2097152) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug enblend: out of memory St9bad_alloc gnumake: *** [mamaloe_exposure_00.tif] Error 1 It would be nice to find out which malloc() fails. According to the older discussion it seems to be a problem in CachedFileImage. IMO the best thing how to try it would be do build enblend without image cache and create HUGE swap space so it won't run out of memory. If stitch works then we should look for the problem in image cache. I'd try it here but it would take ages since I don't have very powerful PC. I'll try to limit RAM on my PC (there is some switch to Linux kernel but IIRC it's almost undocumented) If it doesn't work I can try to replace all my RAM modules with an old 256MB RAM module and disable/reduce swap space. Then it may occur earlier and with smaller projects. I'm a bit afraid that it doesn't depend on how much RAM (or better virtual memory) is there but on the stitch size. ie. that when the stitch output is big enough it exposes some weird bug when it
[hugin-ptx] Re: possible memory leak in enblend enfuse? (was: hugin-mac-2009.4.0-Beta1 for download)
I did another run from the Gui (took a few minutes to find how to compile that one). That gave more results: [assemble.h:308]: (possible style) Pre-Incrementing variable 'i' is preferred to Post-Incrementing [assemble.h:308]: (possible style) Pre-Incrementing variable 'i' is preferred to Post-Incrementing [vigra_impex/exr.cxx:310]: (style) Redundant condition. It is safe to deallocate a NULL pointer [vigra_impex/hdr.cxx:116]: (style) Member variable not initialized in the constructor 'HDRCodecImpl::height' [vigra_impex/hdr.cxx:116]: (style) Member variable not initialized in the constructor 'HDRCodecImpl::width' [vigra_impex/jpeg.cxx:132]: (error) Class JPEGCodecImpl which is inherited by class JPEGDecoderImplBase does not have a virtual destructor [vigra_impex/jpeg.cxx:132]: (error) Class JPEGCodecImpl which is inherited by class JPEGEncoderImplBase does not have a virtual destructor [vigra_impex/rgbe.c:90]: (style) The scope of the variable f can be limited [vigra_impex/tiff.cxx:199]: (style) Member variable not initialized in the constructor 'TIFFCodecImpl::layers' [vigra_impex/viff.cxx:245]: (style) Function parameter 'index' is passed by value. It could be passed by reference instead. This doesn't seem to be memory leaks of some kind. Still I report it here. Harry 2009/10/7 Harry van der Wolf hvdw...@gmail.com To answer my own mail. :-) I just compiled cppcheck on OSX and did a standard run on the enblend trunk. It displays the following [./vigra_impex/jpeg.cxx:132]: (error) Class JPEGCodecImpl which is inherited by class JPEGDecoderImplBase does not have a virtual destructor [./vigra_impex/jpeg.cxx:132]: (error) Class JPEGCodecImpl which is inherited by class JPEGEncoderImplBase does not have a virtual destructor Then I did a full check. That resulted in exactly the same result as mentioned above. This is like giving a monkey an encyclopedia. He has no idea what to do with it. I don't even know if this is usefull. I hope some clever progammers (super monkeys?) know what to do with this. Harry 2009/10/7 Harry van der Wolf hvdw...@gmail.com 2009/10/7 Lukáš Jirkovský l.jirkov...@gmail.com I'm not Mac user (although I find it really cool but very expensive) but I may found solution for out of memory problem. I had a discussion about memory and I mentioned these fragmentation problems on OS. And get interesting advice – use TLSF [1]. It is said that it doesn't suffer from fragmentation much. Maybe some of you want to take a look at it. [1] http://rtportal.upv.es/rtmalloc/ Lukas Hi Lukáš, (You are the one person who I had hoped to react. I started to do tests myself yesterday evening but they take long). Both on 32bit windows, 32bit linux and 32bit OSX, or with the 32bit versions of enblend, we regularly see the error message of enblend crashing due to a memory allocation error. We see this both at hugin-ptx as well as in the bugtracker for large projects. We sometimes see it for enfuse in case of large projects which need to be fused as well. Untill now we blamed it on memory fragmentation, but maybe it's something else. George Row is one of the persons who encounters these errors on OSX. I have received a large set (2.5GB) from George in June, some time before my mac crashed. At that time I did some tests. These results are gone (no backup of test results).Yesterday I took Georges set from my big disk backup server and did some tests myself trying to stich a 12000X6000 (slightly bigger) panorama in hugin-2009.4.0-beta1. My question to you now is: You recently did some memory leak patching on the hugin trunk, using cppcheck, thereby finding some things in celeste. You reported this via http://groups.google.com/group/hugin-ptx/browse_thread/thread/e2b5b09e4706fb80 . Can you do the same for the enblend trunk? If you want to do this and you find the time for it in the near furure, be so kind to publish this on the hugin-ptx list. But please: don't feel obliged. If you don't have time or just do not want to do this: just say so. = If you don't want to do this, you can now stop reading. = If you want to do this or are at least interested: please continue reading. Below you will find my tests on OSX. It's done on the 2.5GB bracked village hotel project of George Row. Below the tail of the enblend error for a very recent 32bit Christoph Spiel build: enblend: info: loading next image: FoyleDays_M2_040007.tif 1/1 enblend: info: creating blend mask: 1/3enblend(11221) malloc: *** vm_allocate(size=580620288) failed (error code=3) enblend(11221) malloc: *** error: can't allocate region enblend(11221) malloc: *** set a breakpoint in szone_error to debug enblend: out of memory enblend: St9bad_alloc gnumake: *** [FoyleDays_M2_04.tif] Error 1 Below the tail of the error for the stable 32bit enblend 3.2 build (This to prove it's not a recent problem. It's already there in the 3.2 stable build).
[hugin-ptx] Re: Celeste and 16bit photos
Hmmm that's strange. Could someone send me a link to the 16-bit tiffs and I'll have a look tonight. Tim Bruno Postle wrote: On Wed 07-Oct-2009 at 04:55 -0700, grow wrote: So it seems that Celeste is not as good at removing control points on 16-bit TIFF images. This is odd, according to the ChangeLog, 16bit support was fixed in December: 2008-12-17 blimbo * [r3566] src/celeste/Celeste.cpp: Celeste support for 16bit images --~--~-~--~~~---~--~~ 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: replacing make?
On Oct 7, 2009, at 8:04 AM, Lukáš Jirkovský l.jirkov...@gmail.com wrote: Hello, I've got a quite sound idea. Just to put a bug in your head (czech saying) – to make you think about it. There are numerous bug reports which are caused by using some forbidden characters inside makefile (and some strange bugs too). Sometimes they can be escaped but sometimes it doesn't help or it breaks something. I can imagine using something different instead of makefile. My first thoughts were about using some dynamic language like python or perl but I rejected these thoughts immediately. They would brink need to distribute python/perl/whatever with hugin. So this is no way. They're too big. What I think may be quite nice way to store necessary data is the XML. Although I'm not a huge XML fan (in fact I think it's overused) it could bring some improvements to the current workflow. I've two ideas how it could help. First it wouldn't break just because someone used = (or so) in file name. Second it would allow to create better structured files which would be more readable especially when working with stacks. However it has it's culprits eg someone would have to write some parser which would process this kind of files. The other problem is backward-compatibility. Let the discussion begin. regards, Lukáš Hello Lukas, I have long since considered something similar to this. I had a draft email that I never sent to this list that outlined my thoughts but I never fully developed it. I would like to see the pto files be replaces by some other persitent file format. I had considered XML at the time as I find it easy to read and extend as more data is needed to be stored. (people always seem to be able to come up with different things for hugin to do.) Hugin would load up the project from this new file and then export .pto files along with some sort of platform specific script file (bat on windows, shell scripts on Linux/mac os x). The script file generation would be handled by a generic interface calling the platform specifc script generators as necessary. In the end, only one file would be necessary to be retained along with the images: the original file. I am a fan of python but it is probably overkill for the sequence of commands that would need to be executed. I hadn't considered reusing the same code to generate a cli tool that would parse the XML and execute the commands directly. That would be cool I'll try to post more later. Gerry --~--~-~--~~~---~--~~ 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: Celeste and 16bit photos
Hi Tim, you can download the jpeg images and use ImageMagick's convert or graphicsmagick gm to convert to 16 bit tiff. I did that and celeste works. Next to that: I still have Georges hotel village 16bit images (from the other topic). If I use them, celeste works also. This almost looks like that ppc does not work correctly and intel does. Do you take care of little_endian and big_endian in celeste? If not, that might be an issue. Not for single byte 8bit images, but certainly for double-byte 16bit tiff and png images and also for 4-byte 32bit tiffs and pngs. This also has been an error for both imagemagick and graphicsmagick in the past. Harry 2009/10/7 Tim Nugent timnug...@gmail.com Hmmm that's strange. Could someone send me a link to the 16-bit tiffs and I'll have a look tonight. Tim Bruno Postle wrote: On Wed 07-Oct-2009 at 04:55 -0700, grow wrote: So it seems that Celeste is not as good at removing control points on 16-bit TIFF images. This is odd, according to the ChangeLog, 16bit support was fixed in December: 2008-12-17 blimbo * [r3566] src/celeste/Celeste.cpp: Celeste support for 16bit images --~--~-~--~~~---~--~~ 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: Celeste and 16bit photos
On Oct 7, 7:17 pm, Harry van der Wolf hvdw...@gmail.com wrote: you can download the jpeg images and use ImageMagick's convert or graphicsmagick gm to convert to 16 bit tiff. George's dataset is quite large, but you need only about 3 images from his dataset to trigger the enblend bug. 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: possible memory leak in enblend enfuse? (was: hugin-mac-2009.4.0-Beta1 for download)
Hi Lukáš instead of changing the RAM on your PC, you could use a virtual machine like vmware or virtualbox. There, you can limit the resources at your will. Regards Stefan Peter --~--~-~--~~~---~--~~ 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: replacing make?
On Wed 07-Oct-2009 at 15:04 +0200, Lukáš Jirkovský wrote:
What I think may be quite nice way to store necessary data is the XML.
Although I'm not a huge XML fan (in fact I think it's overused) it
could bring some improvements to the current workflow. I've two ideas
how it could help. First it wouldn't break just because someone used =
(or so) in file name. Second it would allow to create better
structured files which would be more readable especially when working
with stacks.
That would be recreating 'make' with XML and this would be a massive
task. I think the Makefiles themselves are fine and `make`
processes them efficiently, what is problematic is the way they are
assembled in PanoramaMakefileExport, basically we just print
low-level strings to the Makefile like this:
o $(HDR_STACK_ i ) : $(HDR_STACK_ i _INPUT) endl
I think this could be much cleaner, and as a result the code would
more closely resemble the intent rather than being a huge list of
low level string handling.
I know I'm not great at this stuff, but in the panostart tool there
is a perl module that abstacts all the business of writing and
escaping Makefile rules, i.e. you declare your intent with a list of
input files, a list of output files, and the command(s) needed to
generate those output files:
my $rule = new File::Makefile::Rule;
$rule-Prerequisites ('file-A');
$rule-Targets ('file-B');
$rule-Command ('cp', 'file-A', 'file-B');
To turn this into valid, properly escaped and tabbed make-speak you
just do this:
$rule-Assemble;
Aside from removing the low level stuff, the best thing about
abstracting it like this is that the module is testable, just feed
it a bunch of problematic filenames and see if the Makefile succeeds.
--
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
-~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
allard wrote: Until this is solved I'll take panomatic out of the install script and update. Herbert Bay, the inventor of SURF, was a GSoC-Mentor for Hugin/Panotools in 2007. I recall he mentioned a patent. I've pinged him as well. Independent on wether SURF is patented or not, I repeat that I think that it makes sense to make separate installers for the CP generators, like on MacOSX. I was using Cmake. There's a few unfound files that Cmake comes with, mostly in WxWidgets. that's OK and it will not cause problems because we don't use them. Then there's these two that don't show up in the hugin CMakecache.txt _svnversion:FILEPATH=_svnversion-NOTFOUND PERL_EXE:FILEPATH=PERL_EXE-NOTFOUND Could that be part of the problem? partially. the svnversion can be fixed. IIRC Kornel used it to implement differently what is in Hugin's top level CMakeLists.txt around line 22. I'd suggest changing the Panotools CMake build to do the same thing as the Hugin build, tried and tested on many platforms including Windows. Perl is required for Bruno's Panotools-Scripts which are part of the panotools distribution. I don't know the exact detail of the CMake build, but I think it should also work without perl (and simply not install the perl scripts). Alternatively, try installing Perl on your Windows box and see what it does. All this feedback is blind - I don't have access to my Windows box now; and I don't have time to look at libpano's CMake. Yuv --~--~-~--~~~---~--~~ 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] Language Translation Patch, second attempt
Hi all
attached is my second attempt at patching the source tree so that also
strings outside of wxWidgets can be translated.
This one should work on Windows (or at least not break anything) within
the SDK. Please test on OSX too.
If somebody wants to improve FindGettextLibs.cmake to better support
Windows, that's optional but welcome.
Please test.
Yuv
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Index: src/hugin_base/huginapp/ImageCache.cpp
===
--- src/hugin_base/huginapp/ImageCache.cpp (revision 4588)
+++ src/hugin_base/huginapp/ImageCache.cpp (working copy)
@@ -36,6 +36,9 @@
#include vigra_ext/Pyramid.h
#include vigra_ext/FunctorAccessor.h
+// gettext for internalization of strings
+#include libintl.h
+#define _t(String) gettext(String)
namespace HuginBase {
@@ -506,7 +509,7 @@
return it-second;
} else {
if (m_progress) {
-m_progress-pushTask(AppBase::ProgressTask(Loading image: +hugin_utils::stripPath(filename), , 0));
+m_progress-pushTask(AppBase::ProgressTask(_t(Loading image: )+hugin_utils::stripPath(filename), , 0));
}
#if 1
// load images with VIGRA impex, and store either 8 bit or float images
Index: src/CMakeLists.txt
===
--- src/CMakeLists.txt (revision 4588)
+++ src/CMakeLists.txt (working copy)
@@ -5,10 +5,10 @@
# boost_thread is linked automatically
# additionally link to our getopt
set(common_libs huginbase hugingetopt
-${PANO_LIBRARIES} ${LAPACK_LIBRARIES} huginlevmar)
+${PANO_LIBRARIES} ${GETTEXT_LIBRARIES} ${LAPACK_LIBRARIES} huginlevmar)
ELSE(LAPACK_FOUND)
set(common_libs huginbase hugingetopt
-${PANO_LIBRARIES} huginlevmar)
+${PANO_LIBRARIES} ${GETTEXT_LIBRARIES} huginlevmar)
ENDIF(LAPACK_FOUND)
include_directories( ${CMAKE_SOURCE_DIR}/src/foreign/getopt/include )
ELSE (MSVC)
Index: CMakeModules/FindGettextLibs.cmake
===
--- CMakeModules/FindGettextLibs.cmake (revision 0)
+++ CMakeModules/FindGettextLibs.cmake (revision 0)
@@ -0,0 +1,77 @@
+# Try to find Gettext functionality
+# Once done this will define
+#
+# GETTEXTLIBS_FOUND - system has Gettext
+# GETTEXT_INCLUDE_DIR - Gettext include directory
+# GETTEXT_LIBRARIES - Libraries needed to use Gettext
+
+# TODO: This will enable translations only if Gettext functionality is
+# present in libc. Must have more robust system for release, where Gettext
+# functionality can also reside in standalone Gettext library, or the one
+# embedded within kdelibs (cf. gettext.m4 from Gettext source).
+#
+# Copyright (c) 2006, Chusslove Illich, caslav.i...@gmx.net
+#
+# Redistribution and use is allowed according to the terms of the BSD license.
+# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
+
+
+if (LIBC_HAS_DGETTEXT OR LIBINTL_HAS_DGETTEXT)
+
+# in cache already
+set(GETTEXTLIBS_FOUND TRUE CACHE INTERNAL )
+
+else (LIBC_HAS_DGETTEXT OR LIBINTL_HAS_DGETTEXT)
+
+ include(CheckIncludeFiles)
+ include(CheckLibraryExists)
+ include(CheckFunctionExists)
+
+ find_path(GETTEXT_INCLUDE_DIR libintl.h
+/usr/local/include
+/usr/local/include/postgresql
+/usr/local/postgresql/include
+/usr/local/postgresql/include/postgresql
+/usr/include
+/usr/include/postgresql
+${PG_TMP}
+ )
+ list(APPEND CMAKE_REQUIRED_INCLUDES ${GETTEXT_INCLUDE_DIR})
+ check_include_files(libintl.h HAVE_LIBINTL_H)
+ set(CMAKE_REQUIRED_INCLUDES)
+
+ set(GETTEXT_LIBRARIES)
+
+ if (HAVE_LIBINTL_H)
+ check_function_exists(dgettext LIBC_HAS_DGETTEXT)
+ if (LIBC_HAS_DGETTEXT)
+set(GETTEXT_SOURCE built in libc)
+set(GETTEXTLIBS_FOUND TRUE CACHE INTERNAL )
+ else (LIBC_HAS_DGETTEXT)
+FIND_LIBRARY(LIBINTL_LIBRARY NAMES intl libintl c
+ PATHS
+ /usr/lib
+ /usr/local/lib
+)
+CHECK_LIBRARY_EXISTS(${LIBINTL_LIBRARY} dgettext LIBINTL_HAS_DGETTEXT)
+if (LIBINTL_HAS_DGETTEXT)
+ set(GETTEXT_SOURCE in ${LIBINTL_LIBRARY})
+ set(GETTEXT_LIBRARIES ${LIBINTL_LIBRARY} CACHE FILEPATH path to libintl library, used for gettext)
+ set(GETTEXTLIBS_FOUND TRUE CACHE INTERNAL )
+endif (LIBINTL_HAS_DGETTEXT)
+ endif (LIBC_HAS_DGETTEXT)
+ endif
[hugin-ptx] Re: windows binary release
On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: Perl is required for Bruno's Panotools-Scripts which are part of the panotools distribution. I don't know the exact detail of the CMake build, but I think it should also work without perl (and simply not install the perl scripts). Alternatively, try installing Perl on your Windows box and see what it does. Panotools::Script is in the same SVN repository, but it is a different piece of software from libpano13. -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Glut error while building hugin 2009.9.2 in Ubuntu Jaunty
Thanks, installing libxmu-dev and libxi-dev solved the problem, everything is fine now. On 6 Oct, 04:49, Tduell tdu...@iinet.net.au wrote: Hullo Essi, On Oct 6, 10:34 am, Essi sennai...@googlemail.com wrote: Thanks for the suggestions but nothing works and still the same message. I've added the command and the resulting print: [snip] GLUT_Xi_LIBRARY (ADVANCED) [snip] GLUT_Xmu_LIBRARY (ADVANCED) [snip] -- Configuring incomplete, errors occurred! From what i can see by doing a bit of a snoop in various Ubuntu stuff, you need to have libglu1-mesa-dev and libxmu-dev packages installed, or at least that is what I think the lib packages are named in Ubuntu. In Fedora these library packages are mesa-libGLU-devel and libXmu- devel respectively. If you do have them installed then it is back to the issue of your system seeing them. Not sure how it should be done in Ubuntu but some Linux have the global variable LD_LIBRARY_PATH which you may be able to set in your .bashrc file or whatever, but I suspect that there are simpler/better answers to your problem. I seem to recall Yuv has been building Hugin in Ubuntu, but maybe he is using a different version. Anyway, hope this helps...sorry if it doesn't! Cheers, Terry --~--~-~--~~~---~--~~ 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: replacing make?
On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: Lukáš Jirkovský wrote: What I think may be quite nice way to store necessary data is the XML. this has been discussed before. The result was that some people favor the Makefile, others would favor the XML (me included). This all sounds like 'version 2 syndrome'. Isn't there enough stuff that really needs fixing in Hugin? Sure the .pto format would be more elegant rewritten in YAML (or maybe XML), but without any positive benefits it is just an opportunity to introduce new bugs. What can you do with XML that we can't already do with the current .pto format? Abandoning 'make' is a mistake, the Makefile stitching system is very powerful: we get ordering of commands, parallel processing, restarting, and supervision of the whole process by a mature tool. I can't accept Makefiles are hard as a valid reason for recreating 'make' in XML. -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
On Wed, Oct 7, 2009 at 6:21 PM, Bruno Postle br...@postle.net wrote: On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: Lukáš Jirkovský wrote: What I think may be quite nice way to store necessary data is the XML. this has been discussed before. The result was that some people favor the Makefile, others would favor the XML (me included). This all sounds like 'version 2 syndrome'. Isn't there enough stuff that really needs fixing in Hugin? Sure the .pto format would be more elegant rewritten in YAML (or maybe XML), but without any positive benefits it is just an opportunity to introduce new bugs. What can you do with XML that we can't already do with the current .pto format? Abandoning 'make' is a mistake, the Makefile stitching system is very powerful: we get ordering of commands, parallel processing, restarting, and supervision of the whole process by a mature tool. I can't accept Makefiles are hard as a valid reason for recreating 'make' in XML. Hello, OK. I understand there are many benefits of using makefiles such as the ones you have mentioned. I was considering things such as platform specific script files since they seemed more likely to be able to support filenames with alternate character sets. If it is possible to have make targets such as 'this is a directory/this is date: quoted string' then make is fine. I wasn't aware that all of the problematic strings can be expressed properly in a makefile. If the perl scripts can do this already, then we can certainly look at a refactor of the Makefile exporting. I propose XML or different format than the pto format (hugin project persistent storage only, pto's would still be generated and passed to things such as the optimizer, fulla, nona) as it would more easliy handle extra info and structure of a project that hugin can do now. I haven't seen how the layout mode is storing the state of pano yet so perhaps it is not an issue. Best Regards, - Gerry --~--~-~--~~~---~--~~ 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: replacing make?
Bruno Postle wrote: Isn't there enough stuff that really needs fixing in Hugin? yes there is. but the topic seems to itch Lukáš. Other topics may not be of interest to him. What can you do with XML that we can't already do with the current .pto format? it's extensible without conflicts, and already that is a bonus. I'd like to add plenty of information to the project file, such as GPS coordinates, comments, RAW conversion settings, other workflow consideration, region of interest coordinates, tags, etc. But I have not seen Lukáš mentioning any change to the PTO file format or the project file. Or am I misunderstanding? Abandoning 'make' is a mistake Has anybody mentioned *abandoning*? XML usually comes in as an *additional* layer, not as a replacement. And it is a *descriptive* language, not a procedural one. It just makes some things more explicit, trading off readability for a little bit of disk space and processing time. To my understanding XML2Make would still generate Makefiles. It could catch many of the hard edges that are currently causing errors and that give make a worse reputation (in the context of Hugin) than it deserve. Yuv --~--~-~--~~~---~--~~ 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: windows binary release
Bruno Postle wrote: On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: Perl is required for Bruno's Panotools-Scripts which are part of the panotools distribution. I don't know the exact detail of the CMake build, but I think it should also work without perl (and simply not install the perl scripts). Alternatively, try installing Perl on your Windows box and see what it does. Panotools::Script is in the same SVN repository, but it is a different piece of software from libpano13. I did not articulate my thoughts well enough. The impression I have is that when the CMake was expanded by Kornel beyond what Thomas started, he looked at the whole repository and made it work for all, including the Panotools::Script. I don't see any other reason for making the CMake build dependent on finding perl on the build machine. Yuv --~--~-~--~~~---~--~~ 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: windows binary release
Jim Watters wrote: Lets get the current release out first. I wont be checking any of this into trunk soon. I'm looking forward for the updated Photoshop plugins. I'm currently stuck with Photoshop CS2 because Photoshop CS3 crashes on my box when I use the plugins there. How about a developer branch? Yuv --~--~-~--~~~---~--~~ 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: windows binary release
allard schrieb: no panomatic is definitely not in the SDK. and it adds short term problems - until the patent (SURF) expires. I think we need to follow the lead of the Mac OSX builds and make separate installers for the CP generators. But I also think that this should come after the SDK-build, binaries-build and installer compilation work well enough in sync. not now. for now leave it as it is, but leave it broken (i.e. don't add panomatic itself). I was recently looking for that patent on SURF. I couldn't find it. See: http://v3.espacenet.com/publicationDetails/biblio?CC=EPNR=2027558A2KC=A2FT=Ddate=20090225DB=EPODOClocale=en_V3 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 -~--~~~~--~~--~--~---
