Perimeter coords and pixel values

[BenTupper]

Hi,

I *really* like the new wand - thank you!

However, I am needing some clarification about what the Wand (in  
ImageJ version 1.43b)  is finding.   What muddles me is that  
coordinates of the outline found do not appear to be the coordinates.  
In the example macro below I show that the coordinates of the outline  
may extend "beyond" the pixel coordinates of the blob.  From the  
language I see in the source code I think the reported coordinates  
will completely enclose the blob - including the width of the pixels.  
I am OK with that as I can come up with an alternative if I really  
want the coordinates of the pixels along the perimeter, but I want to  
be sure I understand what Wand is doing before I turn off the path so  
to speak.

//Start the macro
newImage("test", "8-bit Black", 100, 100, 1);
run("Specify...", "width=50 height=50 x=25 y=25");
run("Draw");
setTool(13);
setForegroundColor(255, 255, 255);
makeRectangle(25, 25, 50, 50);
floodFill(26,26);
doWand(25,25);
getSelectionCoordinates(x,y);
print("perimeter and pixel values");
print("x, y, value");
for (i =0; i< x.length; i++){
        print(x[i],y[i], getPixel(x[i], y[i]));
}
//End the macro

Here's the output I get...

perimeter and pixel values
x, y, value
75 75 0
25 75 0
25 25 255
75 25 0

The 0s are from the right and bottom edges just beyond the blob while  
the 255 indicates a pixel within the blob.

Thanks!
Ben


Ben Tupper

[Michael Schmid]

Hi Ben,

your macro result is ok.

To explain it, let me take an example:

If you want to trace the outline of one 'foreground' pixel at (x, y)  
= (10,10) you obviously want to get a selection with side lengths of 1.
One option would be to have fractional coordinates for the selection,  
so that pixel would be enclosed by a rectangle spanned by the points  
(9.5, 9.5) and (10.5, 10.5).

ImageJ uses integer coordinates for the selection, so the upper left  
corner (9.5, 9.5) is rounded up and becomes (10, 10), the lower right  
corner becomes (11, 11).

The same convention is used for all ROIs, including the (old and new)  
Wand. E.g., when selecting a rectangle with upper left coordinate  
(10, 10) and width=1,height=1 it encloses exactly one pixel, the one  
at (10,10).
Also in your example, you will note that getSelectionCoordinates  
returns exactly the coordinates that you have specified by  
makeRectangle.

By the way, also the yellow selection outlines follow the same  
convention, so the outline displayed is inside the selected rectangle  
at the upper left corner, but outside the rectangle at the lower  
right corner (in contrast to some other programs; e.g. Photoshop  
draws the 'marching ants' selection outline always inside the  
selection).

If you want to address only the inside pixels (or only the outside  
ones), you can rely on the new Wand (except in 'Legacy' mode with  
tolerance = 0) always passing around the selection in clockwise  
direction. Thus, for each vector between two successive points of  
getSelectionCoordinates, the inside pixels are to the right, the  
outside pixels to the left when looking in the direction of the vector.

For more information, you can also have a look at the "ascii  
graphics" in the comments in the Wand.traceEdge method:
   http://rsb.info.nih.gov/ij/source/ij/gui/Wand.java

Confusing?

Michael
________________________________________________________________

On 29 Jun 2009, at 19:33, Ben Tupper wrote:

> Hi,
>
> I *really* like the new wand - thank you!
>
> However, I am needing some clarification about what the Wand (in  
> ImageJ version 1.43b)  is finding.   What muddles me is that  
> coordinates of the outline found do not appear to be the  
> coordinates.  In the example macro below I show that the  
> coordinates of the outline may extend "beyond" the pixel  
> coordinates of the blob.  From the language I see in the source  
> code I think the reported coordinates will completely enclose the  
> blob - including the width of the pixels.  I am OK with that as I  
> can come up with an alternative if I really want the coordinates of  
> the pixels along the perimeter, but I want to be sure I understand  
> what Wand is doing before I turn off the path so to speak.
>
> //Start the macro
> newImage("test", "8-bit Black", 100, 100, 1);
> run("Specify...", "width=50 height=50 x=25 y=25");
> run("Draw");
> setTool(13);
> setForegroundColor(255, 255, 255);
> makeRectangle(25, 25, 50, 50);
> floodFill(26,26);
> doWand(25,25);
> getSelectionCoordinates(x,y);
> print("perimeter and pixel values");
> print("x, y, value");
> for (i =0; i< x.length; i++){
> print(x[i],y[i], getPixel(x[i], y[i]));
> }
> //End the macro
>
> Here's the output I get...
>
> perimeter and pixel values
> x, y, value
> 75 75 0
> 25 75 0
> 25 25 255
> 75 25 0
>
> The 0s are from the right and bottom edges just beyond the blob  
> while the 255 indicates a pixel within the blob.
>
> Thanks!
> Ben
>
>
> Ben Tupper

[Gabriel Landini]

On Tuesday 30 June 2009  10:05:39 Michael Schmid wrote:
> The same convention is used for all ROIs, including the (old and new)  
> Wand. E.g., when selecting a rectangle with upper left coordinate  
> (10, 10) and width=1,height=1 it encloses exactly one pixel, the one  
> at (10,10).

Yet, if one chooses to draw (press "D") the polygon created *by the wand*, it
draws pixels outside the selection (right and lower border) (but the same
*rectangular selection* does not)

I have got used to this so I am not asking for a solution, but treating pixels
as 'points' for some selections and as 'areas' for wand-selections is
extremely confusing.

Cheers

Gabriel

[Michael Schmid]

Hi Gabriel,

ok, I see the problem, but is this only an inconsistency in the  
"Draw" command (where it seems to me that the rectangular ROI is the  
only one that does not draw all lines to the bottom right) or does it  
occur somewhere else as well?

The "Draw" problem is one of ImageProcessor.drawRect vs.  
ImageProcessor.drawPoygon.
By the way, with line width > 1, "Draw" behaves consistently for  
rectangular and other rois: for even line width, the line drawn is  
symmetric around the border, for odd line widths the line centers are  
displaced by 1/2 pixel towards bottom right also for rectangles.


Michael
________________________________________________________________

On 30 Jun 2009, at 11:26, Gabriel Landini wrote:

> On Tuesday 30 June 2009  10:05:39 Michael Schmid wrote:
>> The same convention is used for all ROIs, including the (old and new)
>> Wand. E.g., when selecting a rectangle with upper left coordinate
>> (10, 10) and width=1,height=1 it encloses exactly one pixel, the one
>> at (10,10).
>
> Yet, if one chooses to draw (press "D") the polygon created *by the  
> wand*, it
> draws pixels outside the selection (right and lower border) (but  
> the same
> *rectangular selection* does not)
>
> I have got used to this so I am not asking for a solution, but  
> treating pixels
> as 'points' for some selections and as 'areas' for wand-selections is
> extremely confusing.
>
> Cheers
>
> Gabriel

[Gabriel Landini]

On Tuesday 30 June 2009  11:31:59 Michael Schmid wrote:
> ok, I see the problem, but is this only an inconsistency in the  
> "Draw" command (where it seems to me that the rectangular ROI is the  
> only one that does not draw all lines to the bottom right) or does it  
> occur somewhere else as well?

Thanks Michael for the follow up. Not sure whether this happens elsewhere. As
I said, I am not asking for a solution. Knowing that this is so in IJ is
enough to avoid unexpected results. I was just pointing out that a wand-
created regions (and the other polygonal selections) have a "drawn" outline
which is larger than the "filled" region for certain pixel locations, except
for the rectangle selection (with width=1, as you shown) that is inside the
filled region.

