Yes, that's a simpler example that illustrates the difference.  It seems odd it should do that.  For numbers the size of any expected colormap, the whole portion of float mantissa is pretty much the same as integer.

@Dan: I applied your patch to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/a9be96afb39e).

As I understand it, this applies to patch colors.  Does something similar need to be done for surface objects?  I ask because I am seeing slight color discrepancies with trimesh.  I'll take the discussion over to bug #42561.

Oh, interesting, never knew copyobj existed, thanks.

I isolated the graph with the problem.  It is an issue with that zero clim range (i.e., clim(1) == clim(2)).  This scatter demo is using a clim mode of auto, which means clim(1) and clim(2) are the same when there is only a single color.  Attached is a patch that fixes this.  I also changed the case where there is a clim range of zero for TrueColor, but I don't think that ever occurs; higher level code rules out such a combination.

Here are some scripts to test (since it dividing by two I figured I should try even and odd colormap sizes):

close all
m=1;
n=1;
x = rand (n, 1);
y = rand (n, 1);
colors = rand (n, m);
graphics_toolkit fltk
scatter (x, y, [], colors, "filled");
set(gca, 'ColorMap', jet(4));
graphics_toolkit gnuplot
figure
scatter (x, y, [], colors, "filled");
set(gca, 'ColorMap', jet(4));

close all
m=1;
n=1;
x = rand (n, 1);
y = rand (n, 1);
colors = rand (n, m);
graphics_toolkit fltk
scatter (x, y, [], colors, "filled");
set(gca, 'ColorMap', jet(3));
graphics_toolkit gnuplot
figure
scatter (x, y, [], colors, "filled");
set(gca, 'ColorMap', jet(3));

close all
m=1;
n=1;
x = rand (n, 1);
y = rand (n, 1);
colors = rand (n, m);
graphics_toolkit fltk
scatter (x, y, [], colors, "filled");
set(gca, 'ColorMap', jet(1));
graphics_toolkit gnuplot
figure
scatter (x, y, [], colors, "filled");
set(gca, 'ColorMap', jet(1));

I figured I should try a colormap size of one and that revealed gnuplot doesn't like a zero colorbox range.  In such a case I forced it to two and it seems to produce the desired result, so there we go.

(file #42631)

I meant that I think both gnuplot and OpenGL toolkits aren't consistent with Matlab.  Since gnuplot is adding 1 to cdata, I assume that is the same as what FLTK is doing.  I don't see why for integers we'd add one but for doubles (passed through fix) we wouldn't add one.  Logical I can understand--it makes no sense for there to be only alternatives 0 and 1 when the colormap starts at 1.

How did you generate these two scatterplot figures with the same data in both the gnuplot toolkit and FLTK toolkit?  Re-calling the demo with a different toolkit creates a different set of data.  I can probably figure this out by writing a script similar to the northeast case, i.e., a single color in a scatter plot.  It could be a "scaled" issue when the color map size is one entry...in fact, that might be this case where "clim_rng" is 0 because there is only a single color:

    if (clim_rng != 0)
      cdata = 255 * (cdata - clim(1)) / clim_rng;
      cdata(cdata < 0) = 0;  cdata(cdata > 255) = 255;
    else
      cdata(:) = 255;
    endif

Maybe 255 is not the value to use.  I'll investigate...

Binary images aren't allowed as RGB (i.e., 3-component) images, so that was a red herring.

The attached patch should put the gnuplot toolkit in sync with the OpenGL toolkits.  It turns out that for scaled images, the logical case is no different than the integer case.  I.e., logical is {0,1} and clim indicates [0 1].  Run that through the formula and it always picks the first or last entry of the colormap no matter the size.  I then also had to add one for the "Direct" mode.

Here are some test scripts to put the various image data formats through their paces relative to OpenGL:

close all;
monoimg(:,:,1) = toeplitz([0:5]) > 2;
graphics_toolkit fltk
figure
h1 = imshow(monoimg);
set(gca, 'ColorMap', jet(4));
set(h1, 'cdatamapping', 'direct');
graphics_toolkit gnuplot
figure
h2 = imshow(monoimg);
set(gca, 'ColorMap', jet(4));
set(h2, 'cdatamapping', 'direct');

close all;
dblimg(:,:,1) = toeplitz([0:5]);
graphics_toolkit fltk
figure
imshow(dblimg/5);
set(gca, 'ColorMap', jet(500));
h1 = imshow(dblimg);
set(gca, 'ColorMap', jet(4));
set(h1, 'cdatamapping', 'direct');
graphics_toolkit gnuplot
figure
imshow(dblimg/5);
set(gca, 'ColorMap', jet(500));
h2 = imshow(dblimg);
set(gca, 'ColorMap', jet(4));
set(h2, 'cdatamapping', 'direct');

close all;
intimg(:,:,1) = uint8(toeplitz([0:5]));
graphics_toolkit fltk
figure
imshow(intimg*100);
set(gca, 'ColorMap', jet(500));
h1 = imshow(intimg);
set(gca, 'ColorMap', jet(4));
set(h1, 'cdatamapping', 'direct');
graphics_toolkit gnuplot
figure
imshow(intimg*100);
set(gca, 'ColorMap', jet(500));
h2 = imshow(intimg);
set(gca, 'ColorMap', jet(4));
set(h2, 'cdatamapping', 'direct');

I've sat for a while thinking about the results, and I'm fine with most everything except perhaps the "Direct" mode applied to integer data.  I'm not sure if we should be adding 1 to the integer data (just as double data doesn't have 1 added).  It might be only the logical case where we should add one.  That is, rather than the image looking like the current appearance in the attached add_one_to_integer_cdata.png, I wonder if it should look like the appearance in attached file not_add_one_to_integer_cdata.png.

(file #42626,

Try:

monoimg(:,:,1) = logical(ones (128));
% All logical one should be white
graphics_toolkit fltk
figure(1)
imshow(monoimg)
% Not black
graphics_toolkit gnuplot
figure(2)
imshow(monoimg)

This looks like a bug related to the gnuplot rgb range change (0 to 255 is the new default range) similar to the bug identified in http://savannah.gnu.org/bugs/?52599 .  Perhaps all that need be done is to send {0,255} to gnuplot rather than {0,1}.