2010.4.0-beta1 Win32 test

[namklim]

I did a clean install of the 2010.4.0-beta1 Win32 on a Pentium P4 3MHz
running WinXP sp3. No GPU. It installed without any problems.

Align | Running assistant and Batch Processor Assistant
- If either of the Assistants is cancelled the window closes but the
align stack process continues to run. If another align is started and
cancelled there are then two align stack processes continue to run....
- no minimize/maximize buttons

Align stack/icpfind
- very slow for Samyang 8mm using 9 images (6 round, 1 up 2 down)
- Align stack/icpfind only found 8 points and took about 15 min 10 sec
to run (repeatable timing) (I tried with both fisheye and
stereographic settings)
- in comparison, Panomatic found 94 points (and connected all images)
in 1 min 40 sec

Stitching:
- HDR stitching with TIF output creates a file which cannot be opened
with Irfanview, GIMP, etc. The output to an EXR file is OK.
- sometimes a message "LZW compression is not available to due to
Unisys patent enforcement" is shown.

[davidefa]

> Align stack/icpfind
> - very slow for Samyang 8mm using 9 images (6 round, 1 up 2 down)
> - Align stack/icpfind only found 8 points and took about 15 min 10 sec
> to run (repeatable timing) (I tried with both fisheye and
> stereographic settings)
> - in comparison, Panomatic found 94 points (and connected all images)
> in 1 min 40 sec
>

Could you upload the photos and the project file?

[namklim]

The other files I used were large TIF files. I've put a similar set of
lower quality JPG images which exhibit the same characteristics and
the two .pto files at http://goo.gl/2l2im It is a 55Mb download.
cpfind time taken 13:51 control points 4
panomatic time taken 01:59 control points 120 (time includes
optimisation, etc)

[namklim]

Did you have time to look at the files and confirm whether or not
there is a cpfind problem?

On Nov 30, 7:21 pm, namklim <namk...@googlemail.com> wrote:
> The other files I used were large TIF files. I've put a similar set of
> lower quality JPG images which exhibit the same characteristics and

> the two .pto files athttp://goo.gl/2l2im It is a 55Mb download.

[Harry van der Wolf]

2010/11/29 namklim <nam...@googlemail.com>

I did a clean install of the 2010.4.0-beta1 Win32 on a Pentium P4 3MHz
running WinXP sp3. No GPU. It installed without any problems.

Align | Running assistant and Batch Processor Assistant
- If either of the Assistants is cancelled the window closes but the
align stack process continues to run. If another align is started and
cancelled there are then two align stack processes continue to run....
- no minimize/maximize buttons

Align stack/icpfind
- very slow for Samyang 8mm using 9 images (6 round, 1 up 2 down)
- Align stack/icpfind only found 8 points and took about 15 min 10 sec
to run (repeatable timing) (I tried with both fisheye and
stereographic settings)
- in comparison, Panomatic found 94 points (and connected all images)
in 1 min 40 sec

Align_image_stack is very slow as it is not properly "optimized". CPfind itself has approximately the same speed as panomatic.

Anyway, I don't understand why you run align_image_stack in combination with cpfind, and not with panomatic?

align_image_stack does something completely different from cpfind and panomatic, either you use it with both or not at all.

The situations where you want to run align_image_stack is when the images in your panorama are sets of images with different exposure that you want to align first, then (en)fusing them and then (en)blend the fused images to a panorama. In that case you run align_image_stack before cpfind or panomatic or autopano-sift-c.

Harry

[AKS-Gmail-IMAP]

I have been running Hugin on a Windows 7 box for a few months without
any problems until about the time the 64 bit Hugin builds started to
appear. This error started to crop up when opening the fast preview,
so I revert to earlier builds.

"Sorry, the fast preview window requires a system which supports
OpenGL version 1.1 with GL_ARB_multitexture extension. The fast
preview cannot be opened."

I see this error in the most recent 32bit and 64bit builds. The
computer equipment being used is an up to date CAD workstation. I
guess it might handle just about anything thrown to it. Could it be
there is some other error occurring that is trapped by the code that
outputs the error message?

Allan

[namklim]

I used the expression Align stack/icpfind because that was what, if I
remember correctly, Hugin showed in the windows at various points. I
didn't set anything so perhaps my terminology is incorrect. I just did
a clean, install of the Hugin beta and ran it with a set of images
without touching any of the default preference settings or addinng
anything. It was only when the default settings found very few control
points with the Samyang images I added panomatic to check the beta.
Panomatic found many more control points in a much shorter time. So
there appears to be a problem.

