octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rgbplot composite fails with gnuplot


From: Juan Pablo Carbajal
Subject: Re: rgbplot composite fails with gnuplot
Date: Tue, 16 Dec 2014 19:28:10 +0100

On Tue, Dec 16, 2014 at 7:09 PM, Ben Abbott <address@hidden> wrote:
>> On Dec 16, 2014, at 11:30 AM, Juan Pablo Carbajal <address@hidden> wrote:
>>
>> On Tue, Dec 16, 2014 at 5:27 PM, Juan Pablo Carbajal
>> <address@hidden> wrote:
>>> On Tue, Dec 16, 2014 at 5:04 PM, Ben Abbott <address@hidden> wrote:
>>>>
>>>>> On Dec 16, 2014, at 10:56 AM, Juan Pablo Carbajal <address@hidden> wrote:
>>>>>
>>>>> On Tue, Dec 16, 2014 at 4:32 PM, Juan Pablo Carbajal
>>>>> <address@hidden> wrote:
>>>>>> On Tue, Dec 16, 2014 at 4:25 PM, Juan Pablo Carbajal
>>>>>> <address@hidden> wrote:
>>>>>>> On Tue, Dec 16, 2014 at 3:31 PM, Ben Abbott <address@hidden> wrote:
>>>>>>>>> On Dec 16, 2014, at 8:26 AM, Juan Pablo Carbajal <address@hidden> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Tested in 4.1.0+
>>>>>>>>> repo id 19402:5cd83b466a3e
>>>>>>>>>
>>>>>>>>> octave-cli:1> rgbplot(jet(16),'composite')
>>>>>>>>>
>>>>>>>>> multiplot> plot "-" binary array=16x2 scan=yx origin=(1,1) dx=1 dy=0
>>>>>>>>> using 1 title "" with image; ;
>>>>>>>>>                                                                ^
>>>>>>>>>         line 0: Sample period must be positive. Try `flip` for
>>>>>>>>> changing direction
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can anybody reproduce?
>>>>>>>>>
>>>>>>>>> Do we report bugs that involve gnuplot?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I get the same result using gnuplot 4.6 patchlevel 6.
>>>>>>>>
>>>>>>>> The error is indicating that dy must be greater than 0.  The m-code 
>>>>>>>> which produces this gnuplot command is in 
>>>>>>>> plot/utils/private/__go_draw_axes__.m at lines 554-547.
>>>>>>>>
>>>>>>>>       titlespec{data_idx} = "title \"\"";
>>>>>>>>       usingclause{data_idx} = sprintf ("binary array=%dx%d scan=yx 
>>>>>>>> origin=(%.15g,%.15g) dx=%.15g dy=%.15g using %s",
>>>>>>>>           x_dim, y_dim, x_origin, y_origin, dx, dy, format);
>>>>>>>>       withclause{data_idx} = sprintf ("with %s;", imagetype);
>>>>>>>>
>>>>>>>> The image intended looks a similar to a colorbar, so I expect the 
>>>>>>>> problem is on Octave's end.
>>>>>>>>
>>>>>>>> Ben
>>>>>>>
>>>>>>> Ben,
>>>>>>>
>>>>>>> Ok, thanks. I spotted the problem.
>>>>>>> It happens when when the data of the image has a single row.
>>>>>>> That is this fails as well
>>>>>>>
>>>>>>> image (1:8)
>>>>>>>
>>>>>>> The issue comes in lines 513 and 527-529 of __go_draw_axes__.m
>>>>>>> When dy=0 because the ydata of the image is [1 1]
>>>>>>>
>>>>>>> What are the "dx" and "dy" option for plot in gnuplot? I can't find a
>>>>>>> reference. Knowing that we jnow how to fix the issue.
>>>>>>
>>>>>> Ok, found it.
>>>>>>
>>>>>> The clause for gnuplot should not contain "dy=" when dy==0 . This
>>>>>> makes the plot appear but the axis look wrong.
>>>>>> So the sprintf command should be conditional on the value of dy.
>>>>>
>>>>> Another solution is to leave the sprintf fixed and set dy=1 when line
>>>>> 530 gives a 0. (the same should be done to dx).
>>>>> I still do not understand how does gnuplot handles a one dimensional 
>>>>> image.
>>>>
>>>> Does this produce an image with the proper height displayed (i.e. the y 
>>>> extent is from 0.5 to 1.5)?
>>>>
>>>> Ben
>>>>
>>>
>>> It was a little tricky cause gnuplot puts the origin in the middle of
>>> the first pixel, not in the corner.
>>> I think this patch fixes the issue. Could you verify and if so apply?
>>
>> gosh, wrong patch. I think this one is correct.
>> <1dimages_gnuplot.diff>
>
> Juan,
>
> I'm presently unable to build the default branch. Thus, I'd rather someone 
> else run the applicable demos (maybe write some new ones) to exercise the 
> patch before it is pushed.
>
> I see you've opened a bug report and posted a patch.
>
>         http://savannah.gnu.org/bugs/?43836
>
> Ben
>
The root of the problem was image so I added a test to it.
Please let me know if it is correct
https://savannah.gnu.org/bugs/index.php?43836



reply via email to

[Prev in Thread] Current Thread [Next in Thread]