crop-and-search in Fire

[Weng Chaoqun]

Dear Fire Group members,

I am wondering how to implement the crop-and-search in the following demo.

http://thomas.deselaers.de/fire/

I think it should use some javascripts (maybe jQuery). But I do not see any javascripts in the Fire 2.3 source codes.

Cropping the image is no problem to me. The Jcrop is a good choice to crop the image. 

http://deepliquid.com/projects/Jcrop/demos.php

But my problem is, how to search similar images given the cropped image patch. 

[1] Just upload the image patch and extract features and then search like a new file?  If I want to search small logos in the image database, this may not be a good method. 

[2] Or maybe using local features can handle this?

[3] And can Fire do Localized Content Based Image Retrieval? How can I localize the queried logo in the returned images?

Any suggestions? Thanks in advance!

Best regards,

Weng

[Thomas Deselaers]

On Thu, Apr 26, 2012 at 15:24, Weng Chaoqun <wen...@gmail.com> wrote:

Dear Fire Group members,

I am wondering how to implement the crop-and-search in the following demo.

http://thomas.deselaers.de/fire/

I think it should use some javascripts (maybe jQuery). But I do not see any javascripts in the Fire 2.3 source codes.

Cropping the image is no problem to me. The Jcrop is a good choice to crop the image. 

http://deepliquid.com/projects/Jcrop/demos.php

But my problem is, how to search similar images given the cropped image patch. 

[1] Just upload the image patch and extract features and then search like a new file?  If I want to search small logos in the image database, this may not be a good method. 

But this is how the people from the DFKI have done it. 

http://www.youtube.com/watch?v=2eaGwk4Xhks&feature=player_embedded

I myself never have done it.

 

[2] Or maybe using local features can handle this?

[3] And can Fire do Localized Content Based Image Retrieval? How can I localize the queried logo in the returned images?

[2] and [3] would be possible but neither is implemented in FIRE.

Cheers, thomas 

[Weng Chaoqun]

Dear  Thomas,

Thanks for the quick reply. And I have got some more questions about Fire here. 

[1] Fire is designed for comparing different image features and different distance measurement, but not for efficient image search. Right?

[2] So the indexing techniques such as inverted file index, Locality Sensitive Hashing are not implemented in Fire?

[3] What do you think if someone is trying to add the indexing techniques to speed the search? What are the main files that need to be modified?

[4] And I see that each image feature vector is stored in a single file.  When the images number is huge, say 10,0000, will these 10,000 small files cause I/O inefficiency?

Thanks!

Best,

Weng

--
You received this message because you are subscribed to the Google Groups "FIRE - Flexible Image Retrieval Engine" group.
To post to this group, send email to fire...@googlegroups.com.
To unsubscribe from this group, send email to fire-cbir+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fire-cbir?hl=en.

[Thomas Deselaers]

On Thu, Apr 26, 2012 at 16:53, Weng Chaoqun <wen...@gmail.com> wrote:

Dear  Thomas,

Thanks for the quick reply. And I have got some more questions about Fire here. 

[1] Fire is designed for comparing different image features and different distance measurement, but not for efficient image search. Right?

Yes.

 

[2] So the indexing techniques such as inverted file index, Locality Sensitive Hashing are not implemented in Fire?

Right. Neither is implemented. And for some features it's unlikely to be feasible.

 

[3] What do you think if someone is trying to add the indexing techniques to speed the search? What are the main files that need to be modified?

I would be very happy. It would probably have to change quite a bit of the retriever, starting from fire.cpp.

 

[4] And I see that each image feature vector is stored in a single file.  When the images number is huge, say 10,0000, will these 10,000 small files cause I/O inefficiency?

Yes it does. There are some means of converting the indivdual files into one large file (per descriptor). This is a lot faster at startup. 

Best,

t.

--
http://thomas.deselaers.de

[Weng Chaoqun]

OK. Thanks very much.

Best,

Weng