imglib Eclipse project
Curtis Rueden
Recently I committed a simple "SquareTest.java" in a new "tests" folder that provides a very simple example of using imglib. Earlier today Stephan committed a package name change to this file, probably to make it compile in his Eclipse setup. However, the Eclipse project configuration in the imglib repository itself now no longer works properly with SquareTest. I would like to reconcile this difference somehow.
Stephan, the way the Eclipse project is setup in the repository is to use a "FIJI_HOME" variable that points to your checkout of Fiji itself. If you are working with imglib as a submodule, this may seem unnecessary, but if you have imglib checkout standalone, it is quite useful. This scheme allows us to declare dependencies as follows:
<classpathentry kind="var" path="FIJI_HOME/jars/mpicbg.jar"/>
<classpathentry kind="var" path="FIJI_HOME/jars/ij.jar"/>
<classpathentry kind="var" path="FIJI_HOME/plugins/loci_tools.jar"/>
<classpathentry kind="var" path="FIJI_HOME/jars/edu_mines_jtk.jar"/>
If you are willing to use this approach, you can just "File > Import > Existing project into workspace" to get the configuration working. Then define FIJI_HOME in Eclipse Preferences Java > Build Path > Classpath Variables.
If you don't like this approach, let's find an alternative. My long-term preference currently would be to use Maven to manage dependencies, and I can work on creating a "maven" branch of imglib if you would like to see this approach in action.
Any other ideas?
Thanks,
Curtis
Johannes Schindelin
On Mon, 12 Apr 2010, Curtis Rueden wrote:
> Recently I committed a simple "SquareTest.java" in a new "tests" folder
> that provides a very simple example of using imglib. Earlier today
> Stephan committed a package name change to this file, probably to make
> it compile in his Eclipse setup. However, the Eclipse project
> configuration in the imglib repository itself now no longer works
> properly with SquareTest. I would like to reconcile this difference
> somehow.
Aaargh!
I _knew_ that something like this would happen (but that does not benefit
me in _any_ way now, does it?). That's why I wanted someone who knows
Eclopse better than me to work on a Fiji Build -> .project exporter.
Oh well.
My current thinking is that whenever you check out a new submodule (or
whenever any Fakefile changes), you have to re-run the export.
Of course, there is no export yet, but I started cleaning up the directory
layout only to the end of getting such an exporter working. Just for you
Eclipse users.
Ciao,
Dscho
Stephan Saalfeld
repository because everybody's approach here is different (what e.g.
about run profiles?). How came it in---was it me?
Best,
Stephan
> --
> You received this message because you are subscribed to the Google
> Groups "Fiji-devel" group.
> To post to this group, send email to fiji-...@googlegroups.com.
> To unsubscribe from this group, send email to fiji-devel
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fiji-devel?hl=en.
Johannes Schindelin
On Mon, 12 Apr 2010, Stephan Saalfeld wrote:
> I would very much prefer to keep the eclipse project out of the
> repository because everybody's approach here is different (what e.g.
> about run profiles?). How came it in---was it me?
I think you misunderstand. The problem arose exactly because everybody has
a different approach.
Ciao,
Dscho
Stephan Saalfeld
or put in separately---got it. I would like to keep the directory
hierarchy reflect the package structure here or we agree on an exclude
pattern for now.
Best,
Stephan
Johannes Schindelin
On Mon, 12 Apr 2010, Stephan Saalfeld wrote:
> I see. So the test folder was explicitly excluded from the build path
> or put in separately---got it. I would like to keep the directory
> hierarchy reflect the package structure here or we agree on an exclude
> pattern for now.
Or we fix it properly and generate an Eclopse project from Fiji Build. Not
that hard to agree to that, is it?
Ciao,
Johannes
Gabriel Landini
A recent message to the IJ list made me wonder if the development of Imglib or
ImageJ2 implies necessarily using the same ROI classes as IJ.
If not, what do you think about positioning the ROI polygons on the centre of
pixels, instead of the top corner of pixels (or at least make it an option)?
Currently IJ has 2 distinct behaviours when defining, cutting, filling and
drawing ROIs.
Square ROIs when drawn behave different because they [i.e. the yellow polygon]
enclose all the pixels in them (the Magic Wand Tool seems to do the same).
However other drawn ROIs appear shifted right-down because the polygons are
placed on the upper left corner of pixels.
Confusingly, the same looking square ROIs drawn with the Rectangle Tool and
with the Polygon Tool are different sizes when the Draw command is applied,
yet the ROIs have the same area (!).
Similarly an object ROI captured with the magic wand, and re-drawn, grows in
size.
Moving the ROIs to the centre of pixels would make things a bit different but
I think more consistent in the long run.
The Draw and Fill commands would appear to work always OK.
The cutting of drawn ROI would not leave out some of the pixels of drawn
outlines.
1-pixel ROIs should be treated as point ROIs (they are really points).
Filled and drawn ROIs would appear half a pixel larger than the yellow
polygon, but will make it more explicit how the ROIs are defined and
processed.
Anyway, these are just suggestions,and would like to hear if anybody has any
comments on this issue.
Cheers
Gabriel
Curtis Rueden
The way I had it set up, only the mpicbg folder was included as a source folder from the root folder. The tests folder was added as a separate root source folder.
Personally, I prefer to have all the main Java code in a subdirectory called src or something like that, and then just point at that, and to have all the test code (not part of the JAR proper) in a folder called tests or something. Then both src and tests are set as root source folders, and all is well.
FYI, the way Maven does it by default, main source code goes under src/main/java, and source files for test go under src/test/java, which is a very flexible approach.
-Curtis
--
You received this message because you are subscribed to the Google Groups "Fiji-devel" group.
To post to this group, send email to fiji-...@googlegroups.com.
To unsubscribe from this group, send email to fiji-devel+...@googlegroups.com.
Daniel James White
I recently became aware that is was totally misunderstanding reality
when it comes to the issue you bring up regarding ROIs and pixels as
"little squares" that can have a top right or any other "corner"
position.
From the mouth of the great Alvy Ray:
http://alvyray.com/Memos/6_pixel.pdf
"
A Pixel Is Not A Little Square, A Pixel Is Not A Little Square, A
Pixel Is Not A Little Square! (And a Voxel is Not a Little Cube), Tech
Memo 6, Jul 17, 1995
ABSTRACT. My purpose here is to, once and for all, rid the world of
the misconception that a pixel is a little geometric square. This is
not a religious issue. This is an issue that strikes right at the root
of correct image (sprite) computing and the ability to correctly
integrate (converge) the discrete and the continuous. The little
square model is simply incorrect. It harms. It gets in the way. If you
find yourself thinking that a pixel is a little square, please read
this paper. I will have succeeded if you at least understand that you
are using the model and why it is permissible in your case to do so
(is it?).
Everything I say about little squares and pixels in the 2D case
applies equally well to little cubes and voxels in 3D. The
generalization is straightforward, so I won’t mention it from hereon.
I discuss why the little square model continues to dominate our
collective minds. I show why it is wrong in general. I show when it is
appropriate to use a little square in the context of a pixel. I
propose a discrete to continuous mapping—because this is where the
problem arises—that always works and does not assume too much.
I presented some of this argument in Tech Memo 5 but have encountered
a serious enough misuse of the little square model since I wrote that
paper to make me believe a full frontal attack is necessary.
"
On Apr 12, 2010, at 10:22 PM, Gabriel Landini wrote:
> Hi,
> A recent message to the IJ list made me wonder if the development of
> Imglib or
> ImageJ2 implies necessarily using the same ROI classes as IJ.
>
> If not, what do you think about positioning the ROI polygons on the
> centre of
> pixels, instead of the top corner of pixels (or at least make it an
> option)?
As far as my small brain can comprehend, it never makes sense to treat
pixels as anything other than "point" samples in space,
and so a pixels having a top left corner becomes a nonsense.
can anyone let me know a case where image pixels are little squares...
on a CCD detector they for sure are little squares....
but this is a different kettle of fish
and usually they are so small compared to the highest spatial
frequency in the image (the PSF is bigger than the pixel spacing)
that as far as the image is concerned each pixel behaved like a point
detector.
Maybe there are cases in photography etc where thats not true?
>
> Currently IJ has 2 distinct behaviours when defining, cutting,
> filling and
> drawing ROIs.
> Square ROIs when drawn behave different because they [i.e. the
> yellow polygon]
> enclose all the pixels in them (the Magic Wand Tool seems to do the
> same).
> However other drawn ROIs appear shifted right-down because the
> polygons are
> placed on the upper left corner of pixels.
I think that putting ROI handles on the imaginary corners of pixels is
plain wrong? Right?
> Confusingly, the same looking square ROIs drawn with the Rectangle
> Tool and
> with the Polygon Tool are different sizes when the Draw command is
> applied,
> yet the ROIs have the same area (!).
> Similarly an object ROI captured with the magic wand, and re-drawn,
> grows in
> size.
If you treat pixels only as point, that problem goes away right?
>
> Moving the ROIs to the centre of pixels would make things a bit
> different but
> I think more consistent in the long run.
> The Draw and Fill commands would appear to work always OK.
> The cutting of drawn ROI would not leave out some of the pixels of
> drawn
> outlines.
> 1-pixel ROIs should be treated as point ROIs (they are really points).
> Filled and drawn ROIs would appear half a pixel larger than the yellow
> polygon, but will make it more explicit how the ROIs are defined and
> processed.
I dont think you can really have half a pixel since you cant divide a
point in to two.
... but maybe I am being to closed minded here?
Is there any case we should accommodate where its useful to treat
pixels as little squares?
If i understand correctly the little square model leads to mistakes in
image interpolation and rescaling,
giving aliasing and other problems?
See it done right in the plugins-example-downsample script.
http://pacific.mpi-cbg.de/wiki/index.php/Downsample
ImageJ currently does the wrong thing here .... right?
There is every possibility that a CCD or CMOS or other detector could
have pixels arranged in a non square grid.
Could easily be hexagonal or whatever tessellating pattern, even with
2 different CCD pixels shapes/sizes...
I know such things already exist.... yet they output square grid
images, after some interpolation i guess... losing info in the process
i suppose.
Maybe imglib even needs to know about these non square grid cases and
even unstructured or sparse grids (like VTK does)?
If there is no reason to have the square pixel case in ImageJ2 then it
should be fully purged.
???
Dan
>
> Anyway, these are just suggestions,and would like to hear if anybody
> has any
> comments on this issue.
>
> Cheers
> Gabriel
>
> --
> You received this message because you are subscribed to the Google
> Groups "Fiji-devel" group.
> To post to this group, send email to fiji-...@googlegroups.com.
> To unsubscribe from this group, send email to fiji-devel+...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/fiji-devel?hl=en
> .
>
Dr. Daniel James White BSc. (Hons.) PhD
Senior Microscopist / Image Visualisation, Processing and Analysis
Light Microscopy and Image Processing Facilities
Max Planck Institute of Molecular Cell Biology and Genetics
Pfotenhauerstrasse 108
01307 DRESDEN
Germany
+49 (0)15114966933 (German Mobile)
+49 (0)351 210 2627 (Work phone at MPI-CBG)
+49 (0)351 210 1078 (Fax MPI-CBG LMF)
http://www.bioimagexd.net BioImageXD
http://pacific.mpi-cbg.de Fiji - is just ImageJ (Batteries Included)
http://www.chalkie.org.uk Dan's Homepages
https://ifn.mpi-cbg.de Dresden Imaging Facility Network
dan (at) chalkie.org.uk
( white (at) mpi-cbg.de )
Johannes Schindelin
On Tue, 13 Apr 2010, Daniel James White wrote:
> I recently became aware that is was totally misunderstanding reality
> when it comes to the issue you bring up regarding ROIs and pixels as
> "little squares" that can have a top right or any other "corner"
> position.
>
> From the mouth of the great Alvy Ray:
>
> http://alvyray.com/Memos/6_pixel.pdf
Thanks for the great link. I put it on the Wiki, on the Links page.
Ciao,
Dscho
Gabriel Landini
> As far as my small brain can comprehend, it never makes sense to treat
> pixels as anything other than "point" samples in space, and so a pixels
> having a top left corner becomes a nonsense.
You are right. However the corner here relates to the enlarged image of a
pixel (zoom in, the thickness of the yellow frame remains always 1).
> I think that putting ROI handles on the imaginary corners of pixels is
> plain wrong? Right?
Well, that is the way it is now in IJ. It would not make a difference really
if all the ROIs behaved the same, but in the examples I gave they do not.
A "Rectangular Tool ROI rectangle" and a "Polygon Tool ROI rectangle" of the
same size should be the same ROI. They are not. The Draw function seems to
behave differently depending which one is being used (example below).
> If you treat pixels only as point, that problem goes away right?
The point :-) is that the lattice on which the ROI polygons overlays are drawn
should (when enlarged) appear to be achored to the centre of pixels.
At the moment the ROIs treat the pixels as points, but the ROI polygons do
not.
> I dont think you can really have half a pixel since you cant divide a
> point in to two.
Of course, not in the image (unless you are talking interpolation), but a
zoomed image, if we implement what I am talking about, it would look like if
the pixels lock into pixels centres, not corners. However the drawn pixels
with the Draw command would always look underneath the ROI polygon (and not
outside like some of the ROIs). It would also be better defined what is the
filled ROI and the border ROI (the result of the Draw command).
> Is there any case we should accommodate where its useful to treat
> pixels as little squares?
Well, it depends. If you consider the areas of objects. That is why in
Particles8 I compute 2 types of areas: pixel counts and "area" (the area of
the polygon ROI). These are two different things.
> If i understand correctly the little square model leads to mistakes in
> image interpolation and rescaling, giving aliasing and other problems?
Well yes, it would, but this is not the problem I am raising and I do not
think IJ treats pixels as "areas" (except for the area of blobs :-) ). The
problem is the ROI position when zoomed and the consequence this has for Draw
and Fill commands for rectangular and non-rectangular ROIs.
Since a picture is worth a 1000 words (and a word is a millipicture :-) ), see
this example:
newImage("Test", "8-bit Black", 100, 100, 1);
run("Colors...", "foreground=white background=black selection=red");
run("In");
run("In");
run("In");
run("In");
run("In");
run("In");
run("In");
makeRectangle(20, 14, 1, 1);
run("Draw");
wait(1000);
makePolygon(22,14,23,14,23,15,22,15);
run("Draw");
Regards to all,
Gabriel
Stephan Preibisch
maybe we could go a 2-way strategy here, having discrete and continuous
ROIs?
Discrete ROIS could define which pixels are inside the ROI and which are
outside, continuous ROIs could be much smoother when zooming in for example
as they would be defined by some kind of function.
However, in any case it has to be clearly defined where the actual pixel
observation is:
For example Pixel (0,0) could be considered to be at position (a) (0.0, 0.0)
or (b) (0.5, 0.5), i.e. the coordinate (0,0) defines (a) the center of the
observed spot or (b) only the location on a grid where each cell has a size
of 1x1.
If I remember correctly both of them have advantages and disadvantages but
for transformations in general (a) is preferable but especially for ROIs (b)
is more intuitive.
What do you think?
All the best,
Steffi
Regards to all,
Gabriel
--
Gabriel Landini
> maybe we could go a 2-way strategy here, having discrete and continuous
> ROIs?
Hi Stephan,
Well yes, the line ROI is a bit like that (one can position it where one wants
after zooming, regardless of the pixel grid).
> For example Pixel (0,0) could be considered to be at position (a) (0.0,
> 0.0) or (b) (0.5, 0.5), i.e. the coordinate (0,0) defines (a) the center
> of the observed spot or (b) only the location on a grid where each cell
> has a size of 1x1.
I would call Pixe(0,0) at position (0,0). A rectangular ROI going from
(0,0)-(1,1) would involve 4 pixel samples and have an enclosed area of 1.
If one wants to get the value of pixel (0,0) then that is a Point ROI (0
area), not a rectangular one. I would not think it would hurt to consider a
rectangle (0,0)-(0,0) a Point ROI. It would be difficult to display, though.
> If I remember correctly both of them have advantages and disadvantages but
> for transformations in general (a) is preferable but especially for ROIs
> (b) is more intuitive.
The problem with (b) is that defining ROIs would need to specify a decimal
point such a rectangle at (0.5,0,5)-(4.5,10,5).
To make the current IJ ROIs to work as in (a) one needs to do 2 things:
1) shift the position gird of the yellow polygons by (0.5, 0,5) but still use
the floor() of the coordinate system to address the pixels. So one would still
address the pixel as (0,0).
2) rework the rectangular ROIs to comply with this.
I am not suggesting to spend any time right now doing this, but to keep it in
mind should the opportunity to reimplement ROIs arises in the future. It would
be useful at least to have the option of centred ROIs as well.
If there are any disadvantages with this, I would like to know, it is just
that I am not aware of any.
Best wishes,
Gabriel
Stephan Saalfeld
e.g. by a raytracer ;)). Usually (when obtained with a camera) a pixel
is an integral sample, that is the result of collecting photons on an
area---these photons, on the other hand, come in from a 4d region (space
and time: psf, exposure time). When not knowing about any of those.
assuming a normal distribution is the least thumb thing to do as
described by Lindeberg (1994) and as used in the Gaussian downsampler.
Some processing is easier when considering pixels as
squares/hypersquares like e.g. marching cubes or other cell-type
processing that handles connected components. This is just another
approximation like the Gaussian thing and has to be considered when
thinking about. Most important: a pixel being a spatio-temporal
integral, it is important to consider that it has a size or better, an
integral function (PSF*Collector shape). A ROI should respect that
function (but where are its bounds then when the function is smooth,
simplest case the Gaussian, at sigma? at a threshold?). Depending on
the PSF+Collector shape, the `location' of a pixel is not necessarily
its center, but if we think about them as little squares or Gaussian
generators, that just makes the most sense. That has some consequences
for scaling an image:
1. If you want to make imageSize = numPixels * pixelSize, then (0,0) is
not at the image corner but at the first original pixel's center.
2. What to use then for interpolation or averaging <0 and >imageSize-1?
3. When displaying from center first to center last pixel, then
imageSize = (numPixels-1) * pixelSize, which results in effective image
shrinking during consecutive blowups and growth during consecutive
downscales (well---that complements doesn't it? ;)).
Don't be so religious about the square thing :)---it's an ok
approximation. Just the inconsistencies matter.
We plan to support the concept of a pixel generator as a sampler with an
arbitrary generative function with well known properties for imglib.
That would allow both complex scientifically sound `interpolation' or
re-sampling and a proper decision on where boundaries of a selection
are. So far, they are points, but at least we know about.
Best,
Stephan
Gabriel Landini
> 1. If you want to make imageSize = numPixels * pixelSize, then (0,0) is
> not at the image corner but at the first original pixel's center.
Hi Stephan,
Yes, the ROI locked on centre of pixels will contain the pixel at 0,0. It is
under the ROI... When you *enlarge* (i.e. zoom it), it will appear centred on
the pixel, but when at 100%, it will appear overlapping the pixels. I do not
see any problem at all with that. Same as it is now (when unzoomed, not when
zoomed in, the ROI appears surrouding the pixels) with the rectangular tool.
The problem I am mentioning is that not all ROIs behave the same, when in
reality they could and (I think) should.
> 2. What to use then for interpolation or averaging <0 and >imageSize-1?
Sorry, I do not understand what you mean here. Do you mean to address pixels
outside the image boundaries? I do not mind if interpolation uses a different
and more convenient conception of what the image is (rectangles, hexagons or
points). As far as I am concerned the interpolation could still use the
concept of areas and I can't see how the locking of the ROI would affect the
coordinate system used to address the pixels.
The inconsistency of the Draw command is the problem here and that arises from
the inconsistency of the polygon positioning across ROI types.
I hope I clarify a bit what I have been moaning about :-)
Regards to all
Gabriel
Stephan Saalfeld
> The way I had it set up, only the mpicbg folder was included as a
> source folder from the root folder. The tests folder was added as a
> separate root source folder.
>
> Personally, I prefer to have all the main Java code in a subdirectory
> called src or something like that, and then just point at that, and to
> have all the test code (not part of the JAR proper) in a folder called
> tests or something. Then both src and tests are set as root source
> folders, and all is well.
>
That's how I have it too, that is the repository is in src/ to not make
anybody play with my Eclipse projects ;)
> FYI, the way Maven does it by default, main source code goes under
> src/main/java, and source files for test go under src/test/java, which
> is a very flexible approach.
>
I think we shouldn't waste time creating an Eclipse project from fiji.
Consider run profiles that are usually very personal (launch Fiji with
the following image and script and see what happens). An external
Builder is from my perspective a good choice but should be able to use
the Eclipse compiled classes for jaring. I am sure we can convince
Maven to do so. For Fake, this is not going to be possible due to some
design decisions that simplify the complexity of build instructions.
Best,
Stephan
> -Curtis
>
> On Mon, Apr 12, 2010 at 2:19 PM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> Hi,
>
> On Mon, 12 Apr 2010, Stephan Saalfeld wrote:
>
>
> > I see. So the test folder was explicitly excluded from the
> build path
> > or put in separately---got it. I would like to keep the
> directory
> > hierarchy reflect the package structure here or we agree on
> an exclude
> > pattern for now.
>
>
> Or we fix it properly and generate an Eclopse project from
> Fiji Build. Not
> that hard to agree to that, is it?
>
> Ciao,
> Johannes
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "Fiji-devel" group.
> To post to this group, send email to
> fiji-...@googlegroups.com.
> To unsubscribe from this group, send email to fiji-devel
Stephan Saalfeld
Johannes felt insulted by my last comments, so let me clarify:
What I am saying here is my personal opinion and in no case meant to
insult anybody. I am just offering my viewpoint as a user of the
Eclipse platform to develop stuff in Fiji. If I am wrong, tell me and I
will learn. I respect the infrastructural work on the Fiji-development
platform very much, particularly because I do not and will not
contribute too much here just due to lack of time. What I am doing is
just commenting it from the `user' perspective (which means the user of
Fiji the development platform, not the user of Fiji the tool).
BTW, I found myself telling wrong about the run-profiles, they are
workspace-specific not project-specific.
Best,
Stephan
Stephan Saalfeld
> Yes, the ROI locked on centre of pixels will contain the pixel at 0,0. It is
> under the ROI... When you *enlarge* (i.e. zoom it), it will appear centred on
> the pixel, but when at 100%, it will appear overlapping the pixels. I do not
> see any problem at all with that. Same as it is now (when unzoomed, not when
> zoomed in, the ROI appears surrouding the pixels) with the rectangular tool.
> The problem I am mentioning is that not all ROIs behave the same, when in
> reality they could and (I think) should.
>
Yes---the inconsistency is the problem.
> > 2. What to use then for interpolation or averaging <0 and >imageSize-1?
>
> Sorry, I do not understand what you mean here. Do you mean to address pixels
> outside the image boundaries? I do not mind if interpolation uses a different
> and more convenient conception of what the image is (rectangles, hexagons or
> points). As far as I am concerned the interpolation could still use the
> concept of areas and I can't see how the locking of the ROI would affect the
> coordinate system used to address the pixels.
>
See an example here:
http://fly.mpi-cbg.de/~saalfeld/scale.jpg
current ImageJ takes the upper left corner of pixels when scaling. When
doing any non-NN interpolation, for the first row and column, the
required interpolation partners at (-1,y) and (x,-1) are assumed to be
equivalent to (0,y) and (x,0). The result is a shifted image with the
shift not present in the calibration object and, by that, scale(1/k) is
not the inverse of scale(k). Note that, in this example, NN looks like
performing no shift which is true for integer scale factors. For
non-integer scales, the shift is just the same. Try 5/2 and 2/5.
> The inconsistency of the Draw command is the problem here and that arises from
> the inconsistency of the polygon positioning across ROI types.
> I hope I clarify a bit what I have been moaning about :-)
>
Yes.
All the best,
Stephan
Gabriel Landini
> current ImageJ takes the upper left corner of pixels when scaling. When
> doing any non-NN interpolation, for the first row and column, the
> required interpolation partners at (-1,y) and (x,-1) are assumed to be
> equivalent to (0,y) and (x,0). The result is a shifted image with the
> shift not present in the calibration object and, by that, scale(1/k) is
> not the inverse of scale(k). Note that, in this example, NN looks like
> performing no shift which is true for integer scale factors. For
> non-integer scales, the shift is just the same. Try 5/2 and 2/5.
Ah, yes, I get it now.
Well, good that all these issues are clear now, maybe we can do something
about it!
Cheers
Gabriel
Gabriel Landini
> This inconsistency is removed in the 1.43t8 daily build. The Draw command
> now draws rectangular selections the same way it draws polygon selections.
Thanks Wayne for looking into this.
There are really 2 issues:
Positioning of the ROI polygon (esthetic + more intuitive for some)
Behaviour of the Draw command with relation to the Fill command.
My suggestions are these (and they are related):
1) ROIs should land on the "boundary pixels" of objects
2) The boundary pixels should be part of the filled blob
1) Implies that when zooming in the yellow polygon would be better placed so
it overlaps with those pixels. One then would see which pixels are bounding
the ROI. The rectangular ROI and the magic wand do not behave like this, but
surround the filled pixels (i.e. iin the limit between foreground and
background).
2) The relation between boundary pixels, filled ROI and Draw command is
currently systematic, I agree, but somewhat unusual.
Some might think that I am raising a really trivial issue, but there are
important mereotopological (what a word!) relations which need to be met if
one wants to do any kind of spatial reasoning using blobs (Dave Randell gave a
talk on this at the last Lux conference).
It would be great if the relations between ROIs, the blob they define, the
boundary of the blob and its filled version were contained (this might not the
right word) in each other. Currently they are not
Now that the Draw command is consistent, I am suspecting that to do the
Filling I expect, one should do a Draw and immediately a Fill of the ROI. That
way the only issue remaining is that when the image is zoomed the ROIs appears
shifted.
So the question evolves into: why is the current Filled object not including
some boundary pixels?
If this is for correcting the area under the ROI, there are better
approximations (such as the old Freeman chain encoding algorithm).
Does that mean that a pixel under the ROI will not contribute to the intensity
values of the object?
Still, note that if one applies a magic wand to a binary blob, the ROI now
surrounds all the pixels -- rather than being locked to the top left pixels as
it was before -- and if Drawn again the blob is enlarged!.
Shouldn't a magic-wanded blob be just what one sees?
Many thanks for listening!
Regards to all,
Gabriel
Johannes Schindelin
On Thu, 15 Apr 2010, Gabriel Landini wrote:
> Some might think that I am raising a really trivial issue, but there are
> important mereotopological (what a word!) relations which need to be met
> if one wants to do any kind of spatial reasoning using blobs (Dave
> Randell gave a talk on this at the last Lux conference).
Is there any article or presentation of that talk?
It would be good to have something like that, because we are in really hot
discussions about ROIs, hopefully defining a sensible superset in ImageJ2.
Ciao,
Johannes
Gabriel Landini
> now draws rectangular selections the same way it draws polygon selections.
the maximised rectangular ROI and the (0,0) - (width-1, height-1) ROIs, when
drawn return the same results.
Example:
//------------
run("Colors...", "foreground=white background=black selection=yellow");
newImage("test", "8-bit Black", 10, 10, 1);
run("In");
run("In");
run("In");
run("In");
run("In");
run("In");
run("Draw");
wait(1000);
newImage("test2", "8-bit Black", 10, 10, 1);
run("In");
run("In");
run("In");
run("In");
run("In");
run("In");
run("Draw");
//------------
I would not like the idea of the maximised ROI not drawing the right and
bottom pixels of the image frame.
Do you think it would be a good idea to regress this behaviour until this
problem is resolved differently?
I understand that revamping ROIs might not happen right now, but just for
future reference, the idea was that if the ROI were locked on the centre of
boundary pixels, and draw underneath it, the maximised version (zoomed) would
appear just slightly smaller than the image frame (half-interpixel distance on
each side). This would also have the advantage that all drawn ROIs would be
completely included in the ROI bounding box.
Best wishes,
Gabriel
--
You received this message because you are subscribed to the Google Groups "Fiji-devel" group.
To post to this group, send email to fiji-...@googlegroups.com.