[hugin-ptx] Re: GSoC patch ideas

2009-04-21 Thread Bart.van.Andel

On 21 apr, 15:27, paul womack  wrote:
> IEEE floating-point standard, supported by almost all modern processors, 
> specifies that every floating point arithmetic operation, including division 
> by zero, has a well-defined result. In IEEE 754 arithmetic, a ÷ 0 is positive 
> infinity when a is positive, negative infinity when a is negative, and NaN 
> (not a number) when a = 0. The infinity signs change when dividing by -0 
> instead. This is possible because in IEEE 754 there are two zero values, plus 
> zero and minus zero, and thus no ambiguity.

Ah yes, I see, I hadn't considered it that way. Then the question is,
is a check for a=0 necessary? Doesn't the arithmetic take this into
account automatically (as in, it computes the result as +INF or -INF,
depending on the value of Aux_1)?

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: GSoC patch ideas

2009-04-21 Thread Bart.van.Andel

Although I'm not really into this code, shouldn't a divide by zero
result in NAN instead of INF? Of course the limit of 1/n with n->0 is
INF, but only for n>0. For n<0 (a very small negative value), 1/n
actually goes to -INF. At exactly n=0, 1/n is not defined. It's a
small detail, but NAN is more accurate here than INF, if we're going
to use that.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Big hugin project.

2009-04-20 Thread Bart.van.Andel



On 20 apr, 18:27, "r.e.wolff"  wrote:
> On Apr 20, 6:22 pm, "Bart.van.Andel"  wrote:
>
> > My first thought about images rendered black was that somehow you are
> > (well, Hugin is) using a wrong value for the EV. Normally you can
> > tweak the EV value (in the preview window, for instance) to alter the
> > brightness of the image. If the EV is set to a very low value, the
> > image will be rendered completely white, and if set to a very high
> > value, it will be rendered completely black. Is this the case maybe?
>
> Ah! checked the PTO, and it's set to zero. This is a very low value,
> so you
> are expecting a completely white image, but it's black. Weird

Depends. What is really important is the difference between the EV
from the input images and the EV as set in the preview window, maybe
we are referring to different values (I didn't dive into any PTO files
really)...

> > Regarding the final image. I don't know if the zoomed in images cover
> > the entire low res panorama, but if it does, the simplest solution is
> > to remove this image from rendering by clicking the image number once
> > in the preview window. If all positions were already correct, this
> > will leave you with a high resolution panorama with all the data
> > coming from the zoomed in images.
>
> No, the zoomed images cover only the 10 percent "interesting" areas.
> The rest is "grass" and "sky".

Hmm... Well, I can think of a workaround.

1. Render the panorama image, excluding the low res panorama as a
source. Use a low resolution and no interpolation, to speed things up.
Save as TIFF.
2. Use the inverted alpha channel of the generated panorama to
generate a mask for the low resolution panorama. Using some
convolution (thickening/thinning) to make the gaps a little smaller.
3. Finally, render the panorama at full resolution, including the now
masked low resolution panorama.

This is just theory, I haven't tried any of this in practice, but I'm
pretty sure it will work.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Big hugin project.

2009-04-20 Thread Bart.van.Andel

My first thought about images rendered black was that somehow you are
(well, Hugin is) using a wrong value for the EV. Normally you can
tweak the EV value (in the preview window, for instance) to alter the
brightness of the image. If the EV is set to a very low value, the
image will be rendered completely white, and if set to a very high
value, it will be rendered completely black. Is this the case maybe?

Regarding the final image. I don't know if the zoomed in images cover
the entire low res panorama, but if it does, the simplest solution is
to remove this image from rendering by clicking the image number once
in the preview window. If all positions were already correct, this
will leave you with a high resolution panorama with all the data
coming from the zoomed in images.

I hope this helps a bit.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: hugin 0.80 beta for windows

2009-04-15 Thread Bart.van.Andel

On 15 apr, 06:37, Emad ud din Butt  wrote:
> Thanks a lot dear. Actually i was searching it on sourceforge.net where 0.8
> is not available.

Ah yes, that's true. For the newest (beta) binary releases, you should
always check this group (or at least panospace.wordpress.com) instead
of sourceforge, I'm sorry you had to find out "the hard way", my bad.

Best,
Bart

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: fov computation from exifless data

2009-04-14 Thread Bart.van.Andel



On 14 apr, 18:37, Yuval Levy  wrote:
> Bart.van.Andel wrote:
> > Correct me if I'm wrong, but I believe that's what the crop factor is
> > for. It serves as a factor between the sensor size and 36x24mm film,
> > like this:
> > [diagonal of sensor] x [crop factor] = [diagonal of 36x24mm film]
>
> you're right - crop factor is another approximation of size relative to
> 36x24. If the form factor is the same, it works. Else it is an
> approximation.

What do you mean by "form factor"? If you mean the relation between
width and height - that has been taken account for, since the diagonal
is used, or am I mistaken here?

Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: fov computation from exifless data

2009-04-14 Thread Bart.van.Andel

Yuval Levy wrote:
> paul womack wrote:
> > Pixel count and focal length is NOT enough information
> > to calculate a FOV.
>
> I think what would be missing to the above information is pixel pitch or
> another relationship of the pixel dimensions to the sensor dimensions.
>
> sensor size would give a good enough approximation.

Correct me if I'm wrong, but I believe that's what the crop factor is
for. It serves as a factor between the sensor size and 36x24mm film,
like this:
[diagonal of sensor] x [crop factor] = [diagonal of 36x24mm film]
--~--~-~--~~~---~--~~
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 0.80 beta for windows

2009-04-14 Thread Bart.van.Andel

> Where can I get pre-compiled version of hugin 0.8 for windows xp.

If you had bothered to try the search function using "hugin 0.8 beta"
as keywords (even without the quotes) [1], you'd have found the answer
in the very first post of the very first search result [2]. But okay,
to answer your question: go to http://panospace.wordpress.com/downloads/
to find the installers.

[1] 
http://groups.google.com/group/hugin-ptx/search?group=hugin-ptx&q=hugin+0.8+beta
[2]
http://groups.google.com/group/hugin-ptx/browse_thread/thread/4db69067e6ac15ea/081e1645bfffea28?lnk=gst&q=hugin+0.8+beta#081e1645bfffea28
--~--~-~--~~~---~--~~
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: fov computation from exifless data

2009-04-14 Thread Bart.van.Andel

> Can anyone be bothered to check the source to
> end this question?

As I mentioned earlier: calculation is done in the
SrcPanoImage::calcHFOV(...) function, see
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin_base/panodata/SrcPanoImage.cpp?view=markup.

It takes 4 parameters:
- type of projection (e.g., rectangular)
- focal length
- crop factor
- image size

These parameters are exactly what is needed to compute the hfov. Check
the source to see how it's done.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: fov computation from exifless data

2009-04-13 Thread Bart.van.Andel

Ah, I think I see now where the trouble is. You are not taking into
account the ratio between horizontal and vertical sensor size.
Standard analog film has a ratio of 3/2 (36/24), whereas most digital
cameras - like yours - have a ratio of 4/3 (2272/1704). Hugin takes
this into account in the computation of the hfov, as can be seen in
the SrcPanoImage::calcHFOV(...) function. See this file:

http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin_base/panodata/SrcPanoImage.cpp?view=markup

Hope this makes things clear.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: getting strange blending errors for a very wide panorama

2009-04-12 Thread Bart.van.Andel

> I agree, it's looking like it's an Enblend error that's causing the
> problems.
> The intermediate files are clean, they don't show the errors at all.

