On 8/24/05, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> While Perl has many facilities for handling text very well, it does not have
> any limitations with handling binary data. It can easily segment such data,
> convert it from ASCII to binary, generate it, etc. Perl strings can contain
> \0 characters, and thus can represent binary data. Several functions in the
> perlfunc man page can be used to manipulate binary data (like pack() and
> unpack()), and often text-oriented functions that are operated on binary data
> will also work. A similar functionality should be available for programming
> languages that are similar to Perl.
> The main problem with using Perl for this job is that processing thousands or
> millions of Pixels in Perl may be considerably slower than in C, due to the
> fact executing expressions, conditionals and loops in Perl has much more
> speed overhead over their C counterparts. Thus, it is recommended to write an
> image loader in C.
> But handling binary data alone is not the problem here. It is not harder in
> Perl than in C, albeit may be (like many other tasks) slower.


I'm using pack, unpack and substr in perl.  This works quite well.  

And "slower" means "a second or two instead of a fraction of a second".
For what I'm dealing with, this is a minor issue.

My interest is in breaking new ground.  There's sometimes other people who 
are happy to write and support fast C code -- they sometimes use what
I've written as a design basis, and more power to them.  That's less
maintenance work for me.

But I'm guessing what people are saying is that even with the gimp
bindings, SIOD doesn't have enough relevant type punning features, 
so it'll be considerably slower than using perl to just write a different 
kind of image file.  In other words, I can't use the "everything is a
sequence of bytes" mechanism for representing image data?
Gimp-developer mailing list

Reply via email to