Wed 06 Dec 2017 05:32:59 PM UTC, comment #13:
Yes, I agree that the bug should be closed. I think that the problem with bitmap files is a different issue, and I filed bug #52599
Thanks
|
Wed 06 Dec 2017 04:55:29 PM UTC, comment #12:
@Dan: I changed an instance where you had used '%' as a comment character to "##". I checked it in on the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/9cba59ee9564).
I'm going to close this bug report since the issue raised, and the test case, now pass. If there is a different problem with PNG images and saturated colors then please open up a new report with a new example for that.
|
Wed 06 Dec 2017 11:21:15 AM UTC, comment #11:
Thank you, it works for the bug demo. I tried it for my complete work and still I see a problem with an included PNG image using only saturated colours. Going to investigate it and reporting here or possibly in a new bug report.
I attach the result of my complete case for gnuplot end fltk, using print() in PDF without any options
(file #42578, file #42579)
|
Wed 06 Dec 2017 05:18:40 AM UTC, comment #10:
OK, thanks for reviewing. I've added a bug report for the noted light demo:
https://savannah.gnu.org/bugs/index.php?52595
|
Wed 06 Dec 2017 04:45:36 AM UTC, comment #9:
This looks good. I tried the patch on the current stable branch and it solves the problem reported here. I also ran 'rundemos draw' to see if anythig had been upset by the patch, but everything seemed alright.
I did notice that
produced this error
This error is produced regardless of whether the patch is applied so it is a different problem.
|
Tue 05 Dec 2017 11:14:33 PM UTC, comment #8:
I ran drawnow() and the obvious problem is the following:
That clearly makes no sense: can't continue a line which is a complete command. I suppose the mixing of image and non-image data wasn't fully exercised after some things having been changed regarding images. I can't recall or deduce why the image should be drawn in it's own plot command while the other data is separate. Probably has something to do with the fact that gnuplot won't draw the background image in the right order for Qt terminal. Whatever the case, I'm attaching a changeset that moves the "unset obj 1" prior to all plot commands, gets rid of the semicolon for image plots, and generally simplifies the code.
Consider this an alpha patch that we will try for a few days. "demo image" and "demo plot" work for me. The "bug" demo works, gnuplot and fltk toolkits producing a similar result--but perhaps the layout isn't quite the same as shown in the original attached PNG.
(file #42575)
|
Tue 05 Dec 2017 06:22:51 PM UTC, comment #7:
I installed the image package and I get the same problem with 4.2.1 or the development branch. I still suspect it is related to pipes, but I'm going to add the resident expert on gnuplot, Dan Sebald, to the CC list.
I tried using
and then running bug() but Octave did not stop when gnuplot encountered an error. Most likely will need to use drawnow() to dump the commands Octave is issuing to a file and then try reading those in to gnuplot to verify whether it is Octave or an issue with pipes.
|
Tue 05 Dec 2017 05:05:35 PM UTC, comment #6:
Pipe issues were the first thing that came to mind, but then I excluded it because it has always reliably worked on 4.0 and never works on 4.2 here. Ok, I know, that means little...
Anyway, the test case involves two bitmap images. I just tried reducing their resolution to a very low value (8x6 pixels): the problem changes somehow but does not go away.
|
Tue 05 Dec 2017 04:47:44 PM UTC, comment #5:
There have been a lot of changes on the development branch with respect to gnuplot. If it works there occasionally then I'm inclined to say the problem of syntax has probably been fixed.
However, there is a deeper issue which is that Octave communicates with gnuplot over a pipe. When there is a lot of data to be communicated, such as an image with one point per pixel, the pipe can get out of sync and then the errors reported are pretty random. This has the feel of that sort of issue.
|
Tue 05 Dec 2017 04:31:10 PM UTC, comment #4:
It never works for me on a Debian testing system.
Neither from the command line nor from the GUI version.
|
Tue 05 Dec 2017 04:24:20 PM UTC, comment #3:
I get it to work sometimes. see the attached file.
hgid is bffbc95fa72b
But I also saw the errors reported here, when I ran a newer version of octave with ./run-octave.
(file #42572)
|
Tue 05 Dec 2017 04:11:34 PM UTC, comment #2:
I just spent about one hour to reduce the test case before sending the report.
Removing the dependence from the image package would require some more work on my part. I can do that if necessary, but I think it would be much faster if you could install the image package, is that a serious problem?
|
Tue 05 Dec 2017 03:54:58 PM UTC, comment #1:
I couldn't test because the image package was also required. Can you extract a simpler example that illustrates the problem?
|
Tue 05 Dec 2017 03:26:20 PM UTC, original submission:
The attached program works under 4.0, but fails under 4.2.
gnuplot errors out with:
and then spits out lot of errors, all starting with the multiplot> prompt.
To run it, unpack the zip file in a directory and run bug.m
|