Float.floatToIntBits & decrements in byte values

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Float.floatToIntBits & decrements in byte values

Thomson Neil (EAST KENT HOSPITALS UNIVERSITY NHS FOUNDATION
              TRUST)
Dear fellow listers

I'm writing a plugin to export a medical image format. Some of the header values are floats. The values are in a hash table and I then save the floats into my header-block by doing a Float.floatToIntBits conversion and then save the 4 byte values, which is (more or less) copied and pasted from the IJ tiff encoder.

I currently have this code snippet in my format encoder:

System.out.println("" + o_value);  //o_value is float value of some hashmap entry
int v = Float.floatToIntBits((Float) o_value);System.out.println("" + v);
System.out.println("" + (byte) ((v >>> 24) & 255));
System.out.println("" + (byte) ((v >>> 16) & 255));
System.out.println("" + (byte) ((v >>> 8) & 255));
System.out.println("" + (byte) (v & 255));
When float values of o_value these are small (say 1E5) everything seems fine, but when they get larger (say 1E7) the byte output does not seem to be as I would expect. If I import and then export ann image without manipulation, the float value decreases, which I've traced to the byte values: if I start by importing an image where this particular float header field has bytes reading (in big-endian)...

76,-46,-20,-18

... I then export the image and re-import it I get:

75,-47,-21,-18

... and again...:

74,-48,-22,-18

A decrement in three of the four bytes. I'm at a loss as to where to go next and I would greatly appreciate some wise words.

Many thanks, Neil

Neil Thomson,
Nuclear Medicine Physics Section,
Medical Physics,
Kent and Canterbury Hospital,
UK. CT1 3NG
+44 (0) 1227 766877

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere
For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail

********************************************************************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Float.floatToIntBits & decrements in byte values

Stephan Saalfeld
Hi,

not seeing the responsible code makes it complicated to guess.  Instead,
you could look at working code and compare to yours.  We've done similar
once for a simple import/export into the POV-Ray df3 format:

Reader:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=blob;f=src-plugins/IO_/io/Open_DF3.java;h=d8cfe4bb33f45942290adaca3a3af930121bf2d0;hb=HEAD#l100

Writer:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=blob;f=src-plugins/IO_/io/Save_DF3.java;h=1d91b24dc491f22779fbe4c18ed72244296ba905;hb=HEAD#l198

The major difference that I can see is that we worked with long instead
int which might be to avoid sign-bit madness.  It's long ago that we've
done this.

Good luck,
Stephan



On Fri, 2010-12-03 at 17:24 +0000, Thomson Neil (East Kent Hospitals NHS
Trust) wrote:

> Dear fellow listers
>
> I'm writing a plugin to export a medical image format. Some of the header values are floats. The values are in a hash table and I then save the floats into my header-block by doing a Float.floatToIntBits conversion and then save the 4 byte values, which is (more or less) copied and pasted from the IJ tiff encoder.
>
> I currently have this code snippet in my format encoder:
>
> System.out.println("" + o_value);  //o_value is float value of some hashmap entry
> int v = Float.floatToIntBits((Float) o_value);System.out.println("" + v);
> System.out.println("" + (byte) ((v >>> 24) & 255));
> System.out.println("" + (byte) ((v >>> 16) & 255));
> System.out.println("" + (byte) ((v >>> 8) & 255));
> System.out.println("" + (byte) (v & 255));
> When float values of o_value these are small (say 1E5) everything seems fine, but when they get larger (say 1E7) the byte output does not seem to be as I would expect. If I import and then export ann image without manipulation, the float value decreases, which I've traced to the byte values: if I start by importing an image where this particular float header field has bytes reading (in big-endian)...
>
> 76,-46,-20,-18
>
> ... I then export the image and re-import it I get:
>
> 75,-47,-21,-18
>
> ... and again...:
>
> 74,-48,-22,-18
>
> A decrement in three of the four bytes. I'm at a loss as to where to go next and I would greatly appreciate some wise words.
>
> Many thanks, Neil
>
> Neil Thomson,
> Nuclear Medicine Physics Section,
> Medical Physics,
> Kent and Canterbury Hospital,
> UK. CT1 3NG
> +44 (0) 1227 766877
>
> ********************************************************************************************************************
>
> This message may contain confidential information. If you are not the intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
>
> Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients
> NHSmail provides an email address for your career in the NHS and can be accessed anywhere
> For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail
>
> ********************************************************************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Float.floatToIntBits & decrements in byte values

