Wed 13 Dec 2017 08:46:58 PM UTC, comment #10:
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.
|
Wed 13 Dec 2017 08:08:04 PM UTC, comment #9:
I think the algorithm you have now is right.
The interpretation does depend on the data type (integer vs. float) of the "cdata" property. Try this example
Both FLTK and gnuplot produce the same image for the input above.
|
Wed 13 Dec 2017 05:49:24 PM UTC, comment #8:
@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.
|
Wed 13 Dec 2017 04:35:40 AM UTC, comment #7:
Regarding the integer/double indexing, there is still some ambiguity there. If one accepts the first statement "Interpret the values as indices into the current colormap" as the definition and the rest of the paragraphs as corner cases on either end of the range, then there is no adding 1. However, if one accepts the later paragraphs as definition, i.e., "If the values are of type [integer], then values of 0 or less map to the first color in the colormap" then it could be construed that 0 is the first entry in the map, 1 is the second entry, 2 the third, etc. which appears to be adding 1 to the integer index.
Generally speaking, color maps and pixel extents are always a confusion at the nitty-gritty given so many libraries and applications to deal with. I often wish libraries would write a terse math formula rather than try describing behavior.
|
Wed 13 Dec 2017 04:24:32 AM UTC, comment #6:
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):
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)
|
Wed 13 Dec 2017 03:59:08 AM UTC, comment #5:
I used copyobj() to get an identical copy. Sample code:
For the question about +0 or +1, maybe this description of CDataMapping will help. There is definitely an offset of 1 between real types (single and double) and integer types.
|
Wed 13 Dec 2017 02:53:27 AM UTC, comment #4:
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:
Maybe 255 is not the value to use. I'll investigate...
|
Wed 13 Dec 2017 02:11:07 AM UTC, comment #3:
Your patch fixes things for me. I tried the original motivating example and the extra tests in comment #2. I pushed it here (http://hg.savannah.gnu.org/hgweb/octave/rev/cb6a61636a23).
Because I can't see a difference between FLTK and gnuplot in the examples, I'm inclined to accept that +1 is necessary.
I don't know if this is related, but check "demo scatter 7" and the northeast plot. The color of the single dot is different between gnuplot and fltk. It has been this way for a while. I've attached the two images.
(file #42629, file #42630)
|
Wed 13 Dec 2017 01:01:11 AM UTC, comment #2:
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:
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, file #42627, file #42628)
|
Fri 08 Dec 2017 04:55:35 PM UTC, comment #1:
There is probably also a difference in gnuplot versions responsible for this. I'm running 5.0.3 and the plot is all white as it should be. But I know you're runnig a more bleeding edge version of gnuplot.
|
Fri 08 Dec 2017 10:51:47 AM UTC, original submission:
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}.
|