Hyperstack with nz=1 problem

[Fred Damen]

Greetings,

I am using hyperstacks and ran into some issues.

With datasets with multiple slices(NZ>1) and multiple frames (NF>1) everything
seems normal: image status bar shows z:cz/NZ t:ct/NT, and info page shows
similar, two scroll bars on bottom, and, Stacks->Tools->Make Substack...
present the dialog for SubHyperstackMaker.

With datasets with one slice(NZ=1) and multiple frames (NF>1) there are flaws:
image status bar shows n/N, info page lacks slice/frame also, one scroll bar
on bottom, and Stacks->Tools->Make Substack... present the dialog for
SubstackMaker and produces a stack with a 1x1 images.

I suspect that ImagePlus::isHyperStack() is not recognizing single slice
hyperstack properly.

Thanks,

Fred

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings,

Why is a grey scale dataset with one slice per volume and many time points not
considered a HyperStack?  Is the code below, from ImagePlus, trying to tell
the difference between an ImagePlus without a ImageStack and an ImageStack
with only one entry; I can see the former being a cause to not be considered a
Hyperstack but not the later.  I am dealing with the later case.

This causes me to not be able to substack my Hyperstack through the GUI.
Although I can do Stacks->Z Project... in the time/frame dimension with
(NZ=1,NT>1).  Is there available tools to do 'T Project...' and 'Plot T-axis
Profile...' without this bug?

Code from ImagePlus:

        /** Returns 'true' if this image is a hyperstack. */
        public boolean isHyperStack() {
                return isDisplayedHyperStack() || (openAsHyperStack&&getNDimensions()>3);
        }

        /** Returns the number of dimensions (2, 3, 4 or 5). */
        public int getNDimensions() {
                int dimensions = 2;
                int[] dim = getDimensions(true);
                if (dim[2]>1) dimensions++;
                if (dim[3]>1) dimensions++;
                if (dim[4]>1) dimensions++;
                return dimensions;
        }

Thanks,

Fred


On Fri, February 2, 2018 10:46 pm, Fred Damen wrote:

> Greetings,
>
> I am using hyperstacks and ran into some issues.
>
> With datasets with multiple slices(NZ>1) and multiple frames (NF>1) everything
> seems normal: image status bar shows z:cz/NZ t:ct/NT, and info page shows
> similar, two scroll bars on bottom, and, Stacks->Tools->Make Substack...
> present the dialog for SubHyperstackMaker.
>
> With datasets with one slice(NZ=1) and multiple frames (NF>1) there are flaws:
> image status bar shows n/N, info page lacks slice/frame also, one scroll bar
> on bottom, and Stacks->Tools->Make Substack... present the dialog for
> SubstackMaker and produces a stack with a 1x1 images.
>
> I suspect that ImagePlus::isHyperStack() is not recognizing single slice
> hyperstack properly.
>
> Thanks,
>
> Fred
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

> On Feb 8, 2018, at 5:22 PM, Fred Damen <[hidden email]> wrote:
>
> Greetings,
>
> Why is a grey scale dataset with one slice per volume and many time points not
> considered a HyperStack?  Is the code below, from ImagePlus, trying to tell
> the difference between an ImagePlus without a ImageStack and an ImageStack
> with only one entry; I can see the former being a cause to not be considered a
> Hyperstack but not the later.  I am dealing with the later case.

Hyperstacks have 4 or more dimensions. A stack with NC=1, NZ=1 and NT>1 has only 3 dimensions.

> This causes me to not be able to substack my Hyperstack through the GUI.
> Although I can do Stacks->Z Project... in the time/frame dimension with
> (NZ=1,NT>1).  Is there available tools to do 'T Project...' and 'Plot T-axis
> Profile...' without this bug?

The "Z Project…" and "Plot Z-axis Profile…” commands work with non-hyperstacks with NT>1.

-wayne

> Code from ImagePlus:
>
> /** Returns 'true' if this image is a hyperstack. */
> public boolean isHyperStack() {
> return isDisplayedHyperStack() || (openAsHyperStack&&getNDimensions()>3);
> }
>
> /** Returns the number of dimensions (2, 3, 4 or 5). */
> public int getNDimensions() {
> int dimensions = 2;
> int[] dim = getDimensions(true);
> if (dim[2]>1) dimensions++;
> if (dim[3]>1) dimensions++;
> if (dim[4]>1) dimensions++;
> return dimensions;
> }
>
> Thanks,
>
> Fred
>
>
> On Fri, February 2, 2018 10:46 pm, Fred Damen wrote:
>> Greetings,
>>
>> I am using hyperstacks and ran into some issues.
>>
>> With datasets with multiple slices(NZ>1) and multiple frames (NF>1) everything
>> seems normal: image status bar shows z:cz/NZ t:ct/NT, and info page shows
>> similar, two scroll bars on bottom, and, Stacks->Tools->Make Substack...
>> present the dialog for SubHyperstackMaker.
>>
>> With datasets with one slice(NZ=1) and multiple frames (NF>1) there are flaws:
>> image status bar shows n/N, info page lacks slice/frame also, one scroll bar
>> on bottom, and Stacks->Tools->Make Substack... present the dialog for
>> SubstackMaker and produces a stack with a 1x1 images.
>>
>> I suspect that ImagePlus::isHyperStack() is not recognizing single slice
>> hyperstack properly.
>>
>> Thanks,
>>
>> Fred

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings,

I guess my point is more ideological. I have a set of volumes of images, where
the volumes are 3D space -- a stack of slices, and the set consists of volumes
 acquired using varying  parameters -- frames.  This is very common in MRI,
i.e., fMRI, Diffusion, ASL, etc.  Some times there are cases in which we
collect only the same single slice for each parameter value.  ImageJ is
handling the case of a one slice volume different than the case of multiple
slice volumes.  I was wondering why this is? Do I need to add a second dummy
slice so that ImageJ treats a single slice as a volume?

In reference to 'T Project...' and 'Plot T-axis Profile...'  I was referring
to averaging, etc, voxels within the volumes over the T axis.  From glancing
at the ZProjector code seems to do the operation only over the slices within a
volume and not over volumes.  It will repeat the operation for each frame if
requested.

It would be nice to see the change for a voxel of space over time.

Thanks,

Fred

On Thu, February 8, 2018 8:32 pm, Wayne Rasband wrote:

>> On Feb 8, 2018, at 5:22 PM, Fred Damen <[hidden email]> wrote:
>>
>> Greetings,
>>
>> Why is a grey scale dataset with one slice per volume and many time points
>> not
>> considered a HyperStack?  Is the code below, from ImagePlus, trying to tell
>> the difference between an ImagePlus without a ImageStack and an ImageStack
>> with only one entry; I can see the former being a cause to not be considered
>> a
>> Hyperstack but not the later.  I am dealing with the later case.
>
> Hyperstacks have 4 or more dimensions. A stack with NC=1, NZ=1 and NT>1 has
> only 3 dimensions.
>
>> This causes me to not be able to substack my Hyperstack through the GUI.
>> Although I can do Stacks->Z Project... in the time/frame dimension with
>> (NZ=1,NT>1).  Is there available tools to do 'T Project...' and 'Plot T-axis
>> Profile...' without this bug?
>
> The "Z Project…" and "Plot Z-axis Profile…” commands work with
> non-hyperstacks with NT>1.
>
> -wayne
>
>
>> Code from ImagePlus:
>>
>> /** Returns 'true' if this image is a hyperstack. */
>> public boolean isHyperStack() {
>> return isDisplayedHyperStack() || (openAsHyperStack&&getNDimensions()>3);
>> }
>>
>> /** Returns the number of dimensions (2, 3, 4 or 5). */
>> public int getNDimensions() {
>> int dimensions = 2;
>> int[] dim = getDimensions(true);
>> if (dim[2]>1) dimensions++;
>> if (dim[3]>1) dimensions++;
>> if (dim[4]>1) dimensions++;
>> return dimensions;
>> }
>>
>> Thanks,
>>
>> Fred
>>
>>
>> On Fri, February 2, 2018 10:46 pm, Fred Damen wrote:
>>> Greetings,
>>>
>>> I am using hyperstacks and ran into some issues.
>>>
>>> With datasets with multiple slices(NZ>1) and multiple frames (NF>1)
>>> everything
>>> seems normal: image status bar shows z:cz/NZ t:ct/NT, and info page shows
>>> similar, two scroll bars on bottom, and, Stacks->Tools->Make Substack...
>>> present the dialog for SubHyperstackMaker.
>>>
>>> With datasets with one slice(NZ=1) and multiple frames (NF>1) there are
>>> flaws:
>>> image status bar shows n/N, info page lacks slice/frame also, one scroll
>>> bar
>>> on bottom, and Stacks->Tools->Make Substack... present the dialog for
>>> SubstackMaker and produces a stack with a 1x1 images.
>>>
>>> I suspect that ImagePlus::isHyperStack() is not recognizing single slice
>>> hyperstack properly.
>>>
>>> Thanks,
>>>
>>> Fred
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

Good day!

"[...] so that ImageJ treats a single slice as a volume?"

A slice is an image!