That's great, so it's not Hugin itself. Now the next step is to find
out what causes the trouble (not purely the resolution, as your other
test proved).


> As for
> Smartblend, it only runs under windows from what I can tell and don't
> have a windows box, so I can't check to see if it would fix the
> problem.

Well, actually it does run on Linux, with Wine. See the 3rd post in
this thread:
http://groups.google.com/group/hugin-ptx/browse_thread/thread/b11d91ad0280ace0

I haven't tried it (I'm using Windows myself), but if you succeed, I'd
love to see the result!


> As for the output resolution, it is correct.  The camera used is a
> Canon 50D,
> so the images are 3168x4752.  The pano contains 112 images, mostly
> contained
> in a two row setup (the obelisk as you said adding a couple more
> images to the
> height).  It's either 54 or 55 images for each row in the horizontal
> direction.

Ah yes, I see now, I forgot the factor of 1/2 which I had actually
drawn on paper... Sorry!


Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: getting strange blending errors for a very wide panorama

2009-04-12 Thread Bart.van.Andel

Looks to me like Enblend causes the trouble. Most obvious in the sky,
the artifacts seem to be caused by a low frequency blending error
(which explains the wide bands). The errors should not be visible in
the intermediate files generated by Hugin during the process, could
you confirm this? You could try using Smartblend instead of Enblend,
just make sure you set the options right before you do, otherwise
you'll be waiting 6-8 hours ending up with an error and no final
output. Of course you could also have Hugin keep the intermediate
files and perform the last step (the final blending) manually, so you
can try different options without having to recompute the intermediate
images every time.

Besides, I'm wondering if the resolution you chose for the output
really makes sense. As far as I can see from the output, there are
only two series of images overlapping vertically about 50 percent
(except for the obelisk), spanning about half of the final image.
Unless the vertical resolution of the images is about 10,000 real
pixels, this is nonsense. And remember, a 12MP point-and-shoot camera
may deliver 4000x3000 pixels, but at 100% zoom you can see that it
does not really contain that much detail / information.
--~--~-~--~~~---~--~~
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: panoramas from low-quality movies

2009-04-12 Thread Bart.van.Andel

On 11 apr, 10:07, Harry van der Wolf  wrote:
> I assume the variable for the parameters (that holds the images) is
> dimensioned to small. The value of a maximum of 128 (4bits) parameters,
> automatically comes to mind.

It´s probably a minor detail, but 128 (or actually, 127) is 7 bits,
not 4, as (2^7) - 1 = 127.
--~--~-~--~~~---~--~~
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: Enhancement request for Batcher

2009-04-08 Thread Bart.van.Andel

Mike,

Please open a new topic if the subject of your post is *completely*
different from what you are replying to, as you have now done twice.
This keeps the discussion list as clean as possible. Mixed topics are
hard to track, as you will probably agree.

Thank you.
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-07 Thread Bart.van.Andel

Hello,

I've been trying myself and succeeded in putting it on Blogspot. It
does display (after refreshing several times), but the controls
somehow work differently from a standalone version. I'll have to debug
this sometime, when I have more time...

Just view the source of the page to see how I did it.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-07 Thread Bart.van.Andel

Did you post a test blogpost so we can take a peek at it?
Otherwise, there are (free) products on the market to reduce/obfuscate
javascript code, for instance JSMin [1], YUI Compressor [2] and Dojo
Compressor [3]. This might help fit the javascript code into the blog.
I don't know what exact restrictions apply, so I cannot guarantee this
will work.

Best,
Bart

[1] http://crockford.com/javascript/jsmin
[2] http://developer.yahoo.com/yui/compressor/
[3] http://dojotoolkit.org/docs/shrinksafe

--~--~-~--~~~---~--~~
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: Summer of Code Application deadlines

2009-04-03 Thread Bart.van.Andel

Hi all,

Actually, my thesis project is about creating a linear panorama from a
series of photos taken along a line. I'm rebuilding the system as
described in an article called "Photographing Long Scenes with Multi-
Viewpoint Panoramas" [1]. Basically, these are the steps which are
performed (a bit simplified):

0. Correct barrel distortion using PTLens to get rectilinear images.
1. Keypoint extraction.
2. Keypoint matching, which finds matches of keypoints for each pair
of images.
3. Bundle adjustment, which reconstructs a sparse cloud of 3d scene
points (it places the 2d keypoints in 3d space).
4. The bundle adjustment packages also reconstructs where the cameras
are positioned in 3d space.
5. The user selects a projection surface by drawing a line in a 2d map
generated from the 3d point cloud (just a top down view).
6. All images are backprojected onto this surface.
7. The images are blended together.

I haven't finished the whole system yet, but I do have a viewer for
the 3d point cloud, in which I can backproject the images using a very
simple approach: from each camera viewpoint, I draw the accompanying
image at a user specifiable distance. The results are far from
perfect, but it is clear that even a simple approach like this does
nice tricks.

So far, I don't really have a research question (rebuilding a piece of
software obviously isn't enough), although I have some ideas. Because
for each keypoint both 3d information and 2d information (original
keypoint locations) is available, I could warp the images to match the
3d points, such that each image follows its own 3d surface
(difficult), or find a "most common" plane per image and position the
input images on those surfaces (a lot easier and, I suspect, less
prone to error). I have to think of something clever to do after that
works.

Any ideas welcome of course, although in its current form, it will be
quite a challenge to merge my stuff with Hugin. I'm using Noah
Snavely's Bundler [2], for one thing, which is currently dependent on
Cygwin...

So, this is also a GSOC project? Nice :)

[1] http://grail.cs.washington.edu/projects/multipano/
[2] http://phototour.cs.washington.edu/bundler/
--~--~-~--~~~---~--~~
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: Pure JavaScript pano viewer

2009-04-01 Thread Bart.van.Andel

On 2 apr, 02:33, Yuval Levy  wrote:
> Bart.van.Andel wrote:
> > I don't want to be wasting the
> > mentor's, GSOC's or my own resources on a project which is bound to
> > fail for lack of time...
>
> if you can't work full time on your GSoC project, than it is better not
> to apply. Too bad,

Exactly my thought.

> I really like the Javascript viewer, even though I
> would prefer if the mouse controls would be like traditional VR viewers
> (inverted left and right).

I gave that one a thought, but decided somehow that inverted left and
right belong to viewers which also implement autoscroll. I'll add it
as an option (which is really too easy), because the idea attracts me
as well. Autoscroll can be added fairly easily as well, although it's
probably useless when the speed is only 3 fps.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-01 Thread Bart.van.Andel

On 1 apr, 15:26, Yuval Levy  wrote:
> Bart.van.Andel wrote:
>
>   > Cubic panoramas: yes.
>
> > Other types: challenge.
>
> > Hey, GSOC is approaching... ;-)
>
> want to apply? the deadline is April 3, and I think that this is a
> project worth considering.

I'm limping on two legs here (Dutch saying, haha). I'd love to get
this thing working, but first I have to finish my studies. And this
summer is the absolute deadline. After that, I won't be a student
anymore, plus I seriously need a vacation... So probably, this isn't
gonna work well with a GSOC, or is it? I don't want to be wasting the
mentor's, GSOC's or my own resources on a project which is bound to
fail for lack of time...

Maybe I'm guessing wrong, if so, please elaborate!

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-01 Thread Bart.van.Andel

Hi all,

Great to see that I'm not the only one who likes the idea of a
javascript panorama viewer :)

