|
From: Daniel J S. <dan...@ie...> - 2006-02-20 19:28:02
|
Petr Mikulik wrote:
>>> Attached is a patch to fix this bug. It uses a bisecting method.
>>> Please check it over and test it. You'll find that the imshow(A,A,A)
>>> now works but doesn't look to be the correct brightness. We'll
>>> address that problem next.
>
>
> OK, now the patch, gnuplot does not crash.
>
> On the other hand, it shows the following garbage:
>
> octave|3> A = loadimage ("default.img");
> octave|4> imshow(A,A,A);
> gnuplot_x11: unknown command
> <.'.'.'<.<.<.>/>/>/$@0@0@0 ...
OK, I'm seeing that too, so we're consistent. I think this is a bug different from the patch I sent. I'll see if I can find that quick.
I see there is a strip along the right edge in the image that is not appearing. It looks as though that last line is not being read in and is instead being interpretted as a command. Could be an Octave problem.
> > Oh, btw, I made the patch behave similar to the existing routine in that it rounds up, like a ceil() function. I didn't look closely, but perhaps you'd like the routine to be round(), unless that's been compensated for somewhere else already.
>
> I have no idea what you mean.
What I mean is that by rounding up, if the number of palette colors is of less precision than the value of "gray" that is continually passed in, rounding up will mean that the "zero" value will occur only if it exactly equals the zeroeth value in the palette as opposed. An alternative might be instead the comparison
if ((sm_palette.gradient[tmpidx].pos + sm_palette.gradient[tmpidx+1].pos)/2 < gray)
that's all. (I believe the tmpidx+1 above is safe from ever going out of range and causing a crash... tmpidx will never be maxidx - 1 as the bisecting algorithm is because the loop will break first.
> But it does not matter, please send me the patch as close as to the "traditional" octave or Matlab behaviour as possible.
Well, I think the choice should be in gnuplot, then adjust the Octave script appropriately. So whatever you choose is fine.
Dan
|