Michael Schmid
In reply to this post by Thomson Neil (EAST KENT HOSPITALS UNIVERSITY NHS FOUNDATION TRUST)
Hi Neil,

maybe you have somewhere forgotten the '&255' on conversion from the  
bytes back to an int? You did not enclose the code for this direction.

Michael
________________________________________________________________

On 3 Dec 2010, at 18:24, Thomson Neil (East Kent Hospitals NHS Trust)  
wrote:

> Dear fellow listers
>
> I'm writing a plugin to export a medical image format. Some of the  
> header values are floats. The values are in a hash table and I then  
> save the floats into my header-block by doing a  
> Float.floatToIntBits conversion and then save the 4 byte values,  
> which is (more or less) copied and pasted from the IJ tiff encoder.
>
> I currently have this code snippet in my format encoder:
>
> System.out.println("" + o_value);  //o_value is float value of some  
> hashmap entry
> int v = Float.floatToIntBits((Float) o_value);System.out.println(""  
> + v);
> System.out.println("" + (byte) ((v >>> 24) & 255));
> System.out.println("" + (byte) ((v >>> 16) & 255));
> System.out.println("" + (byte) ((v >>> 8) & 255));
> System.out.println("" + (byte) (v & 255));
> When float values of o_value these are small (say 1E5) everything  
> seems fine, but when they get larger (say 1E7) the byte output does  
> not seem to be as I would expect. If I import and then export ann  
> image without manipulation, the float value decreases, which I've  
> traced to the byte values: if I start by importing an image where  
> this particular float header field has bytes reading (in big-
> endian)...
>
> 76,-46,-20,-18
>
> ... I then export the image and re-import it I get:
>
> 75,-47,-21,-18
>
> ... and again...:
>
> 74,-48,-22,-18
>
> A decrement in three of the four bytes. I'm at a loss as to where  
> to go next and I would greatly appreciate some wise words.
>
> Many thanks, Neil
>
> Neil Thomson,
> Nuclear Medicine Physics Section,
> Medical Physics,
> Kent and Canterbury Hospital,
> UK. CT1 3NG
> +44 (0) 1227 766877
>
> **********************************************************************
> **********************************************
>
> This message may contain confidential information. If you are not  
> the intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-
> mail or take any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
>
> Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all  
> NHS staff in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive  
> information with NHSmail and GSi recipients
> NHSmail provides an email address for your career in the NHS and  
> can be accessed anywhere
> For more information and to find out how you can switch, visit  
> www.connectingforhealth.nhs.uk/nhsmail
>
> **********************************************************************
> **********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Float.floatToIntBits & decrements in byte values

Thomson Neil (EAST KENT HOSPITALS UNIVERSITY NHS FOUNDATION
              TRUST)
Thanks your responses,

Apologies for not including useful code in my original posting, I was afraid of creating a monster. The code I use for reading the floats was just copied and pasted from ij.plugin.DICOM:

/*------------------Snip--------------------------------------
  float getFloat() throws IOException {
    int b0 = getByte();
    int b1 = getByte();
    int b2 = getByte();
    int b3 = getByte();
    int res = 0;
    if (littleEndian) {
      res += b0;
      res += (((long) b1) << 8);
      res += (((long) b2) << 16);
      res += (((long) b3) << 24);
    } else {
      res += b3;
      res += (((long) b2) << 8);
      res += (((long) b1) << 16);
      res += (((long) b0) << 24);
    }
    return Float.intBitsToFloat(res);
  }
------------------Snip--------------------------------------*/

