Re: imshow is slow on Mac OSX 10.5

[Todd Rovito]

After more examination I realize that the display range being double
won't have much effect on performance.

On Mon, Nov 23, 2009 at 12:04 PM, Todd Rovito <address@hidden> wrote:
> Carlo,
>   Thanks for the information!  For sure the FLTK backend is much
> faster.  I was looking at the imshow command to GNUPlot and was
> surprised to see that the code seems to be converting the data to
> double.  Here is the code snippet from imshow.m:
>
> ========================================================
> ## Set default display range if display_range not set yet.
>  if (isempty (display_range))
>    display_range = [min(im(:)), max(im(:))];
>  elseif (isna (display_range))
>    t = class (im);
>    switch (t)
>      case {"double", "single", "logical"}
>        display_range = [0, 1];
>      case {"int8", "int16", "int32", "uint8", "uint16", "uint32"}
>        ## For compatibility, uint8 data should not be handled as
>        ## double.  Doing so is a quick fix to allow the images to be
>        ## displayed correctly.
>        display_range = double ([intmin(t), intmax(t)]);
>      otherwise
>        error ("imshow: invalid data type for image");
>    endswitch
>  endif
> ======================================================
>
> Notice that the uint8 data is actually converted to double.  If I read
> the code correctly that would make the transmission to GNU Plot over
> the pipe much slower.  I will have to look into the FLTK backend too.
> Again thanks for the help.
>
> On Mon, Nov 23, 2009 at 2:16 AM, Carlo de Falco <address@hidden> wrote:
>>
>> On 23 Nov 2009, at 12:30, Todd Rovito wrote:
>>
>>> I just started to use Octave for some image processing work and have
>>> noticed how slow Octave is to display images in gnu-plot.
>>> On my 1
>>> year old Mac Book Pro it can take 5 seconds to display a 4 mega-pixel
>>> 8 bit image.  Attached is the function I use to read such image.  I am
>>> wondering if I have something installed wrong or this is a natural
>>> behavior or Octave?  Please understand I am not complaining about
>>> Octave's performance, it seems speedy on everything except for image
>>> display.
>>>
>>>
>>> Thanks for the help.
>>
>>
>> I am afraid this is due to the way communication between Octave and gnuplot
>> is implemented.
>> As communication is implemented via pipes, transferring the image data to
>> gnuplot takes about
>> the same time as writing the whole uncompressed image data to a file and
>> then reading it back.
>> This is one of the reasons why a new graphics backend based on OpenGL is
>> currently under
>> developement.
>> To get an idea of the speed improvement given by the new backend you can
>> try:
>>
>> sombrero (500)
>> close all
>> backend ('fltk')
>> sombrero (500)
>>
>> The difference is really impressive on my own white plastic Core 2 Duo
>> MacBook.
>> unfortunately the new backend does not yet support imshow in the current
>> stable release.
>> If this feature is important to you might want to consider joining the
>> developers mailing list
>> and helping get Octave 3.4 out soon.
>>
>> HTH,
>> c.
>>
>>
>>
>>
>