9:51 a.m.
Hi, according to
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-May/009645...
autopano-sift-C was removed from the F15 repository due to a broken
dependency on libpano13. I've just successfully built it from the f14
source on an f15 system, libpano13 is available and the dependency
seems to have been restored. Is it possible to have it reinstated
please?
Thanks,
--
imalone
11:04 p.m.
On Mon 26-Sep-2011 at 10:51 +0100, Ian Malone wrote:
Hi, according to
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-May/009645...
autopano-sift-C was removed from the F15 repository due to a broken
dependency on libpano13. I've just successfully built it from the f14
source on an f15 system, libpano13 is available and the dependency
seems to have been restored. Is it possible to have it reinstated
please?
Done, rebuilt in rpmfusion/plague for F15 and F16, though will have
to wait for signing etc...
Note that Hugin panorama stitcher now has a fully working
patent-free replacement for autopano-sift-C (you need to reset your
Hugin preferences to enable this), so there isn't really any need
for rpmfusion to carry this package after F16.
--
Bruno
11:14 p.m.
Bruno Postle wrote:
Note that Hugin panorama stitcher now has a fully working
patent-free replacement for autopano-sift-C (you need to reset your
Hugin preferences to enable this), so there isn't really any need
for rpmfusion to carry this package after F16.
What makes it patent-free? Is the quality of the output comparable?
Kevin Kofler
9:15 a.m.
On 27 September 2011 00:04, Bruno Postle <bruno(a)postle.net> wrote:
On Mon 26-Sep-2011 at 10:51 +0100, Ian Malone wrote:
>
> Hi, according to
>
> http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-May/009645...
> autopano-sift-C was removed from the F15 repository due to a broken
> dependency on libpano13. I've just successfully built it from the f14
> source on an f15 system, libpano13 is available and the dependency
> seems to have been restored. Is it possible to have it reinstated
> please?
Done, rebuilt in rpmfusion/plague for F15 and F16, though will have to wait
for signing etc...
Thanks.
--
imalone
8:41 p.m.
On Tue 27-Sep-2011 at 01:14 +0200, Kevin Kofler wrote:
Bruno Postle wrote:
> Note that Hugin panorama stitcher now has a fully working
> patent-free replacement for autopano-sift-C (you need to reset your
> Hugin preferences to enable this), so there isn't really any need
> for rpmfusion to carry this package after F16.
What makes it patent-free?
autopano-sift-C has an implementation of the SIFT technique, and the
alternative panomatic implements SURF. Both algorithms are
apparently patented, so neither tool could go into Fedora.
This was a problem, so Pablo d'Angelo (the original author of Hugin)
wrote cpfind, which uses code from panomatic but has an entirely
novel feature detector.
Is the quality of the output comparable?
Yes, the cpfind in Hugin 2011.0.0 is much more reliable than
autopano-sift-c, but not necessarily faster. Unfortunately 2011.0.0
didn't make it into F15, though it will be in F16.
--
Bruno
9:12 p.m.
On 27 September 2011 21:41, Bruno Postle <bruno(a)postle.net> wrote:
On Tue 27-Sep-2011 at 01:14 +0200, Kevin Kofler wrote:
>
> Bruno Postle wrote:
>>
>> Note that Hugin panorama stitcher now has a fully working
>> patent-free replacement for autopano-sift-C (you need to reset your
>> Hugin preferences to enable this), so there isn't really any need
>> for rpmfusion to carry this package after F16.
>
> What makes it patent-free?
autopano-sift-C has an implementation of the SIFT technique, and the
alternative panomatic implements SURF. Both algorithms are apparently
patented, so neither tool could go into Fedora.
This was a problem, so Pablo d'Angelo (the original author of Hugin) wrote
cpfind, which uses code from panomatic but has an entirely novel feature
detector.
Thanks for the tip. I discovered that I had to re-import the default
control point detectors to get the Fedora 15 ones (I've just upgraded
this system).
> Is the quality of the output comparable?
Yes, the cpfind in Hugin 2011.0.0 is much more reliable than
autopano-sift-c, but not necessarily faster. Unfortunately 2011.0.0 didn't
make it into F15, though it will be in F16.
Trying cpfind on a few panoramas with 2010.4.0.854952d82c8f I've found:
2 where results were acceptable (similar to sift)
1 where results were worse (a very dark image which neither could
automatically handle, but sift was able to cope once some manual
points were added).
1 where cpfind performed better (correctly connected end image of 5,
whereas sift anomalously connected it to the wrong image).
If 2011 is an improvement then on this limited evidence I couldn't complain.
Further question then while on the topic: libpano13 is apparently
compiled with a 179 degree limit to avoid a patent on hemispherical
coverage (aren't patents great?) does anyone know if that limit been
circumvented? (The actual patent, not the number in the source code. I
don't even know if it's much of a problem for single row panoramas
anyway).
--
imalone
9:51 p.m.
On Tue 27-Sep-2011 at 22:12 +0100, Ian Malone wrote:
Further question then while on the topic: libpano13 is apparently
compiled with a 179 degree limit to avoid a patent on hemispherical
coverage (aren't patents great?) does anyone know if that limit
been circumvented? (The actual patent, not the number in the source
code. I don't even know if it's much of a problem for single row
panoramas anyway).
This patent covers input images, specifically stitching two >180°
circular fisheye photos into a single spherical image. As it
happens nobody does this because the quality is terrible.
Professional photographers stitch spherical panoramas from four or
more normal fisheye shots and it all works fine. i.e. I don't think
there is any point rebuilding libpano13 without the 179° limit.
--
Bruno
9:52 a.m.
On 27 September 2011 22:51, Bruno Postle <bruno(a)postle.net> wrote:
On Tue 27-Sep-2011 at 22:12 +0100, Ian Malone wrote:
>
> Further question then while on the topic: libpano13 is apparently compiled
> with a 179 degree limit to avoid a patent on hemispherical coverage (aren't
> patents great?) does anyone know if that limit been circumvented? (The
> actual patent, not the number in the source code. I don't even know if it's
> much of a problem for single row panoramas anyway).
This patent covers input images, specifically stitching two >180° circular
fisheye photos into a single spherical image. As it happens nobody does
this because the quality is terrible. Professional photographers stitch
spherical panoramas from four or more normal fisheye shots and it all works
fine. i.e. I don't think there is any point rebuilding libpano13 without the
179° limit.
Good to know, thanks very much.
--
imalone
4595
days inactive
4597
days old
rpmfusion-developers@lists.rpmfusion.org
7 comments
3 participants
participants (3)
-
Bruno Postle -
Ian Malone -
Kevin Kofler