For writiing floats into the header I've used a minor variation on that in ij.io.ImageWriter. Here "loc" is the location in the header block I'm pointing to and imHdr is the header proper.

/*------------------Snip--------------------------------------
private byte[] imHdr = new byte[2048];

// -------snip--------

  void floatToHeader(float m_float, int loc) {
    intToHeader(Float.floatToIntBits(m_float), loc);
  }

  void intToHeader(int v, int loc) {
    if (littleEndian) {
      imHdr[loc] = (byte) (v & 255);
      imHdr[loc + 1] = (byte) ((v >>> 8) & 255);
      imHdr[loc + 2] = (byte) ((v >>> 16) & 255);
      imHdr[loc + 3] = (byte) ((v >>> 24) & 255);
    } else {
      imHdr[loc] = (byte) ((v >>> 24) & 255);
      imHdr[loc + 1] = (byte) ((v >>> 16) & 255);
      imHdr[loc + 2] = (byte) ((v >>> 8) & 255);
      imHdr[loc + 3] = (byte) (v & 255);
    }
  }
------------------Snip--------------------------------------*/

I am indeed not including &255 when I import the bytes, but without a code sample I wouldn't know how to use the logic.

I've tried the above writing operation with (eg) v >>24 instead of (v>>>24) & 255 and I get an identical result with the learge numbers. I can't remember why I used this variation in the first place.

I'm reading in as longs, but I'm not explicitly operating with longs when writing - is that a problem?

Does anything smell fishy?

Thanks again, Neil

Neil Thomson,
Nuclear Medicine Physics Section,
Medical Physics,
Kent and Canterbury Hospital,
UK. CT1 3NG
+44 (0) 1227 766877
________________________________________
From: ImageJ Interest Group [[hidden email]] On Behalf Of Michael Schmid [[hidden email]]
Sent: 06 December 2010 10:28
To: [hidden email]
Subject: Re: Float.floatToIntBits & decrements in byte values

Hi Neil,

maybe you have somewhere forgotten the '&255' on conversion from the
bytes back to an int? You did not enclose the code for this direction.

Michael
________________________________________________________________

On 3 Dec 2010, at 18:24, Thomson Neil (East Kent Hospitals NHS Trust)
wrote:

> Dear fellow listers
>
> I'm writing a plugin to export a medical image format. Some of the
> header values are floats. The values are in a hash table and I then
> save the floats into my header-block by doing a
> Float.floatToIntBits conversion and then save the 4 byte values,
> which is (more or less) copied and pasted from the IJ tiff encoder.
>
> I currently have this code snippet in my format encoder:
>
> System.out.println("" + o_value);  //o_value is float value of some
> hashmap entry
> int v = Float.floatToIntBits((Float) o_value);System.out.println(""
> + v);
> System.out.println("" + (byte) ((v >>> 24) & 255));
> System.out.println("" + (byte) ((v >>> 16) & 255));
> System.out.println("" + (byte) ((v >>> 8) & 255));
> System.out.println("" + (byte) (v & 255));
> When float values of o_value these are small (say 1E5) everything
> seems fine, but when they get larger (say 1E7) the byte output does
> not seem to be as I would expect. If I import and then export ann
> image without manipulation, the float value decreases, which I've
> traced to the byte values: if I start by importing an image where
> this particular float header field has bytes reading (in big-
> endian)...
>
> 76,-46,-20,-18
>
> ... I then export the image and re-import it I get:
>
> 75,-47,-21,-18
>
> ... and again...:
>
> 74,-48,-22,-18
>
> A decrement in three of the four bytes. I'm at a loss as to where
> to go next and I would greatly appreciate some wise words.
>
> Many thanks, Neil
>
> Neil Thomson,
> Nuclear Medicine Physics Section,
> Medical Physics,
> Kent and Canterbury Hospital,
> UK. CT1 3NG
> +44 (0) 1227 766877
>
> **********************************************************************
> **********************************************
>
> This message may contain confidential information. If you are not
> the intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-
> mail or take any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
>
> Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all
> NHS staff in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive
> information with NHSmail and GSi recipients
> NHSmail provides an email address for your career in the NHS and
> can be accessed anywhere
> For more information and to find out how you can switch, visit
> www.connectingforhealth.nhs.uk/nhsmail
>
> **********************************************************************
> **********************************************

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere
For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail

********************************************************************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Float.floatToIntBits & decrements in byte values

Michael Schmid
Hi Neil,

It depends where you get the data from.

ij.plugin.DICOM gets its bytes already converted to int from  
InputStream.read.
This method, by definition, returns the value as an int in the range  
0 to 255.

If you get your bytes from somewhere as 'byte' data type, casting to  
int or long will result in values between -128 and +127. That's  
because Java has only signed byte data. There is no unsigned byte (or  
unsigned short, int, long) data type in Java.

Then, in getFloat, you should have ((long) b1 & (long)0xff) etc.
Actually, it would be enough to use ints there:

res = b0 & 0xff;
res |= (b1 & 0xff) << 8;
res |= (b2 & 0xff) << 16;
res |= (b3 & 0xff) << 24;

Actually, for the last one you could omit the '&0xff'. Shifting by 24  
bits removes any upper bits.
It is a matter of taste whether you prefer the '+' or the bitwise or  
(vertical bar) operator; I like the latter more because it better  
describes to me what the code does.


Michael
________________________________________________________________

On 6 Dec 2010, at 18:13, Thomson Neil (East Kent Hospitals NHS Trust)  
wrote:

> Thanks your responses,
>
> Apologies for not including useful code in my original posting, I  
> was afraid of creating a monster. The code I use for reading the  
> floats was just copied and pasted from ij.plugin.DICOM:
>
> /*------------------Snip--------------------------------------
>   float getFloat() throws IOException {
>     int b0 = getByte();
>     int b1 = getByte();
>     int b2 = getByte();
>     int b3 = getByte();
>     int res = 0;
>     if (littleEndian) {
>       res += b0;
>       res += (((long) b1) << 8);
>       res += (((long) b2) << 16);
>       res += (((long) b3) << 24);
>     } else {
>       res += b3;
>       res += (((long) b2) << 8);
>       res += (((long) b1) << 16);
>       res += (((long) b0) << 24);
>     }
>     return Float.intBitsToFloat(res);
>   }
> ------------------Snip--------------------------------------*/
>
> For writiing floats into the header I've used a minor variation on  
> that in ij.io.ImageWriter. Here "loc" is the location in the header  
> block I'm pointing to and imHdr is the header proper.
>
> /*------------------Snip--------------------------------------
> private byte[] imHdr = new byte[2048];
>
> // -------snip--------
>
>   void floatToHeader(float m_float, int loc) {
>     intToHeader(Float.floatToIntBits(m_float), loc);
>   }
>
>   void intToHeader(int v, int loc) {
>     if (littleEndian) {
>       imHdr[loc] = (byte) (v & 255);
>       imHdr[loc + 1] = (byte) ((v >>> 8) & 255);
>       imHdr[loc + 2] = (byte) ((v >>> 16) & 255);
>       imHdr[loc + 3] = (byte) ((v >>> 24) & 255);
>     } else {
>       imHdr[loc] = (byte) ((v >>> 24) & 255);
>       imHdr[loc + 1] = (byte) ((v >>> 16) & 255);
>       imHdr[loc + 2] = (byte) ((v >>> 8) & 255);
>       imHdr[loc + 3] = (byte) (v & 255);
>     }
>   }
> ------------------Snip--------------------------------------*/
>
> I am indeed not including &255 when I import the bytes, but without  
> a code sample I wouldn't know how to use the logic.
>
> I've tried the above writing operation with (eg) v >>24 instead of  
> (v>>>24) & 255 and I get an identical result with the learge  
> numbers. I can't remember why I used this variation in the first  
> place.
>
> I'm reading in as longs, but I'm not explicitly operating with  
> longs when writing - is that a problem?
>
> Does anything smell fishy?
>
> Thanks again, Neil
>
> Neil Thomson,
> Nuclear Medicine Physics Section,
> Medical Physics,
> Kent and Canterbury Hospital,
> UK. CT1 3NG
> +44 (0) 1227 766877
> ________________________________________
> From: ImageJ Interest Group [[hidden email]] On Behalf Of  
> Michael Schmid [[hidden email]]
> Sent: 06 December 2010 10:28
> To: [hidden email]
> Subject: Re: Float.floatToIntBits & decrements in byte values
>
> Hi Neil,
>
> maybe you have somewhere forgotten the '&255' on conversion from the
> bytes back to an int? You did not enclose the code for this direction.
>
> Michael
> ________________________________________________________________
>
> On 3 Dec 2010, at 18:24, Thomson Neil (East Kent Hospitals NHS Trust)
> wrote:
>
>> Dear fellow listers
>>
>> I'm writing a plugin to export a medical image format. Some of the
>> header values are floats. The values are in a hash table and I then
>> save the floats into my header-block by doing a
>> Float.floatToIntBits conversion and then save the 4 byte values,
>> which is (more or less) copied and pasted from the IJ tiff encoder.
>>
>> I currently have this code snippet in my format encoder:
>>
>> System.out.println("" + o_value);  //o_value is float value of some
>> hashmap entry
>> int v = Float.floatToIntBits((Float) o_value);System.out.println(""
>> + v);
>> System.out.println("" + (byte) ((v >>> 24) & 255));
>> System.out.println("" + (byte) ((v >>> 16) & 255));
>> System.out.println("" + (byte) ((v >>> 8) & 255));
>> System.out.println("" + (byte) (v & 255));
>> When float values of o_value these are small (say 1E5) everything
>> seems fine, but when they get larger (say 1E7) the byte output does
>> not seem to be as I would expect. If I import and then export ann
>> image without manipulation, the float value decreases, which I've
>> traced to the byte values: if I start by importing an image where
>> this particular float header field has bytes reading (in big-
>> endian)...
>>
>> 76,-46,-20,-18
>>
>> ... I then export the image and re-import it I get:
>>
>> 75,-47,-21,-18
>>
>> ... and again...:
>>
>> 74,-48,-22,-18
>>
>> A decrement in three of the four bytes. I'm at a loss as to where
>> to go next and I would greatly appreciate some wise words.
>>
>> Many thanks, Neil
>>
>> Neil Thomson,
>> Nuclear Medicine Physics Section,
>> Medical Physics,
>> Kent and Canterbury Hospital,
>> UK. CT1 3NG
>> +44 (0) 1227 766877
>>
>> *********************************************************************
>> *
>> **********************************************
>>
>> This message may contain confidential information. If you are not
>> the intended recipient please inform the
>> sender that you have received the message in error before deleting  
>> it.
>> Please do not disclose, copy or distribute information in this e-
>> mail or take any action in reliance on its contents:
>> to do so is strictly prohibited and may be unlawful.
>>
>> Thank you for your co-operation.
>>
>> NHSmail is the secure email and directory service available for all
>> NHS staff in England and Scotland
>> NHSmail is approved for exchanging patient data and other sensitive
>> information with NHSmail and GSi recipients
>> NHSmail provides an email address for your career in the NHS and
>> can be accessed anywhere
>> For more information and to find out how you can switch, visit
>> www.connectingforhealth.nhs.uk/nhsmail
>>
>> *********************************************************************
>> *
>> **********************************************
>
> **********************************************************************
> **********************************************
>
> This message may contain confidential information. If you are not  
> the intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-
> mail or take any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
>
> Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all  
> NHS staff in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive  
> information with NHSmail and GSi recipients
> NHSmail provides an email address for your career in the NHS and  
> can be accessed anywhere
> For more information and to find out how you can switch, visit  
> www.connectingforhealth.nhs.uk/nhsmail
>
> **********************************************************************
> **********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Float.floatToIntBits & decrements in byte values

