[fpc-pascal] Why is FPImage dog slow in reading jpeg's?

Tomas Hajny XHajT03 at hajny.biz
Mon May 30 17:24:59 CEST 2011


On Mon, May 30, 2011 16:59, michael.vancanneyt at wisa.be wrote:
> On Mon, 30 May 2011, Tomas Hajny wrote:
>> On Mon, May 30, 2011 16:16, michael.vancanneyt at wisa.be wrote:
>>>
>>> Try the following code:
>>>
>>> Img:=TFPMemoryImage.Create(0,0);
>>> Img.UsePalette:=False;
>>> Img.loadFromFile(FileList[i]);
>>>
>>> That should work much faster. The reason is probably that the default
>>> image
>>> created by the reader uses a palette, which is of course dog slow when
>>> reading
>>> large images.
>>
>> Interesting. What is supposed to be a "large image"? I ask because the
>> original post mentioned 35 kB and 65 kB (and indirectly also dimensions
>> around 600x400 if I understand the program output correctly) which I
>> certainly wouldn't consider as "large" (and the mentioned time necessary
>> for reading it surely not appropriate regardless of using palette or
>> not).
>> I guess that some optimization may be reasonable because such pictures
>> could be loaded and displayed (including conversion from true colour to
>> 256 colours palette) faster even on a 486 machine...
>
> It depends on the colors used. The default palette algorithm simply
> allocates a slot per found color in the jpg and returns the index of the
> slow. For a picture, this will create a huge palette, in which the search
> for a color is in essence linear, so n^2 lookups.
>
> So, dog slow.
>
> You could obviously speed this up by creating a palette yourself, and
> limiting the number of colors.
>
> Or, best for pictures is  not to use a palette, which is what my solution
> entails.

OK, I see. The point is not about what I need or not (I don't need to work
with pictures at the moment) but about what will happen if people start
using the current code as it is provided in FCL. I'm sure there are
various possibilities for some "optimization" - should it be using a
different (faster) algorithm for creating the palette (e.g. different
algorithms depending on whether the original picture contains a palette or
not), not creating the palette by default for pictures not using it (or
not doing it at all unless explicitly requested, i.e. changing the default
behaviour as suggested by Matthias), limiting the maximum colour depth for
pictures with palette (as mentioned by Ben), etc. In any case, I'm afraid
that the current default behaviour will not work well for majority of FPC
users and their use cases.

Tomas





More information about the fpc-pascal mailing list