Wed 08 Dec 2010 01:05:28 PM UTC, comment #13:
I've pushed the change. John has fixed the set/get problem as well.
|
Wed 08 Dec 2010 04:28:12 AM UTC, comment #12:
Your newest patch appears sound. Go ahead and commit it. I think you can close this bug report as well.
|
Wed 08 Dec 2010 02:43:36 AM UTC, comment #11:
I can confirm there is a second bug involved.
Notice the set/get sequence flips the order of the children.
I'll enter a new bug report.
|
Wed 08 Dec 2010 02:00:48 AM UTC, comment #10:
I looks to me like Rik's image used the gnuplot backend.
Since the changeset I proposed is consistent with the "old" behavior, I'm inclined to push the change. Any objections?
|
Tue 07 Dec 2010 08:09:46 PM UTC, comment #9:
What happened to the plot on top of the images? Was this with the gnuplot backend or with FLTK?
Søren
|
Tue 07 Dec 2010 08:06:15 PM UTC, comment #8:
Looks like imshow should force ydir to be reversed.
I've prepared a trivial changeset (needs testing since I'm unfamiliar with the image functions). It is attached.
I've also attached "arrow_up.jpg" as well as the results I get with gnuplot 4.4.0 and fltk 1.1.10 (aqua).
With this change in place, It looks to me like a different bug/feature is responsible for the differences between Octave's and Matlab's plots.
(file #22149, file #22150, file #22151, file #22152)
|
Tue 07 Dec 2010 07:56:33 PM UTC, comment #7:
I ran your test script in Octave to produce a comparison image against Matlab. Octave is clearly different for the last two cases (3 and 4) in which it does not reverse the y-axis. I also went back to a revision just prior to the new code (11307:6ab93f01df07). It correctly has all the arrows pointing up and the y-axis numbering is reversed as it is in Matlab. See the two attached png files.
(file #22147, file #22148)
|
Tue 07 Dec 2010 06:57:31 PM UTC, comment #6:
I don't do as much image processing as I used to. When doing image processing the basic visualisation work-flow is essentially:
imshow (im);
hold on
plot (col, row, '*');
hold off
where (row, col) denotes the coordinates of some points of interest in the image.
Now with respect to the bug in question I am a bit unsure how things should work. I tried generating a few plots in matlab hoping that this might shed some light on the situation. I'm attaching a script and the resulting figure.
Søren
(file #22144, file #22145)
|
Fri 03 Dec 2010 08:01:37 PM UTC, comment #5:
I would take a look at 30509. It began with exactly the same issue, that 'imshow; hold on; plot' produced different behavior than 'plot; hold on; imshow'.
I implemented the following in changeset 10817:d9147775da54
A) set 'ydir' to 'reverse' when using imshow
B) ignore 'hold on' when using imshow and always reverse axes
C) add some documentation on what imshow is doing since it isn't intuitive.
Part B is exactly the opposite of "prevents image() from reversing the y-axis for plots on hold." Soren did some testing that seemed to show that Matlab doesn't even allow the 'plot; hold on; imshow' sequence. Instead the last imshow command resets the figure.
|
Fri 03 Dec 2010 07:18:15 PM UTC, comment #4:
I haven't looked that the details of 30509/30033, but I think the current problem is due to ydir being changed when the axis is in a hold on state.
I tried the imshow demo. It looks correct to me.
|
Fri 03 Dec 2010 06:54:46 PM UTC, comment #3:
You should ask Soren about this change (I'll add him to the CC list). He seems to do a lot of work with images and exactly the opposite behavior was implemented for imshow. See https://savannah.gnu.org/bugs/?30509. Bug 30509 was, itself, a response to bug 30033. https://savannah.gnu.org/bugs/?30033.
If there is no clarity on this issue, then I think we should just copy exactly, weird behavior for weird behavior, what Matlab does.
|
Fri 03 Dec 2010 12:29:11 AM UTC, comment #2:
I've pushed a change.
http://hg.savannah.gnu.org/hgweb/octave/rev/9a08fa5b33bd
|
Thu 02 Dec 2010 02:02:29 PM UTC, comment #1:
I've attached a proposed changeset which prevents image() form reversing the y-axis for plots on hold.
(file #22090)
|
Thu 02 Dec 2010 01:14:42 PM UTC, original submission:
Matlab and Octave produce the same results for
But if the order if switched ...
... Matlab correctly respects the existing axis limits and y-axis orientation, while Octave does not. For reference, see the hold_2_1.png plots at the link below.
http://octave.sourceforge.net/compare_plots/
|