Not exactly sure how one would put context of what object is more dominant
than other.
Think of landscape with snow, green mountains and set of flowers of varied
colors including a rose
On Fri, Sep 17, 2010 at 8:43 PM, Shashi Kant sk...@sloan.mit.edu wrote:
What I am envisioning (at
Subject: Re: Color search for images
To: solr-user@lucene.apache.org
Date: Thursday, September 16, 2010, 7:58 PM
On 9/16/2010 7:45 AM, Shashi Kant
wrote:
Lire is a nascent effort and based on a cursory
overview a while back,
IMHO was an over-simplified version of what a CBIR
engine should
What I am envisioning (at least to start) is have all this add two fields in
the index. One would be for color information for the color similarity
search. The other would be a simple multivalued text field that we put
keywords into based on what OpenCV can detect about the image. If it
do you mean content based image retrieval or just search images by tag?
if the former, you can try LIRE
2010/9/15 Shawn Heisey s...@elyograg.org:
My index consists of metadata for a collection of 45 million objects, most
of which are digital images. The executives have fallen in love with
Yes, notice the flowers are all a medium-dark crimson red. There are a
bunch of these image-indexing search technologies, but there is no (to
my knowledge) finished technology- it's very much an area of research.
If you want to search the word 'flower' and index data that can find
blobs of
On 9/15/2010 10:50 AM, Shashi Kant wrote:
Shawn, I have done some research into this, machine-vision especially
on a large scale is a hard problem, not to be entered into lightly. I
would recommend starting with OpenCV - a comprehensive toolkit for
extracting various features such as Color,
Lire looks promising, but how hard is it to integrate the content-based
search into Solr as opposed to Lucene? I myself am not a Java developer. I
have access to people who are, but their time is scarce.
Lire is a nascent effort and based on a cursory overview a while back,
IMHO was an
EARTH has a Right To Life,
otherwise we all die.
Read 'Hot, Flat, and Crowded'
Laugh at http://www.yert.com/film.php
--- On Wed, 9/15/10, Shashi Kant sk...@sloan.mit.edu wrote:
From: Shashi Kant sk...@sloan.mit.edu
Subject: Re: Color search for images
To: solr-user@lucene.apache.org
:
From: Shashi Kant sk...@sloan.mit.edu
Subject: Re: Color search for images
To: solr-user@lucene.apache.org
Date: Thursday, September 16, 2010, 6:36 AM
On Thu, Sep 16, 2010 at 3:21 AM,
Lance Norskog goks...@gmail.com
wrote:
Yes, notice the flowers are all a medium-dark crimson
red
On 9/16/2010 7:45 AM, Shashi Kant wrote:
Lire is a nascent effort and based on a cursory overview a while back,
IMHO was an over-simplified version of what a CBIR engine should be.
They use CEDD (color edge descriptors).
Wouldn't work for the kind of applications I am working on - which
needs
On Sep 15, 2010, at 7:59am, Shawn Heisey wrote:
My index consists of metadata for a collection of 45 million
objects, most of which are digital images. The executives have
fallen in love with Google's color image search. Here's a search
for flower with a red color filter:
Shawn, I have done some research into this, machine-vision especially
on a large scale is a hard problem, not to be entered into lightly. I
would recommend starting with OpenCV - a comprehensive toolkit for
extracting various features such as Color, Edge etc from images. Also
there is a project
On a related note, I'm curious if anyone has run across a good set of
algorithms (or hopefully a library) for doing naive image
classification. I'm looking for something that can classify images
into something similar to the broad categories that Google image
search has (Face, Photo, Clip
'Hot, Flat, and Crowded'
Laugh at http://www.yert.com/film.php
--- On Wed, 9/15/10, Ken Krugler kkrugler_li...@transpac.com wrote:
From: Ken Krugler kkrugler_li...@transpac.com
Subject: Re: Color search for images
To: solr-user@lucene.apache.org
Date: Wednesday, September 15, 2010, 9:41 AM
I'm sure there's some post doctoral types who could get a graphic shape
analyzer, color analyzer, to at least say it's a flower.
However, even Google would have to build new datacenters to have the
horsepower to do that kind of graphic processing.
Not necessarily true. Like.com - which
can you you explain exactly how you are indexing the data and what your
query looks like?
I used the same field name (color), not 10 different names (c0 - c9).
So the index fields look like (50% #00, 20% #99):
color: #00
color: #00
color: #00
color: #00
color: #00
: I used the same field name (color), not 10 different names (c0 - c9).
ah .. got it. then what you are probably seeing is because of length
normalization, if you use omitNorms=true then it shouldn't matter.
(i don't know why i suggested a seperate field for each 10% block ... i'm
sure i had
Hi Guangwei,
When you index your products, you could have a single color field, and
include duplicates of each color component proportional to its weight.
For example, if you decide to use 10% increments, for your black dress
with 70% of black, 20% of gray, 10% of brown, you would index the
Another option would be to extend Solr (and donate back) to
incorporate Lucene's payload functionality, in which case you could
associate the percentile of the color as a payload and use the
BoostingTermQuery... :-) If you're interested in this, a discussion
on solr-dev is probably
If it were just a couple of colors, you could have a separate field
for each color and then index the percent in that field.
black:70
grey:20
and then you could use a function query to influence the score (or you
could sort by the color percent).
However, this doesn't scale well to a large
, September 28, 2007 7:14 AM
To: solr-user@lucene.apache.org
Subject: Re: Color search
Hi Guangwei,
When you index your products, you could have a single color field, and
include duplicates of each color component proportional to its weight.
For example, if you decide to use 10% increments, for your black
PROTECTED]
Sent: Friday, September 28, 2007 7:14 AM
To: solr-user@lucene.apache.org
Subject: Re: Color search
Hi Guangwei,
When you index your products, you could have a single color field, and
include duplicates of each color component proportional to its weight.
For example, if you decide
This discussion is incredibly interesting to me! We solved this
simply by indexing the color names, and faceting on that. Not a very
elegant solution, to be sure - but it works. If people search for a
green running shoe they get -green- running shoes.
I would be very very interested in
: useful to search products by color. A product image can have up to 5 colors
: (from a color space of about 100 colors), so we can implement it easily with
: Solr's facet search (thanks all who've developed Solr).
:
: The problem arises when we try to sort the results by the color relevancy.
:
On 28-Sep-07, at 6:31 AM, Grant Ingersoll wrote:
Another option would be to extend Solr (and donate back) to
incorporate Lucene's payload functionality, in which case you could
associate the percentile of the color as a payload and use the
BoostingTermQuery... :-) If you're interested in
Thanks for all the replies. I think creating 10 fields and feeding each
field with a color's value for 10% from that color is a reasonable approach,
and easy to implement too. One problem though, is that not all products have
a total of 100% colors (due to various reasons including our color
26 matches
Mail list logo