Regarding speed, I've been fiddling around a bit myself with the
current version, and here are some of my (mostly quite obvious)
findings:

 - Smaller dimension of input image: faster
 - Smaller dimension of panorama viewer: faster
 - Less vertical slices (larger wSlice): faster (but less accurate)
 - Smaller visible part of the input image (smaller vertical field of
view): faster. Compare MODE_PRESSx to MODE_NORMAL or MODE_PANNINI for
example.
 - Google Chrome or Firefox versus Internet Explorer: faster.

I've tested the script on my new laptop (Core2 Duo at 2.23 GHz), my 4
year old desktop (Athlon64 at 2.2 GHz) and a pretty recent computer at
my job, with the current html file (720x300 pixels). It doesn't run
nearly as smooth as most Flash viewers, but 1 or 2 frames per second
using IE, and a little more using Chrome and Firefox. Considering it's
just Javascript, I found this pretty okay. But of course I hope to get
newer versions to run faster. It's open source, so others are of
course welcome to contribute.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-01 Thread Bart.van.Andel

Thanks (a lot) to Dale, a pretty minimalistic demo can now be viewed
here:
http://www.tatteredmoons.org/jspanoviewer.html

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-01 Thread Bart.van.Andel

> >Well, this page here suggests that 3D is very well possible with the
> >canvas element:
>
> >http://www.xs4all.nl/~peterned/3d/
>
> That's exactly how it can be done, there is everything here for a
> no-plugin cubic panorama viewer, and the speed is comparable to
> flash panoramas.

Cubic panoramas: yes.
Other types: challenge.

Hey, GSOC is approaching... ;-)

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-01 Thread Bart.van.Andel

> I don't mind hosting.

Great!

> What type of traffic can we expect?

Very little. It's only the html and js that have to be hosted, the
images can be hosted anywhere. The example html uses one picture
directly from my Picasa photo album and two other images I found using
Google.

I´m a bit busy right now, but when I get more time, I´ll update the
html and js so parameters (like hFovDst and mode) can be tweaked more
easily. Tweaking is already possible, but at the moment a call to
setMode is needed to propagate the changes to the individual div
elements.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Pure JavaScript pano viewer

2009-04-01 Thread Bart.van.Andel

> Very good, this is smoother than similar ideas I've seen before.  
> The Pannini view works very well in this kind of viewer as you don't
> really want to look up and down with this projection.

I suppose that's true. I might add some support for images where the
horizon is not vertically centered in the image though, and just for
fun a "look up/down" feature might still be a nice idea.

> >The renderer works with div elements containing vertical slices of
> >the input image, so fisheye type panoramas cannot be displayed.
> >Maybe a future version using a canvas could overcome this
> >limitation (and add some speed...)
>
> I looked at the HTML canvas and although it doesn't have image shear
> capability (which is how the current crop of flash viewers fake the
> perspective transformation), it does have rotation and x-y
> differential scaling which ought to be enough to do a full cubic
> panorama viewer - Some testing is needed.

Well, this page here suggests that 3D is very well possible with the
canvas element:

http://www.xs4all.nl/~peterned/3d/

Still, direct access to pixels isn't available for canvas elements, as
I understand, so it will be quite a challenge to get it right. Of
course the div trick could be done in 2 dimensions, but it's slow
enough already...

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Pure JavaScript pano viewer

2009-03-30 Thread Bart.van.Andel

Hello folks,

Over the past two weeks, I've built a panorama viewer using only
standard html and javascript. It expects full or partial cylindrical/
equirectilinear panoramas. The renderer works with div elements
containing vertical slices of the input image, so fisheye type
panoramas cannot be displayed. Maybe a future version using a canvas
could overcome this limitation (and add some speed...)

The source can be downloaded (or checked in using SVN) from
http://code.google.com/p/jspanoviewer/
If someone could host a demo (the unpacked version of the archive,
optionally beautified a bit with some style rules), please let me
know, so I can link to it from the project home page! Maybe we could
feature it on the Hugin home page?

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Hugin Build Version 3649 for Windows

2009-02-18 Thread Bart.van.Andel

On 18 feb, 07:35, lxegs  wrote:
> i think i know 7zip and even if that's just an advice , the primary
> purpose was to test that version and not speaking about possible
> compression
>
> do you give some advices on p2p/illegal sites when people don' t
> compress with 7-zip ???

It almost seems if you're offended, which really wasn't my goal. Relax
man, I'm just trying to be helpful here: it saves you uploading time
and a bunch of people a lot of downloading time. I don't see what
warez have to do with this at all, so cool down.

Actually I'm really appreciating that you share your build with the
world, and I was pretty eager to try it out. That's why I didn't want
to wait for too long for the thing to download :)

Anyway I've tried it out (of course) and it really looks nice.
Progress is really being made! As you can see in another thread I
encountered an Enblend bug, but none within Hugin-SVN3649 itself so
far. And I like the new icon set!

--~--~-~--~~~---~--~~
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: Enblend error: Mask is entirely black, but white image was not identified as redundant

2009-02-18 Thread Bart.van.Andel

Okay I have to admit that the files I fed into Hugin were quite
different from normal panorama input. Instead of using pictures taken
from a single point, I moved the camera along the scene. This will
obviously make it more difficult to find a "pleasing" solution, but I
wasn't going for the aestetics anyway. Still, errors like this
shouldn't occur, even with the strangest input.

Basically, the pictures themselves are normal 35mm (equivalent)
rectilinear pictures (within the margin of the camera of course), with
a 4:3 ratio. The final output has a ratio of about 7:2, so not really
strange here. All 31 images are connected. The output TIFFs are all
normal, except for the final output, which is an illegal/incomplete 8
byte file.

I've just uploaded both the pto and the log as Google documents:

pto: http://docs.google.com/Doc?id=dhb9htjv_20fnckngd6
log: http://docs.google.com/Doc?id=dhb9htjv_21dczt5bdd

The log seems a little bit different from what I posted above, as you
can see. Either the logging system doesn't always handle the output in
the correct order, or things are really not always executed in order
and may interfere???

I've encountered the error with the enblend.exe bundled with Hugin-
svn3649, which is enblend version 3.2. No options changed, except for
TIFF compression.

--~--~-~--~~~---~--~~
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 error: Mask is entirely black, but white image was not identified as redundant

2009-02-17 Thread Bart.van.Andel

I just encountered an enblend error. At the end of a Hugin run, I get
this message:

---(1)---
enblend: an exception occured
Mask is entirely black, but white image was not identified as
redundant.
make: *** [blend.tif] Error 1
---(1)---

After that, the process is interrupted. All intermediate TIFFs are
generated, but not the final, enblended, one.
A little back in the log, I read this:

---(2)---
[...]
Loading next image: blend0019.tif
Loading next image: blend0020.tif
Loading next image: blend0021.tif
Creating blend mask: 1/4 2/4 3/4 4/4
Optimizing 1 distinct seam.

Strategy 1, s0: 1/4enblend: some images are redundant and will not be
blended.
enblend: some images are redundant and will not be blended.
 2/4 3/4 4/4
Strategy 2: s0
Using 7 blending levels
[...]
---(2)---

>From the preview it is clear that some images are completely
overlapped by other images and probably won't be shown in the final
output. However this shouldn't prevent enblend from finalizing the
image, I'd presume.

It seems the issue has been encountered earlier by Michael Galloway.
Guio Kohlmeyer's solution was to pass the option '--fine-mask' to
enblend. I find that a strange solution slash workaround, which did
the trick by the way. But I still consider this an error.

One thing I noticed was that message (2) is still spawned, but in a
different form. Instead of the enblend message coming after 'Strategy
1, s0: 1/4', it now appears just before it. Could the error be in this
part? It looks like this:

