From: Bezoar on
Every example I've seen of creating a image photo from a string
involves a string converted to base64. This string is read in
verbatum to produce an image as follows:

image create photo img1 -data { R0lGODdhCQAJAIAAAASCBPz+/
CwAAAAACQAJAAACEYwPp5Aa3BBcMJrqHsua
P1MAADs=
}

Ok all well and good now suppose I create a gif file for an Icon I
want to use but want to save it as a string.

image create photo img1 -file icon.gif
set buffer [img1 data ]
puts "$buffer"

buffer looks something like this :
{#fcfefc #fcfefc #fcfefc #....

If I base64 encode this I dont get anything like what I started with.
My question is How do I get the original data string back out of the
image?
My test code is below with output I used 8.6b.2

package require Tk
wm withdraw .
package require base64
set datastring { R0lGODdhCQAJAIAAAASCBPz+/
CwAAAAACQAJAAACEYwPp5Aa3BBcMJrqHsua
P1MAADs=
}
set myimg [image create photo -data $datastring ]

if { [string match $datastring [$myimg data ] ] } {
puts "Image comes back in base64 encoded"
} else {
puts "Image does not come back in base64 encoded:
original :[string range $datastring 0 25 ]
as stored:[string range [$myimg data] 0 25 ]"
# encode with base64 before compare
set buffer [base64::encode [$myimg data ]]
if { [string match $datastring [$myimg data ]] } {
puts "Image comes unencoded but is encodable back to original form"
} else {
puts "Image data does not come back in original form even with
encoding:
original :[string range $datastring 0 25 ]
Encoded as stored:[string range [base64::encode [$myimg data ]] 0
25 ]"
}
}

exit
================== End Script ================
Output:

Image does not come back in base64 encoded:
original :
R0lGODdhCQAJAIAAAASCB
as stored:{#fcfefc #fcfefc #fcfefc #
Image data does not come back in original form even with encoding:
original :
R0lGODdhCQAJAIAAAASCB
Encoded as stored:eyNmY2ZlZmMgI2ZjZmVmYyAjZm

Thanks Ahead of time, Bezoar

From: Aric Bills on
For one thing, you need to specify a -format:

$myimg data -format gif

However, I was surprised to discover that the above doesn't work in my
ActiveTcl installation (Tcl 8.6b1.2, ActiveTcl 8.6.0.0.292682, 32-bit
Linux) unless I do [package require Img]. (I thought GIF support was
built into the core; that seems to be true for reading but not for
writing.) What's worse, with Img, the data gets mangled, as can be
seen by running the code below:

package require Tk
package require Img
set datastring {R0lGODdhCQAJAIAAAASCBPz+/
CwAAAAACQAJAAACEYwPp5Aa3BBcMJrqHsua
P1MAADs=
}
set myimg1 [image create photo -data $datastring]
set myimg2 [image create photo -data [$myimg1 data -format gif] -
format gif]
toplevel .test
wm minsize .test 150 50
label .test.l1 -image $myimg1
label .test.l2 -image $myimg2
grid .test.l1 .test.l2

The following works as expected:

package require Tk
package require Img
set datastring {R0lGODdhCQAJAIAAAASCBPz+/
CwAAAAACQAJAAACEYwPp5Aa3BBcMJrqHsua
P1MAADs=
}
set myimg1 [image create photo -data $datastring]
set myimg2 [image create photo -data [$myimg1 data -format png] -
format png]
toplevel .test
wm minsize .test 150 50
label .test.l1 -image $myimg1
label .test.l2 -image $myimg2
grid .test.l1 .test.l2

However, without Img (which should not be necessary since 8.6
introduces PNG support in the core), the data is also altered,
although not as severely as with the GIF in the first test code:

package require Tk
set datastring {R0lGODdhCQAJAIAAAASCBPz+/
CwAAAAACQAJAAACEYwPp5Aa3BBcMJrqHsua
P1MAADs=
}
set myimg1 [image create photo -data $datastring]
set myimg2 [image create photo -data [$myimg1 data -format png] -
format png]
toplevel .test
wm minsize .test 150 50
label .test.l1 -image $myimg1
label .test.l2 -image $myimg2
grid .test.l1 .test.l2

Am I doing something wrong, or are these bugs? If so, which are Img
bugs and which are core Tk bugs?
From: Donal K. Fellows on
On 18/07/2010 09:23, Aric Bills wrote:
> For one thing, you need to specify a -format:
>
> $myimg data -format gif
>
> However, I was surprised to discover that the above doesn't work in my
> ActiveTcl installation (Tcl 8.6b1.2, ActiveTcl 8.6.0.0.292682, 32-bit
> Linux) unless I do [package require Img]. (I thought GIF support was
> built into the core; that seems to be true for reading but not for
> writing.)

The GIF writing code only writes to files, for reasons I do not know.
I'll have a quick look into how easy it might be to lift that
restriction, but no promises...

Donal.
From: Donal K. Fellows on
On 18/07/2010 09:23, Aric Bills wrote:
> However, without Img (which should not be necessary since 8.6
> introduces PNG support in the core), the data is also altered,
> although not as severely as with the GIF in the first test code:
[...]
> Am I doing something wrong, or are these bugs? If so, which are Img
> bugs and which are core Tk bugs?

That one looks like a bug in the PNG engine, specifically in the alpha
channel handling (you can confirm by setting the background color of the
label widget). Not sure offhand whether it is the reader (serious) or
the writer (less critical; just important...)

Donal.
From: Donal K. Fellows on
On 18/07/2010 23:25, Donal K. Fellows wrote:
> The GIF writing code only writes to files, for reasons I do not know.
> I'll have a quick look into how easy it might be to lift that
> restriction, but no promises...

Turned out to be pretty easy to fix. The Tk HEAD can now produce GIF
format data from [$photo data] if asked nicely. :-)

Donal.