headers
Xianyong Fang | 2 Mar 2004 03:56
Picon
Favicon

Please help me on SIFT detection by David Lowe's IJCV paper

Hi,

  I have implemented the SIFT detection algorithm of David Lowe's IJCF paper 'Distinctive Image Features
from Scale-Invariant Keypoints', but why I can not find many initial keypoints(that is the peaks in DOG
images). Even I find the initial keypoints do not always occur in the corners and edges.

  According to my understanding, the resampled guassian image is used as the first scale image of the next
octave, am I right? I build three DOG images in each octave (two DOG images have the same problem), but find
that only few (actually less that 10) initial key points can be detected. But if I compare each sample
points in each DOG image independently(that is, to every position, only when the value in each DOG image of
the same octave is the maximum or minimum among it's eight neighbors of the same DOG image it is selected as
the initial key points) , I can find many more initial key points(more that 100). So I don't know why I get so
few key points with the original method metioned in Lowe's paper? Are there some mistakes made by myself? 

  Even I can not understand that why we can select initial key points from DOG images by the original method. In
my mind, the middle DOG image's intensity should lie between the upper and lower DOG images. So if we use the
value in the middle DOG image to compare with all its neighboring values( including the upper and the lower
DOG images) it is hard to get the maximum or minimum position.

  Can anyone give me some advice? Thanks very much.

Xianyong
Permalink | Reply | 1 comment |
headers
Sebastian Nowozin | 2 Mar 2004 04:27
Picon

Re: Please help me on SIFT detection by David Lowe's IJCV paper


Hi Fang,

On Tue, Mar 02, 2004 at 10:56:52AM +0800, Xianyong Fang wrote:

> I have implemented the SIFT detection algorithm of David Lowe's IJCF paper
> 'Distinctive Image Features from Scale-Invariant Keypoints', but why I can
> not find many initial keypoints(that is the peaks in DOG images). Even I find
> the initial keypoints do not always occur in the corners and edges.

Great to see different implementation, I am very curious about it :)

> According to my understanding, the resampled guassian image is used as the
> first scale image of the next octave, am I right? I build three DOG images in
> each octave (two DOG images have the same problem), but find that only few

The DoG generation is not explained in detail in Lowe's paper. He gives
specifics how to speed the process up, but I found it very generic about the
whole scale space processing. After some fiddling I got around what I think
Lowe meant: three DoG to search for peaks means you have to know 5 DoG maps and
search the middle three DoG's. That means you have to calculate 5+1 gaussian
blurred maps to build the DoGs, to build the differences.

>From ScaleSpace.cs of my implementation:
        // Generate DoG maps. The maps are organized like this:
	//    0: D(sigma)
       	//    1: D(k * sigma)
	//    2: D(k^2 * sigma) 
	//   ...
	//    s: D(k^s * sigma) = D(2 * sigma)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xianyong Fang | 2 Mar 2004 08:03
Picon
Favicon

Re: Re: Please help me on SIFT detection by David Lowe's IJCV paper

Hi Nowozin, 

  Thank you very much. This algorithm bores me for a long time. I feel relieved to some degree now. But still I
have some questions on your advice:

  1) How to build the next octave level's DOG images? I do not quite understand your words.

  2) To get the initial keypoints, do you mean that you compare each sample maps in the middle DOG image with all
26 
neighboring points as Lowe said?

  Please advice. Thanks again!

Xianyong

>
>Hi Fang,
>
>
>On Tue, Mar 02, 2004 at 10:56:52AM +0800, Xianyong Fang wrote:
>
>> I have implemented the SIFT detection algorithm of David Lowe's IJCF paper
>> 'Distinctive Image Features from Scale-Invariant Keypoints', but why I can
>> not find many initial keypoints(that is the peaks in DOG images). Even I find
>> the initial keypoints do not always occur in the corners and edges.
>
>Great to see different implementation, I am very curious about it :)
>
>> According to my understanding, the resampled guassian image is used as the
>> first scale image of the next octave, am I right? I build three DOG images in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gergely Kontra | 2 Mar 2004 17:18
Picon

