Problems reading JPG files

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

Problems reading JPG files

Paul Stutzman-2
Something appears to have changed in the way ImageJ (v 1.50i) is interpreting 8-bit .JPG files that I have been successfully processing in the past. Previously these files would be displayed and processed as 8-bit, single plane images but now with images from my same SEM imaging system (which has not been updated), I get what appears to be a three-plane RGB image, even though the image type is identified as 8-bit via Image->Type. The white strip at the image top notes 1/3  and the bottom strip has a scoll slider as the RGB images do and the colors show in the B&C window as I slide the scroll bar.  If I attempt to adjust the brightness/contrast I get whatever color it is set to using the slider and adjusting brightness/contrast is difficult, if not impossible to retain a gray color scheme.  Attempts to do RGB color merges of X-ray images is similarly useless now.  Can anyone explain the change and how I might be able to read these as 8-bit, single plane images and eliminate the RGB interpretation?  I am not seeing any thing under Options.

Show Info appears to confirm this, and GIMP identifies it as RGB color, 1 layer

SCIFIO version: 0.27.1
File format: JPEG
--- Dataset Information ---
BitsPerPixel = 8
PixelType = 1
Dataset name = /Users/stutz/Documents/Projects/Dale/June_7d_10_23_C_Pastes/MA3-174_LS_10C/LS10_S.jpg
Image 0 Information
Dimension order = X,Y,Channel
Dimension lengths = 512,384,3
--- Global Metadata ---
--- Image Metadata ---

------------------------------------------------------
ImageJ 2.0.0-rc-29-SNAPSHOT/1.50i; Java 1.6.0_65 [64-bit]; Mac OS X 10.9.5; 157MB of 12263MB (1%)

Title: LS10_S.jpg
Width:  512 pixels
Height:  384 pixels
Depth:  1 pixels
Size:  576K
Voxel size: 1x1x1 pixel^3
ID: -96
Bits per pixel: 8 (color LUT)
Display ranges
 1: 0-255
 2: 0-255
 3: 0-255
Image: 1/3
 Channels: 3
 Composite mode: "composite"
No threshold
Uncalibrated
Path: /Users/stutz/Documents/Projects/Dale/June_7d_10_23_C_Pastes/MA3-174_LS_10C/LS10_S.jpg
Screen location: 84,172 (2560x1440)
SetMenuBarCount: 157
Coordinate origin:  0,0,0
No overlay
No selection




Paul

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: Problems reading JPG files

ctrueden
Hi Paul,

Do you have the SCIFIO option checked in Edit > Options > ImageJ2...?
SCIFIO never opens multichannel images as RGB.

http://imagej.net/SCIFIO

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Mon, Aug 29, 2016 at 2:38 PM, Stutzman, Paul E. (Fed) <
[hidden email]> wrote:

> Something appears to have changed in the way ImageJ (v 1.50i) is
> interpreting 8-bit .JPG files that I have been successfully processing in
> the past. Previously these files would be displayed and processed as 8-bit,
> single plane images but now with images from my same SEM imaging system
> (which has not been updated), I get what appears to be a three-plane RGB
> image, even though the image type is identified as 8-bit via Image->Type.
> The white strip at the image top notes 1/3  and the bottom strip has a
> scoll slider as the RGB images do and the colors show in the B&C window as
> I slide the scroll bar.  If I attempt to adjust the brightness/contrast I
> get whatever color it is set to using the slider and adjusting
> brightness/contrast is difficult, if not impossible to retain a gray color
> scheme.  Attempts to do RGB color merges of X-ray images is similarly
> useless now.  Can anyone explain the change and how I might be able to read
> these as 8-bit, single plane images and eliminate the RGB interpretation?
> I am not seeing any thing under Options.
>
> Show Info appears to confirm this, and GIMP identifies it as RGB color, 1
> layer
>
> SCIFIO version: 0.27.1
> File format: JPEG
> --- Dataset Information ---
> BitsPerPixel = 8
> PixelType = 1
> Dataset name = /Users/stutz/Documents/Project
> s/Dale/June_7d_10_23_C_Pastes/MA3-174_LS_10C/LS10_S.jpg
> Image 0 Information
> Dimension order = X,Y,Channel
> Dimension lengths = 512,384,3
> --- Global Metadata ---
> --- Image Metadata ---
>
> ------------------------------------------------------
> ImageJ 2.0.0-rc-29-SNAPSHOT/1.50i; Java 1.6.0_65 [64-bit]; Mac OS X
> 10.9.5; 157MB of 12263MB (1%)
>
> Title: LS10_S.jpg
> Width:  512 pixels
> Height:  384 pixels
> Depth:  1 pixels
> Size:  576K
> Voxel size: 1x1x1 pixel^3
> ID: -96
> Bits per pixel: 8 (color LUT)
> Display ranges
>  1: 0-255
>  2: 0-255
>  3: 0-255
> Image: 1/3
>  Channels: 3
>  Composite mode: "composite"
> No threshold
> Uncalibrated
> Path: /Users/stutz/Documents/Projects/Dale/June_7d_10_23_C_Pastes/
> MA3-174_LS_10C/LS10_S.jpg
> Screen location: 84,172 (2560x1440)
> SetMenuBarCount: 157
> Coordinate origin:  0,0,0
> No overlay
> No selection
>
>
>
>
> Paul
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: Problems reading JPG files

ctrueden
In reply to this post by Paul Stutzman-2
Hi Paul,

> I do see the SCIFIO beta is selected and when I deselect it the images
> are read properly, at least consistent with what I have seen in the
> past.

Glad to hear it.

> I have attached a screen shot of the image read with the SCIFIO option
> deselected (upper) and with it selected. Is this a bug?

It is intended behavior. JPEG files have three color channels—in the case
of grayscale data, the values are just replicated across R, G and B. SCIFIO
inspects the JPEG, detects three channels, and reads them in. Whereas IIRC,
ImageJ 1.x has a special case whereby multichannel images which contain the
same information across each channel get automagically converted to 8-bit
after being read in. This is probably what is happening with your image.

IMHO, this automagical conversion is overzealous, and SCIFIO should not do
this. However, there might be something in the JPEG header that SCIFIO
could use to differentiate between a JPEG which is intended to be
grayscale, vs. an RGB one that happens to have the same values across all
three channels.

I filed an issue so we remember to consider the best way forward here:
https://github.com/scifio/scifio/issues/327

> Will one continue to have an option to use this or not, or is it the
> direction ImageJ is headed?

The ultimate goal of the ImageJ2 project is to replace all ImageJ 1.x
functionality, but that is still several years away. Until that happens,
the SCIFIO toggle will continue to exist. And the option will stay off by
default until the SCIFIO readers and architecture are fully stabilized and
offer a complete replacement for the I/O capabilities of ImageJ 1.x.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Tue, Aug 30, 2016 at 8:09 AM, Stutzman, Paul E. (Fed) <
[hidden email]> wrote:

> Curtis,
>
> Thanks for the quick reply.  I am not sure how to reply to the daily
> ImageJ set of messages so I will reply individually.  I do see the SCIFIO
> beta is selected and when I deselect it the images are read properly, at
> least consistent with what I have seen in the past.  I have attached a
> screen shot of the image read with the SCIFIO option deselected (upper) and
> with it selected. Is this a bug?  Will one continue to have an option to
> use this or not, or is it the direction ImageJ is headed?
>
> I appreciate your pointing this out as it had me stopped cold.
>
> Thanks,  Paul
>
>
> Paul Stutzman
> Materials and Structural Systems Division
> 100 Bureau Drive
> Gaithersburg, MD 20899-8615
> 301 975-6715, 6645 (lab)
> [hidden email]
>
>
>
>
>
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Screen Shot 2016-08-30 at 9.00.06 AM.png (996K) Download Attachment