bugGNU Octave - Bugs: bug #59242, ind2rgb/ind2gray errors with uint...

 
 

bug #59242: ind2rgb/ind2gray errors with uint input containing the maximum integer value outside of colormap range

Submitter:  Niklas Wahl <wahln>
Submitted:  Fri 09 Oct 2020 12:59:11 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 12 Oct 2020 03:32:51 PM UTC, comment #8: 

Changeset works on the motivating example for this bug report.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Fri 09 Oct 2020 04:30:03 PM UTC, comment #7: 

I pushed a change here:
https://hg.savannah.gnu.org/hgweb/octave/rev/25b7ffb514f3

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Oct 2020 04:01:51 PM UTC, comment #6: 

Just so we stay Matlab compatible, ind2gray should clip the input based on the number of colors in the colormap.  The documentation is:


If you specify X as an array of integer data type, then the value 0 corresponds to the first color in the colormap map. For a colormap containing c colors, values of image X are clipped to the range [0, c-1].

If you specify X as an array of data type single or double, then the value 1 corresponds to the first color in the colormap. For a colormap containing c colors, values of image X are clipped to the range [1, c].


At least in Matlab, only single, double, uint8, or uint16 inputs are documented as allowed.  But, uint32 and uint64 do seem to work.  I wouldn't get too caught up in trying to get this to work for strange combinations like uint64 with more than flintmax entries.

Rik <rik5>
Group administrator
Fri 09 Oct 2020 04:01:20 PM UTC, comment #5: 

@gyom: That sounds reasonable to me. But like Niklas pointed out, `x` could be very large. Changing one single value in `x` could lead to twice the memory being required.
Preparing for both cases (large maps or large images) is probably the best way forward.
We can think about the case where both the map and the image are large when this is a problem for someone...

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Oct 2020 03:56:08 PM UTC, comment #4: 

In bug #56950 and bug #41851, I was suggesting to modify 'x' by clipping it to be between 1 and rows(map): could that solve the issue here too?

Guillaume <gyom>
Fri 09 Oct 2020 03:48:08 PM UTC, comment #3: 

Yeah, you're right. For large, maybe multi-dimensional images, it is probably better to not touch the image.

Maybe we should have two branches: The current implementation (+the fix here) for large images (e.g. `numel(x) > maxidx - num_colors + is_int`) and another one for small images.

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Oct 2020 03:39:01 PM UTC, comment #2: 

Ah, yes, 64-bit integers are valid input, so your patch is much more robust than my quick&dirty solution. I just checked it out and it looks good to me.

Regarding the current implementation: I'm not really familiar with octave development yet and how ind2x came to be. Currently, when using small datatypes like uint8, the expansion of the map can be more efficient (small colormap vs large image)? But as you stated the problem comes with larger datatypes (uint32,uint64), where the map could become too large for indexing depending on the values in the image.

Niklas Wahl <wahln>
Fri 09 Oct 2020 03:03:19 PM UTC, comment #1: 

Thank you for your report.
Are 64 bit integers valid input for these functions? In this case, adding 1 to a double greater than flintmax (2^52) wouldn't change the value.

Does the attached patch look good to you?

Anyway, the current implementation looks rather inefficient to me.
Wouldn't it be better to modify `x` (i.e. assign all values outside the map to the maximum value in the map) instead of extending `map`?

The following lets Octave be a victim of the memory overcommit killer on Windows:

ind2rgb (uint32 (intmax ("uint32")), jet (64))



(file #49953)

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Oct 2020 12:59:11 PM UTC, original submission:  

I stumbled upon some unexpected behavior / error in ind2rgb (also reproducible with ind2gray). When you pass your indexed image as an unsigned integer array containing the maximum value of said unsigned integer and this value is outside of the given colormap, ind2rgb will fail when calling the map function internally.

Code Example:
For example, calling

ind2rgb(uint8([255]),jet(64))

throws the following error:

error: map(256,_): out of bound 255 (dimensions are 255x3)
error: called from
    ind2rgb at line 56 column 5


What does work, however, is the following:

ind2rgb(uint8([254]),jet(64)) %Prints the expected warning regarding colormap range
ind2rgb(uint8([255]),jet(256)) %Works normally


Tried this with uint8 and uint16 on ubuntu 20.04 with a dev build and the 5.2 release and with the latter on Windows, too. In Matlab it seems to work normally in all cases.

Possible source of the bug & solution:
I think this comes from the index shift performed in ind2x.m, where maxidx doesn't increase (because its datatype is not changed and therefore it just keeps the maximum integer value). I attached a patch for ind2x.m that fixed the problem for me by changing the type of maxidx to double.

Niklas Wahl <wahln>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49953:  bug59242_ind2x.patch added by mmuetzel (1KiB - application/octet-stream)
file #49949:  patch_ind2x.txt added by wahln (265B - text/plain - Patch for ind2x.m)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by wahln (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-12 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-10-09 mmuetzel StatusNone Ready For Test
    2020-10-09 mmuetzel Attached File- Added bug59242_ind2x.patch, #49953
    2020-10-09 wahln Attached File- Added patch_ind2x.txt, #49949

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code