Image Byte Order Correction

[Xinjie Cao]

Dear all,

I need to convert a big-endian .i33 phantom image into a little-endian .i33
image. I tried to convert one into a little-endian order raw image as
following official guide,
```
https://imagej.nih.gov/ij/docs/menus/file.html
 By default, 16-bit and 32-bit images are saved using big-endian byte
order. Check "Save TIFF and Raw in Intel Byte Order" in the
*Edit>Options>Input/Output* dialog box to save using little-endian byte
order.
```
While it looks like it is not working as it should be, does anyone have
some experience on that? Any answer will be highly appreciated! Thank you!

Best,
Xinjie

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

[Fred Damen]

Greetings Xinjie,

Take the source binary file and display it in a hex dump.  My preferred is
Gvim(Tools>Convert To HEX), or on Linux hexdump, and look at the first
voxel.  Every 4 character block is a 16 bit integer.  In big endian big
numbers (>255) should have nonzero first byte, small numbers (<256) zero
first byte.

Read the binary image into ImageJ. Check the voxel at 0,0 and if its
bigness is the same as in the hexdump then the image was read in
correctly.

Write out the binary image in little endian format and display it as a hex
dump.  If the bytes for the first 16bit number are swapped then you
accomplished your task.

Note, using Gvim you can edit the displayed hex and set the number to
something obvious, then convert back to binary and save.

OR on Linux
dd conv=swab <infile >outfile

Enjoy,

Fred

On Wed, June 10, 2020 9:28 pm, Xinjie Cao wrote:

> Dear all,
>
> I need to convert a big-endian .i33 phantom image into a little-endian
> .i33
> image. I tried to convert one into a little-endian order raw image as
> following official guide,
> ```
> https://imagej.nih.gov/ij/docs/menus/file.html
>  By default, 16-bit and 32-bit images are saved using big-endian byte
> order. Check "Save TIFF and Raw in Intel Byte Order" in the
> *Edit>Options>Input/Output* dialog box to save using little-endian byte
> order.
> ```
> While it looks like it is not working as it should be, does anyone have
> some experience on that? Any answer will be highly appreciated! Thank you!
>
> Best,
> Xinjie
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

[Xinjie Cao]

Dear Fred,

Thanks for your immediate response, really appreciate it. I think your
solution is awesome and I tried it step by step. Here I have one more
question about your description,
```
Write out the binary image in little endian format and display it as a hex
dump.
```
So how do you write out the binary image in little endian format? I only
find a check called 'Save TIFF and raw in Intel byte order', and when I
tried this one, the result is still a big endian byte order file I think,
for example as following,
```
Original file in hex format:
041b940: 0000 0000 0000 803f 0000 803f 0000 803f  .......?...?...?
041b950: 0000 803f 0000 803f 0000 c442 0000 c442  ...?...?...B...B
041b960: 0000 c442 0000 c442 0000 c442 0000 c442  ...B...B...B...B

Saved new raw file in hex format:
041b940: 0000 0000 003f 0047 003f 0047 003f 0047  .....?.G.?.G.?.G
041b950: 003f 0047 003f 0047 0042 4447 0042 4447  .?.G.?.G.BDG.BDG
041b960: 0042 4447 0042 4447 0042 4447 0042 4447  .BDG.BDG.BDG.BDG
```
As you can see above, there is still non-zero first byte in the new output
raw file. Could you explain explicitly how you write out a little endian
new file and recommend me a way to convert the output raw file to .i33
format if you can? I am totally a rookie in image reconstruction and I
really appreciate your help! Thank you!

Best,

On Thu, Jun 11, 2020 at 1:12 AM Fred Damen <[hidden email]> wrote:

> Greetings Xinjie,
>
> Take the source binary file and display it in a hex dump.  My preferred is
> Gvim(Tools>Convert To HEX), or on Linux hexdump, and look at the first
> voxel.  Every 4 character block is a 16 bit integer.  In big endian big
> numbers (>255) should have nonzero first byte, small numbers (<256) zero
> first byte.
>
> Read the binary image into ImageJ. Check the voxel at 0,0 and if its
> bigness is the same as in the hexdump then the image was read in
> correctly.
>
> Write out the binary image in little endian format and display it as a hex
> dump.  If the bytes for the first 16bit number are swapped then you
> accomplished your task.
>
> Note, using Gvim you can edit the displayed hex and set the number to
> something obvious, then convert back to binary and save.
>
> OR on Linux
> dd conv=swab <infile >outfile
>
> Enjoy,
>
> Fred
>
> On Wed, June 10, 2020 9:28 pm, Xinjie Cao wrote:
> > Dear all,
> >
> > I need to convert a big-endian .i33 phantom image into a little-endian
> > .i33
> > image. I tried to convert one into a little-endian order raw image as
> > following official guide,
> > ```
> > https://imagej.nih.gov/ij/docs/menus/file.html
> >  By default, 16-bit and 32-bit images are saved using big-endian byte
> > order. Check "Save TIFF and Raw in Intel Byte Order" in the
> > *Edit>Options>Input/Output* dialog box to save using little-endian byte
> > order.
> > ```
> > While it looks like it is not working as it should be, does anyone have
> > some experience on that? Any answer will be highly appreciated! Thank
> you!
> >
> > Best,
> > Xinjie
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
*....................................................*
*Xinjie Cao*
*M.E. / Ph.D. student*
*Research Project Assistant*
*Department of Electrical and Computer Engineering & Radiology *
*Novel Medical Imaging Technologies Lab*
*Health Science Center Level 8*
*Stony Brook, NY 11794-8460 *
*Tel: [phone]*
you.stonybrook.edu/goldan/people/
*email: **xinjie.cao@stonybroo*k.edu <[hidden email]>


*....................................................*
It is prohibited to distribute or publish the files attached to any other
people unless you get permission from the writer himself. All rights
reserved.

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

[Albert Cardona-2]

Hi xinjie,
If you feel adventurous, you could try writing the TIFF file yourself.
It is not as tricky as it may seem.

Here is a script on how to parse TIFF file headers, which explains how
the TIFF header and file format structure looks like.
https://www.ini.uzh.ch/~acardona/fiji-tutorial/#load-specific-stack-slices

