Saving little-endian 16 bit TIFF / "save-string-to-file" macro command

[Niels Jensen-2]

Hi,

I am using a program (BD AttoVision) that can only read 16 bit TIFF files in the "little endian" TIFF format starting with "49 49 2A 00" ("II*."). However, ImageJ saves all files in the "big endian" TIFF format starting with "4D 4D 00 2a" ("MM.*"). This essentially nukes all my images if I open and save them from ImageJ.

Please could you add an option to save little endian" TIFF files and/or to preserve the format.

I use ImageJ macros to process a large number of these TIFF files and I was trying to figure out a workaround to the problem described above (it would have been as simple as using a regexp to switch bytes). Unfortunately, there is currently no ways to handle binary files (the "print(file, string)" command changes special characters such as newlines).

Please could you also implement binary file support (e.g. a simple "save-string-to-file" command) to the macro language.

Thanks,

Niels


_________________________________________________________________
E-mail for the greater good. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ GreaterGood

[Joachim Wesner]

Hi,

according to official TIFF specifications, all valid TIFF readers MUST be
able to read both endian-formats!!!

You should complain with the vendor of that program!

JW

ImageJ Interest Group <[hidden email]> schrieb am 25.05.2008 00:39:30:

> Hi,
>
> I am using a program (BD AttoVision) that can only read 16 bit TIFF
> files in the "little endian" TIFF format starting with "49 49 2A 00"
> ("II*."). However, ImageJ saves all files in the "big endian" TIFF
> format starting with "4D 4D 00 2a" ("MM.*"). This essentially nukes
> all my images if I open and save them from ImageJ.
>
> Please could you add an option to save little endian" TIFF files
> and/or to preserve the format.
>
> I use ImageJ macros to process a large number of these TIFF files
> and I was trying to figure out a workaround to the problem described
> above (it would have been as simple as using a regexp to switch
> bytes). Unfortunately, there is currently no ways to handle binary
> files (the "print(file, string)" command changes special characters
> such as newlines).
>
> Please could you also implement binary file support (e.g. a simple
> "save-string-to-file" command) to the macro language.
>
> Thanks,
>
> Niels
>
>
> _________________________________________________________________
> E-mail for the greater good. Join the i’m Initiative from Microsoft.
> http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_

GreaterGood

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Niels Jensen-2]

Hi Joachim,

I will also report this to BD, but my guess is that the ImageJ development community is more flexible than BD. Unfortunately, I have to rely upon their software to analyze my data. AttoVision is currently in beta stadium at best and it feels as if it is developed by engineers who never have to use their own software.

Anyway, it would be nice to have these two independent feature requests implemented in ImageJ. Coding-wise this should be really easy.

Thanks,

Niels

> Date: Sun, 25 May 2008 15:00:33 +0200
> From: [hidden email]
> Subject: Antwort: Saving little-endian 16 bit TIFF  / "save-string-to-file" macro command
> To: [hidden email]
>
> Hi,
>
> according to official TIFF specifications, all valid TIFF readers MUST be
> able to read both endian-formats!!!
>
> You should complain with the vendor of that program!
>
> JW
>
> ImageJ Interest Group <[hidden email]> schrieb am 25.05.2008 00:39:30:
>
> > Hi,
> >
> > I am using a program (BD AttoVision) that can only read 16 bit TIFF
> > files in the "little endian" TIFF format starting with "49 49 2A 00"
> > ("II*."). However, ImageJ saves all files in the "big endian" TIFF
> > format starting with "4D 4D 00 2a" ("MM.*"). This essentially nukes
> > all my images if I open and save them from ImageJ.
> >
> > Please could you add an option to save little endian" TIFF files
> > and/or to preserve the format.
> >
> > I use ImageJ macros to process a large number of these TIFF files
> > and I was trying to figure out a workaround to the problem described
> > above (it would have been as simple as using a regexp to switch
> > bytes). Unfortunately, there is currently no ways to handle binary
> > files (the "print(file, string)" command changes special characters
> > such as newlines).
> >
> > Please could you also implement binary file support (e.g. a simple
> > "save-string-to-file" command) to the macro language.
> >
> > Thanks,
> >
> > Niels
> >
> >
> > _________________________________________________________________
> > E-mail for the greater good. Join the i’m Initiative from Microsoft.
> > http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_
> GreaterGood
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