Thomson Neil (EAST KENT HOSPITALS UNIVERSITY NHS FOUNDATION
              TRUST)
Thanks Michael,

the "& 0xff" did the trick

Neil

Neil Thomson,
Nuclear Medicine Physics Section,
Medical Physics,
Kent and Canterbury Hospital,
UK. CT1 3NG
+44 (0) 1227 766877
________________________________________
From: ImageJ Interest Group [[hidden email]] On Behalf Of Michael Schmid [[hidden email]]
Sent: 06 December 2010 17:36
To: [hidden email]
Subject: Re: Float.floatToIntBits & decrements in byte values

Hi Neil,

It depends where you get the data from.

ij.plugin.DICOM gets its bytes already converted to int from
InputStream.read.
This method, by definition, returns the value as an int in the range
0 to 255.

If you get your bytes from somewhere as 'byte' data type, casting to
int or long will result in values between -128 and +127. That's
because Java has only signed byte data. There is no unsigned byte (or
unsigned short, int, long) data type in Java.

Then, in getFloat, you should have ((long) b1 & (long)0xff) etc.
Actually, it would be enough to use ints there:

res = b0 & 0xff;
res |= (b1 & 0xff) << 8;
res |= (b2 & 0xff) << 16;
res |= (b3 & 0xff) << 24;

