Photo with -data option
Gary
image files. Now I want speed things up and use internally
stored data. I've read in a GIF87 file, compared it byte for byte
with the original file (to make sure I've read it correctly),
and passed it to Photo using the -data option.
I keep getting "couldn't recognize image data at
/Perl/site/lib/Tk/image.pm line 21"
I grepped the directories for "recognize" and I can't even find the
error message in any of the pm files. I changed image.pm to Writable
and added print statements around the offending line. The option
-data and the image data are arriving there intact.
Anyone have any idea what I'm doing wrong? Where is the code
(handler) which actually interprets the GIFs?
Thanks in advance.
Thomas Bayen
> Anyone have any idea what I'm doing wrong? Where is the code
> (handler) which actually interprets the GIFs?
Much of the Tk code is written in C. Thats much faster, but you have to
get a source package to analyse it.
Mit freundlichen Grüßen,
Thomas Bayen
t.b...@bayen.de, Tel. 02151/29262
Jim Scavok
[snip][snip]
Try something like this:
use strict;
use Tk;
my $mw = MainWindow->new();
my $ref = $mw->Photo( # ref to new image object
-file => "camel.gif", # one-time disk hit to load image
);
my $imgdata = $ref->data( # convert image data to a string
-format => "gif",
);
$ref->configure(
-data => $imgdata, # configure image object to use
-format => "gif", # string instead of hitting disk
);
$mw->Button(
-command => sub { exit },
-image => $ref,
)->pack;
MainLoop;
Stephen O. Lidie
> Gary wrote:
>> Anyone have any idea what I'm doing wrong? Where is the code
>> (handler) which actually interprets the GIFs?
> Much of the Tk code is written in C. Thats much faster, but you have to
> get a source package to analyse it.
More detail in the yes-it-will-be-a-book, but, in short, binary image
types must be Base-64 encoded so we have printable strings - due to
Tcl's "everything-isa-string" heritage.
Several solutions are in the pTk list archives.... mail me if you
cannot search-up a solution.
Steve
--
@_=map{eval"100${_}"}split/!/,'/5!*2!+$]!/10+$]';use Tk;$m=tkinit;$t='just an'.
'other perl hacker';$z='createText';$c=$m->Canvas(-wi,$_[1],-he,25)->grid;$c->$
z(@_[2,3],-te,$t,-fi,'gray50');$c->$z($_[2]-$],$_[3]-$],-te,$t);$m->bind('<En'.
'ter>',sub{$y=int(rand($m->screenheight));$m->geometry("+$y+$y")});MainLoop;
Jim Scavok
[snip]
> my $ref = $mw->Photo( # ref to new image object
> -file => "camel.gif", # one-time disk hit to load image
> );
>
> my $imgdata = $ref->data( # convert image data to a string
> -format => "gif",
> );
>
> $ref->configure(
> -data => $imgdata, # configure image object to use
> -format => "gif", # string instead of hitting disk
> );
>
> $mw->Button(
> -command => sub { exit },
> -image => $ref,
> )->pack;
Hmm. Now I'm confused.
According to Tk::Photo help, "-data => string : If both the -data and
-file options are specified, the -file option takes precedence."
I created the image object with -file; later, I called `configure'
with -data and -format. Does that "over-ride" (i.e., reconfigure) the
image object, thereby replacing -file with -data/-format? Or does it
simply add -data/-format to the image object created with -file? If
it's the latter, then according to the Tk::Photo help, -file will take
precedence over -data/-format.
This could be tested empirically by specifying -file => "a:\camel.gif"
and observing the drive LED for activity. Of course, it would have to
be a rather large .gif file (e.g., > 4k bytes) so its contents could
not be kept in the buffered disk stream.
Stephen O. Lidie
> Once upon a time I wrote
> [snip]
>> my $ref = $mw->Photo( # ref to new image object
>> -file => "camel.gif", # one-time disk hit to load image
>> );
>>
>> my $imgdata = $ref->data( # convert image data to a string
>> -format => "gif",
>> );
This does the base64 encoding for you.
>>
>> $ref->configure(
>> -data => $imgdata, # configure image object to use
>> -format => "gif", # string instead of hitting disk
>> );
This is proof that -data works.
>>
>> $mw->Button(
>> -command => sub { exit },
>> -image => $ref,
>> )->pack;
> [snip]
> Hmm. Now I'm confused.
> According to Tk::Photo help, "-data => string : If both the -data and
> -file options are specified, the -file option takes precedence."
That's on the same statement:
$photo = $mw->Photo(-file .... -data);
> I created the image object with -file; later, I called `configure'
> with -data and -format. Does that "over-ride" (i.e., reconfigure) the
> image object, thereby replacing -file with -data/-format? Or does it
Yes
> simply add -data/-format to the image object created with -file? If
> it's the latter, then according to the Tk::Photo help, -file will take
> precedence over -data/-format.
> This could be tested empirically by specifying -file => "a:\camel.gif"
> and observing the drive LED for activity. Of course, it would have to
> be a rather large .gif file (e.g., > 4k bytes) so its contents could
> not be kept in the buffered disk stream.
Steve
James Gilbert
You can avoid creating the file by using the MIME::Base64
module (get it on CPAN).
use MIME::Base64 'encode_base64';
my $photo = $mw->Photo(
'-format' => 'gif',
-data => encode_base64($gif),
);
I use this for placing GIFs which I generate with
GD.pm onto a Tk::Canvas.
I discovered that it needed the data base64
encoded only after reading a hint in the
release notes of a version of Tk 4 (under the
heading "Beware of the Leopard")!
I guess that, unlike Perl, Tk isn't 8 bit clean.
James
Slaven Rezic
> I guess that, unlike Perl, Tk isn't 8 bit clean.
Perl and Tk are, but Tcl was not.
Regards,
Slaven
--
use Tk;$c=tkinit->Canvas(-he,20)->grid;$x=5;map{s!\n!!g;map{create$c 'line'=>
map{$a=-43+ord;($x+($a>>3)*2=>5+($a&7)*2)}split''}split"!";$x+=12}split/_/=>'K
PI1_+09IPK_K;-OA1_+K!;A__1;Q!7G_1+QK_3CLPI90,_+K!;A_+1!KQ!.N_K+1Q!.F_1+KN.Q__1+
KN._K+1Q!.F_1+KN.Q_+1Q__+1!KQ!.N_1;Q!7G_K3,09Q_+1!K.Q_K+1Q!.F_1+KN.Q_';MainLoop