---(3)---
[...]
Optimizing 1 distinct seam.
enblend: some images are redundant and will not be blended.
enblend: some images are redundant and will not be blended.
Strategy 1, s0: 1/4 2/4 3/4 4/4
Strategy 2: s0
Using 7 blending levels
[...]
---(2)---

(see 
http://groups.google.com/group/hugin-ptx/browse_thread/thread/c42857dceb7b6fe4/3297012a01321a1d
for the other thread)
--~--~-~--~~~---~--~~
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 Build Version 3649 for Windows

2009-02-17 Thread Bart.van.Andel

OK I tried.

I decompressed your Zip-file, and added the extracted file to a new
self-extracting 7z-archive (using ultra compression). Resulting file
size: only 14.051 KiB (13.7 MiB). Quite a difference from the 37.531
KiB (36.6 MiB) of the Zip...

Just my 4 cents (which are worth 2 nowadays).
--~--~-~--~~~---~--~~
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 Build Version 3649 for Windows

2009-02-17 Thread Bart.van.Andel

Hi,

First of all, thanks for sharing your effort! That said, I'd like to
make a little suggestion. It seems like free.fr is not a blazingly
fast host (either that or a huge amount of people are all downloading
your file ;) To speed up things, a smaller file size would help a lot,
especially if you're really planning to do a weekly update. To this
end, 7-Zip does a far better job than standard (Win)Zip. And it's free
too (see 7-zip.org). Last time I checked with a Hugin build, the 7z
archive was less than half the size of the zip archive holding the
exact same contents! If you're afraid people don't have 7-zip, you can
add a sfx-part to create a self-extracting 7z file (this can be done
from the 7-zip compress dialog).

I'm curious for the build... just another 11 minutes... :)

Cheers,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Parrallax (?)

2009-01-18 Thread Bart.van.Andel

Hi,


I'm not sure if I understand what you mean exactly. I assume you're
taking multiple photographs from a tripod (without a panoramic head)
which you want to compile into a panorama, and you're asking if
parallax is a problem which can be automagically solved? I this case
the answer is no, unfortunately. Although some algorithms can "work
around" parallax errors (Smartblend does quite a decent job), it's
better to avoid them. For landscape photography, small movements of
the camera won't cause trouble because everything is far away, but for
closer subjects, parallax movements will be visible almost instantly
(just see what happens to your view when you move your head half a
centimeter left or right). A properly calibrated panoramic head on
your tripod will do the trick, but these things can be quite
expensive.

For using Smartblend within Hugin, get the necessary files here (read
the readme files for instructions on how to use the scripts):

http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/windows/smartblend-wrapper/
or
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/linux/

If you meant something else with your post, please explain. I couldn't
figure out the sentence, really.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] [Ubuntu 7.04] Building Enblend-Enfuse - glut / libxmu dependency

2009-01-18 Thread Bart.van.Andel

Hi all,


I've spotted a missing dependency on the Panotools wiki regarding
compiling Hugin under Ubuntu (http://wiki.panotools.org/
Hugin_Compiling_Ubuntu). On my freshly installed Ubuntu 7.04 system
(under coLinux), ./configure printed a warning message stating:

[...]
configure: WARNING: WARNING: GL/GLU/GLUT not found, disabling GPU mode
[...]

I've checked a dozen times that the necessary freeglut etc. libraries
were installed correctly, and I couldn't find any problems there. But
warnings are not errors, so I thought I could just compile without
glut. Heck no! I got messages like this:

[...]
make[3]: Entering directory `/home/bart/src/enblend/enblend'
g++ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I../include -
DVIGRA_STATIC_LIB -I/usr/include/OpenEXR -O3 -ffast-math -DNDEBUG -
Wall -DENBLEND_CACHE_IMAGES -ffast-math -o enfuse enfuse-enfuse.o
vigra_impex/libvigra_impex.a -lGLEW -lGLU -lGL -lglut -lSM -lICE -lXi -
lGLU -lGL -lIlmImf -lImath -lHalf -lIex -lz -llcms -ltiff -lpng -ljpeg
-lz
enblend-gpu.o: In function `wrapupGPU()':
gpu.cc:(.text+0x1b9): undefined reference to `glutDestroyWindow'
enblend-gpu.o: In function `initGPU(int*, char**)':
gpu.cc:(.text+0xa87): undefined reference to `glutInit'
gpu.cc:(.text+0xa93): undefined reference to `glutInitDisplayMode'
gpu.cc:(.text+0xa9f): undefined reference to `glutCreateWindow'
gpu.cc:(.text+0xc68): undefined reference to `glutDestroyWindow'
collect2: ld returned 1 exit status
make[3]: *** [enblend] Error 1
[...]

It seems ./configure doesn't work correctly here, trying to compile
glut-specific code even after finding out that there is no glut
installed. Obviously the problem here is caused by a missing -lglut in
the command line.

Solution: after examining the config.log file generated by ./
configure, I found out that the problem wasn't glut, but a missing
libxmu. ./configure then incorrectly assumes that glut is missing.
After installing libxmu-dev, the problem was solved.

So I guess the wiki should be updated with libxmu-dev.


Best,
Bart


NB: output of uname -a:
Linux ubuntu 2.6.22.18-co-0.8.0 #1 PREEMPT Tue Jan 13 20:59:56 UTC
2009 i686 GNU/Linux
Running under coLinux version 0.8.0 (13 January 2009 21:04:42)
--~--~-~--~~~---~--~~
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: 0.61 update of Panini perspective tool available

2009-01-12 Thread Bart.van.Andel

> Aaaarghh!  Mac users are reporting all sorts of problems with cubic
> format, you are not alone...

> But why only on Macs?  And with 3 different video systems at least?

For the record, I don't have a Mac (I only wish I had one, haha). I'm
running WinXP SP3 and just updated my graphic card drivers (ATI Radeon
9600SE) to the newest version. I just installed the drivers, not that
piece of memory consuming bloatware called Catalyst.


> I wouldn't have
> any idea how to set up mapping of multiple texture images onto one
> surface.  If you do know, please tell me.

Well, basically they're just 6 rectangular projections 90 degrees
apart, which shouldn't be too difficult to backproject onto the
panosphere. I guess you're already doing the same thing when loading a
rectangular image?


> Am I safe in assuming that you can display the non-cubic formats OK?

Correct. Only trouble with cubics.


> > I'll see if I can figure out more details later.
>
> Any help you can give would be most welcome.  I am not a Mac developer
> and have no Mac to test on.

Me neither, unfortunately. I've read through the source code a bit and
couldn't find anything wrong there. Moreover, I compared your code to
some of the code available on other websites (by googling), and if not
pretty much an exact copy, it's still fairly the same amount and order
of operations. Strange.

If you look closer at the picture I linked to in my previous post,
it's not only that the same image is shown on every face. It's shown
with a *different* error on every face. The images are shifted in both
X and Y directions (in texture coordinates), and have border issues
which differ from face to face. It popped into my mind that something
might be wrong with texture coordinate generation internally, but this
does not quite explain the cloning behavior.

By the way this is the first time I dive into OpenGL, so don't expect
me doing wonders just yet ;)

Cheers,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: 0.61 update of Panini perspective tool available

2009-01-08 Thread Bart.van.Andel

Hi Tom,

Thanks for bringing regular updates! Unfortunately, I still have
issues displaying the example cubic panoramas. Loading from JPGs and
QTVR gives different errors on screen though. It might be the OpenGL
implementation on my machine, although I doubt that, because I've
never seen such errors in other applications using OpenGL. Here's an
image showing 4 screenshots: both QTVR and cube faces, both with
initial view and super fish at 260 degrees FoV.