_________________________________________________________________
E-mail for the greater good. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ GreaterGood

[Albert Cardona]

Hi Niels,

> I will also report this to BD, but my guess is that the ImageJ development community is more flexible than BD. Unfortunately, I have to rely upon their software to analyze my data. AttoVision is currently in beta stadium at best and it feels as if it is developed by engineers who never have to use their own software.
>  


Then please I would appreciate if you could spend the same effort you do
for BD to ImageJ: donate time/resources to code development -as
equivalent to purchasing.


> Anyway, it would be nice to have these two independent feature requests implemented in ImageJ. Coding-wise this should be really easy.
>  


Suggesting that others could do it for you is not very nice. Instead,
you could do it yourself and submit a patch, or even code it for
yourself  alone. And we'd help you along the way.

ImageJ's source is available, even in a git repos:
http://rsb.info.nih.gov/ij/download/src/
http://repo.or.cz/w/imageja.git/

Cheers,

Albert

--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[lechristophe]

Niels,

I don't know what is the size of your individual images. Can you use
the File.openAsString(path) command to load the whole image as a
string, modify it, and then re-write it as a whole with print(string)
?

Christophe

PS/ I totally agree with Albert and Joachim on the do-it-yourself
approach although as a non-java capable person (I don't even know what
a patch is) I understand it represents a big investment to learn how
to do it yourself. Anyway, just asking "please implement feature X" is
percieved as a bit rude when you are devoting quite a lot of time in
open source development !

On Mon, May 26, 2008 at 5:21 AM, Albert Cardona
<[hidden email]> wrote:

> Hi Niels,
>
>> I will also report this to BD, but my guess is that the ImageJ development
>> community is more flexible than BD. Unfortunately, I have to rely upon their
>> software to analyze my data. AttoVision is currently in beta stadium at best
>> and it feels as if it is developed by engineers who never have to use their
>> own software.
>>
>
>
> Then please I would appreciate if you could spend the same effort you do for
> BD to ImageJ: donate time/resources to code development -as equivalent to
> purchasing.
>
>
>> Anyway, it would be nice to have these two independent feature requests
>> implemented in ImageJ. Coding-wise this should be really easy.
>>
>
>
> Suggesting that others could do it for you is not very nice. Instead, you
> could do it yourself and submit a patch, or even code it for yourself
>  alone. And we'd help you along the way.
>
> ImageJ's source is available, even in a git repos:
> http://rsb.info.nih.gov/ij/download/src/
> http://repo.or.cz/w/imageja.git/
>
> Cheers,
>
> Albert
>
> --
> Albert Cardona
> http://www.mcdb.ucla.edu/Research/Hartenstein/acardona
>

[Wayne Rasband]

> I am using a program (BD AttoVision) that can only read 16 bit TIFF  
> files in the "little endian" TIFF format starting with "49 49 2A  
> 00" ("II*."). However, ImageJ saves all files in the "big endian"  
> TIFF format starting with "4D 4D 00 2a" ("MM.*"). This essentially  
> nukes all my images if I open and save them from ImageJ.
>
> Please could you add an option to save little endian" TIFF files  
> and/or to preserve the format.

The v1.41d daily build saves TIFFs in little endian format if you  
enable the "Save TIFF and Raw in Intel Byte Order" option in  
Edit>Options>Input/Output.

> I use ImageJ macros to process a large number of these TIFF files  
> and I was trying to figure out a workaround to the problem  
> described above (it would have been as simple as using a regexp to  
> switch bytes). Unfortunately, there is currently no ways to handle  
> binary files (the "print(file, string)" command changes special  
> characters such as newlines).
>
> Please could you also implement binary file support (e.g. a simple  
> "save-string-to-file" command) to the macro language.

You can do this be converting the string to an image and saving the  
image in raw format.

-wayne