color order vs ImageJ version

[Chinn, Steve Dr CIV USA AMC]

We have created an application that saves 32-bit ARGB RAW video files.
When imported as such, and viewed using ImageJ 1.39o, the colors appear
as we intended, and as displayed in our real-time application (running
in Windows XP, SP3).

 

However, when viewed on another computer using the newer version ImageJ
1.43o, the Red and Blue colors appear reversed. Can someone explain the
cause of this, and a possible way to get the old behavior back with the
newer ImageJ versions?

 

Thanks.

 

Stephen R. Chinn, Ph.D.
US Army RDECOM CERDEC
Night Vision and Electronic Sensors Directorate
AMSRD CER NV ST LT
10221 Burbeck Road
Fort Belvoir, VA 22060-5806
[phone]; FAX: [phone]
[hidden email] <mailto:[hidden email]>  
 

[Jeffrey B. Woodward]

Just guessing here, but are you sure that it is an ImageJ version issue,
and not a platform endianness issue [with the application that is
producing the raw video files]? Quick test, does the "older" version of
ImageJ work as expected on the "other" system and vice versa? I am
guessing that the older version won't work for you on the "other" system
either (i.e., not an ImageJ version issue)...

What platform (hardware type and O/S) is the application that is saving
the 32-bit ARGB RAW video files running on...i.e.,
    System A running ImageJ 1.39o [known to exist in your setup] stated
to be Windows XP SP3 assumed to be Intel architecture.
    System B running ImageJ 1.43o [known to exist in your setup] not
stated what O/S and hardware architecture.
    System ? running application to produce 32-bit ARGB RAW video files
for system A -- platform not stated.
    System ? running application to produce 32-bit ARGB RAW video files
for system B -- platform not stated.
So, are there 2, 3, or 4 systems involved? Seeing that the JAVA JVM is
big endianness regardless of the endianness of the host platform, [if I
were a betting man] I'd guess that you are producing your 32-bit ARGB
RAW video files for System B on a different platform with different
endianness than the platform used to produce the files for System A.
Thus, if you take a video file that had been known to work on System A
and transferred it to System B, does it work? I am guess that it will...

Sorry in advance if all my guessing is completely wrong (thankfully, I
am only betting with virtual money, and I have a lot of that to waste ;-))

-Woody



Chinn, Steve Dr CIV USA AMC wrote:

> We have created an application that saves 32-bit ARGB RAW video files.
> When imported as such, and viewed using ImageJ 1.39o, the colors appear
> as we intended, and as displayed in our real-time application (running
> in Windows XP, SP3).
>
>  
>
> However, when viewed on another computer using the newer version ImageJ
> 1.43o, the Red and Blue colors appear reversed. Can someone explain the
> cause of this, and a possible way to get the old behavior back with the
> newer ImageJ versions?
>
>  
>
> Thanks.
>
>  
>
> Stephen R. Chinn, Ph.D.
> US Army RDECOM CERDEC
> Night Vision and Electronic Sensors Directorate
> AMSRD CER NV ST LT
> 10221 Burbeck Road
> Fort Belvoir, VA 22060-5806
> [phone]; FAX: [phone]
> [hidden email] <mailto:[hidden email]>  
>  
>
>
>  

[Chinn, Steve Dr CIV USA AMC]

Woody,

Thanks for your reply. Here are some details you asked about.

First, the monochrome camera we are using produces U16 output, in
little-endian order. We select small regions of interest, color them
Red, and overlay them on the original gray-scale image. Each pixel is
then stored as four-byte data (with a constant Alpha bit that is set,
but unused) in Microsoft standard quad-color format (with Alpha last).

System A produces and saves the video files using our camera
application. It runs WinXP SP3, and uses IJ 1.39o for purposes of
displaying saved files. When the saved video file is imported into IJ
1.39o, File>Import>Raw.. 32-bit ARGB, little-endian the IJ display
reproduces our real-time video.