http://lh3.ggpht.com/_Fel5i-Q8T8g/SWXolMtRS5I/BxA/i78G0TsTEw4/2009.01.08%20Panini%20cubic%20pano%20errors.jpg

As you can see, the same face image is shown on every cube face,
although with slightly different displaying errors. I assume you are
still using OpenGL's builtin solution for the cube thing? I guess this
one causes the trouble.

I'll see if I can figure out more details later.

Good luck,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: any way of replacing low-resolution images with higher-resolution originals?

2008-12-19 Thread Bart.van.Andel

I think what breic means is downsizing in resolution, not merely jpeg
file compression. Although jpeg images will load faster than tiffs due
to their file size, they use the same amount of memory when loaded and
will slow down CP finding, CP manipulation and preview displaying.

Since Hugin and the tools used by Hugin use pixel coordinates for the
CPs, reoptimizing will fail after replacing small images with bigger
ones, because the pixel locations will be different. Just open a .pto
file in a text editor to find the coordinates.

However, when you have already optimized with the smaller images, you
can then close the project, replace the image files with the bigger
files and load the project back into Hugin. Don't reoptimize, but go
to the Stitcher tab immediately and stitch the image. I just tested it
on a small 2 image panorama. It works because after optimizing,
the .pto file contains the necessary information about roll, pitch,
yaw and other warping values, next to the (at this point unnecessary)
CP information.

Best,
Bart


On Dec 19, 2:38 pm, "Don Holeman"  wrote:
> Forgot to add, jpeg to a lower resolution for the mapping images, but keep
> the image dimensions the same.
>
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
>
> Behalf Of breic
> Sent: Thursday, December 18, 2008 11:21 PM
> To: hugin and other free panoramic software
> Subject: [hugin-ptx] any way of replacing low-resolution images with
> higher-resolution originals?
>
> Since Hugin is slow at loading images on my laptop, I sometimes downsize the
> photos before starting the panorama.  This lets me keep my sanity waiting
> for Hugin, and is often okay if I just want an equirectangular projection.
> (I am shooting 10 megapixel images at 27mm equivalent.)  However, if I
> decide to make a stereographic projection, then I want all the megapixels
> available to minimize pixelation in the distorted areas.  Is there any way
> of replacing the smaller versions with the originals in a project?
> Basically, I'd like the control points to be placed appropriately and, if
> possible, to reoptimize each control point (although that might not be
> necessary).
--~--~-~--~~~---~--~~
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: Release 0.5 of pvQt viewer

2008-12-15 Thread Bart.van.Andel

Hi Tom,

> Let me know if this fixes the problems; sorry for the inconvenience.

Unfortunately the problem persists (mov and jpg cubics). I see you've
changed the cancel behavior however :)

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: hugin 0.7.0 crashing in WinXP SP2 - solved

2008-12-15 Thread Bart.van.Andel

Yes this is a known bug and workaround, but thanks anyway.

I suppose the source could be adapted to use the short path name (8.3
format) when calling external tools which fail on the unicode paths.
To my knowledge, these won't contain unreadable symbols (although
spaces can occur technically). I checked this by making a folder named
Vysočina. When dir/x is typed in a cmd window, it shows the following:

C:\temp>dir /x
[...]
15-12-2008  14:30  VYSOIN~1 Vysočina

So, this Vysočina folder can also accessed by using VYSOIN~1 instead.

The win32 c++ function to use is GetShortPathName which is documented
at http://msdn.microsoft.com/en-us/library/aa364989(VS.85).aspx

--~--~-~--~~~---~--~~
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: Release 0.5 of pvQt viewer

2008-12-15 Thread Bart.van.Andel

Hi Tom,

> > > First, please make sure you have version 0.5.72.  I posted 0.5.71
> > > before testing on a system with only power-of-2 textures.  That
> > > revealed a serious error in scaling cubic textures -- fatal there, but
> > > could affect cubic panos on any system. 0.5.72 fixes that.
>
> > I checked and I have the 0.5.72 release. But as no error message is
> > produced anywhere (as far as I can see anyway) I can't tell whether it
> > has to do anything with my video card having problems with non-power-
> > of-2 textures.
>
> That would not be the case in OGL version 2.1.  More likely I'm asking
> for something really stupid, when you do that OpenGL often just aborts
> the operation without reporting an error.

Hmm, I just ran the program through an OpenGL debugger (I found a free
one at http://www.vis.uni-stuttgart.de/glsldevil/, but there are
more), and there seems to be no detectable error. I find this quite
strange, a behavior of aborting without reporting.
It is interesting however to see when the image gets redrawn, see for
yourself that this happens even when nothing really changes in the
image (e.g. when opening the Load File window).

By the way, as requested, the details from the about box:

About your OpenGL implementation:
Version: 2.1.7976 Release
Vendor: ATI Technologies Inc.
Video: RADEON 9600 SERIES
Limits: texPwr2 0, texMax 2048, cubeMax 2048

The dialog states "pvQt version 0.5.71" although I just double checked
that I'm using 0.5.72, by redownloaded the thing, unpacking it to a
different location and running it again.
--~--~-~--~~~---~--~~
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: Release 0.5 of pvQt viewer

2008-12-14 Thread Bart.van.Andel

> First, please make sure you have version 0.5.72.  I posted 0.5.71
> before testing on a system with only power-of-2 textures.  That
> revealed a serious error in scaling cubic textures -- fatal there, but
> could affect cubic panos on any system. 0.5.72 fixes that.

I checked and I have the 0.5.72 release. But as no error message is
produced anywhere (as far as I can see anyway) I can't tell whether it
has to do anything with my video card having problems with non-power-
of-2 textures.

> Yes, Bart, the display of "empty frames" when you cancel an image load
> is intentional.   The main idea was to make the cube faces visible as
> drag-and-drop targets; but I have come to rely on this behavior so
> much for debugging texture mappings that I doubt if I will want t
> change it any time soon.

It should be quite easy to disable this for a release build through
the use of some #define and #ifdef statements, I guess, but never
mind, it's not a serious "problem" at all :)
--~--~-~--~~~---~--~~
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: Rendering high-resolution panorama

2008-12-14 Thread Bart.van.Andel

On Dec 14, 5:01 pm, Erik Krause  wrote:
> Bart.van.Andel wrote:
> > Well, I have an example here which consists of two images with almost
> > 50 percent overlap. The source resolution is 2576 pixels wide, and
> > Hugin suggests an optimum of 5055 pixels (rectilinear projection).
> > Although it need a little cropping, this resolution is too wide to
> > prevent pixels from being upscaled.
>
> This depends on the angle of view. Rectilinear output is same resolution
> only in the image center and needs to be stretched outside. Only if you
> restrict output hFoV to the hFoV of a single input image you can compare
> the values.

The case you describe is a pretty obvious case. A single picture taken
with a "rectilinear lens" will remain the same when using a
rectilinear projection. My point is, how does Hugin determine this
estimate for a multiple image panorama? To give Ralf a nice answer as
to why the estimate wasn't correct, this would really help (together
with the other information I requested).

Ralf, maybe you could upload your source images (jpg will do) and .pto
somewhere?
--~--~-~--~~~---~--~~
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: Rendering high-resolution panorama

2008-12-14 Thread Bart.van.Andel

Well, I have an example here which consists of two images with almost
50 percent overlap. The source resolution is 2576 pixels wide, and
Hugin suggests an optimum of 5055 pixels (rectilinear projection).
Although it need a little cropping, this resolution is too wide to
prevent pixels from being upscaled.

