bugGNU Octave - Bugs: bug #41851, ind2rgb values outside range of...

 
 

bug #41851: ind2rgb values outside range of colour map

Submitted by:  Guillaume <gyom>
Submitted on:  Thu 13 Mar 2014 12:30:44 PM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: FixedAssigned to: None
Originator Name: GuillaumeOpen/Closed: Closed
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 18 Mar 2014 02:09:26 AM UTC, comment #12:

Okay, I went with your modification to the proposed changeset. It's checked in on the default branch (http://hg.savannah.gnu.org/hgweb/octave/rev/875f4510d6dc).

Rik <rik5>
Project Administrator
Tue 18 Mar 2014 12:11:24 AM UTC, comment #11:

Rik, as an alternative, please take a look at the attached patch. It is an amend of yours.

It makes note of this bug number in the comments, prints a warning for the opposite case (colours above the cmap limit), and tests that warnings are issued for 0, off by one errors for integers and floats.

Also, it performs just a tiny little better (since we don't need isindex to check if all values are integers again) and avoids "x(x < 1) = 1" unless absolutely required which always creates a copy of the image.

(file #30934)

Carnë Draug <carandraug>
Project Member
Mon 17 Mar 2014 06:07:10 PM UTC, comment #10:

Thanks Rik, works fine for me with the warning below being displayed for values < 1.

Guillaume <gyom>
Mon 17 Mar 2014 04:13:14 PM UTC, comment #9:

Carne, I've attached a patch that makes Octave compatible with Matlab in this regard. I don't like it much either though. If someone tests the patch and verifies it I will check it in.

(file #30929)

Rik <rik5>
Project Administrator
Mon 17 Mar 2014 03:16:02 PM UTC, comment #8:

Matlab behaviour is plain wrong since the value for that index does not exist. If instead of an image this was a matrix for some other purpose, would you think appropriate to give you the last element of the matrix if you tried to index outside the limit of the matrix? And colours in a colourmap are not necessarily sorted by intensity.

In addition, "fixing" this will make it much easier for users to make "off by one" mistakes.

Still, we may not have much of a choice to introduce this error for the sake of matlab compatibility. So I'm reopened the bug and ask for opinion of others devs. Let us at least print a big fat warning if users try to index out of the bounds of the colourmap.

Carnë Draug <carandraug>
Project Member
Mon 17 Mar 2014 01:30:30 PM UTC, comment #7:

Thanks once again.
I personally think that the MATLAB behaviour is appropriate here and could be implemented by having these lines in private/ind2x.m:

Guillaume <gyom>
Fri 14 Mar 2014 05:18:22 PM UTC, comment #6:

Hmm... I see what you mean. Looking into private/ind2x.m function, there is:

Maybe we should also give an error for this cases? Or issue a warning?

Carnë Draug <carandraug>
Project Member
Fri 14 Mar 2014 12:06:57 PM UTC, comment #5:

Thanks for your comments. I used the code with uint8() and double() because it is the exact one from the test cases.

Maybe I should use another example - in MATLAB you get this:

while Octave will complain of values -1 and 0, but is OK with values beyond the size of the colormap:

So values larger than the size of the colormap are all reassigned to that value (in Octave and MATLAB). And only MATLAB assigns an index of 1 to all values less than 1.
It seems to me like a reasonable behaviour (symmetrical handling of both extrema) and compatible to what happens when you display an image with a fixed CLim axis (out of range values are assigned the first or last colors from the colormap).

Guillaume <gyom>
Thu 13 Mar 2014 11:03:55 PM UTC, comment #4:

I second Rik's opinion.

Ignoring the case of the class explanation, you will notice that in your example, the indexed image has indices with a value of "zero" and "one" (the first and third row of the first column). From your example, it seems that Matlab assigns the same colour to both of them. How come two different indices give the same colour when there's no repeated colours in the colormap?

This is yet another case where Matlab returns rubbish due to improper input check. A matrix of class double is only an indexed image if all values are positive integers. Rather than returning a wrong answer, Octave gives an error. That sounds right to me so I'm marking this as invalid.

Another suggestion. Instead of using

I'll instead recommend to use the image package which has a set of functions meant to convert an image between different types. If they are indexed, you can do

which handles all the details for you.

Carnë Draug <carandraug>
Project Member
Thu 13 Mar 2014 09:42:20 PM UTC, comment #3:

I don't know what Matlab is doing, but I think Octave is correct in rejecting the variable img as not being an indexed image.

When the img is of type double, a 1 in the matrix points to the first row in the colormap. When the img is an integer type, such as uint8, then an offset of 1 is used such that a 0 in the matrix points to the first row in the colormap. See Matlab's own documentation for more information (http://www.mathworks.com/help/matlab/creating_plots/image-types.html).

In the posted code, the image is originally in uint8 format and thus has 0 values. Using double() to convert a uint8 image is not correct. You actually need to do

Rik <rik5>
Project Administrator
Thu 13 Mar 2014 05:46:50 PM UTC, comment #2:

Sorry about that, I should have copied the exact code I used:

MATLAB returns:

while Octave dev returns:

Guillaume <gyom>
Thu 13 Mar 2014 05:20:44 PM UTC, comment #1:

I am a bit confused by the bug report. Your first sample are the results you get in Matlab or Octave? I do not get an error, and it works correctly (althout not the results you are displaying). Using Octave 3.8.1:

which should be the correct values.

Carnë Draug <carandraug>
Project Member
Thu 13 Mar 2014 12:30:44 PM UTC, original submission:

The tests for ind2rgb return a different output in MATLAB for floating point inputs: (using variables from scripts/image/ind2rgb.m)

while Octave expects an error.
The other tests in "Test input validation" that do not return an error are:

Guillaume <gyom>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #30934:  ind2bug.cset added by carandraug (7kB - application/octet-stream)
file #30929:  ind2x.cset added by rik5 (6kB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by gyom (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 18 Mar 2014 02:09:26 AM UTCrik5StatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Tue 18 Mar 2014 12:11:24 AM UTCcarandraugAttached File-=>Added ind2bug.cset, #30934
    Mon 17 Mar 2014 04:13:14 PM UTCrik5Attached File-=>Added ind2x.cset, #30929
      StatusNone=>Ready For Test
    Mon 17 Mar 2014 03:16:02 PM UTCcarandraugStatusInvalid=>None
    Fri 14 Mar 2014 05:18:22 PM UTCcarandraugOpen/ClosedClosed=>Open
      Summaryind2rgb tests=>ind2rgb values outside range of colour map
    Thu 13 Mar 2014 11:04:02 PM UTCcarandraugOpen/ClosedOpen=>Closed
    Thu 13 Mar 2014 11:03:55 PM UTCcarandraugStatusNone=>Invalid

    Back to the top


    Powered by Savane 3.1-cleanup