tkImg Rendering Problem
James Allen
It recently became necessary for us to display .png format images in
our application. In order to do this, we built and installed the
tkImg extension. To perform the build we checked out the latest
sources from the Subversion repository at Sourceforge (http://
sourceforge.net/projects/tkimg/). We built the package on top of Tcl/
Tk 8.4.2 on Linux RHEL3.0/2.4. The version of libpng that was built
is 1.2.24.
We are able to use tkImg to display images without complaint or
message, but the images displayed are not correct. Specifically,
levels of transparency are not rendered correctly. We created a test
image that consists of a solid black rectangle in the middle and a
circle around it. The circle is also black but has an alpha value of
10, i.e. is very nearly fully transparent. Using gimp and firefox, on
a white background, it shows up as a faint gray circle. When we
display this same image using tkImg, however, the circle is full
black.
I'm wondering if tkImg is built correctly. Perhaps there is some
configuration or compile option that we need to specify to cause
transparency to be honored?
We tried downloading ActiveTcl version 8.4.18 and using it and that
made a difference - but image transparency was still not rendered
correctly. Now the circle displays as a gray that is darker than the
gimp or firefox rendering. For practical purposes this results in an
unacceptable "glow" around the images we are displaying that make use
of variable transparency (e.g. icons).
We tried some other combinations of Tcl/Tk versions and tkImg and
there was some variation in the darkness of the transparent circle but
in none of them did it match the reference image.
Can anyone shed light on this behavior? Has anyone else experienced
the tkImg renderings of .png files being incorrect?
Thanks!
James Allen
George Peter Staplin
> Hello,
>
> It recently became necessary for us to display .png format images in
> our application. In order to do this, we built and installed the
> tkImg extension. To perform the build we checked out the latest
> sources from the Subversion repository at Sourceforge (http://
> sourceforge.net/projects/tkimg/). We built the package on top of Tcl/
> Tk 8.4.2 on Linux RHEL3.0/2.4. The version of libpng that was built
> is 1.2.24.
Tk 8.4.2 is ancient. That's before the alpha transparency stuff was
really added to Tk, unfortunately it's still not right in Tk 8.5 or 8.6.
See this bug that affects Tk to this day:
http://www.xmission.com/~georgeps/tmp/clipping_bug.tcl
When you scroll the text widget, the image stops displaying. It's a
clipping bug, relating to the XGetImage() returning NULL, because a
coordinate caused a BadMatch. I've even patched it, but my patch was
rejected as too costly. Unfortunately there's not a way around this,
because the Tk public API would need to change to cache the drawable
information, and we can't do that now.
> We are able to use tkImg to display images without complaint or
> message, but the images displayed are not correct. Specifically,
> levels of transparency are not rendered correctly. We created a test
> image that consists of a solid black rectangle in the middle and a
> circle around it. The circle is also black but has an alpha value of
> 10, i.e. is very nearly fully transparent. Using gimp and firefox, on
> a white background, it shows up as a faint gray circle. When we
> display this same image using tkImg, however, the circle is full
> black.
That makes sense. It doesn't have anything to blend with, and performs
no blending. It's all boolean transparency.
> I'm wondering if tkImg is built correctly. Perhaps there is some
> configuration or compile option that we need to specify to cause
> transparency to be honored?
You need to upgrade, and I need to push to get the clipping_bug.tcl bug
fixed. I've complained about it before only to be told "the fix is too
costly." Correctness should come before speed IMO.
> We tried downloading ActiveTcl version 8.4.18 and using it and that
> made a difference - but image transparency was still not rendered
> correctly. Now the circle displays as a gray that is darker than the
> gimp or firefox rendering. For practical purposes this results in an
> unacceptable "glow" around the images we are displaying that make use
> of variable transparency (e.g. icons).
Strange. I don't see that, but perhaps the gamma or something is weird
with TkImg. I don't use the Img extension usually though. I tend to
use megaimage, pngext2, and megaimagetk or ntk.
> We tried some other combinations of Tcl/Tk versions and tkImg and
> there was some variation in the darkness of the transparent circle but
> in none of them did it match the reference image.
>
> Can anyone shed light on this behavior? Has anyone else experienced
> the tkImg renderings of .png files being incorrect?
Yes. I recall several complaints over the years about that. I thought
they had been fixed.
George
James Allen
<georgepsSPAMME...@xmission.com> wrote:
George, thank you for the insightful reply.
> > It recently became necessary for us to display .png format images in
> > our application. In order to do this, we built and installed the
> > tkImg extension. To perform the build we checked out the latest
> > sources from the Subversion repository at Sourceforge (http://
> > sourceforge.net/projects/tkimg/). We built the package on top of Tcl/
> > Tk 8.4.2 on Linux RHEL3.0/2.4. The version of libpng that was built
> > is 1.2.24.
>
> Tk 8.4.2 is ancient. That's before the alpha transparency stuff was
> really added to Tk, unfortunately it's still not right in Tk 8.5 or 8.6.
>
> See this bug that affects Tk to this day:http://www.xmission.com/~georgeps/tmp/clipping_bug.tcl
>
> When you scroll the text widget, the image stops displaying. It's a
> clipping bug, relating to the XGetImage() returning NULL, because a
> coordinate caused a BadMatch. I've even patched it, but my patch was
> rejected as too costly. Unfortunately there's not a way around this,
> because the Tk public API would need to change to cache the drawable
> information, and we can't do that now.
Interesting. I ran clipping_bug.tcl under 8.4.2 and the image does
not disappear when scrolling, but remains solidly displayed. The
borders of the letters, however, appear dark and somewhat broken.
When I run the script under 8.4.18, the image disappears when
scrolling, as you relate. The letter borders are much smoother,
however.
> > We are able to use tkImg to display images without complaint or
> > message, but the images displayed are not correct. Specifically,
> > levels of transparency are not rendered correctly. We created a test
> > image that consists of a solid black rectangle in the middle and a
> > circle around it. The circle is also black but has an alpha value of
> > 10, i.e. is very nearly fully transparent. Using gimp and firefox, on
> > a white background, it shows up as a faint gray circle. When we
> > display this same image using tkImg, however, the circle is full
> > black.
>
> That makes sense. It doesn't have anything to blend with, and performs
> no blending. It's all boolean transparency.
>
> > I'm wondering if tkImg is built correctly. Perhaps there is some
> > configuration or compile option that we need to specify to cause
> > transparency to be honored?
>
> You need to upgrade, and I need to push to get the clipping_bug.tcl bug
> fixed. I've complained about it before only to be told "the fix is too
> costly." Correctness should come before speed IMO.
We are pursuing upgrading. Our product is supported on many
platforms, though, and built with many extensions, from both external
and internal sources. So, unfortunately, upgrading is a non-trivial
task.
>
> > We tried downloading ActiveTcl version 8.4.18 and using it and that
> > made a difference - but image transparency was still not rendered
> > correctly. Now the circle displays as a gray that is darker than the
> > gimp or firefox rendering. For practical purposes this results in an
> > unacceptable "glow" around the images we are displaying that make use
> > of variable transparency (e.g. icons).
>
> Strange. I don't see that, but perhaps the gamma or something is weird
> with TkImg. I don't use the Img extension usually though. I tend to
> use megaimage, pngext2, and megaimagetk or ntk.
We are considering the use of TkPNG, which does render images
correctly in our testing thus far, though of course not with Tcl/Tk
8.4.2 (same result as TkImg, for reasons you previously explicated).
I did a search for the packages you mention above (megaimage, etc.).
It wasn't clear from my brief perusal of the results if these provide
a format extension to the "image create" command or something more
elaborate.
> > We tried some other combinations of Tcl/Tk versions and tkImg and
> > there was some variation in the darkness of the transparent circle but
> > in none of them did it match the reference image.
>
> > Can anyone shed light on this behavior? Has anyone else experienced
> > the tkImg renderings of .png files being incorrect?
>
> Yes. I recall several complaints over the years about that. I thought
> they had been fixed.
Unfortunately, at least based on my testing, it appears they have not.
Thanks,
James
Jeff Hobbs
> > > Can anyone shed light on this behavior? Has anyone else experienced
> > > the tkImg renderings of .png files being incorrect?
>
> > Yes. I recall several complaints over the years about that. I thought
> > they had been fixed.
>
> Unfortunately, at least based on my testing, it appears they have not.
It would be good to see reproducible problem cases (with script and
images) based on the latest code base (8.4.19 or preferrably 8.5.2).
Jeff