http://imagej.273.s1.nabble.com/Image-Byte-Order-Correction-tp5023490p5023501.html
order. Thank you again for your patience!
> 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: +1 (631)202-9445*
> > 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>
*M.E. / Ph.D. student*
people unless you get permission from the writer himself. All rights