[hugin-ptx] Re: Some of my recent hugin efforts
On 6 Nov., 06:36, Robert Krawitz r...@alum.mit.edu wrote: I've posted a bunch of the panorama, exposure fused, and exposure fused panorama shots I've been working on tohttp://rlk.smugmug.com/Other/Landscapes/4851912_oeCNm#1079379436_dCVAv (#9-15). These are the ones I was making so much noise about a few weeks ago :-) These aren't actually full size. Comments welcome. Nice one! Seems making noise was to good effect;) Bit difficult to make technical comments on the images since they're so small, but they look fine to me. One thing I'm not sure about: it looks as if some of the images were done with a polarizer. Is that so? The effect of using a polarizer is that the view will differ quite a bit from one shot to the next (especially noticable in the sky), and when you stitch the lot, the result may look slightly unnatural, so it's usually recommended not to use a polarizer for panoramas, unless you really want the effect. with regards Kay -- 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: Not a Panorama - just control points for Enfuse - How to?
On 6 Nov., 01:41, Isaac Gouy igo...@yahoo.com wrote: Where do I have to give them separate fake EV values? In the exif of the photos? In some input field in Hugin? You don't have to change anything in your images, though that works just the same. It's enough to go to the 'camera and lens' tab, choose the 'photometric' subsection, select each image in turn and enter the fake EV value in the 'EV' field in the lower left of the screen. Although from what I've seen a stable camera is a basic requirement for enfuse exposure fusion and focus fusion - any movement beyond what align_image_stack can fix seems to be too much movement for an acceptable result. Correct. To use enfuse you need very precise alignment. Much more than in ordinary stitching, where enblend can just try and put the seam somewhere where there's little visible discrepancy. Your 'movement' inevitably translates to parallactic errors, so precise alignment becomes impossible and the result is disappointing. This is no fault of the software, it's a direct consequence of the laws of optics. So you absolutely must shoot from the same position. If you can't use a tripod, find a rock or tree. The problem with focus stacks is that you have to change the focus between shots, so unless your camera is mounted somehow, it's very difficult to maintain the same position from one shot to the next. With exposure blending, you can just do an AEB with a steady hand and that may still be enough. with regards Kay -- 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: Stitcher Tab
Hi James, I know that this is a long wished feature. But we have Darkos overview branch which some massive changes to the fast preview window waiting to integrate. So it would be a better way to integrate the feature into this branch and not into default. Now the integration has become more complicated. And maybe some of your changes need to be done again after integration. I needed to fix some issues so that it compiles on windows. At a first test a had some crashes. Project 1: 20 images Project 2: 5 images 1.) Load project 1 2.) Switch to cp tab and select image 1 and image 15 (e.g.) 3.) Load project 2 - crash I think this happens when an image with a number higher than the new max image number is selected in the cp tab. Thomas -- 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: Some of my recent hugin efforts
On Sat, 6 Nov 2010 01:35:55 -0700 (PDT), kfj wrote: On 6 Nov., 06:36, Robert Krawitz r...@alum.mit.edu wrote: I've posted a bunch of the panorama, exposure fused, and exposure fused panorama shots I've been working on tohttp://rlk.smugmug.com/Other/Landscapes/4851912_oeCNm#1079379436_dCVAv (#9-15). These are the ones I was making so much noise about a few weeks ago :-) These aren't actually full size. Comments welcome. Nice one! Seems making noise was to good effect;) Bit difficult to make technical comments on the images since they're so small, but they look fine to me. One thing I'm not sure about: it looks as if some of the images were done with a polarizer. Is that so? The effect of using a polarizer is that the view will differ quite a bit from one shot to the next (especially noticable in the sky), and when you stitch the lot, the result may look slightly unnatural, so it's usually recommended not to use a polarizer for panoramas, unless you really want the effect. No polarizer; this was done with curve and saturation tweaking (in some cases selectively on the sky). I uploaded them to SmugMug at horizontal sizes of 3000~4000 pixels (the originals were 8000~16000). At some point I'll probably go back and upload the full size. I learned a lot during this, and next time it will be quite a bit faster. -- 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: Problems building HG default version on Windows
Hugin_2010.3.0 now requires also the boost library signals. To rebuild boost libraries: bjam --with-date_time --with-thread --with-regex --with-filesystem -- with-iostreams --with-system --with-signals toolset=msvc variant=debug variant=release link=static threading=multi runtime-link=static stage -- 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: Some of my recent hugin efforts
Some other comments about this whole thing: 1) Panoramas with extreme wide angle lenses do work. The 360 of Provincetown and the shot down Crawford Notch (with the road and railroad running off into the distance) were both taken with my 8-16 mm lens at 8 mm. There is some distortion at that setting, which didn't matter for the Crawford Notch shot but which did for Provincetown (with the horizon visible just about everywhere). In the latter case, I had to use a lot of horizontal control points and other linear control points to correct it, but when I did, things snapped into place. For Crawford Notch, I simply didn't worry about it and had no problem. 2) Even with an extreme wide angle lens, photos should be taken as closely spaced as practicable, preferably not more than 45 degrees apart. Remapping to cylindrical (which I use) or equirectangular causes the images to severely barrel; if there isn't a lot of overlap, there will be a lot of foreground that isn't usable after cropping. At Provincetown, I had no choice but to space them 90 degrees apart due to the construction of the monument I was shooting from (and it's very obvious that there's no other place from where I could take this shot). If the viewing platform were octagonal rather than square, I could have gotten a lot more foreground. 3) Except for the sunsets (on a tripod) and the 360 (on a monopod, but from different locations), everything was hand held. That should have caused problems in the foreground from perspective errors...but in practice didn't. The reason is that these shots emphasize background more than foreground, and I simply tossed control points in the foreground that were correct but which had large errors. Enblend managed to do a good job; there aren't a lot of visible seams even if you do know where to look. 4) Blend stacks or fuse layers: that is the question. Blending from stacks caused some colorimetric problems in the 360; the areas near the edges of the original photos turned out noticeably lighter. However, fusing layers caused ghosting problems where enblend picked different seam lines for each exposure set (quite apart from ghosting caused by subject motion between the three shots in each stack). In the end, I went with blending stacks. I guess one way around this would be to use enblend with one layer, generate the masks from it, and use those masks to blend the other layers. Perhaps Hugin could automate that? It would probably yield the best results of all when blending a panorama consisting of exposure-bracketed stacks. 5) Related to point (2), if you don't take enough extra shots at both ends of what you're interested in, the barreling effect of the remapping will result in either the left and right ends not being usable or having to crop a lot vertically. I found an easy workaround for this problem. After creating the initial panorama, run Hugin again on the panorama (just the one image). Specify the lens as a wide angle cylindrical lens, and then specify the output projection as rectilinear. This has the opposite effect of remapping rectilinear to cylindrical: it pincushions the result. Experimenting with different angles (I used 20 mm for Crawford Notch and 30-35 for most of the others, which were taken with the longer end of the 8-16 lens) eventually gave me something good in each case. Until I came up with that trick, I was faced with a very unpleasant cropping decision on the sunset panorama, but this trick expanded the height at the left and right enough that I got everything I wanted. Taking one more shot (or bracket sequence) at each end, and setting the lens to somewhat wider than I really wanted, also would have solved this problem. This obviously won't work for the 360. 6) Autocrop isn't all that useful. Sometimes the cropping decisions it made were rather strange. But there's another kind of autocrop that would have been very useful to me: crop to the outer envelope of the panorama (rather than something approximating an inner envelope or maximum fully covered area). (Sorry, I don't have time to get involved here; I have a big backlog of stuff as it is with Gutenprint that I need to get to, so perhaps Yuv will forgive me for suggesting this enhancement without providing code to go along with it!) 7) I'm still not entirely happy with what enfuse does, particularly with sunsets and very bright sky near the horizon (see the sunset panorama -- the dark exposures have plenty of detail in the clouds near the horizon that enfuse lost, and there's no way to get it back). The exposure-mu and exposure-sigma parameters (and, for that matter, the others) are not at all intuitive. It's a great tool and a lot easier than tone mapping with qtpfsgui aka luminance, but for a
[hugin-ptx] Re: Some of my recent hugin efforts
Robert Krawitz r...@alum.mit.edu wrote: [...] 8) For control points with exposure stacks, I found the following strategy to work well: connect the middle exposures to the other middle exposures, and connect the low and high exposures only to the middle exposure of the same stack (and maybe to each other, but only within the same stack). The CP finders that I've tried don't do too good of a job of matching features between images that are exposed very differently (or in general for areas that are badly exposed, and I'm intentionally badly exposing to get selective good exposure in the highlights and shadows), and it's important to have a really good match between the exposures in each stack. So I simply knock out all the control points connecting high and low exposures with any shot in a different stack. If you assign the images to stacks using Autopano-SIFT-C (multirow/stacked) as control point detector will do something like this. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- 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: Not a Panorama - just control points for Enfuse - How to?
On Nov 6, 1:58 am, kfj _...@yahoo.com wrote: On 6 Nov., 01:41, Isaac Gouy igo...@yahoo.com wrote: Where do I have to give them separate fake EV values? In the exif of the photos? In some input field in Hugin? You don't have to change anything in your images, though that works just the same. It's enough to go to the 'camera and lens' tab, choose the 'photometric' subsection, select each image in turn and enter the fake EV value in the 'EV' field in the lower left of the screen. Although from what I've seen a stable camera is a basic requirement for enfuse exposure fusion and focus fusion - any movement beyond what align_image_stack can fix seems to be too much movement for an acceptable result. Correct. To use enfuse you need very precise alignment. Much more than in ordinary stitching, where enblend can just try and put the seam somewhere where there's little visible discrepancy. Your 'movement' inevitably translates to parallactic errors, so precise alignment becomes impossible and the result is disappointing. This is no fault of the software, it's a direct consequence of the laws of optics. The only reason I was tempted to try was that as you say, in ordinary stitching there's often little visible discrepancy. So you absolutely must shoot from the same position. If you can't use a tripod, find a rock or tree. The problem with focus stacks is that you have to change the focus between shots, so unless your camera is mounted somehow, it's very difficult to maintain the same position from one shot to the next. With exposure blending, you can just do an AEB with a steady hand and that may still be enough. As long as the camera provides a wide enough bracket, otherwise it's the same situation as focus fusion :-) -- 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: Some of my recent hugin efforts
On 6 Nov., 16:22, Robert Krawitz r...@alum.mit.edu wrote: Some other comments about this whole thing: 4) Blend stacks or fuse layers: that is the question. Blending from stacks caused some colorimetric problems in the 360; the areas near the edges of the original photos turned out noticeably lighter. However, fusing layers caused ghosting problems where enblend picked different seam lines for each exposure set (quite apart from ghosting caused by subject motion between the three shots in each stack). In the end, I went with blending stacks. I am more of a stack person myself, for precisely these reasons. I think I should point you to an interesting technique here. If you take a good look at the enfuse manual, it states (quote) 7.3.2 Common Misconceptions Here are some surprisingly common misconceptions about exposure series. A single image cannot be the source of an exposure series. Raw-files in particular lend themselves to be converted multiple times and the results being fused together. The technique is simpler, faster, and usually even looks better than digital blending (as opposed to using a graduated neutral density filter) or blending exposures in an image manipulation program. Moreover, perfect alignment comes free of charge! ... (end quote) How can that be? Because your camera has a greater dynamic range than can be shown on the screen. So if you take a raw image that is not overexposed anywhere at low ISO, there is plenty of dynamic range to play with. What you do is, for example, develop the raw once to show the sky perfectly, at the same time letting the shadows go very dark, and then develop again to an image where the sky is white but the land is perfectly exposed. If you enfuse these two exposures (using mainly saturation as your criterion), the effect is often astonishingly good. Try playing with that! as the manual says, perfect alignment comes with the technique free of charge. with regards KFJ -- 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: Stitcher Tab
Hi devs, On November 6, 2010 06:32:36 am T. Modes wrote: I know that this is a long wished feature. But we have Darkos overview branch which some massive changes to the fast preview window waiting to integrate. So it would be a better way to integrate the feature into this branch and not into default. Now the integration has become more complicated. And maybe some of your changes need to be done again after integration. quick fix. how good is tip to branch out a release? are there critical bugs that need attention? If there is consensus amongst the devs I can branch out 2010.4 and run the release process. This will free tip for the integration of the overview branch and solve the current bottleneck. Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Some of my recent hugin efforts
On November 6, 2010 01:36:57 am Robert Krawitz wrote: Comments welcome. thank you for sharing. good to see that the effort was worth it. some of them are a bit oversaturated for my taste, but that's purely subjective. I hope to see you regularly here. Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] LP demo link
Hi Lukáš On November 4, 2010 09:41:17 am Lukáš Jirkovský wrote: I am trying to avoid own hosting because it eats up resources that we don't have. If we had resources, I would prefer to see them prioritized first to provide official binary releases than hosting. Ah, the windows binary saga... Almost forgot about it. It's not just windows. Some windows users happen to be the more vocal about it, but the issue concerns the project as a whole and every supported platform. I still don't want to think what would happen if Harry would give up the Mac for Kubuntu ;-) During the 2010.2 release cycle Windows installers were actually at the forefront, both in terms of quantity and quality. For the first time we have both a 32bit and 64bit binary installer on the official SF download space and there are a number of capable builders/contributors sharing on this list. The wiki documentation is not up to date yet, but at some point they will discover that too. I will feel comfortable about project resources when we can achieve the following: 1. at least two experienced active builders for every major supported platform 2. official binary distributions for all major supported platforms within a week of release of source code tarballs. Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Re: Stitcher Tab
On Sat 06-Nov-2010 at 14:22 -0400, Yuval Levy wrote: quick fix. how good is tip to branch out a release? are there critical bugs that need attention? I think it is ok. There are bound to be some more bugs that need fixing, and maybe some new ones from the background image loading, but now is the time to do a feature freeze and go for a release. If there is consensus amongst the devs I can branch out 2010.4 and run the release process. This will free tip for the integration of the overview branch and solve the current bottleneck. Thanks for offering to do the release, it would be great to get 2010.4.0 out before the end of the year. Especially since it will be the first Hugin version with a full feature-set. -- 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: Stitcher Tab
On Sat 06-Nov-2010 at 03:32 -0700, Thomas Modes wrote: I know that this is a long wished feature. But we have Darkos overview branch which some massive changes to the fast preview window waiting to integrate. So it would be a better way to integrate the feature into this branch and not into default. Now the integration has become more complicated. I was going to say that one of the advantages of moving to Mercurial is that it ought to be possible to pull all the updated stuff from the tip into the overview branch and then merge this branch with the tip later (something that would have been painful with Subversion). ..but James just did this, so it looks to be ok. -- 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] Recent changes to default branch slow preview display
Hullo All, I have just been testing the recent changes in the default branch (rev b6554a90d55), and am seeing slow display of images in both the fast preview window and the control points tab. For example, if I select the control points tab, then select images 0 and 1, there is a noticeable delay before image 1 is displayed, and moving on to images 1,2 there is a delay before image 2 is displayed. In the fast preview window, if I select photometrics, each image is displayed with a delay between. This does vary between projects, some of the scanned images I have been playing with are larger and they do exhibit a more noticeable delay. This has never been an issue on my system previously, images in the control points tab and FPW have always 'appeared' to display instantly, so for my typical project, these recent changes seem to be a step backwards. I guess the changes do have some benefit in areas or projects that I don't use. Is there a cmake or configure option that might help with this? 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] Precondition violation - crash
With the current (or least past few days) Mercurial, if I open a project (or create a new one, open the control point table, and click on a control point, I get the following crash: ContractViolation: Precondition violation! BasicImage::upperLeft(): image must have non-zero size. (/home/rlk/sandbox/hugin/src/foreign/vigra/vigra/basicimage.hxx:857) If, however, I open either preview (the slow one or the fast GL one), I'm able to do so. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton -- 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] Enblend's determination of feature size
As I understand it, enblend selects the seam width based on its determination of feature size -- the smaller the local feature size (the more detail there is), the narrower the seam. The problem here is that when the feature size is anisotropic -- for example, the local features consist of long horizontal lines -- enblend doesn't pick the seam width very well. The attached image fragment demonstrates this. The local features are long, more or less featureless horizontal lines, so there's a lot of detail in the vertical direction but almost none in the horizontal direction. If a seam crosses these lines, enblend selects a narrow seam because there's a fair amount of local detail. The problem is that there isn't really much detail across the seam boundary. In this case, the horizontal lines were rows of waves in the far distance, so they moved between shots (there may also have been focus differences playing a part). I think that enblend should primarily at the detail perpendicular to the seam and ignore detail parallel to the seam. In this case, there's a fair amount of detail in the vertical direction, parallel to the seam, but almost nothing perpendicular to it. -- 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 enblend-issue.tif
[hugin-ptx] some mailing list admin, displaying the membership list
I'd like to change a googlegroups setting so that members can see the members list. This page doesn't include email addresses, just usernames. The old 'ptx' mailman list allowed this, and it doesn't seem right that this stuff should be hidden in an open project. -- 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] Recent changes to default branch slow preview display
On Sat, 2010-11-06 at 15:58 -0700, Tduell wrote: Hullo All, I have just been testing the recent changes in the default branch (rev b6554a90d55), and am seeing slow display of images in both the fast preview window and the control points tab. The images now show as a temporary place holder while they are fetched and decoded. Previously the user interface would freeze and not respond during image loading. This means when you start the fast preview, the window should appear and become usable much quicker, but take just as long to get all the images. Similarly, the control point will show a blank image and let you do other things while the image is loading. This has never been an issue on my system previously, images in the control points tab and FPW have always 'appeared' to display instantly, so for my typical project, these recent changes seem to be a step backwards. Is the total time taken noticeably slower? Or is it the display changing without the images present which you don't like? Is there a cmake or configure option that might help with this? Sorry, I didn't make it optional. I thought having an unresponsive interface while images load was always a bad thing. If there is a noticeably slower total time between request and full result displaying, I would say that is a bug however. -James -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: Stitcher Tab
On Sat, 2010-11-06 at 03:32 -0700, T. Modes wrote: I know that this is a long wished feature. But we have Darkos overview branch which some massive changes to the fast preview window waiting to integrate. So it would be a better way to integrate the feature into this branch and not into default. I've merged changes from default into the overview branch, so merging overview into default should be much easier now. Project 1: 20 images Project 2: 5 images 1.) Load project 1 2.) Switch to cp tab and select image 1 and image 15 (e.g.) 3.) Load project 2 - crash I think this happens when an image with a number higher than the new max image number is selected in the cp tab. I tried something similar, but on my system the control point editor selected the highest numbered image in the second project, displayed it when loaded, and carried on as usual. Could you provide a backtrace for this crash? -James -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] some mailing list admin, displaying the membership list
On 6 November 2010 23:24, Bruno Postle br...@postle.net wrote: I'd like to change a googlegroups setting so that members can see the members list. This page doesn't include email addresses, just usernames. ok with me mick -- 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] some mailing list admin, displaying the membership list
On 07.11.2010 00:24, Bruno Postle wrote: I'd like to change a googlegroups setting so that members can see the members list. This page doesn't include email addresses, just usernames. Ok to me. Bernd -- Bernd Hohmann Dipl. Organisationsprogrammierer DV Sachverständiger Gutachter Höhenstrasse 2 * 61130 Nidderau Telefon: 06187/900495 * Telefax: 06187/900493 Blog: http://blog.harddiskcafe.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
Re: [hugin-ptx] Precondition violation - crash
On Sat, 2010-11-06 at 19:01 -0400, Robert Krawitz wrote: With the current (or least past few days) Mercurial, if I open a project (or create a new one, open the control point table, and click on a control point, I get the following crash: ContractViolation: Precondition violation! BasicImage::upperLeft(): image must have non-zero size. (/home/rlk/sandbox/hugin/src/foreign/vigra/vigra/basicimage.hxx:857) Thanks for reporting this. I fixed it in Mercurial. -James -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
