Wed 26 Feb 2014 04:34:13 PM UTC, comment #10:
I applied the patch to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/bf0d2e51c8f0). It is fine without a test.
|
Tue 25 Feb 2014 11:16:24 PM UTC, comment #9:
The patch is attached. I modified axis to use "__image_pixel_size__" and extend image data.
In image "axis image" is called only if the axes has only one child (the new image).
This is the way ML seams to work:
- if the axes has only one image child its limits are set tight and equal whatever the "x/ylimmode".
- else "x/ylimmode" values control whether or not limits are adjusted.
Should I add a test for the above behavior?
(file #30702)
|
Tue 25 Feb 2014 07:44:11 PM UTC, comment #8:
@pantxo: If you could implement it that would be great. I can review the patch, but am otherwise too swamped to do anything.
I'm not overly concerned about the 'axis equal' difference. According to the Matlab documentation, this command is about making the x and y axes use equal length, not about setting the actual limits used. For setting limits there is
|
Tue 25 Feb 2014 06:21:36 PM UTC, comment #7:
If you'd like me to do some more testing (or even implement this), just let me know.
There will still be the discrepancy in "axis equal" after which the position of the axes should be the default. I'll look into this.
|
Mon 24 Feb 2014 05:12:26 PM UTC, comment #6:
That's good news. This means we can consolidate all the limit setting code in axis.m and remove the dubious FIXME and duplicate code from image.m. As a bonus, this is all just m-file changes rather than messing with C++.
|
Sun 23 Feb 2014 05:11:06 PM UTC, comment #5:
Sorry my mistake, I didn't see that enlarging the limits manually let fltk draw the whole pixels with the expected colors.
In your example script "xlimmode" is "manual" in the 3 cases so I don't understand the comment and I'd say your approach will lead to the right result.
After fixing axis, image.m should use "axis (hax, 'image')" for the purpose of setting limits. This would avoid duplicating code.
|
Sun 23 Feb 2014 04:22:17 PM UTC, comment #4:
This is what I thought. The problem is not in the actual rendering by OpenGL but in Octave's selection of the axis limits. Octave gets it right when you actually call 'image'. See this code section from image.m
_image_pixel_size_ is a C++ routine that, for the test image of 4 pixels, returns 0.5. The axis limits are then set to the tight data limits (xdata) +/- the pixel size which results in limits of [0.5, 4.5]. This is perfect.
'axis image' is equivalent to 'axis tight' followed by 'daspect ([1 1 1])'. One quick fix would be to change axis.m to use the same calculation routine for axis limits as above. Even better would be to change the _get_tight_lims_ routine in axis.m so that it would take account of the graphic object type. For all object types which were not images (line, surface, etc.) it could use the limits of the data. For image types it would perform the calculation above.
Finally, there is that suspicious FIXME note in the code. Octave sets the axis limits manually when doing a call to image(). What does Matlab do?
Is the xlimmode 'manual' or 'auto'?
|
Sun 23 Feb 2014 03:24:13 PM UTC, comment #3:
Here is the result of the script slightly modified to show differences with octave behavior:
Indeed, in ML, axes limits include the half width of the pixels on the boundary when necessary.
Equal mode is different in octave but maybe those tests about xy/lim should be part of another bug report. AFAIU this bug is now mainly about octave openGL not being able render unint8 images properly.
|
Sun 19 Jan 2014 09:40:28 PM UTC, comment #2:
With gnuplot, the correct colors are now shown in both 3.8.0 and the development version of Octave.
Still waiting on reporter or someone with access to Matlab to run Rik's script to determine default axis limits.
|
Thu 07 Jun 2012 03:49:56 PM UTC, comment #1:
There are several bugs interacting with each other here.
First, are you using FLTK or gnuplot as the graphics toolkit for imshow? My guess is that you are using FLTK which has a strange issue here.
Second, full support for uint8 images will probably come in version 3.8.0 of Octave. For the moment, it would be better to use images of class double. To convert use the following:
The addition of 1 is necessary because double images index into the colormap starting with 1, not 0.
Finally, it appears to me that the data has been correctly plotted but the axis limits are incorrect. The test image/matrix you plotted had four values and so the xlimits were set at [1, 4]. The following command sets correct limits which reproduces the entire image.
In order to help debug this, could you run the following code under Matlab? I want to verify what axis limits get set.
|
Tue 05 Jun 2012 01:48:43 PM UTC, original submission:
The test program is as follows.
>>im=uint8([0 1 2 0; 0 1 2 0; 0 1 2 0; 0 1 2 0]);
>>map=[0 0 0; 1 0 0; 0 1 0; 0 0 1; 1 1 0; 0 1 1 ; 1 0 1];
>>imshow(im,map)
The result of Matlab is right. It will show a small image whose colors are black, red, green and black from left to right.
If using the "Octave with Visual Studio" version , the colors are just only black, red and black, and the spaces between colors are not equal.
If using Octave-3.6.1-mingw, it is totally white.
|