Feature Request: Thumbnail cache

Hi!

While working big panoramas, it will be great, if the hugin project file
can load quickly. I must edit the same project, and every time I must
wait, while hugin resizes all the images. How about caching the
thumbnails?

Gergo
--

-- 
+-[ Kontra, Gergely<kgergely <at> mcl.hu> PhD student Room IB113 ]---------+
| http://www.mcl.hu/~kgergely            "Olyan langesz vagyok, hogy  |
| Mobil:(+36 20) 356 9656 ICQ: 175564914   poroltoval kellene jarnom" |
+-- Magyar php mirror es magyar php dokumentacio: http://hu.php.net --+
Permalink | Reply | 1 comment |
headers
Marko Mäkelä | 2 Mar 2004 20:57
Picon
Picon

Re: Feature Request: Thumbnail cache

On Tue, Mar 02, 2004 at 05:18:02PM +0100, Gergely Kontra wrote:
> While working big panoramas, it will be great, if the hugin project file
> can load quickly. I must edit the same project, and every time I must
> wait, while hugin resizes all the images. How about caching the
> thumbnails?

Or how about embedding thumbnails in the files, or making use of existing
thumbnails?  There are two common variants of JPEG files: JFIF (JPEG File
Interchange Format, implemented by IJG's libjpeg) and EXIF (Exchangeable
Image File, used by digital cameras).  Both image formats allow embedding
of thumbnail images.  As far as I know, thumbnails can also be embedded
in other major bitmap file formats.

For what it is worth, I've written a tool, jpegnail, for embedding or removing
thumbnails in JFIF and EXIF images.  The tool is part of a bigger suite,
pHoToMoLo, which I wrote in order to make browseable JPEG image galleries
featuring multiple thumbnail resolutions and static HTML.  The software is
available at http://www.funet.fi/pub/sci/graphics/packages/photomolo/.  You
can see from it how embedded JPEG thumbnails can be extracted from EXIF and
JFIF files.

I've been told that the Mac OS X file manager (Finder) makes use of EXIF
thumbnails but not JFIF.  Last when I looked, Nautilus (the file manager
of GNOME) didn't make use of embedded thumbnails, and neither does GIMP 1.x.

I don't know why this is so; were the thumbnail embedded in the main image
file, you wouldn't be left with "stray" thumbnail files when you delete the
original.  One of the main argument against embedded thumbnails is that they
consume space.  But I think that a separately stored thumbnail file will often
occupy more disk sectors.  Besides, the default 160×120 EXIF thumbnails occupy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xianyong Fang | 3 Mar 2004 14:02
Picon
Favicon

More questions on autopano-sift

Hi Sebastian,

  Thank you very much for your autopano-sift package. After analysis it, I finally understand the ideas in
Lowe's paper. 

  Still I have some more questions. It seems to me that your package just treat all the images that can fully
stitched into one panorama or wide angle image. In your package, you don't consider how to remove false
image matches as Brown's paper discussed.In Brown's paper, he used a probabilistic model to verify the
homography recovered by ransac method. But in your implementation, after getting the matched match
feature pairs, you just send the result into hugin without image match verification. Am I right? If I am
right, do you know any existing implementation that can realize homography verification? I am lazy,and
don't want to code it even,*_*  

  Thank you very much in advance.	

Xianyong
Permalink | Reply | 1 comment |
headers
alexandre jenny | 3 Mar 2004 14:17

RE : More questions on autopano-sift


Let's respond to that ... Even I'm not sebastian.