If I had to do this from scratch, I would locate the polygons at the 'centre'
of pixels,  yet some users would (rightly!) complain that it makes it look as
if there were half-pixels outside the ROIs. Yet I think such solution would be
consistent for all regions and their drawn outlines.

> By the way, with line width > 1, "Draw" behaves consistently for  
> rectangular and other rois: for even line width, the line drawn is  
> symmetric around the border, for odd line widths the line centers are  
> displaced by 1/2 pixel towards bottom right also for rectangles.

I guess that a partial solution would be to make the rectangle selection of
width 1 to draw like all other polygons, but this would cause 2 further
problems:
1) selecting one single pixel with the current overlay placement would draw 4,
so that would need to be resolved,
2) drawing the largest rectangle of an image, would draw the right and bottom
borders outside it.

Cheers,

Gabriel

[dscho]

Hi Gabriel,

On Tue, 30 Jun 2009, Gabriel Landini wrote:

> On Tuesday 30 June 2009  11:31:59 Michael Schmid wrote:
> > ok, I see the problem, but is this only an inconsistency in the "Draw"
> > command (where it seems to me that the rectangular ROI is the only one
> > that does not draw all lines to the bottom right) or does it occur
> > somewhere else as well?
>
> Thanks Michael for the follow up. Not sure whether this happens
> elsewhere. As I said, I am not asking for a solution. Knowing that this
> is so in IJ is enough to avoid unexpected results.

It is even worse: if you create a selection from a thresholded image, the
pixels are treated as coordinates, as the ROI wants a GeneralPath.

As you know, the ThresholdToSelection tool is part of ImageJ since short
after the first conference (where somebody gave me the idea to write it).  
Now, the bigger problem is that it is not defined _explicitely_ in ImageJ
how a selection tool should behave.

I wonder what the old Wand did.

Ciao,
Dscho

[BenTupper]

Hi Michael,

On Jun 30, 2009, at 4:26 AM, Michael Schmid wrote:

> Hi Ben,
>
> your macro result is ok.
>
> To explain it, let me take an example:
>
> If you want to trace the outline of one 'foreground' pixel at (x, y)  
> = (10,10) you obviously want to get a selection with side lengths of  
> 1.
> One option would be to have fractional coordinates for the  
> selection, so that pixel would be enclosed by a rectangle spanned by  
> the points (9.5, 9.5) and (10.5, 10.5).
>
> ImageJ uses integer coordinates for the selection, so the upper left  
> corner (9.5, 9.5) is rounded up and becomes (10, 10), the lower  
> right corner becomes (11, 11).
>
> The same convention is used for all ROIs, including the (old and  
> new) Wand. E.g., when selecting a rectangle with upper left  
> coordinate (10, 10) and width=1,height=1 it encloses exactly one  
> pixel, the one at (10,10).
> Also in your example, you will note that getSelectionCoordinates  
> returns exactly the coordinates that you have specified by  
> makeRectangle.
>
> By the way, also the yellow selection outlines follow the same  
> convention, so the outline displayed is inside the selected  
> rectangle at the upper left corner, but outside the rectangle at the  
> lower right corner (in contrast to some other programs; e.g.  
> Photoshop draws the 'marching ants' selection outline always inside  
> the selection).
>
> If you want to address only the inside pixels (or only the outside  
> ones), you can rely on the new Wand (except in 'Legacy' mode with  
> tolerance = 0) always passing around the selection in clockwise  
> direction. Thus, for each vector between two successive points of  
> getSelectionCoordinates, the inside pixels are to the right, the  
> outside pixels to the left when looking in the direction of the  
> vector.
>
> For more information, you can also have a look at the "ascii  
> graphics" in the comments in the Wand.traceEdge method:
>  http://rsb.info.nih.gov/ij/source/ij/gui/Wand.java
>
> Confusing?

Not now.