System B, used only for data-retrieval and display, also runs WinXP SP3,
but uses ImageJ 1.43o. When the same, duplicated RAW video data file is
imported as above, the Red color appears Blue, but the rest of the
gray-scale image is correct (also implying the Alpha-byte order is
correct?). When I reverted System B to IJ 1.39o, and imported the same
RAW data the same way, the Red color appeared correctly. I believe this
latter test shows the issue to be ImageJ related, rather than system or
system 'endian-ness' related.

I welcome any further thoughts you might have.

Stephen R. Chinn, Ph.D.
US Army RDECOM CERDEC
Night Vision and Electronic Sensors Directorate
AMSRD CER NV ST LT
10221 Burbeck Road
Fort Belvoir, VA 22060-5806
[phone]; FAX: [phone]
[hidden email]
 
-----Original Message-----
From: Jeffrey B. Woodward [mailto:[hidden email]]
Sent: Monday, July 13, 2009 2:22 PM
Subject: Re: color order vs ImageJ version

Just guessing here, but are you sure that it is an ImageJ version issue,
and not a platform endianness issue [with the application that is
producing the raw video files]? Quick test, does the "older" version of
ImageJ work as expected on the "other" system and vice versa? I am
guessing that the older version won't work for you on the "other" system
either (i.e., not an ImageJ version issue)...

What platform (hardware type and O/S) is the application that is saving
the 32-bit ARGB RAW video files running on...i.e.,
    System A running ImageJ 1.39o [known to exist in your setup] stated
to be Windows XP SP3 assumed to be Intel architecture.
    System B running ImageJ 1.43o [known to exist in your setup] not
stated what O/S and hardware architecture.
    System ? running application to produce 32-bit ARGB RAW video files
for system A -- platform not stated.
    System ? running application to produce 32-bit ARGB RAW video files
for system B -- platform not stated.
So, are there 2, 3, or 4 systems involved? Seeing that the JAVA JVM is
big endianness regardless of the endianness of the host platform, [if I
were a betting man] I'd guess that you are producing your 32-bit ARGB
RAW video files for System B on a different platform with different
endianness than the platform used to produce the files for System A.
Thus, if you take a video file that had been known to work on System A
and transferred it to System B, does it work? I am guess that it will...

Sorry in advance if all my guessing is completely wrong (thankfully, I
am only betting with virtual money, and I have a lot of that to waste
;-))

-Woody



Chinn, Steve Dr CIV USA AMC wrote:

> We have created an application that saves 32-bit ARGB RAW video files.
> When imported as such, and viewed using ImageJ 1.39o, the colors
> appear as we intended, and as displayed in our real-time application
> (running in Windows XP, SP3).
>
>  
>
> However, when viewed on another computer using the newer version
> ImageJ 1.43o, the Red and Blue colors appear reversed. Can someone
> explain the cause of this, and a possible way to get the old behavior
> back with the newer ImageJ versions?
>
>  
>
> Thanks.
>
>  
>
> Stephen R. Chinn, Ph.D.
> US Army RDECOM CERDEC
> Night Vision and Electronic Sensors Directorate AMSRD CER NV ST LT
> 10221 Burbeck Road
> Fort Belvoir, VA 22060-5806
> [phone]; FAX: [phone]
> [hidden email] <mailto:[hidden email]>
>  
>
>
>  

[Wayne Rasband]

On Jul 13, 2009, at 10:58 AM, Chinn, Steve Dr CIV USA AMC wrote:

> We have created an application that saves 32-bit ARGB RAW video files.
> When imported as such, and viewed using ImageJ 1.39o, the colors appear
> as we intended, and as displayed in our real-time application (running
> in Windows XP, SP3).
>
> However, when viewed on another computer using the newer version ImageJ
> 1.43o, the Red and Blue colors appear reversed. Can someone explain the
> cause of this, and a possible way to get the old behavior back with the
> newer ImageJ versions?

ImageJ 1.39 did not correctly open images in interleaved ARGB format
(rgbargbargba...). The v1.43d daily build adds a "32-bit ABGR" option
to the File>Import>Raw dialog that opens images in interleaved ABGR
format (bgrabgrabgra...). This option is equivalent to "32-bit ARGB" in
v1.39.

-wayne