Actually, for the last one you could omit the '&0xff'. Shifting by 24
bits removes any upper bits.
It is a matter of taste whether you prefer the '+' or the bitwise or
(vertical bar) operator; I like the latter more because it better
describes to me what the code does.


Michael
________________________________________________________________

On 6 Dec 2010, at 18:13, Thomson Neil (East Kent Hospitals NHS Trust)
wrote:

> Thanks your responses,
>
> Apologies for not including useful code in my original posting, I
> was afraid of creating a monster. The code I use for reading the
> floats was just copied and pasted from ij.plugin.DICOM:
>
> /*------------------Snip--------------------------------------
>   float getFloat() throws IOException {
>     int b0 = getByte();
>     int b1 = getByte();
>     int b2 = getByte();
>     int b3 = getByte();
>     int res = 0;
>     if (littleEndian) {
>       res += b0;
>       res += (((long) b1) << 8);
>       res += (((long) b2) << 16);
>       res += (((long) b3) << 24);
>     } else {
>       res += b3;
>       res += (((long) b2) << 8);
>       res += (((long) b1) << 16);
>       res += (((long) b0) << 24);
>     }
>     return Float.intBitsToFloat(res);
>   }
> ------------------Snip--------------------------------------*/
>
> For writiing floats into the header I've used a minor variation on
> that in ij.io.ImageWriter. Here "loc" is the location in the header
> block I'm pointing to and imHdr is the header proper.
>
> /*------------------Snip--------------------------------------
> private byte[] imHdr = new byte[2048];
>
> // -------snip--------
>
>   void floatToHeader(float m_float, int loc) {
>     intToHeader(Float.floatToIntBits(m_float), loc);
>   }
>
>   void intToHeader(int v, int loc) {
>     if (littleEndian) {
>       imHdr[loc] = (byte) (v & 255);
>       imHdr[loc + 1] = (byte) ((v >>> 8) & 255);
>       imHdr[loc + 2] = (byte) ((v >>> 16) & 255);
>       imHdr[loc + 3] = (byte) ((v >>> 24) & 255);
>     } else {
>       imHdr[loc] = (byte) ((v >>> 24) & 255);
>       imHdr[loc + 1] = (byte) ((v >>> 16) & 255);
>       imHdr[loc + 2] = (byte) ((v >>> 8) & 255);
>       imHdr[loc + 3] = (byte) (v & 255);
>     }
>   }
> ------------------Snip--------------------------------------*/
>
> I am indeed not including &255 when I import the bytes, but without
> a code sample I wouldn't know how to use the logic.
>
> I've tried the above writing operation with (eg) v >>24 instead of
> (v>>>24) & 255 and I get an identical result with the learge
> numbers. I can't remember why I used this variation in the first
> place.
>
> I'm reading in as longs, but I'm not explicitly operating with
> longs when writing - is that a problem?
>
> Does anything smell fishy?
>
> Thanks again, Neil
>
> Neil Thomson,
> Nuclear Medicine Physics Section,
> Medical Physics,
> Kent and Canterbury Hospital,
> UK. CT1 3NG
> +44 (0) 1227 766877
> ________________________________________
> From: ImageJ Interest Group [[hidden email]] On Behalf Of
> Michael Schmid [[hidden email]]
> Sent: 06 December 2010 10:28
> To: [hidden email]
> Subject: Re: Float.floatToIntBits & decrements in byte values
>
> Hi Neil,
>
> maybe you have somewhere forgotten the '&255' on conversion from the
> bytes back to an int? You did not enclose the code for this direction.
>
> Michael
> ________________________________________________________________
>
> On 3 Dec 2010, at 18:24, Thomson Neil (East Kent Hospitals NHS Trust)
> wrote:
>
>> Dear fellow listers
>>
>> I'm writing a plugin to export a medical image format. Some of the
>> header values are floats. The values are in a hash table and I then
>> save the floats into my header-block by doing a
>> Float.floatToIntBits conversion and then save the 4 byte values,
>> which is (more or less) copied and pasted from the IJ tiff encoder.
>>
>> I currently have this code snippet in my format encoder:
>>
>> System.out.println("" + o_value);  //o_value is float value of some
>> hashmap entry
>> int v = Float.floatToIntBits((Float) o_value);System.out.println(""
>> + v);
>> System.out.println("" + (byte) ((v >>> 24) & 255));
>> System.out.println("" + (byte) ((v >>> 16) & 255));
>> System.out.println("" + (byte) ((v >>> 8) & 255));
>> System.out.println("" + (byte) (v & 255));
>> When float values of o_value these are small (say 1E5) everything
>> seems fine, but when they get larger (say 1E7) the byte output does
>> not seem to be as I would expect. If I import and then export ann
>> image without manipulation, the float value decreases, which I've
>> traced to the byte values: if I start by importing an image where
>> this particular float header field has bytes reading (in big-
>> endian)...
>>
>> 76,-46,-20,-18
>>
>> ... I then export the image and re-import it I get:
>>
>> 75,-47,-21,-18
>>
>> ... and again...:
>>
>> 74,-48,-22,-18
>>
>> A decrement in three of the four bytes. I'm at a loss as to where
>> to go next and I would greatly appreciate some wise words.
>>
>> Many thanks, Neil
>>
>> Neil Thomson,
>> Nuclear Medicine Physics Section,
>> Medical Physics,
>> Kent and Canterbury Hospital,
>> UK. CT1 3NG
>> +44 (0) 1227 766877
>>
>> *********************************************************************
>> *
>> **********************************************
>>
>> This message may contain confidential information. If you are not
>> the intended recipient please inform the
>> sender that you have received the message in error before deleting
>> it.
>> Please do not disclose, copy or distribute information in this e-
>> mail or take any action in reliance on its contents:
>> to do so is strictly prohibited and may be unlawful.
>>
>> Thank you for your co-operation.
>>
>> NHSmail is the secure email and directory service available for all
>> NHS staff in England and Scotland
>> NHSmail is approved for exchanging patient data and other sensitive
>> information with NHSmail and GSi recipients
>> NHSmail provides an email address for your career in the NHS and
>> can be accessed anywhere
>> For more information and to find out how you can switch, visit
>> www.connectingforhealth.nhs.uk/nhsmail
>>
>> *********************************************************************
>> *
>> **********************************************
>
> **********************************************************************
> **********************************************
>
> This message may contain confidential information. If you are not
> the intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-
> mail or take any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
>
> Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all
> NHS staff in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive
> information with NHSmail and GSi recipients
> NHSmail provides an email address for your career in the NHS and
> can be accessed anywhere
> For more information and to find out how you can switch, visit
> www.connectingforhealth.nhs.uk/nhsmail
>
> **********************************************************************
> **********************************************

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere
For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail

********************************************************************************************************************