Here is script (example #6) on how to read specific stack slices from
a TIFF file:
https://www.ini.uzh.ch/~acardona/fiji-tutorial/#load-specific-stack-slices

And here is a script on writing TIFF files. Where it creates the
ByteBuffer bb (line 66), you could then call bb.order to change it to
little endian, like this:

bb = ByteBuffer.wrap(bytes).order(ByteOrder.Little_ENDIAN)

https://github.com/acardona/scripts/blob/dev/python/imagej/examples/imglib2_bit_image_as_TIFF.py#L66

Otherwise, the simplest, scripting way to do this is to grab the pixel
array from ImageJ, put it into a ByteBuffer, change the byte order to
LITTLE_ENDIAN, view it as a ShortBuffer, and then get the short[]
array out with its bytes now in little endian ordering, and then set
the array again to replace the original one in the ShortProcessor.
Save the TIFF file normally. In disk, the bytes will be in little
endian. Something like this (untested, in jython):

from ij import IJ
from java.nio import ByteBuffer, ByteOrder
imp = IJ.getImage() # current image
ip = imp.getProcessor() # expecting a ShortProcessor
shorts = ip.getPixels() # the underlying original short[] array
bb = ByteBuffer.allocate(len(shorts) * 2).order(ByteOrder.LITTLE_ENDIAN)
bb.asShortBuffer().write(shorts) # write in little endian
ip.setPixels(bb.array()) # replace pixels array
IJ.save(imp, "/path/to/file.tif") # write to disk in little endian

Best,

Albert

Missatge de Xinjie Cao <[hidden email]> del dia dj., 11 de
juny 2020 a les 15:38:

>
> Dear Fred,
>
> Thanks for your immediate response, really appreciate it. I think your
> solution is awesome and I tried it step by step. Here I have one more
> question about your description,
> ```
> Write out the binary image in little endian format and display it as a hex
> dump.
> ```
> So how do you write out the binary image in little endian format? I only
> find a check called 'Save TIFF and raw in Intel byte order', and when I
> tried this one, the result is still a big endian byte order file I think,
> for example as following,
> ```
> Original file in hex format:
> 041b940: 0000 0000 0000 803f 0000 803f 0000 803f  .......?...?...?
> 041b950: 0000 803f 0000 803f 0000 c442 0000 c442  ...?...?...B...B
> 041b960: 0000 c442 0000 c442 0000 c442 0000 c442  ...B...B...B...B
>
> Saved new raw file in hex format:
> 041b940: 0000 0000 003f 0047 003f 0047 003f 0047  .....?.G.?.G.?.G
> 041b950: 003f 0047 003f 0047 0042 4447 0042 4447  .?.G.?.G.BDG.BDG
> 041b960: 0042 4447 0042 4447 0042 4447 0042 4447  .BDG.BDG.BDG.BDG
> ```
> As you can see above, there is still non-zero first byte in the new output
> raw file. Could you explain explicitly how you write out a little endian
> new file and recommend me a way to convert the output raw file to .i33
> format if you can? I am totally a rookie in image reconstruction and I
> really appreciate your help! Thank you!
>
> Best,
>
> On Thu, Jun 11, 2020 at 1:12 AM Fred Damen <[hidden email]> wrote:
>
> > Greetings Xinjie,
> >
> > Take the source binary file and display it in a hex dump.  My preferred is
> > Gvim(Tools>Convert To HEX), or on Linux hexdump, and look at the first
> > voxel.  Every 4 character block is a 16 bit integer.  In big endian big
> > numbers (>255) should have nonzero first byte, small numbers (<256) zero
> > first byte.
> >
> > Read the binary image into ImageJ. Check the voxel at 0,0 and if its
> > bigness is the same as in the hexdump then the image was read in
> > correctly.
> >
> > Write out the binary image in little endian format and display it as a hex
> > dump.  If the bytes for the first 16bit number are swapped then you
> > accomplished your task.
> >
> > Note, using Gvim you can edit the displayed hex and set the number to
> > something obvious, then convert back to binary and save.
> >
> > OR on Linux
> > dd conv=swab <infile >outfile
> >
> > Enjoy,
> >
> > Fred
> >
> > On Wed, June 10, 2020 9:28 pm, Xinjie Cao wrote:
> > > Dear all,
> > >
> > > I need to convert a big-endian .i33 phantom image into a little-endian
> > > .i33
> > > image. I tried to convert one into a little-endian order raw image as
> > > following official guide,
> > > ```
> > > https://imagej.nih.gov/ij/docs/menus/file.html
> > >  By default, 16-bit and 32-bit images are saved using big-endian byte
> > > order. Check "Save TIFF and Raw in Intel Byte Order" in the
> > > *Edit>Options>Input/Output* dialog box to save using little-endian byte
> > > order.
> > > ```
> > > While it looks like it is not working as it should be, does anyone have
> > > some experience on that? Any answer will be highly appreciated! Thank
> > you!
> > >
> > > Best,
> > > Xinjie
> > >
> > > --
> > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> > >
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
>
> --
> *....................................................*
> *Xinjie Cao*
> *M.E. / Ph.D. student*
> *Research Project Assistant*
> *Department of Electrical and Computer Engineering & Radiology *
> *Novel Medical Imaging Technologies Lab*
> *Health Science Center Level 8*
> *Stony Brook, NY 11794-8460 *
> *Tel: [phone]*
> you.stonybrook.edu/goldan/people/
> *email: **xinjie.cao@stonybroo*k.edu <[hidden email]>
>
>
> *....................................................*
> It is prohibited to distribute or publish the files attached to any other
> people unless you get permission from the writer himself. All rights
> reserved.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

[Fred Damen]

Greetings Xinjie,

I assumed that your data was in 16bit unsigned integers.  From your data I
suspect that this is not completely true.  It seems as though you have
data stored in 32bit chunks with only 16bits of data, which could be
either floating point or integer.  The data seems to have 16bit word swap
with a fixed manipulation of the number is happening in between input and
output.  From the form of the number I suspect that the input is in
floating point.

I said 'seems' as there are several ways of accomplishing what appears in
your data, so...

What is the actual input number format of the data?, i.e., what does the
header information tell you?
What was the input format of the number told to ImageJ?
what should the value at offset 041b944 be?, Is it the same in ImageJ?
To answer this question I generally cheat and set the first byte to 01.
This eliminates the question of row vs column major. Also is will be easy
to distinguish actual vs interpreted number format, i.e.,
if 0100 0000 is interpreted as x then y
1 then little endian in either 16bit or 32bit integer
256 then big endian in either 16bit or 32bit integer
8388608 then little endian in 32bit integer.
0 then probably floating point
The following number will determine number of bits, but will require
knowledge if row or column major.

If these were read in as 16bit integers (803f) the sign is on and ImageJ
does not like signed 16bit data, and then adds 32767 to the value.  This
may explain the manipulation of the values. Note that I know this from
reading in 16bit (assumed to be signed but actually not) DICOM data; raw
data may be different.  Also, note, sometimes when converting from
ShortProcessor to FloatProcessor a rescaling is performed.

The number format written out should be the same the ImagePlus, i.e.,
image window, see Image>Type>___.

I do not know .i33 format.  I google(d) it and it seems to be just a raw
format, with a separate .h33 header file.  The data should be written the
same as read in, so the format should be the same.

Fred

N.B.: the first byte, and 32bit word, is zero in both the input and output.


On Thu, June 11, 2020 9:37 am, Xinjie Cao wrote:

> Dear Fred,
>
> Thanks for your immediate response, really appreciate it. I think your
> solution is awesome and I tried it step by step. Here I have one more
> question about your description,
> ```
> Write out the binary image in little endian format and display it as a hex
> dump.
> ```
> So how do you write out the binary image in little endian format? I only
> find a check called 'Save TIFF and raw in Intel byte order', and when I
> tried this one, the result is still a big endian byte order file I think,
> for example as following,
> ```
> Original file in hex format:
> 041b940: 0000 0000 0000 803f 0000 803f 0000 803f  .......?...?...?
> 041b950: 0000 803f 0000 803f 0000 c442 0000 c442  ...?...?...B...B
> 041b960: 0000 c442 0000 c442 0000 c442 0000 c442  ...B...B...B...B
>
> Saved new raw file in hex format:
> 041b940: 0000 0000 003f 0047 003f 0047 003f 0047  .....?.G.?.G.?.G
> 041b950: 003f 0047 003f 0047 0042 4447 0042 4447  .?.G.?.G.BDG.BDG
> 041b960: 0042 4447 0042 4447 0042 4447 0042 4447  .BDG.BDG.BDG.BDG
> ```
> As you can see above, there is still non-zero first byte in the new output
> raw file. Could you explain explicitly how you write out a little endian
> new file and recommend me a way to convert the output raw file to .i33
> format if you can? I am totally a rookie in image reconstruction and I
> really appreciate your help! Thank you!
>
> Best,
>
> On Thu, Jun 11, 2020 at 1:12 AM Fred Damen <[hidden email]> wrote:
>
>> Greetings Xinjie,
>>
>> Take the source binary file and display it in a hex dump.  My preferred
>> is
>> Gvim(Tools>Convert To HEX), or on Linux hexdump, and look at the first
>> voxel.  Every 4 character block is a 16 bit integer.  In big endian big
>> numbers (>255) should have nonzero first byte, small numbers (<256) zero
>> first byte.
>>
>> Read the binary image into ImageJ. Check the voxel at 0,0 and if its
>> bigness is the same as in the hexdump then the image was read in
>> correctly.
>>
>> Write out the binary image in little endian format and display it as a
>> hex
>> dump.  If the bytes for the first 16bit number are swapped then you
>> accomplished your task.
>>
>> Note, using Gvim you can edit the displayed hex and set the number to
>> something obvious, then convert back to binary and save.
>>
>> OR on Linux
>> dd conv=swab <infile >outfile
>>
>> Enjoy,
>>
>> Fred
>>
>> On Wed, June 10, 2020 9:28 pm, Xinjie Cao wrote:
>> > Dear all,
>> >
>> > I need to convert a big-endian .i33 phantom image into a little-endian
>> > .i33
>> > image. I tried to convert one into a little-endian order raw image as
>> > following official guide,
>> > ```
>> > https://imagej.nih.gov/ij/docs/menus/file.html
>> >  By default, 16-bit and 32-bit images are saved using big-endian byte
>> > order. Check "Save TIFF and Raw in Intel Byte Order" in the
>> > *Edit>Options>Input/Output* dialog box to save using little-endian
>> byte
>> > order.
>> > ```
>> > While it looks like it is not working as it should be, does anyone
>> have
>> > some experience on that? Any answer will be highly appreciated! Thank
>> you!
>> >
>> > Best,
>> > Xinjie
>> >
>> > --
>> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>> >
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
>
> --
> *....................................................*
> *Xinjie Cao*
> *M.E. / Ph.D. student*
> *Research Project Assistant*
> *Department of Electrical and Computer Engineering & Radiology *
> *Novel Medical Imaging Technologies Lab*
> *Health Science Center Level 8*
> *Stony Brook, NY 11794-8460 *
> *Tel: [phone]*
> you.stonybrook.edu/goldan/people/
> *email: **xinjie.cao@stonybroo*k.edu <[hidden email]>
>
>
> *....................................................*
> It is prohibited to distribute or publish the files attached to any other
> people unless you get permission from the writer himself. All rights
> reserved.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

[Xinjie Cao]

Dear Fred,

Thanks for your explicit explain, I think I have got your point of the byte
order. Thank you again for your patience!

Also, thanks for Albert suggestion!

Best,
On Thu, Jun 11, 2020 at 3:03 PM Fred Damen <[hidden email]> wrote:

> Greetings Xinjie,
>
> I assumed that your data was in 16bit unsigned integers.  From your data I
> suspect that this is not completely true.  It seems as though you have
> data stored in 32bit chunks with only 16bits of data, which could be
> either floating point or integer.  The data seems to have 16bit word swap
> with a fixed manipulation of the number is happening in between input and
> output.  From the form of the number I suspect that the input is in
> floating point.
>
> I said 'seems' as there are several ways of accomplishing what appears in
> your data, so...
>
> What is the actual input number format of the data?, i.e., what does the
> header information tell you?
> What was the input format of the number told to ImageJ?
> what should the value at offset 041b944 be?, Is it the same in ImageJ?
> To answer this question I generally cheat and set the first byte to 01.
> This eliminates the question of row vs column major. Also is will be easy
> to distinguish actual vs interpreted number format, i.e.,
> if 0100 0000 is interpreted as x then y
> 1 then little endian in either 16bit or 32bit integer
> 256 then big endian in either 16bit or 32bit integer
> 8388608 then little endian in 32bit integer.
> 0 then probably floating point
> The following number will determine number of bits, but will require
> knowledge if row or column major.
>
> If these were read in as 16bit integers (803f) the sign is on and ImageJ
> does not like signed 16bit data, and then adds 32767 to the value.  This
> may explain the manipulation of the values. Note that I know this from
> reading in 16bit (assumed to be signed but actually not) DICOM data; raw
> data may be different.  Also, note, sometimes when converting from
> ShortProcessor to FloatProcessor a rescaling is performed.
>
> The number format written out should be the same the ImagePlus, i.e.,
> image window, see Image>Type>___.
>
> I do not know .i33 format.  I google(d) it and it seems to be just a raw
> format, with a separate .h33 header file.  The data should be written the
> same as read in, so the format should be the same.
>
> Fred
>
> N.B.: the first byte, and 32bit word, is zero in both the input and output.
>
>
> On Thu, June 11, 2020 9:37 am, Xinjie Cao wrote:
> > Dear Fred,
> >
> > Thanks for your immediate response, really appreciate it. I think your
> > solution is awesome and I tried it step by step. Here I have one more
> > question about your description,
> > ```
> > Write out the binary image in little endian format and display it as a
> hex
> > dump.
> > ```
> > So how do you write out the binary image in little endian format? I only
> > find a check called 'Save TIFF and raw in Intel byte order', and when I
> > tried this one, the result is still a big endian byte order file I think,
> > for example as following,
> > ```
> > Original file in hex format:
> > 041b940: 0000 0000 0000 803f 0000 803f 0000 803f  .......?...?...?
> > 041b950: 0000 803f 0000 803f 0000 c442 0000 c442  ...?...?...B...B
> > 041b960: 0000 c442 0000 c442 0000 c442 0000 c442  ...B...B...B...B
> >
> > Saved new raw file in hex format:
> > 041b940: 0000 0000 003f 0047 003f 0047 003f 0047  .....?.G.?.G.?.G
> > 041b950: 003f 0047 003f 0047 0042 4447 0042 4447  .?.G.?.G.BDG.BDG
> > 041b960: 0042 4447 0042 4447 0042 4447 0042 4447  .BDG.BDG.BDG.BDG
> > ```
> > As you can see above, there is still non-zero first byte in the new
> output
> > raw file. Could you explain explicitly how you write out a little endian
> > new file and recommend me a way to convert the output raw file to .i33
> > format if you can? I am totally a rookie in image reconstruction and I
> > really appreciate your help! Thank you!
> >
> > Best,
> >
> > On Thu, Jun 11, 2020 at 1:12 AM Fred Damen <[hidden email]> wrote:
> >
> >> Greetings Xinjie,
> >>
> >> Take the source binary file and display it in a hex dump.  My preferred
> >> is
> >> Gvim(Tools>Convert To HEX), or on Linux hexdump, and look at the first
> >> voxel.  Every 4 character block is a 16 bit integer.  In big endian big
> >> numbers (>255) should have nonzero first byte, small numbers (<256) zero
> >> first byte.
> >>
> >> Read the binary image into ImageJ. Check the voxel at 0,0 and if its
> >> bigness is the same as in the hexdump then the image was read in
> >> correctly.
> >>
> >> Write out the binary image in little endian format and display it as a
> >> hex
> >> dump.  If the bytes for the first 16bit number are swapped then you
> >> accomplished your task.
> >>
> >> Note, using Gvim you can edit the displayed hex and set the number to
> >> something obvious, then convert back to binary and save.
> >>
> >> OR on Linux
> >> dd conv=swab <infile >outfile
> >>
> >> Enjoy,
> >>
> >> Fred
> >>
> >> On Wed, June 10, 2020 9:28 pm, Xinjie Cao wrote:
> >> > Dear all,
> >> >
> >> > I need to convert a big-endian .i33 phantom image into a little-endian
> >> > .i33
> >> > image. I tried to convert one into a little-endian order raw image as
> >> > following official guide,
> >> > ```
> >> > https://imagej.nih.gov/ij/docs/menus/file.html
> >> >  By default, 16-bit and 32-bit images are saved using big-endian byte
> >> > order. Check "Save TIFF and Raw in Intel Byte Order" in the
> >> > *Edit>Options>Input/Output* dialog box to save using little-endian
> >> byte
> >> > order.
> >> > ```
> >> > While it looks like it is not working as it should be, does anyone
> >> have
> >> > some experience on that? Any answer will be highly appreciated! Thank
> >> you!
> >> >
> >> > Best,
> >> > Xinjie
> >> >
> >> > --
> >> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >> >
> >>
> >> --
> >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >>
> >
> >
> > --
> > *....................................................*
> > *Xinjie Cao*
> > *M.E. / Ph.D. student*
> > *Research Project Assistant*
> > *Department of Electrical and Computer Engineering & Radiology *
> > *Novel Medical Imaging Technologies Lab*
> > *Health Science Center Level 8*
> > *Stony Brook, NY 11794-8460 *
> > *Tel: [phone]*
> > you.stonybrook.edu/goldan/people/
> > *email: **xinjie.cao@stonybroo*k.edu <[hidden email]>
> >
> >
> > *....................................................*
> > It is prohibited to distribute or publish the files attached to any other
> > people unless you get permission from the writer himself. All rights
> > reserved.
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
*....................................................*
*Xinjie Cao*
*M.E. / Ph.D. student*
*Research Project Assistant*
*Department of Electrical and Computer Engineering & Radiology *
*Novel Medical Imaging Technologies Lab*
*Health Science Center Level 8*
*Stony Brook, NY 11794-8460 *
*Tel: [phone]*
you.stonybrook.edu/goldan/people/
*email: **xinjie.cao@stonybroo*k.edu <[hidden email]>


*....................................................*
It is prohibited to distribute or publish the files attached to any other
people unless you get permission from the writer himself. All rights
reserved.

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