Posted by
Fred Damen on
URL: http://imagej.273.s1.nabble.com/Hyperstack-with-nz-1-problem-tp5019980p5020074.html
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>
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html