A slice has no extension orthogonal to itself.
A pixel also has no extension in any direction because it is a mathematical
point in 2D, i.e. a number or sample value.
A voxel also has no extension in any direction because it is a mathematical
point in 3D, i.e. a number or sample value.

Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
sometimes equidistant *spacing* of the grid points is often confused with
the pixel size, that actually doesn't exist.
(A pixel doesn't have a size.)

Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
sometimes equidistant *spacing* of the grid points is often confused with
the voxel size, that actually doesn't exist.
(A voxel doesn't have a size.)

In short:
A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
spacing in the third dimension.

That said, you may indeed use dummy slices to define the missing spacing!

HTH

Herbie



--
Sent from: http://imagej.1557.x6.nabble.com/

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

I respectfully disagree.

First, I think it's preferable to consider pixels as having area, and voxels as having volume (this view is supported by the display shown when images are zoomed).  Indeed - this was usually part of the content in the first class meeting for every course in image processing (or raster graphics) that I taught over the course of 40 years.

Second, I think it's preferable for it to be possible to view a slice as a volume which simply has zero extent in the z-direction.  I'd actually prefer it to be considered to have some finite depth (when viewed as a volume) rather than 0.0, but, alas, there is no easy way to assign that finite depth.  Once you have two slices, and a spacing between them, I prefer to think of each slice as having a finite depth (a slab, rather than a plane).

Most of the time, it's reasonable to take the point of view that a pixel = a point (rather than an area) and a voxel = a point (rather than a volume), but I think it's preferable to ALLOW both points of view.

I see nothing problematic about a 3d volume consisting of a single slice.

If you think a pixel is a point - do you consider a SINGLE pixel to be a 1x1 image?  or it that "not an image"?

I, for one, would be pleased if ImageJ were to allow this point of view (A volume with x*y*1 voxels).  But, for now, the answer for the OP is: ImageJ just doesn't allow that point of view.  I think it's a deficiency.


--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

> On 9 Feb 2018, at 12:03 , Herbie <[hidden email]> wrote:
>
> Good day!
>
> "[...] so that ImageJ treats a single slice as a volume?"
>
> A slice is an image!
>
> A slice has no extension orthogonal to itself.
> A pixel also has no extension in any direction because it is a mathematical
> point in 2D, i.e. a number or sample value.
> A voxel also has no extension in any direction because it is a mathematical
> point in 3D, i.e. a number or sample value.
>
> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
> sometimes equidistant *spacing* of the grid points is often confused with
> the pixel size, that actually doesn't exist.
> (A pixel doesn't have a size.)
>
> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
> sometimes equidistant *spacing* of the grid points is often confused with
> the voxel size, that actually doesn't exist.
> (A voxel doesn't have a size.)
>
> In short:
> A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
> spacing in the third dimension.
>
> That said, you may indeed use dummy slices to define the missing spacing!
>
> HTH
>
> Herbie
>
>
>
> --
> Sent from: http://imagej.1557.x6.nabble.com/
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings,

Beauty is in the eyes of the beholder...  and my beauty is MRI.

In MRI a slice is a 3D entity with length, width and depth -- which we call
slice thickness.  A voxel, i.e., volume element, represents a single value for
a location in 3D space. Voxels are contiguous within the slice and depending
on how data was collected may be contiguous in z also -- you can have what we
call an interslice gap.  In MRI there is no way to acquire a slice with
infinitesimally thin slice thickness.  Usually the slice thickness is more
than twice that of the in-slice voxel size.

Thanks for the info,

Fred

On Fri, February 9, 2018 11:03 am, Herbie wrote:

> Good day!
>
> "[...] so that ImageJ treats a single slice as a volume?"
>
> A slice is an image!
>
> A slice has no extension orthogonal to itself.
> A pixel also has no extension in any direction because it is a mathematical
> point in 2D, i.e. a number or sample value.
> A voxel also has no extension in any direction because it is a mathematical
> point in 3D, i.e. a number or sample value.
>
> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
> sometimes equidistant *spacing* of the grid points is often confused with
> the pixel size, that actually doesn't exist.
> (A pixel doesn't have a size.)
>
> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
> sometimes equidistant *spacing* of the grid points is often confused with
> the voxel size, that actually doesn't exist.
> (A voxel doesn't have a size.)
>
> In short:
> A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
> spacing in the third dimension.
>
> That said, you may indeed use dummy slices to define the missing spacing!
>
> HTH
>
> Herbie
>
>
>
> --
> Sent from: http://imagej.1557.x6.nabble.com/
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

Dear Kenneth,

we had this discussion before...

In short:

The answer is in signal theory, especially in signal discretisation,
vulgo sampling, and in signal reconstruction (from discrete signals).

The little areas or volumes you are referring to represent the easiest
or cheapest way of interpolation of discrete signals (reconstruction)
and of course, as we all know, it is not the correct way.

The issue in question is only indirectly related to this signal
theoretical fact and partly even a matter of taste. The way I've argued
is closely related to signal theory, favoring the sampling distances as
the essential entity because it is independent of the way discrete
signals are represented or displayed.

"do you consider a SINGLE pixel to be a 1x1 image?"

Of course it is not a discretisation of an image, it is number and as
such is not related to a (pictorial) signal, except it is known that it
was taken from a (spatially) discrete signal.

I don't insist on discussing this topic any further because this would
mean to rewrite the respective chapters of signal/l and systems theory.
The view of informatics or computer science may be different but not
necessarily correct.
(Because it appears important for you to mention your academic teaching
experience, I've been a university prof. in both fields, signal /
systems theory and informatics.)

Best

Herbie

:::::::::::::::::::::::::::::::::::::::::::
Am 09.02.18 um 22:57 schrieb Kenneth Sloan:

> I respectfully disagree.
>
> First, I think it's preferable to consider pixels as having area, and voxels as having volume (this view is supported by the display shown when images are zoomed).  Indeed - this was usually part of the content in the first class meeting for every course in image processing (or raster graphics) that I taught over the course of 40 years.
>
> Second, I think it's preferable for it to be possible to view a slice as a volume which simply has zero extent in the z-direction.  I'd actually prefer it to be considered to have some finite depth (when viewed as a volume) rather than 0.0, but, alas, there is no easy way to assign that finite depth.  Once you have two slices, and a spacing between them, I prefer to think of each slice as having a finite depth (a slab, rather than a plane).
>
> Most of the time, it's reasonable to take the point of view that a pixel = a point (rather than an area) and a voxel = a point (rather than a volume), but I think it's preferable to ALLOW both points of view.
>
> I see nothing problematic about a 3d volume consisting of a single slice.
>
> If you think a pixel is a point - do you consider a SINGLE pixel to be a 1x1 image?  or it that "not an image"?
>
> I, for one, would be pleased if ImageJ were to allow this point of view (A volume with x*y*1 voxels).  But, for now, the answer for the OP is: ImageJ just doesn't allow that point of view.  I think it's a deficiency.
>
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
>> On 9 Feb 2018, at 12:03 , Herbie <[hidden email]> wrote:
>>
>> Good day!
>>
>> "[...] so that ImageJ treats a single slice as a volume?"
>>
>> A slice is an image!
>>
>> A slice has no extension orthogonal to itself.
>> A pixel also has no extension in any direction because it is a mathematical
>> point in 2D, i.e. a number or sample value.
>> A voxel also has no extension in any direction because it is a mathematical
>> point in 3D, i.e. a number or sample value.
>>
>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>> sometimes equidistant *spacing* of the grid points is often confused with
>> the pixel size, that actually doesn't exist.
>> (A pixel doesn't have a size.)
>>
>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>> sometimes equidistant *spacing* of the grid points is often confused with
>> the voxel size, that actually doesn't exist.
>> (A voxel doesn't have a size.)
>>
>> In short:
>> A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
>> spacing in the third dimension.
>>
>> That said, you may indeed use dummy slices to define the missing spacing!
>>
>> HTH
>>
>> Herbie
>>
>>
>>
>> --
>> Sent from: http://imagej.1557.x6.nabble.com/
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

Good day Fred,

no problem with your statements. They are compatible with signal theory
(see my answer to Kenneth).

Mathematical fact is that samples are numbers (or in RGB number
triplets) that have no spatial or temporal extension.

If you consider the physical process of sampling, the question may arise
of how an extended little area, or in your tomographic case, an extended
little volume eventually leads to a number. The answer is easy:

        By spatial integration.

Consequently, it is not the little integration area or the little
integration volume that is later (after pictorial or tomographic
reconstruction) displayed as little area or little volume. It is the
number (gray value) that resulted from integration during signal
acquisition that is smeared out or interpolated in some fashion on a
display or by a projector and presented as a light intensity.

Of course the integration area or volume during signal acquisition may
be much larger than the sampling distance. In tomography (CT and MRI)
this is not only the case regarding the z-direction but also, usually
not as pronounced, in the xy-directions. The classic example however, is
the flying spot scanner in which the spot represents the integration
area and the sampling distance may be chosen independently from the spot
size.

Hopefully I could clarify the topic a bit.

Regards

Herbie

::::::::::::::::::::::::::::::::::::::::
Am 10.02.18 um 02:54 schrieb Fred Damen:

> Greetings,
>
> Beauty is in the eyes of the beholder...  and my beauty is MRI.
>
> In MRI a slice is a 3D entity with length, width and depth -- which we call
> slice thickness.  A voxel, i.e., volume element, represents a single value for
> a location in 3D space. Voxels are contiguous within the slice and depending
> on how data was collected may be contiguous in z also -- you can have what we
> call an interslice gap.  In MRI there is no way to acquire a slice with
> infinitesimally thin slice thickness.  Usually the slice thickness is more
> than twice that of the in-slice voxel size.
>
> Thanks for the info,
>
> Fred
>
> On Fri, February 9, 2018 11:03 am, Herbie wrote:
>> Good day!
>>
>> "[...] so that ImageJ treats a single slice as a volume?"
>>
>> A slice is an image!
>>
>> A slice has no extension orthogonal to itself.
>> A pixel also has no extension in any direction because it is a mathematical
>> point in 2D, i.e. a number or sample value.
>> A voxel also has no extension in any direction because it is a mathematical
>> point in 3D, i.e. a number or sample value.
>>
>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>> sometimes equidistant *spacing* of the grid points is often confused with
>> the pixel size, that actually doesn't exist.
>> (A pixel doesn't have a size.)
>>
>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>> sometimes equidistant *spacing* of the grid points is often confused with
>> the voxel size, that actually doesn't exist.
>> (A voxel doesn't have a size.)
>>
>> In short:
>> A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
>> spacing in the third dimension.
>>
>> That said, you may indeed use dummy slices to define the missing spacing!
>>
>> HTH
>>
>> Herbie
>>
>>
>>
>> --
>> Sent from: http://imagej.1557.x6.nabble.com/
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[lechristophe]

Hi everyone,

I think the discussion has reached the "post the Alvy Ray Smith paper"
point:
https://news.ycombinator.com/item?id=8614159
"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)"

As a biologist-microscopist I can't say I understand everything in it, but
I got the part about pixels not being little squares :)

Christophe



2018-02-10 10:11 GMT+01:00 Herbie <[hidden email]>:

> Good day Fred,
>
> no problem with your statements. They are compatible with signal theory
> (see my answer to Kenneth).
>
> Mathematical fact is that samples are numbers (or in RGB number triplets)
> that have no spatial or temporal extension.
>
> If you consider the physical process of sampling, the question may arise
> of how an extended little area, or in your tomographic case, an extended
> little volume eventually leads to a number. The answer is easy:
>
>         By spatial integration.
>
> Consequently, it is not the little integration area or the little
> integration volume that is later (after pictorial or tomographic
> reconstruction) displayed as little area or little volume. It is the number
> (gray value) that resulted from integration during signal acquisition that
> is smeared out or interpolated in some fashion on a display or by a
> projector and presented as a light intensity.
>
> Of course the integration area or volume during signal acquisition may be
> much larger than the sampling distance. In tomography (CT and MRI) this is
> not only the case regarding the z-direction but also, usually not as
> pronounced, in the xy-directions. The classic example however, is the
> flying spot scanner in which the spot represents the integration area and
> the sampling distance may be chosen independently from the spot size.
>
> Hopefully I could clarify the topic a bit.
>
> Regards
>
> Herbie
>
> ::::::::::::::::::::::::::::::::::::::::
> Am 10.02.18 um 02:54 schrieb Fred Damen:
>
> Greetings,
>>
>> Beauty is in the eyes of the beholder...  and my beauty is MRI.
>>
>> In MRI a slice is a 3D entity with length, width and depth -- which we
>> call
>> slice thickness.  A voxel, i.e., volume element, represents a single
>> value for
>> a location in 3D space. Voxels are contiguous within the slice and
>> depending
>> on how data was collected may be contiguous in z also -- you can have
>> what we
>> call an interslice gap.  In MRI there is no way to acquire a slice with
>> infinitesimally thin slice thickness.  Usually the slice thickness is more
>> than twice that of the in-slice voxel size.
>>
>> Thanks for the info,
>>
>> Fred
>>
>> On Fri, February 9, 2018 11:03 am, Herbie wrote:
>>
>>> Good day!
>>>
>>> "[...] so that ImageJ treats a single slice as a volume?"
>>>
>>> A slice is an image!
>>>
>>> A slice has no extension orthogonal to itself.
>>> A pixel also has no extension in any direction because it is a
>>> mathematical
>>> point in 2D, i.e. a number or sample value.
>>> A voxel also has no extension in any direction because it is a
>>> mathematical
>>> point in 3D, i.e. a number or sample value.
>>>
>>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>>> sometimes equidistant *spacing* of the grid points is often confused with
>>> the pixel size, that actually doesn't exist.
>>> (A pixel doesn't have a size.)
>>>
>>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>>> sometimes equidistant *spacing* of the grid points is often confused with
>>> the voxel size, that actually doesn't exist.
>>> (A voxel doesn't have a size.)
>>>
>>> In short:
>>> A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
>>> spacing in the third dimension.
>>>
>>> That said, you may indeed use dummy slices to define the missing spacing!
>>>
>>> HTH
>>>
>>> Herbie
>>>
>>>
>>>
>>> --
>>> Sent from: http://imagej.1557.x6.nabble.com/
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

Bonjour Christophe,

thanks for chiming in and of course I know this paper. However and
although it is to the point, a more thorough view would be desirable.

For those who read German, here is a link to an article written for
those who prefer thorough scientific explanations that require only
moderate mathematical knowledge:
<www.gluender.de/Writings/WritingsTexts/WritingsDownloads/2016_Diskretisierung.zip>

Best

Herbie

::::::::::::::::::::::::::::::::::::::::::::::::::
Am 10.02.18 um 10:47 schrieb Christophe Leterrier:

> Hi everyone,
>
> I think the discussion has reached the "post the Alvy Ray Smith paper"
> point:
> https://news.ycombinator.com/item?id=8614159
> "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)"
>
> As a biologist-microscopist I can't say I understand everything in it, but
> I got the part about pixels not being little squares :)
>
> Christophe
>
>
>
> 2018-02-10 10:11 GMT+01:00 Herbie <[hidden email]>:
>
>> Good day Fred,
>>
>> no problem with your statements. They are compatible with signal theory
>> (see my answer to Kenneth).
>>
>> Mathematical fact is that samples are numbers (or in RGB number triplets)
>> that have no spatial or temporal extension.
>>
>> If you consider the physical process of sampling, the question may arise
>> of how an extended little area, or in your tomographic case, an extended
>> little volume eventually leads to a number. The answer is easy:
>>
>>          By spatial integration.
>>
>> Consequently, it is not the little integration area or the little
>> integration volume that is later (after pictorial or tomographic
>> reconstruction) displayed as little area or little volume. It is the number
>> (gray value) that resulted from integration during signal acquisition that
>> is smeared out or interpolated in some fashion on a display or by a
>> projector and presented as a light intensity.
>>
>> Of course the integration area or volume during signal acquisition may be
>> much larger than the sampling distance. In tomography (CT and MRI) this is
>> not only the case regarding the z-direction but also, usually not as
>> pronounced, in the xy-directions. The classic example however, is the
>> flying spot scanner in which the spot represents the integration area and
>> the sampling distance may be chosen independently from the spot size.
>>
>> Hopefully I could clarify the topic a bit.
>>
>> Regards
>>
>> Herbie
>>
>> ::::::::::::::::::::::::::::::::::::::::
>> Am 10.02.18 um 02:54 schrieb Fred Damen:
>>
>> Greetings,
>>>
>>> Beauty is in the eyes of the beholder...  and my beauty is MRI.
>>>
>>> In MRI a slice is a 3D entity with length, width and depth -- which we
>>> call
>>> slice thickness.  A voxel, i.e., volume element, represents a single
>>> value for
>>> a location in 3D space. Voxels are contiguous within the slice and
>>> depending
>>> on how data was collected may be contiguous in z also -- you can have
>>> what we
>>> call an interslice gap.  In MRI there is no way to acquire a slice with
>>> infinitesimally thin slice thickness.  Usually the slice thickness is more
>>> than twice that of the in-slice voxel size.
>>>
>>> Thanks for the info,
>>>
>>> Fred
>>>
>>> On Fri, February 9, 2018 11:03 am, Herbie wrote:
>>>
>>>> Good day!
>>>>
>>>> "[...] so that ImageJ treats a single slice as a volume?"
>>>>
>>>> A slice is an image!
>>>>
>>>> A slice has no extension orthogonal to itself.
>>>> A pixel also has no extension in any direction because it is a
>>>> mathematical
>>>> point in 2D, i.e. a number or sample value.
>>>> A voxel also has no extension in any direction because it is a
>>>> mathematical
>>>> point in 3D, i.e. a number or sample value.
>>>>
>>>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>>>> sometimes equidistant *spacing* of the grid points is often confused with
>>>> the pixel size, that actually doesn't exist.
>>>> (A pixel doesn't have a size.)
>>>>
>>>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>>>> sometimes equidistant *spacing* of the grid points is often confused with
>>>> the voxel size, that actually doesn't exist.
>>>> (A voxel doesn't have a size.)
>>>>
>>>> In short:
>>>> A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
>>>> spacing in the third dimension.
>>>>
>>>> That said, you may indeed use dummy slices to define the missing spacing!
>>>>
>>>> HTH
>>>>
>>>> Herbie
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://imagej.1557.x6.nabble.com/
>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[lechristophe]

Hi Herbie,

I didn't dare to send this often-posted link for you, Kenneth or the other
knowledgable people already discussing in this thread - I figured it could
be a nice introduction to the discussed problem for the whole list. The
argument made is along the line of your earlier statements about a pixel
not having a surface or a slice not having a thickness. Sadly I don't read
German to really understand if your underlying reasons or explanation
differ from Alvy Ray Smith - in any case it's always interesting to learn
more about the "philosophical" aspect of what we're dealing with every day.

Best Regards,

Christophe

2018-02-10 11:09 GMT+01:00 Herbie <[hidden email]>:

> Bonjour Christophe,
>
> thanks for chiming in and of course I know this paper. However and
> although it is to the point, a more thorough view would be desirable.
>
> For those who read German, here is a link to an article written for those
> who prefer thorough scientific explanations that require only moderate
> mathematical knowledge:
> <www.gluender.de/Writings/WritingsTexts/WritingsDownloads/20
> 16_Diskretisierung.zip>
>
> Best
>
> Herbie
>
> ::::::::::::::::::::::::::::::::::::::::::::::::::
> Am 10.02.18 um 10:47 schrieb Christophe Leterrier:
>
> Hi everyone,
>>
>> I think the discussion has reached the "post the Alvy Ray Smith paper"
>> point:
>> https://news.ycombinator.com/item?id=8614159
>> "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)"
>>
>> As a biologist-microscopist I can't say I understand everything in it, but
>> I got the part about pixels not being little squares :)
>>
>> Christophe
>>
>>
>>
>> 2018-02-10 10:11 GMT+01:00 Herbie <[hidden email]>:
>>
>> Good day Fred,
>>>
>>> no problem with your statements. They are compatible with signal theory
>>> (see my answer to Kenneth).
>>>
>>> Mathematical fact is that samples are numbers (or in RGB number triplets)
>>> that have no spatial or temporal extension.
>>>
>>> If you consider the physical process of sampling, the question may arise
>>> of how an extended little area, or in your tomographic case, an extended
>>> little volume eventually leads to a number. The answer is easy:
>>>
>>>          By spatial integration.
>>>
>>> Consequently, it is not the little integration area or the little
>>> integration volume that is later (after pictorial or tomographic
>>> reconstruction) displayed as little area or little volume. It is the
>>> number
>>> (gray value) that resulted from integration during signal acquisition
>>> that
>>> is smeared out or interpolated in some fashion on a display or by a
>>> projector and presented as a light intensity.
>>>
>>> Of course the integration area or volume during signal acquisition may be
>>> much larger than the sampling distance. In tomography (CT and MRI) this
>>> is
>>> not only the case regarding the z-direction but also, usually not as
>>> pronounced, in the xy-directions. The classic example however, is the
>>> flying spot scanner in which the spot represents the integration area and
>>> the sampling distance may be chosen independently from the spot size.
>>>
>>> Hopefully I could clarify the topic a bit.
>>>
>>> Regards
>>>
>>> Herbie
>>>
>>> ::::::::::::::::::::::::::::::::::::::::
>>> Am 10.02.18 um 02:54 schrieb Fred Damen:
>>>
>>> Greetings,
>>>
>>>>
>>>> Beauty is in the eyes of the beholder...  and my beauty is MRI.
>>>>
>>>> In MRI a slice is a 3D entity with length, width and depth -- which we
>>>> call
>>>> slice thickness.  A voxel, i.e., volume element, represents a single
>>>> value for
>>>> a location in 3D space. Voxels are contiguous within the slice and
>>>> depending
>>>> on how data was collected may be contiguous in z also -- you can have
>>>> what we
>>>> call an interslice gap.  In MRI there is no way to acquire a slice with
>>>> infinitesimally thin slice thickness.  Usually the slice thickness is
>>>> more
>>>> than twice that of the in-slice voxel size.
>>>>
>>>> Thanks for the info,
>>>>
>>>> Fred
>>>>
>>>> On Fri, February 9, 2018 11:03 am, Herbie wrote:
>>>>
>>>> Good day!
>>>>>
>>>>> "[...] so that ImageJ treats a single slice as a volume?"
>>>>>
>>>>> A slice is an image!
>>>>>
>>>>> A slice has no extension orthogonal to itself.
>>>>> A pixel also has no extension in any direction because it is a
>>>>> mathematical
>>>>> point in 2D, i.e. a number or sample value.
>>>>> A voxel also has no extension in any direction because it is a
>>>>> mathematical
>>>>> point in 3D, i.e. a number or sample value.
>>>>>
>>>>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>>>>> sometimes equidistant *spacing* of the grid points is often confused
>>>>> with
>>>>> the pixel size, that actually doesn't exist.
>>>>> (A pixel doesn't have a size.)
>>>>>
>>>>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>>>>> sometimes equidistant *spacing* of the grid points is often confused
>>>>> with
>>>>> the voxel size, that actually doesn't exist.
>>>>> (A voxel doesn't have a size.)
>>>>>
>>>>> In short:
>>>>> A slice has no neighbors orthogonal to itself, i.e. there is no
>>>>> (defined)
>>>>> spacing in the third dimension.
>>>>>
>>>>> That said, you may indeed use dummy slices to define the missing
>>>>> spacing!
>>>>>
>>>>> HTH
>>>>>
>>>>> Herbie
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sent from: http://imagej.1557.x6.nabble.com/
>>>>>
>>>>> --
>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>
>>>>>
>>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

Dear Christophe,

to avoid a possible misunderstanding, I don't think that there is
anything wrong with the very article and of course it is in no way
contradictory to signal / systems theory. Personally, I find the
article's style a bit one-sided and in any case it doesn't deal with the
whole story, i.e. "signal discretization and reconstruction of the
continuous signal".

"[...] in any case it's always interesting to learn more about the
"philosophical" aspect of what we're dealing with every day."

I would prefer to call it mathematical not philosophical but you've put
the latter in inverted commas, so it is perfectly ok.

The advantage of mathematical conclusions is that they are generally not
a matter of taste.

For instance and with respect to Fred's tomographic slice question:
Although the slice thickness may be known from the process of data
acquisition, it is not contained in the slice data and therefore can't
be reconstructed from it. However, if one has sufficient discrete
neighboring slices and if one knows that the sampling not only in x and
y but also in z was made according to the sampling theorem, then one can
reconstruct the void volume between the slices (and of course between
the samples of each slice). If one calls this reconstruction "thickness
of the slice" is indeed rather a philosophical question than a
mathematical one...

Best greetings

Herbie

::::::::::::::::::::::::::::::::::::::::::::::::::
Am 10.02.18 um 11:30 schrieb Christophe Leterrier:

> Hi Herbie,
>
> I didn't dare to send this often-posted link for you, Kenneth or the other
> knowledgable people already discussing in this thread - I figured it could
> be a nice introduction to the discussed problem for the whole list. The
> argument made is along the line of your earlier statements about a pixel
> not having a surface or a slice not having a thickness. Sadly I don't read
> German to really understand if your underlying reasons or explanation
> differ from Alvy Ray Smith - in any case it's always interesting to learn
> more about the "philosophical" aspect of what we're dealing with every day.
>
> Best Regards,
>
> Christophe
>
> 2018-02-10 11:09 GMT+01:00 Herbie <[hidden email]>:
>
>> Bonjour Christophe,
>>
>> thanks for chiming in and of course I know this paper. However and
>> although it is to the point, a more thorough view would be desirable.
>>
>> For those who read German, here is a link to an article written for those
>> who prefer thorough scientific explanations that require only moderate
>> mathematical knowledge:
>> <www.gluender.de/Writings/WritingsTexts/WritingsDownloads/20
>> 16_Diskretisierung.zip>
>>
>> Best
>>
>> Herbie
>>
>> ::::::::::::::::::::::::::::::::::::::::::::::::::
>> Am 10.02.18 um 10:47 schrieb Christophe Leterrier:
>>
>> Hi everyone,
>>>
>>> I think the discussion has reached the "post the Alvy Ray Smith paper"
>>> point:
>>> https://news.ycombinator.com/item?id=8614159
>>> "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)"
>>>
>>> As a biologist-microscopist I can't say I understand everything in it, but
>>> I got the part about pixels not being little squares :)
>>>
>>> Christophe
>>>
>>>
>>>
>>> 2018-02-10 10:11 GMT+01:00 Herbie <[hidden email]>:
>>>
>>> Good day Fred,
>>>>
>>>> no problem with your statements. They are compatible with signal theory
>>>> (see my answer to Kenneth).
>>>>
>>>> Mathematical fact is that samples are numbers (or in RGB number triplets)
>>>> that have no spatial or temporal extension.
>>>>
>>>> If you consider the physical process of sampling, the question may arise
>>>> of how an extended little area, or in your tomographic case, an extended
>>>> little volume eventually leads to a number. The answer is easy:
>>>>
>>>>           By spatial integration.
>>>>
>>>> Consequently, it is not the little integration area or the little
>>>> integration volume that is later (after pictorial or tomographic
>>>> reconstruction) displayed as little area or little volume. It is the
>>>> number
>>>> (gray value) that resulted from integration during signal acquisition
>>>> that
>>>> is smeared out or interpolated in some fashion on a display or by a
>>>> projector and presented as a light intensity.
>>>>
>>>> Of course the integration area or volume during signal acquisition may be
>>>> much larger than the sampling distance. In tomography (CT and MRI) this
>>>> is
>>>> not only the case regarding the z-direction but also, usually not as
>>>> pronounced, in the xy-directions. The classic example however, is the
>>>> flying spot scanner in which the spot represents the integration area and
>>>> the sampling distance may be chosen independently from the spot size.
>>>>
>>>> Hopefully I could clarify the topic a bit.
>>>>
>>>> Regards
>>>>
>>>> Herbie
>>>>
>>>> ::::::::::::::::::::::::::::::::::::::::
>>>> Am 10.02.18 um 02:54 schrieb Fred Damen:
>>>>
>>>> Greetings,
>>>>
>>>>>
>>>>> Beauty is in the eyes of the beholder...  and my beauty is MRI.
>>>>>
>>>>> In MRI a slice is a 3D entity with length, width and depth -- which we
>>>>> call
>>>>> slice thickness.  A voxel, i.e., volume element, represents a single
>>>>> value for
>>>>> a location in 3D space. Voxels are contiguous within the slice and
>>>>> depending
>>>>> on how data was collected may be contiguous in z also -- you can have
>>>>> what we
>>>>> call an interslice gap.  In MRI there is no way to acquire a slice with
>>>>> infinitesimally thin slice thickness.  Usually the slice thickness is
>>>>> more
>>>>> than twice that of the in-slice voxel size.
>>>>>
>>>>> Thanks for the info,
>>>>>
>>>>> Fred
>>>>>
>>>>> On Fri, February 9, 2018 11:03 am, Herbie wrote:
>>>>>
>>>>> Good day!
>>>>>>
>>>>>> "[...] so that ImageJ treats a single slice as a volume?"
>>>>>>
>>>>>> A slice is an image!
>>>>>>
>>>>>> A slice has no extension orthogonal to itself.
>>>>>> A pixel also has no extension in any direction because it is a
>>>>>> mathematical
>>>>>> point in 2D, i.e. a number or sample value.
>>>>>> A voxel also has no extension in any direction because it is a
>>>>>> mathematical
>>>>>> point in 3D, i.e. a number or sample value.
>>>>>>
>>>>>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>>>>>> sometimes equidistant *spacing* of the grid points is often confused
>>>>>> with
>>>>>> the pixel size, that actually doesn't exist.
>>>>>> (A pixel doesn't have a size.)
>>>>>>
>>>>>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>>>>>> sometimes equidistant *spacing* of the grid points is often confused
>>>>>> with
>>>>>> the voxel size, that actually doesn't exist.
>>>>>> (A voxel doesn't have a size.)
>>>>>>
>>>>>> In short:
>>>>>> A slice has no neighbors orthogonal to itself, i.e. there is no
>>>>>> (defined)
>>>>>> spacing in the third dimension.
>>>>>>
>>>>>> That said, you may indeed use dummy slices to define the missing
>>>>>> spacing!
>>>>>>
>>>>>> HTH
>>>>>>
>>>>>> Herbie
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from: http://imagej.1557.x6.nabble.com/
>>>>>>
>>>>>> --
>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>
>>>>>>
>>>>>> --
>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>
>>>>>
>>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings Herbie,

Let me start by thanking you for your responses and dedication to ImageJ,
et.el. We are looking at the data that ImageJ can manipulate from differing
perspectives.

The datasets that I view as images are more than the math or signal processing
that went into the acquisition.  There is the NMR physics and physiology that
is involved that defines what is in this space that you are simplifying to
just a number. It matters where the voxel is and how big it is because there
are many different entities contained in that voxel.  I collect many versions
of said collection of voxels with differing physical inputs to tease out what
is happening within said voxels, thus my interest in Hyperstacks.  I need to
analyze that data in a voxel through the frame dimension, be it diffusion
weighting, labeled blood passage, various flips angles, etc.  Thus my question
regarding 'T project...' and 'Plot T axis profile...'?

Having the frame dimension represented as the third spatial dimension to me
seems to be wrong, even if there is differing opinions of infinitesimal verse
finite spatial extent.  My view from what I need to use ImageJ to accomplish.

In the case of MRI the answer you give is not as simple as you portray.  The
signal that is acquired is in the frequency domain and it comes from region of
space drastically larger than the space that a voxel represents. In fact every
acquired sample contains information from the entire Field Of View of the
dataset acquired.  Depending on if a slice is being acquired in 2D or 3D the
spatial extent of the slice in the z direction can be spatially limited or
intertwined through out the entire FOV, respectively.

Thanks expressing your views,

Fred

On Sat, February 10, 2018 3:11 am, Herbie wrote:

> Good day Fred,
>
> no problem with your statements. They are compatible with signal theory
> (see my answer to Kenneth).
>
> Mathematical fact is that samples are numbers (or in RGB number
> triplets) that have no spatial or temporal extension.
>
> If you consider the physical process of sampling, the question may arise
> of how an extended little area, or in your tomographic case, an extended
> little volume eventually leads to a number. The answer is easy:
>
> By spatial integration.
>
> Consequently, it is not the little integration area or the little
> integration volume that is later (after pictorial or tomographic
> reconstruction) displayed as little area or little volume. It is the
> number (gray value) that resulted from integration during signal
> acquisition that is smeared out or interpolated in some fashion on a
> display or by a projector and presented as a light intensity.
>
> Of course the integration area or volume during signal acquisition may
> be much larger than the sampling distance. In tomography (CT and MRI)
> this is not only the case regarding the z-direction but also, usually
> not as pronounced, in the xy-directions. The classic example however, is
> the flying spot scanner in which the spot represents the integration
> area and the sampling distance may be chosen independently from the spot
> size.
>
> Hopefully I could clarify the topic a bit.
>
> Regards
>
> Herbie
>
> ::::::::::::::::::::::::::::::::::::::::
> Am 10.02.18 um 02:54 schrieb Fred Damen:
>> Greetings,
>>
>> Beauty is in the eyes of the beholder...  and my beauty is MRI.
>>
>> In MRI a slice is a 3D entity with length, width and depth -- which we call
>> slice thickness.  A voxel, i.e., volume element, represents a single value
>> for
>> a location in 3D space. Voxels are contiguous within the slice and depending
>> on how data was collected may be contiguous in z also -- you can have what
>> we
>> call an interslice gap.  In MRI there is no way to acquire a slice with
>> infinitesimally thin slice thickness.  Usually the slice thickness is more
>> than twice that of the in-slice voxel size.
>>
>> Thanks for the info,
>>
>> Fred
>>
>> On Fri, February 9, 2018 11:03 am, Herbie wrote:
>>> Good day!
>>>
>>> "[...] so that ImageJ treats a single slice as a volume?"
>>>
>>> A slice is an image!
>>>
>>> A slice has no extension orthogonal to itself.
>>> A pixel also has no extension in any direction because it is a mathematical
>>> point in 2D, i.e. a number or sample value.
>>> A voxel also has no extension in any direction because it is a mathematical
>>> point in 3D, i.e. a number or sample value.
>>>
>>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>>> sometimes equidistant *spacing* of the grid points is often confused with
>>> the pixel size, that actually doesn't exist.
>>> (A pixel doesn't have a size.)
>>>
>>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>>> sometimes equidistant *spacing* of the grid points is often confused with
>>> the voxel size, that actually doesn't exist.
>>> (A voxel doesn't have a size.)
>>>
>>> In short:
>>> A slice has no neighbors orthogonal to itself, i.e. there is no (defined)
>>> spacing in the third dimension.
>>>
>>> That said, you may indeed use dummy slices to define the missing spacing!
>>>
>>> HTH
>>>
>>> Herbie
>>>
>>>
>>>
>>> --
>>> Sent from: http://imagej.1557.x6.nabble.com/
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings,

Most MRI datasets, e.g., DICOM, files contain the slice thickness and in some
ways of viewing MRI images it is indeed used.  Voxels have dimensions.  Almost
all the time, the voxels within the slice plane, (i.e., xy) is acquired as a
square, thus rarely does anyone try to display the voxels with rectangles
instead of squares when displaying the x,y plane.  The z direction, or third
spatial dimension, which is commonly a different dimension than in the x,y
directions, is displayed including the third dimension, i.e., xz or yz planes,
the voxel is displayed as rectangles.  Also if there are inter-slice gaps,
then black space should be displayed in between voxels in the z direction as
in this case the voxels are not contiguous. If one is trying to compare an
isometric dataset with one that has a different z dimension, this is a very
important issue.

Since, in MRI, the data within a 2D slice or a 3D-dataset is acquired in the
frequency domain, it is correct to say that the space between the voxels in
the xy or xy/xz/yz, respectively, can be interpolated from the acquired data.
The Fourier components, i.e., acquired samples, are discrete, yet represent a
continuous spatial domain.  In Fourier acquired data this is done by
zero-padding. Interpolating in the z direction of a stack of slices is
complicated as the data is not spatially continuous and may not be contiguous.
 In MRI, being able to interpolate in the spatial domain in no way implies the
ability to interpolate in the frequency domain, this would be considered
inventing information.  For example, try acquiring every other line of the
Fourier data and then try to invent the unacquired, i.e., skipped, lines.  In
fact, to be able to extract the interpolated acquired samples within x,y plane
using data acquired from many parallel coils is hot topic in the MRI world,
and, to be able to do it in the z direction is a very hot topic.

Without the philosophical aspect this is just a bunch of numbers...

Thanks,

Fred

On Sat, February 10, 2018 5:07 am, Herbie wrote:

> Dear Christophe,
>
> to avoid a possible misunderstanding, I don't think that there is
> anything wrong with the very article and of course it is in no way
> contradictory to signal / systems theory. Personally, I find the
> article's style a bit one-sided and in any case it doesn't deal with the
> whole story, i.e. "signal discretization and reconstruction of the
> continuous signal".
>
> "[...] in any case it's always interesting to learn more about the
> "philosophical" aspect of what we're dealing with every day."
>
> I would prefer to call it mathematical not philosophical but you've put
> the latter in inverted commas, so it is perfectly ok.
>
> The advantage of mathematical conclusions is that they are generally not
> a matter of taste.
>
> For instance and with respect to Fred's tomographic slice question:
> Although the slice thickness may be known from the process of data
> acquisition, it is not contained in the slice data and therefore can't
> be reconstructed from it. However, if one has sufficient discrete
> neighboring slices and if one knows that the sampling not only in x and
> y but also in z was made according to the sampling theorem, then one can
> reconstruct the void volume between the slices (and of course between
> the samples of each slice). If one calls this reconstruction "thickness
> of the slice" is indeed rather a philosophical question than a
> mathematical one...
>
> Best greetings
>
> Herbie
>
> ::::::::::::::::::::::::::::::::::::::::::::::::::
> Am 10.02.18 um 11:30 schrieb Christophe Leterrier:
>> Hi Herbie,
>>
>> I didn't dare to send this often-posted link for you, Kenneth or the other
>> knowledgable people already discussing in this thread - I figured it could
>> be a nice introduction to the discussed problem for the whole list. The
>> argument made is along the line of your earlier statements about a pixel
>> not having a surface or a slice not having a thickness. Sadly I don't read
>> German to really understand if your underlying reasons or explanation
>> differ from Alvy Ray Smith - in any case it's always interesting to learn
>> more about the "philosophical" aspect of what we're dealing with every day.
>>
>> Best Regards,
>>
>> Christophe
>>
>> 2018-02-10 11:09 GMT+01:00 Herbie <[hidden email]>:
>>
>>> Bonjour Christophe,
>>>
>>> thanks for chiming in and of course I know this paper. However and
>>> although it is to the point, a more thorough view would be desirable.
>>>
>>> For those who read German, here is a link to an article written for those
>>> who prefer thorough scientific explanations that require only moderate
>>> mathematical knowledge:
>>> <www.gluender.de/Writings/WritingsTexts/WritingsDownloads/20
>>> 16_Diskretisierung.zip>
>>>
>>> Best
>>>
>>> Herbie
>>>
>>> ::::::::::::::::::::::::::::::::::::::::::::::::::
>>> Am 10.02.18 um 10:47 schrieb Christophe Leterrier:
>>>
>>> Hi everyone,
>>>>
>>>> I think the discussion has reached the "post the Alvy Ray Smith paper"
>>>> point:
>>>> https://news.ycombinator.com/item?id=8614159
>>>> "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)"
>>>>
>>>> As a biologist-microscopist I can't say I understand everything in it, but
>>>> I got the part about pixels not being little squares :)
>>>>
>>>> Christophe
>>>>
>>>>
>>>>
>>>> 2018-02-10 10:11 GMT+01:00 Herbie <[hidden email]>:
>>>>
>>>> Good day Fred,
>>>>>
>>>>> no problem with your statements. They are compatible with signal theory
>>>>> (see my answer to Kenneth).
>>>>>
>>>>> Mathematical fact is that samples are numbers (or in RGB number triplets)
>>>>> that have no spatial or temporal extension.
>>>>>
>>>>> If you consider the physical process of sampling, the question may arise
>>>>> of how an extended little area, or in your tomographic case, an extended
>>>>> little volume eventually leads to a number. The answer is easy:
>>>>>
>>>>>           By spatial integration.
>>>>>
>>>>> Consequently, it is not the little integration area or the little
>>>>> integration volume that is later (after pictorial or tomographic
>>>>> reconstruction) displayed as little area or little volume. It is the
>>>>> number
>>>>> (gray value) that resulted from integration during signal acquisition
>>>>> that
>>>>> is smeared out or interpolated in some fashion on a display or by a
>>>>> projector and presented as a light intensity.
>>>>>
>>>>> Of course the integration area or volume during signal acquisition may be
>>>>> much larger than the sampling distance. In tomography (CT and MRI) this
>>>>> is
>>>>> not only the case regarding the z-direction but also, usually not as
>>>>> pronounced, in the xy-directions. The classic example however, is the
>>>>> flying spot scanner in which the spot represents the integration area and
>>>>> the sampling distance may be chosen independently from the spot size.
>>>>>
>>>>> Hopefully I could clarify the topic a bit.
>>>>>
>>>>> Regards
>>>>>
>>>>> Herbie
>>>>>
>>>>> ::::::::::::::::::::::::::::::::::::::::
>>>>> Am 10.02.18 um 02:54 schrieb Fred Damen:
>>>>>
>>>>> Greetings,
>>>>>
>>>>>>
>>>>>> Beauty is in the eyes of the beholder...  and my beauty is MRI.
>>>>>>
>>>>>> In MRI a slice is a 3D entity with length, width and depth -- which we
>>>>>> call
>>>>>> slice thickness.  A voxel, i.e., volume element, represents a single
>>>>>> value for
>>>>>> a location in 3D space. Voxels are contiguous within the slice and
>>>>>> depending
>>>>>> on how data was collected may be contiguous in z also -- you can have
>>>>>> what we
>>>>>> call an interslice gap.  In MRI there is no way to acquire a slice with
>>>>>> infinitesimally thin slice thickness.  Usually the slice thickness is
>>>>>> more
>>>>>> than twice that of the in-slice voxel size.
>>>>>>
>>>>>> Thanks for the info,
>>>>>>
>>>>>> Fred
>>>>>>
>>>>>> On Fri, February 9, 2018 11:03 am, Herbie wrote:
>>>>>>
>>>>>> Good day!
>>>>>>>
>>>>>>> "[...] so that ImageJ treats a single slice as a volume?"
>>>>>>>
>>>>>>> A slice is an image!
>>>>>>>
>>>>>>> A slice has no extension orthogonal to itself.
>>>>>>> A pixel also has no extension in any direction because it is a
>>>>>>> mathematical
>>>>>>> point in 2D, i.e. a number or sample value.
>>>>>>> A voxel also has no extension in any direction because it is a
>>>>>>> mathematical
>>>>>>> point in 3D, i.e. a number or sample value.
>>>>>>>
>>>>>>> Pixels, i.e. values at points in 2D, are arranged in a 2D grid and the
>>>>>>> sometimes equidistant *spacing* of the grid points is often confused
>>>>>>> with
>>>>>>> the pixel size, that actually doesn't exist.
>>>>>>> (A pixel doesn't have a size.)
>>>>>>>
>>>>>>> Voxels, i.e. values at points in 3D, are arranged in a 3D grid and the
>>>>>>> sometimes equidistant *spacing* of the grid points is often confused
>>>>>>> with
>>>>>>> the voxel size, that actually doesn't exist.
>>>>>>> (A voxel doesn't have a size.)
>>>>>>>
>>>>>>> In short:
>>>>>>> A slice has no neighbors orthogonal to itself, i.e. there is no
>>>>>>> (defined)
>>>>>>> spacing in the third dimension.
>>>>>>>
>>>>>>> That said, you may indeed use dummy slices to define the missing
>>>>>>> spacing!
>>>>>>>
>>>>>>> HTH
>>>>>>>
>>>>>>> Herbie
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sent from: http://imagej.1557.x6.nabble.com/
>>>>>>>
>>>>>>> --
>>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>
>>>>>>
>>>>>> --
>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>
>>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

Dear experts,

presently and to my knowledge there are 4 ways to pass a variable to a
macro run-command.

E.g. in case of image normalization one could write

getRawStatistics( N, mn, mi, mx );

// 1.
if ( mx != 0 ) run( "Divide...", "value=&mx" );

// 2.
if ( mx != 0 ) run( "Divide...", "value=[mx]" );

// 3.
if ( mx != 0 ) run( "Divide...", "value=" + d2s( mx, 9 ) );

// 4.
if ( mx != 0 ) run( "Divide...", "value=" + mx );

 From my investigation, #1. to #3. give the same and best precision and
#4. does not. The fact that #4. is depreciated is known since long and
#3. was recommended instead. However, the newer techniques #1. and #2.
have not yet been specified with respect to precision and that's why I ask:

Do #1. to #3. behave equally with respect to numerical precision?

Best regards

Herbie

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html