Login  Register

Re: Ideas for Algorithm

Posted by jadrake75 on Jul 30, 2011; 7:20pm
URL: http://imagej.273.s1.nabble.com/Ideas-for-Algorithm-tp3683675p3683677.html

Thanks to everyone who provided feedback on the ideas.

Using David's result below actually worked like a charm.  I need to go back
and try some of the previous suggestions based on what I know now but this
really worked for me - I realize I was using "fill holes" incorrectly.  I
now realize fill holes means "fill the areas within a bounding region" and
not fill the edge holes (ie. the perforations - heh I am a stamp guy!).
When I was running it was I doing an inverse bit mask (such that white
became black and black become white) so when I ran fill holes... I got a
black page!  I have figured it out now.

This looks like it will provide me with pretty close bounding boxes (with
the exception of the skinny/abnomolies) which as suggested I should be able
to remove from the result set by simply checking the area exceeds 10000+.
Actually I found that when using the  Analyze Particles, if I set the size^2
of 10000 to infinity this gets rid of all the small boundings (based on my
scan sizes it is unlikely I'll ever scan a stamp less thant 10K sq pixels).

Now it is just a matter of plugging in this via the APIs of the library
(duplicating the manual user-interface actions).  I can then extract the
remaining bounding boxes add a padding (~ 10-15 pixels around) and display
them in my user interface to allow me to make any small "tweaks"

I may have API questions if I get bogged down, but given my Java
experience/expertise this shouldn't be an issue.  For me it was the theory
and transformations I was not familiar with.  Web devleopment,
user-interfaces, encoding or databases -- not a problem.

Cheers

-Jason



-Jason




On Sat, Jul 30, 2011 at 12:36 AM, David Webster <[hidden email]>wrote:

> jason,
>
> I thgink you can what you want using existing ImageJ menu function and a
> macro without doing any pixel crunching algorithm development yourself.
>
> You may/will need to furthur preprocess your image by using
> Process/Binary/Make Binary and Process/Binary/Fill Holes. This converts the
> stamps to a bunch of solid white rectangular objects (or Particles).
>
> Then, do Analyze/Set Measurements and select Area, Bounding Box. and I
> think
> Shape Descriptors (this will get aspect ratio).
>
> Now run Analyze/Analyze Particles. You will get the selected properties
> including the Bounding Box spec in a Results Table. You may want to write
> some macro code to eliminate objects that are to small (area) or to
> "skinny"
> (aspect ratio). This can be done using built in macro functions to get
> Column/row data from the table and to delete rows as needed.
>
>
> David Webster
>
> On Fri, Jul 29, 2011 at 3:14 PM, Jason Drake <[hidden email]> wrote:
>
> > Hi .... I am writing (or rather have substantially written) a program in
> > Java to take a scanned page of stamps and attempt to create subimages of
> > the
> > stamps (and allow me to quickly save them in certain directories with
> > particular names).
> >
> > I am struggling a little bit to come up with the right algorithm to "box
> > off" the stamp images that I need to crop.  I just need the rectangular
> > bounding boxes so I can present these in my interface, make any changes
> and
> > proceed in the application to burst them into subimages.
> >
> > An example image is here (warning it is a 50Mb image):
> > http://stamps.drakeserver.com/scan005.jpg
> >
> > Though investigation I found ImageJ.  One thing I have managed to use
> > ImageJ
> > for is to convert the image to binary format (and filter with a
> threshold).
> > This gives me a working image (obviously my cropping will occur from the
> > original) that is easier to deal with.  I may also use their image object
> > instead of BufferedImages as these are memory hogs:
> >
> > Here is the filtered image: http://stamps.drakeserver.com/scan005-5.jpg
> >
> > My current algorthim is quite dum.... I start in the top left and proceed
> > on
> > a forty-five degree angle toward the bottom right.  As soon as a catch a
> > color change I mark it and attempt to achieve a 10 pixel threshold.  At
> > this
> > occurance, I will try and find the top left corner of a stamp, and
> > conversely attempt to find the lower right corner. Since they are in
> rows,
> > I
> > will move to the right and attempt the same thing for stamps to the right
> > (if I hit the edge I go to next row).  I keep track of the lowest "y"
> value
> > and use that for my next row.  The perforations make this tricky.  The
> > algorithm is only ~ 80% efficient and struggles when I come into gaps
> (ie.
> > stamps I have removed) I also can skip rows if there are not stamps in
> the
> > first couple slots on the left.....
> >
> > Another thought I had was to start top right and simply scan to the
> right.
> > As soon as I hit multiple "white" pixels (say 10) I start to determine if
> > there is an area under them (ie. it isn't simply a reflection line but
> > represents a stamp shape). I proceed down the rows until I hit matches.
> >
> > My background is engineering and computer science (but not graphics
> > focussed) so I am not particularly up-to-speed with algorithms for this
> > type
> > of thing.  I would welcome any input on how to computationally solve
> this.
> > It will drastically save me time in scannign and cataloguing my
> collection
> > (although I have to admit the time I have put into my program could've
> > better been used on my hobby and just use Gimp, but well..... the
> computer
> > scientist in me loves to tinker.
> >
> > -Jason
> >
>