[hugin-ptx] Re: traditional preview
AKS-Gmail-IMAP wrote: Along the lines of transforming the fast preview into the main base for the final product composition, the crop feature should be expanded to include cropping individual images in context with the final product. there are two different crops: input crop (individual images) and output crop (output panorama). I hope that at some point we'll have a context menu when right-clicking on an input image on the layout (and maybe even on the distorted preview), to open the image in the (existing) croppying window; to open it in a (work in progress based on a gsoc2008 project) mask editor; to select it for the left or right half side of the CP editor. future stuff 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] Hugin-2009.4.0_rc1 source code released
Panorama stitching and more. A powerful software package for creation and processing of panoramic images. hugin-2009.4.0_rc1 (release candidate 1) tarball is available here: https://sourceforge.net/projects/hugin/files/hugin-2009.4_beta/hugin-2009.4.0_rc1.tar.gz/download This is a candidate release and may be declared final on October 31. CHANGES SINCE LAST BETA: * updated translations: - Czech (Lukáš Jirkovský, Vaclav Cerny) - Dutch (Harry van der Wolf) - French (Jean-Luc Coulon) - German (Joachim Schneider) - Swedish (Ulf Wilhelmson) * improved plattform support - CMake build (Kornel Benko) - Windows Installer (Allard Katan) * bug fixes (Thomas Modes) MAJOR CHANGES SINCE 2009.2.0: * Automated Lens Calibration: a new command line tool to extract automatically lens correction parameters. (Tim Nugent) * New pruning of bad control points by means of statistical method. Clean control points button on the Images tab. (Thomas Modes) * Improved usability, particularly crop settings and help which now uses the system's default browser. The handbook itself still needs work, styling and translation. (Yuval Levy) * Lots of bugfixes, hopefully not so many new bugs. See README, ChangeLog and INSTALL_cmake for more information. This release is tagged in the subversion repository as /hugin/tags/hugin-2009.4.0_rc1 at revision 4598. SHA1SUM: ee761ee7c28f09d83ed3f94765a3faa82368bd7f hugin-2009.4.0_rc1.tar.gz Recent Hugin binary installers for testing are provided by the users communities and can be found here: http://panospace.wordpress.com/downloads/ --~--~-~--~~~---~--~~ 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: Integration Queue Status Oct 11
2009/10/11 Yuval Levy goo...@levy.ch: Hi all, to my understanding, trunk builds well on the main supported plattforms and the integration of Lukáš' deghosting has worked well (thanks to Thomas for the GUI addition). Has anybody checked this [patch]? I'll certainly look at it. I usually check only bug tracker. I'll wait at least until Oct 31 to declare 2009.4.0 final (may be later if show stopping bugs are found). Trunk is open for further integration. What should go next? to my understanding, gsoc2008_layout is not ready yet? shall we put in Gary Stein's auto-crop? will need some GUI work. the other features on my radar screen are relatively small (feel free to add / correct): - improved localization (Yuv), need testing on OSX, and need to make it optional (feedback Rogier Wolff) - proactive cacheing v1 (Yuv), pending discussion with James et al. - panorama transforms palette (Yuv), need further implementation then there are a number of patches in our patch tracker. I have not tested them, has anybody? should we consider / integrate? Yuv [patch] https://sourceforge.net/tracker/?func=detailaid=2874644group_id=77506atid=550443 --~--~-~--~~~---~--~~ 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?
Let me mention that I'm good at C but I don't have much if any C++
experience. I just know the principles.
On Sat, Oct 10, 2009 at 05:14:08PM -0700, grow wrote:
cout R11c;fflush (stdout);
if (snake-front().first) {
cout R16;fflush (stdout);
// First vertex is moveable. Rotate list so that first vertex is
nonmoveable.
Segment::iterator firstNonmoveableVertex = snake-begin();
while (firstNonmoveableVertex-first) ++firstNonmoveableVertex;
cout R17;fflush (stdout);
// Copy initial run on moveable vertices and first nonmoveable
vertex to end of list.
Segment::iterator firstNonmoveablePlusOne =
firstNonmoveableVertex;
++firstNonmoveablePlusOne;
cout R18;fflush (stdout);
snake-insert(snake-end(), snake-begin(),
firstNonmoveablePlusOne);
cout R19;fflush (stdout);
// Erase initial run of moveable vertices.
snake-erase(snake-begin(), firstNonmoveableVertex);
cout R20;fflush (stdout);
}
Segment is an slist, which seems to be standard C++.
OK. I was fearing a thousand-entry list as 'snake', and having to
step through all that. Not so... When things go wrong:
the snake is:
110322,2103 010320,2087
So first nonmovable is the second entry.
So firstNonmoveablePlusOne is snake.end()
and then when trying to insert the part of the list upto-end just
before end() you end up in an infinite loop. This code doesn't work
if the list is just two entries long.
My C experience tells me that when you code things like this just
right, you shouldn't need, any special cases. However my C++
experience is not good enough to know how to code this so that special
casing is not required.
Anyway, I'll try to create some special-case code for the two element
list that needs to be swapped.
On the other hand, maybe a snake of only two elements is
nonsensical. I have not studied the code enough to know what it's
doing here. I just traced the code to find where and why it's
crashing. So maybe after adding the code to just swap the two
elements, which it is trying to do, things will crash just a little
bit further on because two element lists is never expected. We'll see.
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: traditional preview
On Sat, Oct 10, 2009 at 09:07:47PM -0400, Yuval Levy wrote: initial palette mockup attached. Icons will need to be designed. Have not thought of full screen mode yet - IMO it is a no brainer and when the fast preview is the hub it should open full screen only. I hate programs that think they are the only one on my computer and go full-screen automatically. If I'm working with a single program I may want to dedicate 80-90% of my screenspace to this program, but almost never all. So to me full screen is 90% of my pixels. Or maybe 45% on my dual screen setup... All this tells you is that this is a personal preference. Options: - Make it a preference setting. - just start up the way the user left it last time. - both of the above. (settings: normal window, full size, leave at previous) 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: traditional preview
On Sat, Oct 10, 2009 at 09:07:47PM -0400, Yuval Levy wrote: ... we'll have to get around this. Lukas suggested a second, lower priority thread (in another ML-thread I have yet to answer). The UI should be functional / responsive even when the images are not loaded in the preview, with placeholders being filled as time passes by. Really, showing previews should be almost instantaneous. But why aren't they? I have a computer running several CPUs at several billions of operations per second per CPU. I (the human) can only process about 2 Mpixels at about 1 FPS (unless they are highly correlated as in a movie). With 4 bytes per pixel, we're talking about 10Mbytes per second of throughput to create an almost instantaneous feedback! Should be no problem with almost 10 billion operations per second available? No? Waiting minutes for a preview to open is totally unneccesary. So where does the difference come from? A large project has a destination resolution of several gigapixels. Several billion pixels! This is usually stored as jpeg which is CPU intensive to decode. Or it is stored as a TIFF, which is disk-intensive to load. (*) The preview however only deals with up to two megapixels of visual information. Why process billions of pixels when only just over a million matter? How can we implement this? As soon as we get told about an image, we should start off a thread that decompresses the jpeg, reduces the resolution by half, and caches the result (on disk!) somewhere. Repeat until the images are very small. Say less than 64 pixels in both directions. (in JPEG there may even be shortcuts you can take if you want to just find out the sum of each 4 adjacent pixels! You can skip decoding all higher-freqency coefficients) This should happen just once. Now, for a preview, a quick calculation will tell you that the two opposite corners of an image in the preview window lie for example 200 pixels apart. Then grabbing the 256x192 thumbnail for the preview is going to be adequate. Similarly, showing the whole image in the control-point editor, requires only access to a lower-resolution version of the image. Zooming in to 100%, actually only requires access to PART of the full image. So even then it could be made unneccesary to decode the whole 10 megapixels of my camera. Roger. (*) the tiffs are so large, we should assume they do not fit into memory. -- ** 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?
On Sat, Oct 10, 2009 at 05:14:08PM -0700, grow wrote:
output file. The crashes tend to happen as the number of mask and/or
the complexity of their shape increases, especially if I request a
full-size output file.
It seems you have so many (157) seams that some of them are quite
short (only two entries). Apparently two entries is not a problem,
except for the situation where they are the wrong way around: The
first should not be moveable(*). So having corrected the code for
making sure that the first one is (non)movable, enblend runs just
fine.
The patch for enblend is attached.
George's village hotel now stitches just fine at 12000x6000.
Roger.
(*) Or the other way around, I don't care. Too many negatives makes my
head spin.
--
** 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
-~--~~~~--~~--~--~---
diff --exclude config.log -ur enblend-enfuse-3.2/src/mask.h enblend-enfuse-3.2-rew/src/mask.h
--- enblend-enfuse-3.2/src/mask.h 2008-03-02 22:19:47.0 +0100
+++ enblend-enfuse-3.2-rew/src/mask.h 2009-10-11 12:04:28.0 +0200
@@ -512,9 +512,15 @@
// Copy initial run on moveable vertices and first nonmoveable vertex to end of list.
Segment::iterator firstNonmoveablePlusOne = firstNonmoveableVertex;
-++firstNonmoveablePlusOne;
-snake-insert(snake-end(), snake-begin(), firstNonmoveablePlusOne);
+ // This (the else clause of this if) used to crash on
+ // two-element lists. I'd rather not special case this
+ // situation, but I personally don't know any better. Sorry. --REW
+ if (++firstNonmoveablePlusOne == snake-end()) {
+ snake-insert_after (firstNonmoveableVertex, snake-begin(), firstNonmoveableVertex);
+ } else {
+ snake-insert(snake-end(), snake-begin(), firstNonmoveablePlusOne);
+ }
// Erase initial run of moveable vertices.
snake-erase(snake-begin(), firstNonmoveableVertex);
}
[hugin-ptx] Re: Integration Queue Status Oct 11
On Sun, Oct 11, 2009 at 12:21:37AM -0400, Yuval Levy wrote: - improved localization (Yuv), need testing on OSX, and need to make it optional (feedback Rogier Wolff) Don't consider this a need. Your argument: but we already can't configure the translations in wxwidgets holds up for me. 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-2009.4.0_rc1 source code released
Yuval Levy goo...@levy.ch wrote:
[...]
* Improved usability, particularly crop settings and help which now
uses the system's default browser.
[...]
Hello,
This does not work for me at all. I somehow get the feeling that the
respective wx-function *requires* KDE or GNOME instead of
using/falling back to to /etc/{mailcap,mime.types} if necessary.
Could hugin perhaps fall back to old-style-help if lauching the
browser fails?
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: possible memory leak in enblend enfuse?
Roger, WOW! all the best George On 11 Oct, 12:10, Rogier Wolff rew-googlegro...@bitwizard.nl wrote: On Sat, Oct 10, 2009 at 05:14:08PM -0700, grow wrote: output file. The crashes tend to happen as the number of mask and/or the complexity of their shape increases, especially if I request a full-size output file. It seems you have so many (157) seams that some of them are quite short (only two entries). Apparently two entries is not a problem, except for the situation where they are the wrong way around: The first should not be moveable(*). So having corrected the code for making sure that the first one is (non)movable, enblend runs just fine. The patch for enblend is attached. George's village hotel now stitches just fine at 12000x6000. Roger. (*) Or the other way around, I don't care. Too many negatives makes my head spin. -- ** 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 infinite-fix.diff 1KViewDownload --~--~-~--~~~---~--~~ 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 and cppcheck
2009/9/29 Yuval Levy goo...@levy.ch: Lukáš Jirkovský wrote: Anyway, there are some reported memory leaks which I think they are not really a problem like the leak in align_image_stack.cpp. Eg. this one is that the leftImage is not deallocated but then align_image_stack terminates almost immediately. Should I fix these too? Thanks for all the good work, Lukáš Please fix. IMO keeping the code clean is good practice, always. Also as a general practice: rely on your judgment when deciding whether to commit or not. If you fear unintended consequences on platforms other than yours, request people to test a patch. If you have no negative feedback on the patch within a week or so, commit. And if the change is small, works locally, and is unlikely to break other things, just commit it. Yuv [hugin/src/hugin1/hugin/PreviewTool.h:36]: (error) Class PreviewTool which is inherited by class PreviewIdentifyTool does not have a virtual destructor This one is not problem now since there doesn't seem to be any need for destructor in any of it's children. Is it possible that it may become a problem in future? Lukas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- destructor.patch Description: Binary data
[hugin-ptx] Re: hugin and cppcheck
On Sun, 2009-10-11 at 16:43 +0200, Lukáš Jirkovský wrote: [hugin/src/hugin1/hugin/PreviewTool.h:36]: (error) Class PreviewTool which is inherited by class PreviewIdentifyTool does not have a virtual destructor This one is not problem now since there doesn't seem to be any need for destructor in any of it's children. Is it possible that it may become a problem in future? Lukas There isn't a need for a destructor at the moment because the tools are only freed when Hugin quits. Some PreviewTools allocate OpenGL textures which are not freed automatically, so would need a destructor if that changes. I imagine more PreviewTools will be written, and we are planning to change the way they are accessed (In the Traditional Preview thread), so it is possible that a virtual destructor is needed in the future. -James --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Hugin-2009.4.0_rc1 source code released
Andreas Metzler wrote:
Yuval Levy goo...@levy.ch wrote:
[...]
* Improved usability, particularly crop settings and help which now
uses the system's default browser.
[...]
Hello,
This does not work for me at all. I somehow get the feeling that the
respective wx-function *requires* KDE or GNOME instead of
using/falling back to to /etc/{mailcap,mime.types} if necessary.
Could hugin perhaps fall back to old-style-help if lauching the
browser fails?
My understanding is that this would be a wxWidgets issue. Have you
thought of filing a bug report there?
While adding the fall back would not be technically difficult, and I am
likely to release another release candidate before the expected final
release on October 31, I am very reluctant to fall back on
old-style-help - unless there is enough critical mass to the request.
For all practical purposes old-style-help was dysfunctional for a
contemporary help system with hyperlinks. And when the average user
faces this dysfunction, the blame falls on... you guess it.
So I'm inclined to put an explanation how to remedy the failure (please
install a contemporary web browser). IMO it is safe to assume that a
system running a modern GUI application like Hugin has at least the
resources to run an applicable web browser. We are not asking the user
to be connected to the www (which would be unreasonable IMO).
Using proper web-pages / web-standards for the documentation is for me a
first step toward injecting more dynamic into the documentation process.
I hope to create a welcoming environment for users to contribute to the
documentation - with tutorials, images, maybe even animations and
movies. Improving documentation's quantity / quality / translation.
The limit will be the minimum common functionality of all viable
browsers. I don't want to put an even lower limit on users by using
old-style-help. In the explanation we can refer them to the wiki, but
that would require proper web browser *and* www connection. And we can
refer them to the man pages and other text based help, but that is very
minimal and hardly maintained, while with an HTML help system based on
widely adopted standards we may even get to a Docbook or other modern,
managed documentation system that produces different outputs, including
PDF for print (another alternative for those who do not have a
functional and modern web browser).
What do other think of this? is the new help also limiting for them
because it implies the presence of a modern web browser?
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: Integration Queue Status Oct 11
Rogier Wolff wrote: On Sun, Oct 11, 2009 at 12:21:37AM -0400, Yuval Levy wrote: - improved localization (Yuv), need testing on OSX, and need to make it optional (feedback Rogier Wolff) Don't consider this a need. Your argument: but we already can't configure the translations in wxwidgets holds up for me. OK, thanks. And thank a lot for debugging Enblend. I loved watching you going, and it makes me feel less lonely as I dip my toes into C++ 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: Integration Queue Status Oct 11
Lukáš Jirkovský wrote: I'll certainly look at it. I usually check only bug tracker. thanks! it is worth it to subscribe to the [t]rackers' mailing list - I use a separate inbox for all these mailing lists stuff and it becomes kind of a todo list - I scan everything and I keep what I want to answer. Then I go about answering them and delete them only after they are answered (or when I don't have time). Yuv [t] https://lists.sourceforge.net/lists/listinfo/hugin-tracker --~--~-~--~~~---~--~~ 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: traditional preview
Rogier Wolff wrote: I hate programs that think they are the only one on my computer me too. and go full-screen automatically. me not because I try to do one thing at a time. I find it more efficient, at least when I'm not interrupted. - just start up the way the user left it last time. that's the way it is now, and I'll leave it like that. I suspect more people will come with the same objection. It's like trying to stop smoking... 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: traditional preview
Rogier Wolff wrote: Really, showing previews should be almost instantaneous. But why aren't they? now this one was an excellent piece of analysis. I agree 100%. As soon as we get told about an image, we should start off this is what I tried to approximate with my primitive use of the idle time (assuming that immediately after loading an image the software goes in idle mode, which is where modern CPU spend most of their time) a thread a separate thread would be more efficient indeed. that decompresses the jpeg, reduces the resolution by half, and caches the result (on disk!) somewhere. Repeat until the images are very small. Say less than 64 pixels in both directions. (in JPEG there may even be shortcuts you can take if you want to just find out the sum of each 4 adjacent pixels! You can skip decoding all higher-freqency coefficients) This should happen just once. this is a very interesting strategy. disk space is cheap nowadays and does not suffer the addressing limitations of RAM. however we can't assume that disk space is unlimited, especially when people work with very large projects. And we need to leave enough disk space for later stages of the process (enblend). So add to it some disk space calculations to prevent errors like could not write to file. also, aren't there intermediate image formats that are faster to load from disk into memory than TIFF and JPEG? that said, caching on disk the images, even at full resolution, would be very helpful to me. I often stitch from a network drive just because I am too lazy to copy the files from the network drive to the local drive and back (and because the local drive is not backed up like the network drive is). for the resolution scaling, wouldn't it make sense to go powers of two from the initial scaling? Now, for a preview, a quick calculation will tell you that the two opposite corners of an image in the preview window lie for example 200 pixels apart. Then grabbing the 256x192 thumbnail for the preview is going to be adequate. Similarly, showing the whole image in the control-point editor, requires only access to a lower-resolution version of the image. Zooming in to 100%, actually only requires access to PART of the full image. So even then it could be made unneccesary to decode the whole 10 megapixels of my camera. I love this kind of thinking; and I hope that one of our student turned master wizards on this list will pick up on it and make it come true. 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: Hugin-2009.4.0_rc1 source code released
Yuval Levy goo...@levy.ch wrote:
Andreas Metzler wrote:
Yuval Levy goo...@levy.ch wrote:
[...]
* Improved usability, particularly crop settings and help which now
uses the system's default browser.
[...]
Hello,
This does not work for me at all. I somehow get the feeling that the
respective wx-function *requires* KDE or GNOME instead of
using/falling back to to /etc/{mailcap,mime.types} if necessary.
Could hugin perhaps fall back to old-style-help if lauching the
browser fails?
My understanding is that this would be a wxWidgets issue. Have you
thought of filing a bug report there?
You are probably right. I will try whether wxWidgets upstream is as
responsive as you are. ;-)
[...]
So I'm inclined to put an explanation how to remedy the failure (please
install a contemporary web browser).
export BROWSER=firefox
would probaly work.
IMO it is safe to assume that a
system running a modern GUI application like Hugin has at least the
resources to run an applicable web browser. We are not asking the user
to be connected to the www (which would be unreasonable IMO).
I think you are misunderstanding me. I have got a webbrowser installed,
but hugin does not find it since it relies on KDE/Gnome
infrastructure to do so.
I have snipped your reasons why you do not want to rely the wx-help
anymore since your arguments were convincing.
For Debian I think we are going to use a patch like this one:
--
diff -NurbBp a/src/hugin1/hugin/MainFrame.cpp b/src/hugin1/hugin/MainFrame.cpp
--- a/src/hugin1/hugin/MainFrame.cpp2009-10-11 07:48:35.0 +0200
+++ b/src/hugin1/hugin/MainFrame.cpp2009-10-11 14:53:16.0 +0200
@@ -1131,10 +1131,14 @@ void MainFrame::DisplayHelp(wxString sec
return;
}
DEBUG_INFO(help file: strFile.mb_str(wxConvLocal));
-if(!wxLaunchDefaultBrowser(strFile))
+/* if(!wxLaunchDefaultBrowser(strFile)) */
+{
+wxString cmd = wxT(sensible-browser ) + strFile;
+if (!::wxExecute(cmd, wxEXEC_ASYNC))
{
wxLogError(_(Can't start system's web browser));
}
+}
}
void MainFrame::OnTipOfDay(wxCommandEvent WXUNUSED(e))
--
Does this look ok? (sensible-browser is Debian specific script that
searches for a install browser and invokes the prefered one.
thanks, 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: (Probably very basic) help needed for build process on WinXP: missing files?
Hallo Yuval, I hope the move went well and you did not have the same weather we're having here (pouring rain, and cold wind). Only on the road, so all went well. First something you mentioned at the end of your mail: I am starting to lose track of things. Maybe time for an initial summary of the steps, starting from the SDK? Well, if even you lose track ... I had that same feeling as well. did you document the instructions for this in the wiki (do you edit as you go along) ? To be honest, at the moment I feel it is a little too much trial and error to document it live in the wiki. But I did this locally to keep track of all the ramifications. Without having a real overview of what I am doing this is really difficult. I wrote it down and uploaded it to http://www.joachimschneider.info/moving_target.html As you see, I always have to remind myself what it is that I am building, e.g. now it is a dependency of enblend (and not directly of hugin). Now I go on and secondly, I would like to solve one misunderstanding. ..\..\tiff-3.8.2\libtiff NO but now changed to ..\..\wxWidgets-2.8.10\src\jpeg Looks like I didn't read something correctly, took a wrong line or something like this. So how was it before? I re-entered a line ..\..\tiff-3.8.2\libtiff for the moment (though I might change it later) and left ..\..\wxWidgets-2.8.10\src\jpeg in the list. So the list now begins with ..\..\STLport-trunk\stlport ..\include ..\..\include ..\..\tiff-3.8.2\libtiff ..\..\wxWidgets-2.8.10\src\tiff ..\..\wxWidgets-2.8.10\src\jpeg and ... png, zlib, I guess I fixed this. (But just to understand it better: If tiff.h is what is needed and it is in the mentioned wxWidgests folder, then changing the entry to that folder should generally work?) Now trying to build libtiff: * start a MSVC shell snip nmake /f makefile.vc It will fail (while building some tools), but all we need is the library and it is produced before. What is it that I need? The newly created stuff inside libtiff? There is a new libtiff.dll compiled. Fine! 1. STLport ..\..\STLport-trunk\stlport NO ok, we'll need to build that one. Instructions for 64 bit are at http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#STLport_.2864-bit_Only.29 we'll need to adapt them for 32bit. Suppose this is just exchanging x64 with x32 ... get them with SVN from https://stlport.svn.sourceforge.net/svnroot/stlport/trunk/STLport OK. Rev 6512. I have got STLport now in my huginbase. Is it later to be renamed STLport-trunk? yes. the instructions to build it are in the INSTALL file, and make use of nmake (that you have installed with MSVC). What I read on the wiki page mentioned above seems to be the same in short. Am I going to build the STLport iostreams library? Is that what is said in stloport-trunk\INSTALL ? There are instructions on Unpacking and installing STLport and then they say If you DO NOT plan to use STLport iostreams and/or locale implementation but just the STL, you do not have to build the library. The separate instuctions to build this follow. Now I understand that this is the actual build process and the first steps are just preliminary actions. So building the library is not an option in a two-part-process but it is the main thing. And I go on. Anyway on the MSVC command line I get: setenv: The command was either misspelled or couldn't be found. Looks like I started somehow completely wrong. where in the instructions did you find setenv ? have you followed the instructions in stlport-trunk\INSTALL ? No, this was from the wiki. I was confuse by two instructions. And after I changed into the STLport directory even configure --help yields a result - I didn't understand that this command is is not part of MSVC. OK, so configure msvc9 gives output that looks OK, though doc\README.msvc says it is configure -c msvcX (where X is the version), but the document is for an older version (2005). Same with the instruction in readme.windows: If I omit the -c it states that the desired compiler has been chosen, but Das Sprungziel - opt_xtra wurde nicht gefunden. seems to mean that it did not understand --extra-cxxflag /D_WIN32_WINNT=0x0501 in configure msvc9 --extra-cxxflag /D_WIN32_WINNT=0x0501 But the instructions suggest that they are most important for older versions of windows and since I use XP for building STLport and the same OS for using STLport for building other software this seems to be OK. So I leave it at configure msvc9 and continue with the README.msvc instructions: cd C:\Program Files\Microsoft Visual Studio\VC98\Bin seems to be C:\Program Files\Microsoft Visual Studio 9.0\VC\bin in my case. The problem with the next step cd C:\STLport\build\lib (d:\huginbase\STLport\build\lib) and nmake /fmsvc.mak install is that my \build\lib folder is empty. No msvc.mak inside. (Though several instances in other subdirectories.) So I get myself version
[hugin-ptx] Re: hugin and cppcheck
Hi James, 2009/10/11 James Legg lankyle...@gmail.com: On Sun, 2009-10-11 at 16:43 +0200, Lukáš Jirkovský wrote: [hugin/src/hugin1/hugin/PreviewTool.h:36]: (error) Class PreviewTool which is inherited by class PreviewIdentifyTool does not have a virtual destructor This one is not problem now since there doesn't seem to be any need for destructor in any of it's children. Is it possible that it may become a problem in future? Lukas There isn't a need for a destructor at the moment because the tools are only freed when Hugin quits. Some PreviewTools allocate OpenGL textures which are not freed automatically, so would need a destructor if that changes. I imagine more PreviewTools will be written, and we are planning to change the way they are accessed (In the Traditional Preview thread), so it is possible that a virtual destructor is needed in the future. -James I can imagine new tools too. I'll leave the decision to you because you're more experienced than I. have a nice day, Lukas --~--~-~--~~~---~--~~ 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: (Probably very basic) help needed for build process on WinXP: missing files?
I'd like to set up a Windows hugin development environment, but the terrifying length of this thread is somewhat deterrent. Do you recon your moving target is closing in? /O 2009/10/11 J. Schneider j-schn...@gmx.de First something you mentioned at the end of your mail: I am starting to lose track of things. Maybe time for an initial summary of the steps, starting from the SDK? Well, if even you lose track ... I had that same feeling as well. did you document the instructions for this in the wiki (do you edit as you go along) ? To be honest, at the moment I feel it is a little too much trial and error to document it live in the wiki. But I did this locally to keep track of all the ramifications. Without having a real overview of what I am doing this is really difficult. I wrote it down and uploaded it to http://www.joachimschneider.info/moving_target.html As you see, I always have to remind myself what it is that I am building, e.g. now it is a dependency of enblend (and not directly of hugin). -- /O --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: (Probably very basic) help needed for build process on WinXP: missing files?
Oskar Sander schrieb: I'd like to set up a Windows hugin development environment, but the terrifying length of this thread is somewhat deterrent. Do you recon your moving target is closing in? Well, I don't have the slightest clue. Any step in one of the branches can yield more steps. Or end and lead back to trunk, i.e. the main objective to build hugin. But if you just follow the actual steps (http://www.joachimschneider.info/moving_target.html) and leave out all my errors, mistakes and misapprehensions it is not so much you actually have to do (to reach whatever intermediate result it is that I have got). regards Joachim --~--~-~--~~~---~--~~ 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 and cppcheck
On Sun, 2009-10-11 at 19:02 +0200, Lukáš Jirkovský wrote: Hi James, 2009/10/11 James Legg lankyle...@gmail.com: On Sun, 2009-10-11 at 16:43 +0200, Lukáš Jirkovský wrote: [hugin/src/hugin1/hugin/PreviewTool.h:36]: (error) Class PreviewTool which is inherited by class PreviewIdentifyTool does not have a virtual destructor This one is not problem now since there doesn't seem to be any need for destructor in any of it's children. Is it possible that it may become a problem in future? Lukas There isn't a need for a destructor at the moment because the tools are only freed when Hugin quits. Some PreviewTools allocate OpenGL textures which are not freed automatically, so would need a destructor if that changes. I imagine more PreviewTools will be written, and we are planning to change the way they are accessed (In the Traditional Preview thread), so it is possible that a virtual destructor is needed in the future. -James I can imagine new tools too. I'll leave the decision to you because you're more experienced than I. have a nice day, Lukas I've added a virtual destructor to PreviewTool. -James --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin and cppcheck
James Legg wrote: On Sun, 2009-10-11 at 19:02 +0200, Lukáš Jirkovský wrote: -James I can imagine new tools too. I'll leave the decision to you because you're more experienced than I. have a nice day, Lukas I've added a virtual destructor to PreviewTool. thanks, guys! I've added all the fixes to the stable codeline. we'll have at least one other release candidate before declaring 2009.4.0 final. 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: (Probably very basic) help needed for build process on WinXP: missing files?
J. Schneider wrote: Oskar Sander schrieb: I'd like to set up a Windows hugin development environment, but the terrifying length of this thread is somewhat deterrent. Do you recon your moving target is closing in? Well, I don't have the slightest clue. Any step in one of the branches can yield more steps. Or end and lead back to trunk, i.e. the main objective to build hugin. But if you just follow the actual steps (http://www.joachimschneider.info/moving_target.html) and leave out all my errors, mistakes and misapprehensions it is not so much you actually have to do (to reach whatever intermediate result it is that I have got). exactly! Actually you're very close. I could just limit you in your creativity and curiosity and tell you to do A/B/C and that's it. But this would not help you nor me. Part of the mentoring job is to deal with things that I took for granted and look at them anew. Another part of it is to help you develop that perspective on your own terms. Following instructions blindly will inevitably break at the code, the dependencies, or both. Understanding the interaction (which is what you are doing now) is key to being able to understand what went wrong and fix it. First fix small things (you already have the tools, you know how to manipulate project properties in MSVC); then larger things (such as finding either binaries or source code packages of the dependencies and integrating them into your build process). In terms of just following instructions (Oskar's question) Windows is not the easiest platform. You can speed through the Ubuntu instructions on the wiki and be up and running in less than an hour, and given its statistics and the feedback we get from it I guess that hundreds if not thousands of people have done it. Most people will stop there. It works for them, fine. It does not, they will look for alternatives but won't have the courage to admit it. Some actually come here on the list and make us aware of the changes that broke the instructions. Few make the step to really understand what's going on. Some make the step to update / edit the wiki. The more dangerous are those that make the step to edit the wiki (or to suggest changes) without understanding them. But we keep those at bay (I am known to bark and sometimes I even bite ;-) ). The best ones are those like Joachim, who are driven by curiosity and will peek and poke fiddling at things until they get them working. I actually fear the day when the Windows (or OSX) build will be documented as well as the Ubuntu one. There is so much that can go wrong in Windows; and then people take things for granted and when they don't work as expected it is Hugin's fault. Your documentation is excellent, Joachim. It's a good summary of what you did. At some point you'll need to split it into different levels: which one is an update of the SDK (e.g. tiff-3.8.2) and which are part of building with an existing SDK; and how to find out what makes a build with the existing SDK fail, and how to fix those failures. You're on the good road and in the right direction. I'm not sure yet how much time I can dedicate to this in the coming week, but our common journey is on my todo list, so you'll hear from me. have a good week 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: GSoC2009_layout with XYZ for Windows - please test
Ok! I think one of the big challenges with this is to visualize the paramters in some some of tutorial/online manual. The camera plane is Z=0,Xc,Yc right? How do you then describe subject projection plane with the 2 parameters? Do you aaume something about the geometry with respect to PrincipalPoint or Nadir? http://www.r-s-c-c.org/rscc/v1m6images/pitch.jpg Cheers 2009/10/10 Pablo d'Angelo pablo.dang...@web.de Oskar Sander schrieb: Pablo, when you said that you are working on this, did you refer to the optimization strategy above, or the image-load-bug? That was for the optimisation strategy. I'm also playing around with extenting the XYZ with two more parameters that specify the plane that is used for each image. This would be very helpful for the nadir and wall patching applications. Its not in a state that can be commited yet, unfortunately. Maybe I have some time next weekend to polish it a bit and commit to libpano13 and the layout branch. ciao Pablo -- /O --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: traditional preview
Hi all, sorry for stepping in so late, I just would like to stress a few things that are important to me: Single buttons for images should definitely stay! They could be more space saving if desired. They are very important for my workflow to be easily accessible and visible all at the same time. I would hate to find them in dropdown menus like in the stitcher tab. (Of course I haven't got a clue how these single buttons are handled in very big projects like I never have myself.) Buttons that indicate a mode that the preview window is in or what a click will do (e.g. drag, crop) and that can be switched on or off are very good tools to keep the user oriented about what he is doing. I guess for beginners they are even more helpful. Button size could be reduced quite a lot and text could be wrapped. Currently they are spaced with about 2 button-widths of whitespace in between (at least on Windows). So I think you could fit even more buttons even on small screens. (Is there any design guideline that says down to how few pixel width hugin should be working?) I am not sure if I like the palettes approach. They tend to be where you don't need them and I guess I'm going to move them around all the time. What I would like to have is a combined window containing the preview in e.g. the upper half and the rest, tabbed as is, in the lower. With a movable divider between. As an option. I find it important to be able to have e.g. the cp tab full screen. A first (easy?) step to make the preview the hub could be to make the existing shortcuts of the normal hugin window work from within the preview window. Yuval Levy wrote: good point. maybe merging them into one single view is not a good idea on the back-end, even if it looks good in the front end. But maybe back-ends can be kept separate and their output directed to the one preview window, depending on the mode it is set to? (Thoughts of a non-programmer) people have expressed enough views why it is worth keeping the traditional preview, or at least its features. Any other ideas how this can be done without maintaining the current confusing situation of two previews at the same hierarchical level? Here I agree, it is confusing and that's why I find merging a really good idea from the front-end view. regards Joachim --~--~-~--~~~---~--~~ 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: GSoC2009_layout with XYZ for Windows - please test
Oskar Sander schrieb: Ok! I think one of the big challenges with this is to visualize the paramters in some some of tutorial/online manual. Indeed. But so far I'm not sure if I have found the right parameters... The camera plane is Z=0,Xc,Yc right? Yes. How do you then describe subject projection plane with the 2 parameters? My experimental implementation does use plane yaw and plane pitch, to specify the surface normal of the plane, and the plane is always tangent to the unit sphere around the panorama camera. This works very similar to the yaw and pitch of the input images. For example, a plane at the nadir would be specified by plane_pitch=-90. However I get strange results when placing this plane at the nadir of a spherical pano and then optimizing, this is why I haven't commited anything yet. Do you aaume something about the geometry with respect to PrincipalPoint or Nadir? http://www..r-s-c-c.org/rscc/v1m6images/pitch.jpg http://www.r-s-c-c.org/rscc/v1m6images/pitch.jpg Ehm, not sure what you want to express with that picture? 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Hugin-2009.4.0_rc1 source code released
On Sun 11-Oct-2009 at 11:25 -0400, Yuval Levy wrote: While with an HTML help system based on widely adopted standards we may even get to a Docbook or other modern, managed documentation system that produces different outputs, including PDF for print Using the panotools wiki has the advantage that we get to use the 'Glossary' pages from the wiki which makes the manual much more useful. We'll lose that connection if we fork. Alexandre has suggested that we could move to flossmanuals, this has translation support: http://en.flossmanuals.net/ Also since I've written most of the 'manual' pages, I'd like to see some commitment from others to improve it before we do the work to change the infrastructure. Note that the shipped 2009.2.0 manual was out-of-date, as will the 2009.4.0 manual. Getting the manual up-to-date is much less work than migrating it. -- Bruno --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Bug Tracker Policy
On Fri 09-Oct-2009 at 02:14 -0400, Yuval Levy wrote: unless there are strong objections I intend to change the tracker policy to accept only bug reports from identified users. This is fine by me, most reports initially raise questions rather than provide a reproducible bug description straight-away. -- 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: Hugin-2009.4.0_rc1 source code released
On Sun 11-Oct-2009 at 18:25 +0200, Andreas Metzler wrote: I think you are misunderstanding me. I have got a webbrowser installed, but hugin does not find it since it relies on KDE/Gnome infrastructure to do so. My desktop is Gnome (Centos4), but Hugin launches the manual in Konqueror. -- 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: traditional preview
On Fri 09-Oct-2009 at 06:36 -0700, T. Modes wrote: IMO the (Fast) Preview should become the hub and everything else should float around it. Performance! (especially with big projects) With the current implemtation you can open a big project and start working. When finish the optimising the can open the preview, wait a little time - or a little more time, and check the result. So automatically starting with the Preview could only work if Hugin loads images in the background and allows full editing, saving and even quitting before the last photo is opened. -- 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] Te0 and Te1 parameters in libpano13
Hi all, I have just commited some experimental extension to the TrX, TrY, TrZ parameters for mosaicing images of a planar scene to the libpano13 SVN trunk One of the main drawbacks of the Tr* parameters is/was that the images had to be located on plane straight ahead of the panorama. This is too restrictive for the nadir and wall patching usecase. As hinted in an earlier mail to hugin-ptx, I have added two more parameters that allow specification of the plane on which the off center images should be projected for each image by means of plane yaw (Te0) and plane pitch (Te1) parameters. They define the normal of the plane in 3D space, similar to yaw and pitch, which define the looking direction of a camera. So for nadir patching, off center shot should be set to Te00 Te1-90. For fixing something on the left wall, the following parameters should be used: Te0-90 Te10. etc. The main drawback of these parameters is that it is quite hard to optimize them: It is easily possible to have cameras that do not look onto the plane. This will confuse the optimization process and it won't be able to find a good solution. So initialization with good values or very careful stepwise optimization is required. 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin mentioned in an article
Hi Harry, you are right that parts of the article are not overly specific or accurate. I think the normal readers of futurezone.orf.at are no specialists in photography or even panoramas but are somehow interested in free software. I know this is no excuse to write incorrect facts. I only had a quick look at the article on Friday and I stumbled over futurezone only by chance. At least hugin is mentioned in a positive context as I think, maybe he should ask on this list when he needs proofreaders... That Version 2 was mentioned before somewhere and I have no clue how people come to such a conclusion when they never had a version 1. Thomas Bredenfeld is a member of Panotools NG and I don't think negative about him. He also was at the Lucerne/Zermatt panotools meeting, you can easily find several photos he posted on flickr, search for zermatt+panotools. BTW the 2010 panotools meeting will be in Plymouth, UK. http://panotools-meeting.com/ Carl Harry van der Wolf wrote: 2009/10/9 Carl von Einem http://futurezone.orf.at/stories/1628944/ When he writes about montagesoftware to create Gigapixel panos he says : Die ist sogar gratis zu haben, etwa beim Open-Source-Projekt Hugin, das erst am 29. September die Version 2.0 für Linux vorgestellt hatte. Das Programm ist - in niedrigeren Versionsnummern - auch für Windows und Mac OS erhältlich. (Sorry for those who don't speak German). What does he mean with version 2.0? And lower versions also for windows and Mac? I suppose he means 2009.2.0 but he's not very accurate. I think we should be glad for the publication, but what do you mean with: Oh, I just see that it's an article by Thomas Bredenfeld :-). I know him because he asked me in April if he could add ImageFuser to the DVD of his new book. Which was OK with me. From your reply I get the impression that you don't value him very high. Is that correct? Tschau, 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: traditional preview
On Sat 10-Oct-2009 at 21:07 -0400, Yuval Levy wrote: mockup attached. please read the (long, sorry) email addressing most comments expressed. thanks to everybody who participated in this round of feedback. if there is enough interest, as the next step I will implement the attached tabbed palette without touching / removing anything from the Stitcher tab for now. I don't think there is enough functionality here to justify a tabbed palette, how much space would all this stuff take up in one frame? This needs to be a pop-up window just for stuff that can otherwise be done with the mouse in the Fast Preview, but which on occasions need to be modified numerically. So, the panorama pixel size is an output 'quality' setting, and needs to be on the Stitcher tab; the Projection pull-down is a central function of the Preview and has to be on the preview proper. and what was the result of the merger discussion? ..to do it later, after the Layout mode was done. from your ribbon/buttons comment it sounds as if this is not an option. We can still add buttons, the problem is that the spacing between buttons is scaled to the largest text - On a 1280 pixel display the English version of the Preview window has enough space for all proposed buttons. It is broken with German apparently, but with Chinese there is enough space for twice as many buttons. Maybe the fix is as simple as abbreviating the German translation? It doesn't set the output of the project to HDR, it just implements HDR merging and basic tonemapping in the Preview window itself. I'll have to disambiguate my thoughts. Preview Output is what I mean and what I understand on the Preview windows. I have not implemented this in the mockup (yet). People have assumed (incorrectly) that selecting 'HDR' in the Preview window enabled floating-point linear output when stitching. This suggests the GUI isn't as clear as it should be. So more or less at the same time as Layout integration? Should we go ahead and integrate autocrop? It works, I haven't tested it to see how slow it can be with big projects - i.e. if it is still in need of a progress indication. I was also going to add a button to the Fast Preview, which would be an obvious modification of the existing Crop button (but didn't find time). It isn't going to break everything, and if we decide to release without it, the button can be simply removed from the XRC file. -- 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: Hugin-2009.4.0_rc1 source code released
Hi Yuv, I haven't updated my installer script for this release yet. Will have to make some adaptations and test with this version. No time right now to test anything but will find some before that oct 31 date I think. Allard On Oct 11, 12:15 am, Yuval Levy goo...@levy.ch wrote: Panorama stitching and more. A powerful software package for creation CHANGES SINCE LAST BETA: * improved plattform support - CMake build (Kornel Benko) - Windows Installer (Allard Katan) --~--~-~--~~~---~--~~ 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: traditional preview
Bruno Postle wrote: I don't think there is enough functionality here to justify a tabbed palette, how much space would all this stuff take up in one frame? not yet. when the fast preview will become the hub, the tabbed palette will contain many more functions. This needs to be a pop-up window just for stuff that can otherwise be done with the mouse in the Fast Preview, but which on occasions need to be modified numerically. for mouse driven users true. for users who prefer to juggle with the number it is the other way around. actually I am trying to design something that can be either docked or a floating pop-up. In both cases, horizontal, not taller than the current toolbar+images list, and will actuall replace the toolbar + images list, with the images list being one of the tabs. So, the panorama pixel size is an output 'quality' setting, and needs to be on the Stitcher tab; disagree. this is where the complexity of the Stitcher tab starts: mixing workflow with panorama settings. The Stitcher tab shall be workflow only. And eventually will become a tab in the palette as well. the Projection pull-down is a central function of the Preview and has to be on the preview proper. if the palette is docked. If not it is floating. Consider the tabbed palette as *the* control - with the exception of those actions that are taken on the images or on the preview themselves (identifying CP manually; cropping; masking; dragging; etc.) from your ribbon/buttons comment it sounds as if this is not an option. We can still add buttons, the problem is that the spacing no, the problem is the quantity of buttons. makes it useless. Maybe the fix is as simple as abbreviating the German translation? that's not a fix, that's a hack. People have assumed (incorrectly) that selecting 'HDR' in the Preview window enabled floating-point linear output when stitching. This suggests the GUI isn't as clear as it should be. indeed. the GUI should be completely remodeled and for this we need to break out of the current frame of mind. So more or less at the same time as Layout integration? Should we go ahead and integrate autocrop? It works, I haven't tested it to see how slow it can be with big projects - i.e. if it is still in need of a progress indication. I've tested it on a 30 pictures project on the dynobook and a progress indication would be appreciated. I was also going to add a button to the Fast Preview, which would be an obvious modification of the existing Crop button (but didn't find time). It isn't going to break everything, and if we decide to release without it, the button can be simply removed from the XRC file. Yes, go ahead. We need more drawings / icons. 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: hugin mentioned in an article
Hi Carl and Harry, Carl von Einem wrote: That Version 2 was mentioned before somewhere and I have no clue how people come to such a conclusion when they never had a version 1. I think it is just a shortcut from 2009.2 - often people don't pay attention to detail. With 2010.0 they may realize that their pre-conceived notion was wrong. What distrubs me most is another pre-conceived notion. The article was mentioning that the latest version is available for Linux, and older versions are available for Windows and OSX. This is completely wrong. First, we know there is no Linux - there are many Linux distributions. Second, if we look at what is officially in these distributions by default, some of them have not even bothered upgrading from 0.7.0 *beta* Third, these distribution do not upgrade. It is as if we'd only have Hugin-0.7.0 for Windows XP; Hugin-0.8.0 for Windows Vista; and Hugin-2009.2.0 for Windows 7. It is users who share and contribute so called back-ports, i.e. builds recent Hugin binaries for Linux distributions that are 6 to 18 months old. It is users who share and contribute binaries of the latest releases. And in that sense, OSX users are better off than most Linux distribution users; and Windows users are also better off than many Linux distribution users. One of my efforts during the current fast pacing of releases was to liaise with distributions and help them adopt our latest releases. It works better with source distributions (FreeBSD and Gentoo are amongst the best supported Hugin users) because they don't have cut-off line for the distribution. I hope Andreas Metzler's work will bear fruits and we'll see soon more recent versions of Hugin trickling down to Debian based distributions including Ubuntu, although I am afraid it's too late for Ubuntu 9.10, i.e. it will be another six months with 0.7.0 *beta* for Ubuntu users, and even in six months only those who do upgrade distribution will move up. Fedora had traditionally a better support because it is Bruno's system and he liaises with that distribution. 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: traditional preview
Bruno Postle wrote: So automatically starting with the Preview could only work if Hugin loads images in the background and allows full editing, saving and even quitting before the last photo is opened. that's the goal. I started reading about threading in wxWidgets. 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: Hugin-2009.4.0_rc1 source code released
Bruno Postle wrote: My desktop is Gnome (Centos4), but Hugin launches the manual in Konqueror. is this intended? i.e. is Konqueror your default web browser? 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: Hugin-2009.4.0_rc1 source code released
Bruno Postle wrote: Using the panotools wiki has the advantage that we get to use the 'Glossary' pages from the wiki which makes the manual much more useful. We'll lose that connection if we fork. every tool has plus and minuses. Alexandre has suggested that we could move to flossmanuals, this has translation support: http://en.flossmanuals.net/ whoever does this should consider the pros and cons of flossmanuals. I don't know enough about its back-end to judge. I do know that as a user I find some things that I want there - PDF to download; printed book to buy. One mandatory condition for me is that the whole HTML manual be navigable locally, off-line. Also since I've written most of the 'manual' pages, I'd like to see some commitment from others to improve it before we do the work to change the infrastructure. You mean the current HTML manual? or do you mean plain text man pages? Note that the shipped 2009.2.0 manual was out-of-date, as will the 2009.4.0 manual. Getting the manual up-to-date is much less work than migrating it. you mean getting up to date the wiki pages? 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: buliding panomatic fails on Ubuntu 9.10 / AMD64
Kornel Benko wrote: Maybe a include of a header file which defines EOF would be more appropriate. I don't have ubuntu 9.10, only 9.04. Here it is defined in /usr/include/stdio.h thanks, Kornel. the official patch is http://aorlinsk2.free.fr/panomatic/panomatic_gcc44.patch 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: [PanoTools-devel] Te0 and Te1 parameters in libpano13
Am Monday 12 October 2009 schrieb Jim Watters: Pablo d'Angelo wrote: Hi all, I have just commited some experimental extension to the TrX, TrY, TrZ parameters for mosaicing images of a planar scene to the libpano13 SVN trunk ciao Pablo I just attempted to build. And I get a build error. 1.\math.c(1807) : error C2065: 'M_PI' : undeclared identifier Maybe you meant PI instead, that is defined in filter.h Interesting, here it is defined in /usr/include/math.h, therefore no error. Maybe we should define it the same as in fftn.c, but better in some of our header files. Kornel -- Kornel Benko kornel.be...@berlin.de signature.asc Description: This is a digitally signed message part.