According to the release notes "For the first time Hugin can be
considered feature-complete. A third-party control points generator
is no longer necessary. This release delivers some major new features,
integrates some projects from the 2010 Google Summer of Code, and
includes many general improvements."

I was highlighting an issue which I thought might mean that statement
was not correct and new users of Hugin could well be disappointed
because of the out-of-the-box performance.

On Dec 5, 3:35 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> 2010/11/29 namklim <namk...@googlemail.com>

[Emad ud din Btt]

This problem started from builds with Masking feature. Masking is a very very fine addition to hugin. But this causes this problem to windows users. I have pointed out this problem on this forum and after much investigation by experts......there is no solution. You have to change VGA card that supports it or  You can also try Ubuntu operating system. All my VGA cards that are not compatible with hugin fast preview mode, works perfectly under ubuntu. I dont know why is that? Why one VGA supports it in ubuntu and same VGA doest not support it in windows.

 

--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

--


Emaad
www.flickr.com/emaad

[namklim]

In the Preferences Control Point Detectors in the default install it
is called Align image stack. When you run the Align the first called
program in the Assistant windowis icpfind. In the Windows Task Manager
it runs align_image_stack.exe.

As in beta 1, in beta 2 if you Cancel the Align Assistant (and even if
you then close Hugin) the align_image_stack.exe continues to run using
significant cpu cycles.

[AKS-Gmail-IMAP]

The build that does work for me without exhibiting this problem has the Masking feature and the feature functions.

[namklim]

subject title changed back after thread hijacking

[Yuval Levy]

Hi,

sorry for getting very late on this very important issue.

On December 6, 2010 03:34:59 am namklim wrote:
> According to the release notes "For the first time Hugin can be
> considered feature-complete. A third-party control points generator
> is no longer necessary. This release delivers some major new features,
> integrates some projects from the 2010 Google Summer of Code, and
> includes many general improvements."
>
> I was highlighting an issue which I thought might mean that statement
> was not correct and new users of Hugin could well be disappointed
> because of the out-of-the-box performance.

downloading your files was a pain. next time before using one of these so
called "free" download services that throw consumer-hostile code at everybody
and waste my time (and yours), ask here if you need to share a large file.

I have uploaded your file to my server at
<http://www.photopla.net/hugin/namklim.zip> and strongly encourage developers
to have a look / use it as a test case.

This is the result of my testing on these files. cpfind was run on an empty
pto file that is just listing the images (attached). panomatic was run on the
images themselves. I only ran three tests.

1. REFERENCE: `time panomatic -o panomatic.default.pto *.jpg`

real 1m17.629s
user 2m20.150s
sys 0m2.980s

detected CPs: 158

2. DEFAULT `time cpfind -o cpfind.default.pto imgonly.pto`

real 0m58.063s
user 1m40.830s
sys 0m2.890s

detected CPs: 4

3. FULLSCALE `time cpfind fullscale time cpfind --fullscale -o
cpfind.fullscale.pto imgonly.pto`

real 3m0.262s
user 5m17.250s
sys 0m7.640s

detected CPs: ZERO

these results are puzzling. they require more confirmation to see if this is
an exceptional case, or if the issue affects more cases and we can only find
this out if the code is out in real world use.

In terms of speed, cpfind (default) is almost 20% faster than panomatic
(default), but what is speed if the quality is not there?

What surprises me is that cpfind's results are worse at full scale than
resized.

Is this a show stopper? I don't think so - shipping without cpfind is worse
than shipping with cpfind as-is. But we definitely need more information to
understand under which circumstances this problem happens.

I have started a tracker ticket:
<https://bugs.launchpad.net/hugin/+bug/694329>

Please continue discussion and testing there.

Yuv

[kfj]

On 25 Dez., 19:26, Yuval Levy <goo...@levy.ch> wrote:

> 1. REFERENCE: `time panomatic -o panomatic.default.pto *.jpg`
>
> real    1m17.629s
> user    2m20.150s
> sys     0m2.980s
>

> these results are puzzling.  they require more confirmation to see if this is
> an exceptional case, or if the issue affects more cases and we can only find
> this out if the code is out in real world use.
>
> In terms of speed, cpfind (default) is almost 20% faster than panomatic
> (default), but what is speed if the quality is not there?

since you refer to panomatic as your reference, did you take into
account that panomatic also scales down the images? To make a valid
speed comaprison, you have to also call panomatic with the --fullscale
flag.