Like I said before, I don't know how Hugin determines the optimal
resolution, but it seems to me that it isn't always a "correct"
estimate.

(by the way, 70 percent minus 10 percent of that 70 percent would be
63 percent, not 60 percent)
--~--~-~--~~~---~--~~
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: Release 0.5 of pvQt viewer

2008-12-14 Thread Bart.van.Andel

Hi Tom,

I just tested this new version, and everything runs fine, except the
cubic projection. Whether I load the cubic QTVR or the cube faces
(from the example images you provided), I get an all white screen. No
error message appears, and by judging the gui, the mouse controls
still work. My graphics card (Sapphire Radeon 9600SE with 128MB
memory) is OpenGL 2.1 compatible.

Another thing which is slightly different from expected behavior is
when you start to load an image but cancel it. I'd expect the button
would really cancel the loading process, leaving the current view
intact. Instead, an image showing "front" appears and any previously
loaded images disappear. Is this intended behavior or is it some
testing feature you accidentally left in the source code?

Apart from those glitches, this piece of software is getting more and
more interesting with each release!

Cheers,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Rendering high-resolution panorama

2008-12-12 Thread Bart.van.Andel

Okay. So now we have:
- Panorama at 4000 pixels width looks sharp overall, but it doesn't at
19000 pixels.
- Source images: 20 in 3 rows, so about 7 images per row?
- Resolution of source images: unknown.
- Sharpness of source images: unknown.
- Images taken in portrait or landscape mode (or tilted otherwise):
unknown.
- Amount of overlap of source images (or at least an estimate):
unknown.
- Projection chosen: unknown.

For an equirectilinear panorama using source images taken in landscape
mode at 20 percent overlap per image (for better results you should
take more overlap), you'd need source images of about 19000 / (7 -
6*0.20) = 3276 pixels wide (or about 8MP) to achieve a more or less 1-
to-1 correspondence between input pixels and output pixels. Of course
this isn't really true because the images are warped during
projection, and some parts will probably be cut of to get rid of empty
spaces in the final panorama, but to get an idea of what you need this
computation should do.

So, fill in the blanks and someone might give you an even smarter
answer, I can't guess them for you :)


On Dec 12, 7:00 pm, ralf  wrote:
> thanks for your reply. There are 3 rows together 20 images (because
> handheld). It`s a rectlinear panorama, the horizontal view is 118
> degree. I guess it is width but not to width (landscape). It`s not the
> distortion or the edges which are looking unspharp it is the overall
> impression. The smaller image with about 4000 pixel is sharp, (details
> are much sharper in center and edges). For the smaller image I used
> Nona/Poly 3.
>
> On 12 Dez., 17:46, "Bart.van.Andel"  wrote:
>
> > Well I don't know exactly how the "suggested size" is computed by
> > Hugin and how it relates to the input images (amount, resolution,
> > sharpness, field of view etc. etc.) and the projection chosen (type
> > and parameters). Based on the very little information that you provide
> > there is not much to suggest, except to just fiddle around a bit.
>
> > As an example however, if you create a rectilinear panorama from two
> > 35mm equivalent images which have an overlap of about 25 percent, the
> > center will always look a lot sharper than locations further from the
> > center. At the very left and right (assuming a horizontal panorama),
> > the source pixels will be stretched quite a lot, while at the center
> > they might be a little squeezed. If the horizontal resolution of your
> > source images were a 1000 pixels, a very wild guess for the output
> > horizontal resolution would be something like 1750 (2 times 1000 minus
> > the overlap) before details get blown up too much, but the distortions
> > caused by the rectilinear projection would still be visible.
>
> > On Dec 11, 6:15 pm, ralf  wrote:
>
> > > Hello,
> > > rendering a panorama with about 4000 pixel width looks sharp,
> > > rendering the same with 19000 pixel (suggested size) it doesn't  look
> > > so sharp. I used Nona/spline 64. Are there any recommendations?
> > > Ralf
--~--~-~--~~~---~--~~
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: Rendering high-resolution panorama

2008-12-12 Thread Bart.van.Andel

Well I don't know exactly how the "suggested size" is computed by
Hugin and how it relates to the input images (amount, resolution,
sharpness, field of view etc. etc.) and the projection chosen (type
and parameters). Based on the very little information that you provide
there is not much to suggest, except to just fiddle around a bit.

As an example however, if you create a rectilinear panorama from two
35mm equivalent images which have an overlap of about 25 percent, the
center will always look a lot sharper than locations further from the
center. At the very left and right (assuming a horizontal panorama),
the source pixels will be stretched quite a lot, while at the center
they might be a little squeezed. If the horizontal resolution of your
source images were a 1000 pixels, a very wild guess for the output
horizontal resolution would be something like 1750 (2 times 1000 minus
the overlap) before details get blown up too much, but the distortions
caused by the rectilinear projection would still be visible.

On Dec 11, 6:15 pm, ralf  wrote:
> Hello,
> rendering a panorama with about 4000 pixel width looks sharp,
> rendering the same with 19000 pixel (suggested size) it doesn't  look
> so sharp. I used Nona/spline 64. Are there any recommendations?
> Ralf
--~--~-~--~~~---~--~~
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: Has anyone ever installed hugin in shared web hosting?

2008-12-09 Thread Bart.van.Andel

What is it that you try to accomplish? Hugin is not a web
application... it runs on the local machine.

On Dec 9, 7:28 pm, xhe <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am wondering if anyone has ever successfully installed hugin in
> shared web hosting server? Since many libraries are required for using
> hugin, and in shared hosting server, I won't have admin access right,
> it may be really a big challenge to install hugin in shared server.
>
> Can you share with me your procedure if you ever did it?
>
> Thanks in advance.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Release 0.4 of pvQt pano viewer.

2008-11-20 Thread Bart.van.Andel

On Nov 20, 9:03 am, "Guido Kohlmeyer" <[EMAIL PROTECTED]> wrote:
> The movement up and down should be blocked on nadir
> and zenith, because I felt like doing a somersault.

Actually I like being able to navigate across zenith and nadir, a
feature which I haven't found in any other panorama viewer I've come
across so far! Of course it could be added as an option, just like any
other restriction in moving around. For instance, a 180x90 degree pano
could have such restrictions as well, e.g. horizontal between -90 and
90 degrees, vertical between -45 and 45 degrees, like some other
viewers provide.

It would be interesting to be able to move around in 3D space relative
to the current projection surface as well I think (variable camera
position). This could generate some very weird but interesting views I
guess...
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: hugin creating random panoramas

2008-11-09 Thread Bart.van.Andel

Erik Krause wrote:
> Bart.van.Andel wrote:
> > Especially with a large
> > number of input images. It could be as simple as found in M. Brown and
> > Lowe's paper on "Automatic Panoramic Image Stitching using Invariant
> > Features" (http://www.cs.ubc.ca/~mbrown/papers/ijcv2007.pdf, top of
> > page 5).
>
> This is not very feasible if there are lots of images and it doesn't
> provide a convenient way to identify unrelated images either. The
> thumbnails would be far too small.