Yes, you're right, there's no key pairs verification systems like a ransac
or hough transform.
In my own version of autopano, I used a ransac approach to get rid of the
false pair of points
founded beetween 2 pictures. After that you can use the same statistical
approach as brown
to see if there is a probability of more than 97% match by using ni > 5.9f *
0.22*nf, (ni, ransac
inlers, and nf ransac outlers). So you have criterion to check if pictures
matches.
The next stage is to regroup by panorama and have a small Levenberg
Marquardt algorithm to
recalculate yaw, pitch, roll to get a really good estimation of picture's
position.

My source of inspiration were the ltilib, if you want to look into
algorithms.

I will release my full version of autopano soon.

Bye
   Alexandre

> -----Message d'origine-----
> De : ptx-bounces <at> email-lists.org 
> [mailto:ptx-bounces <at> email-lists.org] De la part de Xianyong Fang
> Envoyé : mercredi 3 mars 2004 14:03
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xianyong Fang | 3 Mar 2004 15:00
Picon
Favicon

Re: RE : More questions on autopano-sift

  Thank Alexandre. Great! I wish that your full version can be released very soon, ^_^. 

  You mean that there is a ransac algorithm in the ltilib? If that, where can I find it?

Xianyong

========================

>Let's respond to that ... Even I'm not sebastian.
>
>Yes, you're right, there's no key pairs verification systems like a ransac
>or hough transform.
>In my own version of autopano, I used a ransac approach to get rid of the
>false pair of points
>founded beetween 2 pictures. After that you can use the same statistical
>approach as brown
>to see if there is a probability of more than 97% match by using ni > 5.9f *
>0.22*nf, (ni, ransac
>inlers, and nf ransac outlers). So you have criterion to check if pictures
>matches.
>The next stage is to regroup by panorama and have a small Levenberg
>Marquardt algorithm to
>recalculate yaw, pitch, roll to get a really good estimation of picture's
>position.
>
>My source of inspiration were the ltilib, if you want to look into
>algorithms.
>
>I will release my full version of autopano soon.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luca Vascon | 3 Mar 2004 19:59
Picon
Favicon

IPIX PATENTS revoked in EU?


>From a friend who is in another panoramacamera list
that asked me to share with everybody else is interested.

PS
Check his website!!!
;-)

*-*-*-*-*-------------------------------------------------

Hello friends,

the EU-parliament will maybe revoke the IPIX base patent in Europe.

For further details please have a look at the
document of 307 pages which could be seen here:
http://ofi.epoline.org/view/GetDossier?lang=EN
when you choose the document number: 99118032 (!)
enjoy!

There you could see every single detail from 1999-09-21 until now 2004-02-10.
Please have a special look at the second document from 2004-02-02
with 5 pages in PDF.

You could also download the all 307 Pages
in a PDF-File with about 13.5MB for further studies.

a marvelous new day is here .. let's take this new one and enjoy it to the
maximum ..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Nowozin | 5 Mar 2004 12:15
Picon

RFC: "tube-panorama"


Hi *,

my brother and me travelled some interesting road in Shanghai, that would make
a very nice picture as very long linear picture. Like photographing each side
of the road, complete as one very long picture. We thought and discussed a bit
about it and then end up at a different kind of panorama image, we called
"tube".

Here is some food for thought and questions how doable such kind of panorama
is... please discuss/reject/approve it freely :)

Three-dimensional "tube-panorama"

The idea is this: Instead of having a single point around which a sphere with
image information is constructed, one could have a "line", around which a
"tube" is constructed. The ends of the tube are half spheres. So, with a
viewer programm, one could do the usual viewing operations, plus travel on
this "line" forth and back.

The idea sounds neat, but there are some problems there. (obviously not
complete)

1. Recording the pictures

The ideal recording would be a 1-pixel 360 degree CCD slid at equal speed over
this line, recording all information. The 1-pixel lines are then used to form
the tube. This is the ideal world without any parallax effects, in reality
this has to be simulated through taking many pictures (maybe a video?). With
many objects in different depth there will be unavoidable parallax effects,
(Continue reading)

Permalink | Reply | 2 comments |

Gmane