> What surprises me is that cpfind's results are worse at full scale than
> resized.

that is indeed very worrying!
I made a trial, though, and the --fullscale version did take much
longer, but also produced more CPs.

> Please continue discussion and testing there.

...oops, saw that too late

Kay

[namklim]

On Dec 25, 7:26 pm, Yuval Levy <goo...@levy.ch> wrote:
> Hi,
>
snip

>
> downloading your files was a pain.  next time before using one of these so
> called "free" download services that throw consumer-hostile code at everybody
> and waste my time (and yours), ask here if you need to share a large file.
>
>

> Please continue discussion and testing there.
>
> Yuv
>

So where should any test images be posted? I was asked to post them
somewhere and did. I wasn't given any indication of where to post
them. There was nothing in the original beta announcement indicating
where to post any problem images. You were rather lucky you downloaded
them when you did. Having had no feedback, I was going to delete them
when I got back home after my December holiday.

I'd rather given up on testing/raising possible issues after posting
the images as there was no further follow-up or feedback. The problem
occurred with all the Samyang panoramas I tried. I have not checked
with other lenses. I raised several issues in the original posting and
none were followed up although two were later raised by others and
resolved. The CP problem with cpfind has only now, after a month been
picked up. I have not checked in the RC whether the orphan instances
and the EXR issues have been resolved.

[Harry van der Wolf]

Hi Yuv and others,

2010/12/25 Yuval Levy <goo...@levy.ch>

I have uploaded your file to my server at
<http://www.photopla.net/hugin/namklim.zip> and strongly encourage developers
to have a look / use it as a test case.

This is the result of my testing on these files.  cpfind was run on an empty
pto file that is just listing the images (attached).  panomatic was run on the
images themselves.  I only ran three tests.

....

these results are puzzling.  they require more confirmation to see if this is
an exceptional case, or if the issue affects more cases and we can only find
this out if the code is out in real world use.

In terms of speed, cpfind (default) is almost 20% faster than panomatic
(default), but what is speed if the quality is not there?

What surprises me is that cpfind's results are worse at full scale than
resized.

Is this a show stopper?  I don't think so - shipping without cpfind is worse
than shipping with cpfind as-is.  But we definitely need more information to
understand under which circumstances this problem happens.

I have started a tracker ticket:
<https://bugs.launchpad.net/hugin/+bug/694329>

Please continue discussion and testing there.

Yuv