Of course the thumbs are too small in this example, but since our
screen space may be expected to be somewhat bigger than in the paper,
larger thumbs can be used. Or simply a list of images on a canvas,
with matched images shown to the right of each list item, maybe also
showing the number of matched CPs and their average distance, for
instance. Like this (img# represents a visual image):

img0:  img1, img5
img1:  img0, img2
img2:  img1, img3, img5
img3:  img2, img4
img4:  img3, img5
img5:  img0, img2, img4

Such a list (or the graph view I mentioned earlier) could also be used
to trigger the control point to find correspondences between images
not linked together yet (for instance when an image is added later).
Not sure if this will be used a lot though...

> I'd prefer the global CP's table would highlight (put a border around)
> the respective images in pano preview instead of loading those images in
> CP pane (which takes ages on my computer, same as loading and scaling
> images for pano preview BTW).

Not agreed. Even though I'd really like to see image highlighting in
the pano preview, the CP table now provides easy access to CPs with a
large distance, so these can directly be edited in the CP pane. Or am
I misunderstanding you? Providing it as an option (with a checkbox in
the CP window for instance) would be quite nice though.

> > This is only true of course if the images are taken in order, and it
> > doesn't apply to multi-row panoramas either.
>
> This should be a rather unusual case. You easily miss an image if you
> shoot out of order. However, I often shoot a panorama in order and then
> additional images. But those images must be treated specially anyway.

How would I miss an image? I'm adding them to Hugin which finds the
CPs very nicely, no matter what order the images are fed. I don't see
why additional images would need different treatment, in general.
Again, maybe I misunderstood your point?

Best, Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: hugin creating random panoramas

2008-11-09 Thread Bart.van.Andel



On Nov 9, 12:00 am, "Erik Krause" <[EMAIL PROTECTED]> wrote:
> Am Saturday, November 08, 2008 um 14:10 schrieb Bart.van.Andel:
>
> >  After removing these wrong matches, the problem was
> > solved. It took quite a lot of effort to remove all these CPs by hand
> > though.
>
> The place to do that is the global control point table (F3). First
> sort by right image, then sort by left image. Now scroll down and
> compare image numbers.

That is one possible way to deal with it, although maybe not the most
intuitive one, having to sort twice first. Using a graph displaying
thumbnails of the images and connections between them if Hugin found
at least one matching CP, it should be far more easy to see the
correspondences found by Hugin very quickly. Especially with a large
number of input images. It could be as simple as found in M. Brown and
Lowe's paper on "Automatic Panoramic Image Stitching using Invariant
Features" (http://www.cs.ubc.ca/~mbrown/papers/ijcv2007.pdf, top of
page 5).

> compare image numbers. If it is a one row panorama any image n should
> have control points to n-1 and n+1 only. If it is a 360° one the last
> image should have points with the first one of course.

This is only true of course if the images are taken in order, and it
doesn't apply to multi-row panoramas either.

> Ususally there are few wrong points only, hence you might spot them
> in the "P CP" (private control point number) column, too.

Ah, that's what "P CP" stands for. I assume that "G CP" then stands
for global control point? Guess this is one of these examples where
tool tips come in handy :)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: hugin creating random panoramas

2008-11-08 Thread Bart.van.Andel

> most of the time hugin forms the panoramas
> totally wrong and on the preview i get all kinds of shapes and circles
> and diagonals

Could you explain this a bit more, by showing a screenshot for
example?

I've had a problem recently which kind of sounds like what you're
trying to explain, I think. In my case, there were very nice control
points between the right images, but also some between images which
aren't adjacent at all. This caused Hugin to screw up the alignment
completely. After removing these wrong matches, the problem was
solved. It took quite a lot of effort to remove all these CPs by hand
though.

Feature idea: a graph showing which images are matched to which could
be a nice idea, with an option to remove "edges" in the graph, to
speed up the process of removing such wrong image match CPs quite a
bit.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Enfuse artifact -- "Fairy ring"

2008-11-04 Thread Bart.van.Andel

I've spotted the same behavior with Enblend, while stitching a normal
panorama from two images with a slightly different exposure and white
balance (auto settings from digital point-and-shoot camera). It
happens seldom, and after some tweaking of parameters (can't remember
which) the effect was gone, at least visibly. I guess just like
Tennevin that it has to do with an overly active vignetting
correction, so playing around with that might do the trick.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: reassigning bugs in the hugin tracker

2008-11-03 Thread Bart.van.Andel

Even thought I'm not an active developer (yet) I think basically this
is a good approach. However I'd like to add a remark.

You suggest working with two version numbers, or even three (0.7.1,
0.9.0, 0.8.0), with different levels of importance with relation to
bugs and features. Even though currently the system isn't working like
this, it might be an idea to copy the way the GIMP developers use
version numbering. Odd version numbers (e.g. 2.1.x, 2.3.x, 2.5.x) are
used for "unstable" development builds to test new features. If these
features prove useful and stable, they make it into the stable release
"thread" using even numbers (e.g. 2.2.x, 2.4.x, 2.6.x). The latter are
intended for the general public, whereas the development builds are
more suitable for testing purposes and for people who want the newest
technology regardless of stability.

Implementing this scheme would require assigning a new version number
to the current stable release (0.7.0). Or 0.8.0 could be a "quick"
usability upgrade from 0.7.0, with fresh icons, some gui
rearrangements and some more intuitiveness, as suggested in another
thread here, without adding too much other functionality. Or something
like that.

It's just an idea, and it's no big deal if nobody agrees. But I think
if such a scheme is used, it could clarify the difference between
stable and unstable releases, by just looking at the version number.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: A new release of pvQT pano viewer

2008-11-01 Thread Bart.van.Andel

Hi Tom,

I like your program a lot! Even though it's still an alpha, I think it
already does quite a good job, and I'm happy you're sharing it with
us. A couple of possible displaying improvements though:

- Enable anti-aliasing and line blending (for the grid which is
displayed before an image is loaded), with a few lines of code like
this:
glHint(GL_LINE_SMOOTH_HINT, GL_NICEST); 
// Set Line Antialiasing
glEnable(GL_BLEND); 
// Enable Blending
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);  
// Type Of
Blending To Use

- Enable anisotropic filtering. Another few lines of code, see
http://www.gamedev.net/reference/programming/features/oglch9excerpt/#Heading3

- I like the way some flash viewers have implemented mouse moving,
which doesn't stop moving the image abruptly when releasing the mouse
button. But that's probably a matter of taste.

Also, it seems that the screen stutters a bit when moving around
diagonally using the mouse. It feels like the frames aren't always
displayed in the right order. Maybe a buffering issue?

Using version 0.3.46 on Windows XP SP3 / ATI Radeon 9600SE with up-to-
date drivers (OpenGL 2.1 compatible)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: newbie introduction - hugin usability

2008-10-27 Thread Bart.van.Andel

I have to agree with 'newbee' and Dale Beams. Hugin is a great
program, and I'm quite used to programs which aren't that user
friendly, so for me, it's no problem to use it. However, from a
usability perspective, certain things definitely should be changed.

I think any program which is intended to be used by a large group of
people (like Hugin) should be as intuitive as possible. The comments
'newbee' has given, are really worth investigating. In fact, I think
he/she tackles the problem quite well. Unfortunately I don't have the
time nor the skills (in terms of C++) at the moment (yet) to implement
it, but it might really help putting Hugin on the map a lot better.
Maybe it doesn't have the highest priority, but in the end, it should
be dealt with anyway, so I think we should really welcome such helpful
comments on how the Hugin process works.

Best,
Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Windows XP-compatible binaries of latest release?

2008-10-15 Thread Bart.van.Andel

If you had looked a little further into the topic list of this group,
you'd have found a topic named "Release 0.7.0 for Win32 available",
where a link is posted to the binaries (http://tksharpless.net/). Note
that these binaries haven't been extensively tested, which is why they
aren't on the official Hugin site just yet. I haven't found any
trouble yet using them however.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Could not decode image (JPEG)

2008-10-09 Thread Bart.van.Andel

> There are also programs, which can remove metadata from JPEGs (i.e.
> EXIF, IPTC, etc.) - e.g.
>  http://www.rainbow-software.org/programs.html#JPG%20Cleaner

This can be done with Irfanview as well, no need to download a
separate tool for that.
In the English version: just open Options -> "JPG Lossless Rotation...
(Shift-J)", choose "None" as the transformation, check "Optimize JPG
file", and tick "Clean all APP markers" (or Custom, with any
combination of metadata to keep).
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Smartblend: Potential use with Hugin

