[REBOL] Re: do %image.png
From: jasonic::panix::com at: 15-Nov-2001 8:27
Thanks everyone...
Ryan and Gabriele both suggested I put my script in a block, and Ryan noted
a bug where that the outer block needs to be preceeded by "^/" or #{0A}.
Unfortunately this strategy still does not work inside a binary file. Nice
try ;-) Maybe next version ??
>> do %buddha_inablock.png
** Syntax Error: Script is missing a REBOL header
** Near: do %buddha_inablock.png
Porter suggested using a more sophisticated use of "read", to avoid need to
first load the entire image binary into a string as I do now.
To recap, this took about 6 seconds for a 29Kb PNG image on 500Mhz PIII.
Once loaded like this, it was very fast and flexible to find my script.
> Basically using a combination of read/part/skip you should be able to
> navigate thru the various chunks to get to the chunk you want. The first
4
> bytes of a chunk indicate its length, and the next 4 indicate the chunk
> type. So - after reading the first 8 bytes of the file to verify it's a
> PNG, read the next 8 bytes and take a look at them to see if the next
chunk
> is a "tEXt" chunk - if not use the length value as the skip in a read...
> You'll have to accumulate bytes read and what not though. But - it'd
avoid
> you having to scan thru the file for an identifier.
On first impressions, this does seem to be much faster hybrid approach. It
should really help with larger images.
Now I just need to become more skilled in my use of read/binary/part/skip
:-)
I think storing special PNG 'tEXt' chunk keyword like "REBOLscript" before
the REBOL[] script block is a good strategy. Consistent with PNG spec, which
anticipates common keyword descriptors [Title, description, ..], but also
specialized and highly individual ones. The keyword naming scheme could be
extended to allow multiple scripts in the same PNG file:
REBOLscript0000
,"REBOLscript0001", ... "REBOLscript9999" or maybe more
poetic choices.
For some uses this would be overkill, but at a minimum I can see argument
for using 2 distinct scripts, a default 'Image-system.r' and a
'Image-script.r'.
The first would be probably be much better defined, associated with
security, and the the outer mechanics for transport, parse, edit, display
functions.
The second script would be freer according to whatever the
application/context. There woudl be some filesize bloat, so hwere that was
critical one might try comprssion and bundling.
Imagine an image which is widely shared, among a group of system or
individual people. Each of thse might want to have their own small script
space inside. Much like VANILLA snip/dynasnip scheme, which is where I am
going to use this initially. Instead of multiple scipts,it might be better
to have lots of objects inside a snigle script. This wuold seem to afll
inline faster with Vanilla's structuer, and also adapt nicely to xmlrpc
programming.
No reason that eveything has to be REBOL either, its #1 choice here. Python
is a good candidate too.
- Jason
