[Octave-bug-tracker] [bug #46382] imread returns image of class logical for too many rgb images

[Hartmut]

URL:
  <http://savannah.gnu.org/bugs/?46382>

                 Summary: imread returns image of class logical for too many
rgb images
                 Project: GNU Octave
            Submitted by: hardy
            Submitted on: Do 05 Nov 2015 21:13:33 GMT
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.0.0
        Operating System: Any

    _______________________________________________________

Details:

This happens with the current 4.0.0 release of Octave:


clear, close all;
R = [0 0 0 0; 0 255 255 0; 0 255 255 0; 0 0 0 0];
G = [0 1 2 3; 4 5 6 7; 100 101 102 103; 200 201 202 203];
B = G + 10;
RGB = uint8(cat(3, R, G, B));
filename = 'test_image.png';
imwrite(RGB, filename);       % so far so good
I = imread(filename);
class(I)                      % -> class logical :(


The resulting class of I is "logical". This results in a significant amount of
data loss, because all the information in the G and B channel is thus mostly
discarded by imread.

I think I have read elsewhere that imread needs to do some kind of "guessing"
if the read image is ment to be of class logical or of an integer class,
because Image Magick doesn't provide this information. And I assume that
imread does its best for greyscale images. But for RGB images like in this
example, I think we could do better:

I would suggest to only assign class logical to an image (inside of the imread
function) if ALL the color channels only consist of 0 and intmax. Currenetly
it seems to me that for this decision only the red R channel is used.

(PS: This seems to be an artificial example. But I had a real image with only
orange hues in it, where this really happened...)




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46382>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/