2008-10-09 Thread Bart.van.Andel

Great! Bob's bash script (as shown earlier in this thread) should be
added as well.

One thing in the readme is incorrect:
  1. save smartblend-hugin.bat to a known path
should be
  1. save smartblend-hugin.bat to the path where smartblend.exe
resides

The script uses its own path to determine the location of
smartblend.exe, so they have to be in the same path (either that, or
one has to modify the batch file manually to enter the correct path).

Concerning integration: it seems Hugin is prepared to use different
blenders from the GUI, as the Stitcher tab shows a pulldown menu. It
would be most convenient of course if the items in that menu are
configurable through the options menu, so Smartblend can show up there
as well. For instance like the following:

Name: Enblend
Type: blender
Executable: path\to\enblend\enblend.exe
Parameters: --compression=%compression -f %widthx%height+%x0+%y0 -o
enblend-%out %in

Name: Smartblend
Type: blender
Executable: path\to\smartblend\smartblend.exe
Parameters: -o smartblend-%out %in

Name: Nona
Type: remapper
Executable: path\to\nona\nona.exe
Parameters: (whatever parameters apply)

Just an idea. Of course you still want most options to be configurable
through the GUI, but that's what placeholders can be used for (like
%in or %out).


On Oct 9, 4:20 pm, Yuval Levy <[EMAIL PROTECTED]> wrote:
> Bart.van.Andel wrote:
> > I just adapted Bob's bash script into a Windows batch file
>
> Thanks a lot. I've added it to SVN (rev. 3489) and will try not to
> forget to add it to the next Windows installer.
>
> <http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/w...>
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Could not decode image (JPEG)

2008-10-08 Thread Bart.van.Andel

Just curious, and trying to pinpoint the problem. Could you try saving/
converting those images as TIFF first, before loading them in Hugin?
As you mentioned, there might be something wrong with loading JPGs
with Hugin on your computer, but does loading TIFF work? If not, Exif
might not be the problem.

If you'd really want to test if Exif is the problem on your computer,
you could also try to strip off the Exif data from the JPG and see
what happens then. A way to do that is to open the image in an image
editor, select all, paste as a new image and save it (of course this
isn't exactly the most sophisticated way).

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Smartblend: Potential use with Hugin

2008-10-08 Thread Bart.van.Andel

I just adapted Bob's bash script into a Windows batch file, for usage
with Windows 2000 and up. Save the script at the end of this post to a
file named "smartblend-hugin.bat" and store it in the folder where
smartblend was installed.

Usage:
  1. Start Hugin.
  2. Open File -> preferences.
  3. Switch to Enblend tab.
  4. Check "Use alternative Enblend program".
  5. Choose "smartblend-hugin.bat" as the executable (use the full
path).
  6. Press OK to save the settings.
  7. On the Stitcher tab in Hugin, click the Options button next to
the Remapper and make sure "Save cropped images" is unchecked.
  8. Enjoy SmartBlend!


Script (everything below this line):

@echo off & setlocal

set SMARTBLEND=%~dp0\smartblend.exe
set SMARTBLENDARGS=

:paramstrip
set arg=%1
if not "%arg%"=="" (
if "%arg%"=="--compression" (
rem Skip compression parameter and its argument
shift
) else if "%arg:~0,2%"=="-f" (
rem Skip ...
) else if "%arg:~0,2%"=="-l" (
rem Skip ...
) else if "%arg:~0,2%"=="-o" (
rem Reformat output parameter: add "smartblend-" prefix
set SMARTBLENDARGS=%SMARTBLENDARGS% -o smartblend-%2
shift
) else (
rem Copy other parameters
set SMARTBLENDARGS=%SMARTBLENDARGS% %1
)
shift
goto :paramstrip
)

echo.
echo Executing smartblend.exe %SMARTBLENDARGS%
echo.

%SMARTBLEND% %SMARTBLENDARGS%

endlocal
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Could not decode image (JPEG)

2008-10-08 Thread Bart.van.Andel

> I tried to find a file "exiv*.*" on my computer, but there is none...

You won't find or need such a file unless you are building from
source. Upon compiling, it is integrated into the program.

"FieldOfView" doesn't seem to be a real tag in the Exif specification
by the way; it can't be found in http://www.exif.org/Exif2-2.PDF
anyway (specifications for Exif version 2.2). I guess it is computed
from other tags.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Smartblend: Potential use with Hugin

2008-09-24 Thread Bart.van.Andel

On Sep 23, 6:51 pm, Bob Bright <[EMAIL PROTECTED]> wrote:
> For the record: I'm not a fan of closed software.  I'm using smartblend
> (for the time being) only because [...]

Actually I emailed Michael Norel (the author of SmartBlend) about it
earlier this month, asking whether development had stopped at 1.2.5.
In turn, he replied that:
"It is true, the development of SB is freezed.   Just because i have
other , very nice projects. At least i'll find time to publicsh
sources."

Sounds like a nice promise! I pointed him to this group for informing
us when he does.

Cheers, Bart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Huign-0.7.0-rc5 for Windows available

2008-09-11 Thread Bart.van.Andel

Hi Tom

Well, the example I gave shows it's about twice as small, I'm talking
about the same files (though a different SVN version, but this
shouldn't make a huge difference). The 7Z also creates self-extracting
archives.
For fair comparison, I tried it on your last file, which is 20.621.719
bytes in size. After decompressing and recompressing again (settings:
7Z format, Ultra compression, LZMA, 64MB dictionary, 64 word size, 4GB
solid block size, Create SFX enabled, Compress shared files enabled),
the file is just 8.274.702 bytes. That's about 40 percent of your RAR
SFX file, or about 2.5 times smaller. Quite impressive, I'd say.

But anyway, thanks for providing the RC5 of course :)

Best,
Bart

On Sep 11, 5:05 am, Tom Sharpless <[EMAIL PROTECTED]> wrote:
> Hi Bart
>
> Yes, 7zip archives are smaller (though not 2x smaller -- try archiving
> the installed directory with 7zip), but who cares?   I don't have
> 7zip, I do have WinRAR, and WinRAR makes nice self-installing
> archives.  So I use it.
>
> Regards, Tom
>
> .
>
> On Sep 10, 7:08 am, "Bart.van.Andel" <[EMAIL PROTECTED]> wrote:
>
> > Thanks for posting!
>
> > Just a tip: to save yourself some bandwidth, you could compress the
> > archive using 7-Zip (7zip.org), which compresses Hugin twice as much
> > as WinRAR does, apparently. For instance, your rc5 file is 19.6 MiB,
> > while the SVN3407 build takes up only 9.26 MiB of disk space. The
> > actual content of the SVN build is actually even a little bigger than
> > the rc5 content, in bytes.
>
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: Huign-0.7.0-rc5 for Windows available

2008-09-10 Thread Bart.van.Andel

Thanks for posting!

Just a tip: to save yourself some bandwidth, you could compress the
archive using 7-Zip (7zip.org), which compresses Hugin twice as much
as WinRAR does, apparently. For instance, your rc5 file is 19.6 MiB,
while the SVN3407 build takes up only 9.26 MiB of disk space. The
actual content of the SVN build is actually even a little bigger than
the rc5 content, in bytes.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---