First of all: I'm a nitwit when it comes to fisheye panos as I don't do that (I only create wide angle panos like the Max Lyons ones on his gallery on tambaware. That's my cup of tea as well), but it is known that both cpfind and panomatic are not good at fisheye images. Pablo mentioned this at the time he was working on "pablomatic".

And as we are talking about fisheye images here, the first thing I did was increase the "sieve1size" default value of 30 to 100 (--sieve1size 100), as that's recommended for fisheyes.
Now this "--sieve1size 100" generates 20 CPs instead of your 4. However only a few images were connected.
Then I used "--sieve1size 200" which generates 35 pairs of CPs, still 4 images not connected.
Then with "--sieve1size 300" which generates 57 pairs of CPs. Still 2 images not connected.

Then I used the "fullscale" option together with the "--sieve1size 200" option (still fisheye images, so I won't try without the increased size). CP pairs generated: 26. 5 images not connected (man, fullscale is slow!!). So indeed, fullscale delivers worse results.

Then I did a final run with "--sieve1width 50 --sieve1height 50 --sieve1size 300" (no fullscale). This generated 64 CPs with only one image not connected: the 20101109_IMGP1465_KX.jpg, which is the nadir image. (From my limited knowledge this is always a hard image for the CPs, or not?)

Optimization of the panos was weak to rubbish, be it that I don't have experience with fisheye panos, so maybe I did something not completely right.


Finally: I would not qualify this as a showstopper. I myself never create fisheye 360x180 degree panos. cpfind always works for me! How many of the users are really creating 360x180 degree panos and who only create wide angle panos (like the Max Lyons ones I already mentioned.)
Is there a way to make a poll to check the percentages of:
- 360x180 degree only pano makers
- 360 degree pano makers
- wide angle pano makers.

Harry



 

[Yuval Levy]

On December 25, 2010 03:10:28 pm namklim wrote:
> So where should any test images be posted?

I have not seen / hit yet a file size limit on our Launchpad bug tracker [0].
If we do hit a limit, there is place on the panotools server. I can set up
something on my own server too if needed. The bottom line is that if you put
it on services like rapidshare or other "free" download sites, you make it
difficult for me (and maybe for others too) to receive the files.

> There was nothing in the original beta announcement indicating
> where to post any problem images.

There was (and it was the first or second paragraph) a statement to report
bugs on Launchpad [0].

> I'd rather given up on testing/raising possible issues after posting
> the images as there was no further follow-up or feedback.

If you want follow up on issues or feedback, the bug tracker [0] is the place
to go. And even then, don't expect a quick or immediate reply. People have
other priorities than yours and you got to accept this (the same way I accept
it if you decide that filing a report on Launchpad is not your priority and
the issue goes unnoticed).

> The problem occurred with all the Samyang panoramas I tried.

File a bug report [0]. I don't have a Samyang lens. AFAIK the developers of
cpfind don't have one either. I can't deal with what I don't know, and the
chatter of a mailing list is not the right place to store this kind of
information.

I was cleaning up the backlog of mailing list messages and you are lucky that
I had the time to actually read some of them and not just scan the subject
lines. When I saw you kept coming back, I looked into it and quite frankly,
without raising accusations, I found that people who replied to you
misunderstand the issue; and not because they did not try to understand you.

Speaking of which: meaningful subject lines attract attention. When I see
"2010.4.0-beta1 Win32 test" I skip it, simply because I don't have Windows, I
can't help, and it does not affect me. "cpfind does not find CP on Samyang
fisheye images" would have attracted more attention, at least on my side.

> I raised several issues in the original posting

It is good practice to raise one issue in one bug ticket; and to put the
issues in the bug tracker [0] (no, I won't stop repeating that). If you raise
your issues anywhere else than in the bug tracker, don't expect anybody to pay
attention or do anything about it. And if you raise multiple issues in a
single message don't expect anybody to take the time and identify that there
are multiple issues.

> The CP problem with cpfind has only now, after a month been
> picked up.

This is not uncommon. Go into the bug tracker and you will find issues dating
back to 2007. This is because people don't have time, and when they do they
don't necessarily deal with your issues.

> I have not checked in the RC whether the orphan instances
> and the EXR issues have been resolved.

I don't even know what you mean with "orphan instances". Regarding EXR, can
it be [1]?

As I stated, I read the subject saying "Win32 test" and I decided that this is
not something I have time for. Was I wrong? of course I was. Why was I
wrong?

Yuv

[0] https://bugs.launchpad.net/hugin
[1] https://bugs.launchpad.net/hugin/+bug/678694

[Yuval Levy]

Hoi Harry,

Thank you for the whole information about sieve size width height. We need
more such practical info and we should expect this to be a "frequently asked
question" (i.e. add it to the Hugin FAQ [0] ).

We need to determine whether the optimal sieve parameters depend on only on
the lens type (fisheye vs. rectilinear lens); or if they also depend on focal
distance; on image size; and maybe on other factors as well.

With such a body of knowledge, maybe it is possible to expand cpfind with an
"auto" mode that automatically adjusts the sieve based on the type of input
images?

On December 25, 2010 05:03:24 pm Harry van der Wolf wrote:
> Then I did a final run with "--sieve1width 50 --sieve1height 50
> --sieve1size 300" (no fullscale). This generated 64 CPs with only one
> image not connected: the 20101109_IMGP1465_KX.jpg, which is the nadir
> image. (From my limited knowledge this is always a hard image for the CPs,
> or not?)

well, yes, the nadir is a difficult image, but not necessarily in terms of CP
detection. It is difficult because often we move the tripod or monopod to
take it and so it may have more parallax. In terms of feature detection it is
the same as any other picture, and depends on the availability of features.

> Optimization of the panos was weak to rubbish, be it that I don't have
> experience with fisheye panos, so maybe I did something not completely
> right.

possible. did you check visually if the detected CP correspond? this is what
we need now.

> Is there a way to make a poll to check the percentages of:
> - 360x180 degree only pano makers
> - 360 degree pano makers
> - wide angle pano makers.

I don't think we need such a poll. There are enough users in all of these
categories (or at least at the two extremes) to warrant support for both.

For now it will be FAQ-support, until some logic will come along to
automagically determine the right sieve parameters. I started [1].

Yuv

[0] <http://wiki.panotools.org/Hugin_FAQ>
[1]
<http://wiki.panotools.org/Hugin_FAQ#cpfind:_not_enough_control_points_generated>

[Yuval Levy]

On December 25, 2010 02:00:11 pm kfj wrote:
> since you refer to panomatic as your reference

this is what milkman used as reference.

> , did you take into
> account that panomatic also scales down the images?

yes - the first two reports are with scaled down images, and I assume they
scale both to the same size (since that part has been borrowed from panomatic
for cpfind).

> To make a valid speed comaprison, you have to also call panomatic with the
> --fullscale flag.

I'm not into speed comparison at this moment.

> > What surprises me is that cpfind's results are worse at full scale than
> > resized.
>
> that is indeed very worrying!
> I made a trial, though, and the --fullscale version did take much
> longer, but also produced more CPs.

with the posted images, or with your own images? we need more data. it is
cpfind non-fullscale vs. cpfind fullscale that I was comparing in my last
comparison, and that finding was very worrying.

> > Please continue discussion and testing there.
>
> ...oops, saw that too late

no worries. for now this is mostly chatter. But we need to collect the body
of information available, and it will be a collection over weeks and months
and maybe even years and this is where the limits of a mailing list and of
human memory are attained.

thanks for testing
Yuv

[Harry van der Wolf]

Hi,

Quick answer as I have familiy visits today (It's christmas) and leaving in 30 minutes.

2010/12/26 Yuval Levy <goo...@levy.ch>

Hoi Harry,

Thank you for the whole information about sieve size width height.  We need
more such practical info and we should expect this to be a "frequently asked
question" (i.e. add it to the Hugin FAQ [0] ).

We need to determine whether the optimal sieve parameters depend on only on
the lens type (fisheye vs. rectilinear lens); or if they also depend on focal
distance; on image size; and maybe on other factors as well.

Thank you for adding it to the FAQ. However, there is also the cpfind page on wiki.panotools.org [0] that Thomas wrote.
I remembered it from earlier discussions when Pablo mentioned it, but I also checked the cpfind page.

 

> Optimization of the panos was weak to rubbish, be it that I don't have
> experience with fisheye panos, so maybe I did something not completely
> right.

possible.  did you check visually if the detected CP correspond?  this is what
we need now.

Yes, I did check. In the final run that generated 64 CP pairs I deleted 10 pairs as they didn't fit at all. Some others were badly fitted as well. I will do some further tests.


Harry

[0]: <http://wiki.panotools.org/Cpfind>

[namklim]

The focal length of the Samyang is very nominal at 8mm (and the
Vivitar version is labelled as 7mm). Older versions of Hugin optimised
it to about 9.5mm and I set the lens to that before any CP detection.
However, I suspect the latest version may still try to use the EXIF
focal length as well in optimisation? The nadir image really needs to
be declared as a different lens otherwise the optimisation gets
confused and tries to optimise all images with a shorter than optimal
focal length. Perhaps that nadir image should be deleted before you
run any basic tests?

It is possible to use the lens for four rather than round and only one
up and one down. I can provide more sample sets in the New Year when I
am back home, if any one wants any?

[kfj]

On 26 Dez., 11:58, namklim <namk...@gmail.com> wrote:
> The focal length of the Samyang is very nominal at 8mm (and the
> Vivitar version is labelled as 7mm). Older versions of Hugin optimised
> it to about 9.5mm and I set the lens to that before any CP detection.
> However, I suspect the latest version may still try to use the EXIF
> focal length as well in optimisation? The nadir image really needs to
> be declared as a different lens otherwise the optimisation gets
> confused and tries to optimise all images with a shorter than optimal
> focal length. Perhaps that nadir image should be deleted before you
> run any basic tests?

Hi!
I also use the Samyang 8mm on a Canon EOS 450D, so this isn't a full-
format sensor, but 1.6 crop. Let me mention a few things I've found
using it:
- I think it's best to do 6 around in portrait orientation, one up one
down to have enough overlap
- don't do the zenith straight up but tilted up at about 60 degrees,
that way you get more overlap with the 6 around and still have enough
in the up shot to get the sky right
- same thing for the nadir; just tilt it down 60 degrees, not straight
down.
- for the optimization to work out right, you want lens type
'stereographic'.
- you also want to calibrate the lens carefully. I came up with
lens.ini values like
v=98.6965
a=0.0215261
b=-0.0839417
c=0.0349003
- as long as the hfov is right, I think the precise focal length
doesn't matter.
- and you should optimize for d and e every time.
- use the same lens setting for all shots, just make sure it's well
calibrated

> It is possible to use the lens for four rather than round and only one
> up and one down.

I think 6+1+1 is better.

Give it a shot, maybe it sorts out your problem.

Kay

[Yuval Levy]

On December 26, 2010 03:20:32 am Harry van der Wolf wrote:
> Thank you for adding it to the FAQ. However, there is also the cpfind page
> on wiki.panotools.org [0] that Thomas wrote.

Thanks. I stopped at the man page. Updated the FAQ entry. Updating the man
page.

My mistake: the lens was specified as rectilinear in my input pto file. But
even after going to fisheye, the default settings find "only" 22 CPs.

Yuv

[Harry van der Wolf]

2010/12/26 Yuval Levy <goo...@levy.ch>

My mistake: the lens was specified as rectilinear in my input pto file.  But
even after going to fisheye, the default settings find "only" 22 CPs.

Yuv

Well, same for me. Thanks for pointing this out.

Now I did another run with "--sieve1width 50 --sieve1height 50 --sieve1size 300" (no fullscale).

This generated 470 CP pairs with all images connected. I removed CPs by using the statistical method (from Thomas), which removed 34 points (or so). Optimized, immediately removed a great bunch with errors above 50 (some 100), optimized again, removed all points with error > 7.
Did some further optimization for positons, viewing angle and barrel.

Ended up with this 360x180 equirectangular (See attached, reduced to 1024x512 for attachment size). I assume further optimization will improve it a lot, but it is working now with cpfind.


Harry

[Yuval Levy]

On December 26, 2010 05:04:55 pm Harry van der Wolf wrote:
> Ended up with this 360x180 equirectangular (See attached, reduced to
> 1024x512 for attachment size). I assume further optimization will improve
> it a lot, but it is working now with cpfind.

well done, Harry!

For the first time, Hugin has its own CP finder. Those who want to keep using
third party tools can do so, but they should also direct their critique to the
maintainers of those third party tools, not to Hugin.

Yuv

[Jeffrey Martin]

this is off topic, but in reply to Yuval's wailing about those pesky file transfer services (i hate them too)

there is one great one - www.wetransfer.com - no bullshit at all, pleasant to use :) i try to use no other.

[Yuval Levy]

that's even more pesky. it's flash, it has consumer-hostile tracking code,
and it collects email addresses.

Conclusion: BS^2

there is space on the panotools.org server. whoever has a need to share a big
file, ask for the ftp credentials.

Yuv (just finished an intense week, with an even more intense one ahead, may
or may not catch up with Hugin over the weekend)

[kfj]

On 7 Jan., 22:09, Jeffrey Martin <360cit...@gmail.com> wrote:
> this is off topic, but in reply to Yuval's wailing about those pesky file
> transfer services (i hate them too)
>

> there is one great one -www.wetransfer.com- no bullshit at all, pleasant

> to use :) i try to use no other.

I don't get anything on that link, can you doublecheck it's correct?

Kay

[Carl von Einem]

kfj schrieb am 08.01.11 11:40:

I just tried and it's a https site:
https://www.wetransfer.com/

Since I use NoScript the site shows me a message to install Adobe's
Flash player or "...wait - we will start a HTML version shortly":

> Um WeTransfer Benutzen zu k�nnen, bitte Installiere die
> neuste Version von Adobe Flash Player. Wenn es nicht
> funktioniert (oder du nicht willst), keine Sorge - wir
> starten die HTML version in k�rze.

While the statement about the HTML version sounds ambiguous to me I read
it as if they plan on realizing a non-Flash version, too.

http://www.wetransfer.info/ contains an faq about the service.

Carl

[Pablo d'Angelo]

Hi all,

Am 25.12.2010 19:26, schrieb Yuval Levy:

> I have started a tracker ticket:
> <https://bugs.launchpad.net/hugin/+bug/694329>

I have improved cpfind to be much more reliable when using fisheye
images. Most tests so far have been positive, except for images with
very little overlap. If there are still problems with the latest
development version (hg: 3da7ecaa2dea), please comment on the above bug
request.

ciao
Pablo

[bloody tomatoes]

Pablo / Harry,

are these settings still the best to use for fisheye?

"--sieve1width 50 --sieve1height 50 --sieve1size 300" (no fullscale).

what about non-fisheye - is it best to stay with the default settings?

Thanks, 

Tomato

[Harry van der Wolf]

2011/1/17 bloody tomatoes <bloodyt...@gmail.com>

I don't know whether they are the best. In my tryouts they worked best for one set of fisheye images of a samyang lense. I have no experience with fisheyes and settings might be different for other lenses and/or panos.

Harry