This is a great description of how it works. I think the above should  
be captured, along with your subsequent discussion with Gabriel, and  
posted it on the DocuWiki - perhaps separate from http://tinyurl.com/mpksfx 
.   I could take a stab at it later this week, but it would be great  
if you and others could review it.

Thanks!
Ben

>
> Michael
> ________________________________________________________________
>
> On 29 Jun 2009, at 19:33, Ben Tupper wrote:
>
>> Hi,
>>
>> I *really* like the new wand - thank you!
>>
>> However, I am needing some clarification about what the Wand (in  
>> ImageJ version 1.43b)  is finding.   What muddles me is that  
>> coordinates of the outline found do not appear to be the  
>> coordinates.  In the example macro below I show that the  
>> coordinates of the outline may extend "beyond" the pixel  
>> coordinates of the blob.  From the language I see in the source  
>> code I think the reported coordinates will completely enclose the  
>> blob - including the width of the pixels.  I am OK with that as I  
>> can come up with an alternative if I really want the coordinates of  
>> the pixels along the perimeter, but I want to be sure I understand  
>> what Wand is doing before I turn off the path so to speak.
>>
>> //Start the macro
>> newImage("test", "8-bit Black", 100, 100, 1);
>> run("Specify...", "width=50 height=50 x=25 y=25");
>> run("Draw");
>> setTool(13);
>> setForegroundColor(255, 255, 255);
>> makeRectangle(25, 25, 50, 50);
>> floodFill(26,26);
>> doWand(25,25);
>> getSelectionCoordinates(x,y);
>> print("perimeter and pixel values");
>> print("x, y, value");
>> for (i =0; i< x.length; i++){
>> print(x[i],y[i], getPixel(x[i], y[i]));
>> }
>> //End the macro
>>
>> Here's the output I get...
>>
>> perimeter and pixel values
>> x, y, value
>> 75 75 0
>> 25 75 0
>> 25 25 255
>> 75 25 0
>>
>> The 0s are from the right and bottom edges just beyond the blob  
>> while the 255 indicates a pixel within the blob.
>>
>> Thanks!
>> Ben
>>
>>
>> Ben Tupper

Ben Tupper

[Michael Schmid]

Hi Dscho,

don't worry, the convention how the Wand treats the pixels did not  
change. (and it does not depend on whether it works on a thresholded  
image or not.)
Also, if you create a rectangle, fill it, threshold it and create a  
selection from it, getSelectionCoordinates will deliver the expected  
corner points, again using the same convention.

So I still don't see any inconsistency besides the 'Draw' command for  
rectangles with line width=1.

BTW, I have added a remark on the 'Draw' problem to the gui  
documentation on the wiki
   http://imagejdocu.tudor.lu/doku.php?id=gui:edit:draw


Michael
________________________________________________________________

On 30 Jun 2009, at 14:38, Johannes Schindelin wrote:

> Hi Gabriel,
>
> On Tue, 30 Jun 2009, Gabriel Landini wrote:
>
>> On Tuesday 30 June 2009  11:31:59 Michael Schmid wrote:
>>> ok, I see the problem, but is this only an inconsistency in the  
>>> "Draw"
>>> command (where it seems to me that the rectangular ROI is the  
>>> only one
>>> that does not draw all lines to the bottom right) or does it occur
>>> somewhere else as well?
>>
>> Thanks Michael for the follow up. Not sure whether this happens
>> elsewhere. As I said, I am not asking for a solution. Knowing that  
>> this
>> is so in IJ is enough to avoid unexpected results.
>
> It is even worse: if you create a selection from a thresholded  
> image, the
> pixels are treated as coordinates, as the ROI wants a GeneralPath.
>
> As you know, the ThresholdToSelection tool is part of ImageJ since  
> short
> after the first conference (where somebody gave me the idea to  
> write it).
> Now, the bigger problem is that it is not defined _explicitely_ in  
> ImageJ
> how a selection tool should behave.
>
> I wonder what the old Wand did.
>
> Ciao,
> Dscho