Tcl - TIP #198: Image Command XPM Extension

Author

TIP #198: Image Command XPM Extension

R. Timothy Edwards

2004-05-17, 7:32 pm

TIP #198: IMAGE COMMAND XPM EXTENSION
=======================================
Version: $Revision: 1.2 $
Author: R. Timothy Edwards <tim_at_stravinsky.jhuapl.edu>
Don Porter <dgp_at_users.sf.net>
State: Draft
Type: Project
Tcl-Version: 8.4
Vote: Pending
Created: Wednesday, 12 May 2004
URL: http://purl.org/tcl/tip/198.html
WebEdit: http://purl.org/tcl/tip/edit/198
Post-History:

-------------------------------------------------------------------------

ABSTRACT
==========

This TIP proposes an extension to the Tk *image* command to incorporate
color pixmap images based on the XPM format. The format is analogous to
the *bitmap* option (/tkImgBmap.c/ in the Tk source).

RATIONALE
===========

The "XPM" format has become more-or-less a standard, and is a nice
text-readable color alternative to the standard X11 bitmap format. The
runtime library for XPM is available in standard Linux distributions
and elsewhere. Tk has a number of color *photo* image formats, but
these make various assumptions about rendering. There is no color
alternative to the simple pixel-based bitmap format.

SPECIFICATION
===============

This TIP specifies the extension of the *image* command in the
following manner:

*image create xpm* /name/ *-file* /xpm_file/

It would probably be a nice idea to include in-line pixmap
specifications similar to that allowed for bitmaps by the BLT package.
However, at this time, the reference implementation does not include
such an extension.

REFERENCE IMPLEMENTATION
==========================

There is an implementation in the source for
XCircuit[<URL:http://xcircuit.ece.jhu.edu/>]. The source file is
"tkPixmap.c".

COMMENTS
==========

I'd like to see more justification in this proposal as to why a new
image type is needed, rather than implementing a suitable format for
either the existing bitmap or photo image types.

COPYRIGHT
===========

This document has been placed in the public domain.

-------------------------------------------------------------------------

TIP AutoGenerator - written by Donal K. Fellows

[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
Send administrivia to tcl-announce-request@mitchell.org
Tcl/Tk at http://tcl.tk/ ]]

Andreas Leitgeb

2004-05-18, 6:31 am

R Timothy Edwards <tim@stravinsky.jhuapl.edu> wrote:
> COMMENTS
>==========
> I'd like to see more justification in this proposal as to why a new
> image type is needed, rather than implementing a suitable format for
> either the existing bitmap or photo image types.
>
I'd expect different semantics in cases of low-depth displays.
While a "photo" conveys the type of images that are usually
stored as jpeg's, an "xpm" (or some other name) might convey
rather the discrete pixel-types of images (like .xpm, .gif)
Treatment may differ on low-color displays (usually depth=8),
where photos might be best served with a private palette
(for a 6x6x6-colorcube plus some system-colors), whereas
the other type would be guaranteed to be forced into the
standard palette (to avoid any palette-switching)

Just an idea. I'm not sure how photo-images and 8bit-displays
work together now, since it's a long time since I last used
tk's photo images on a 8bit display. Nor am I sure whether
8bit-displays are even worth a thought nowadays.

Anyway, wherever these types of images are mixed up, resulting
quality always s*cks. (as everyone can see when converting a
jpeg to a gif or reverse)

Donal K. Fellows

2004-05-18, 10:46 am

Andreas Leitgeb wrote:
> Just an idea. I'm not sure how photo-images and 8bit-displays
> work together now, since it's a long time since I last used
> tk's photo images on a 8bit display. Nor am I sure whether
> 8bit-displays are even worth a thought nowadays.

I'm tempted to urge people to just ignore 8-bit displays. The only place
you're likely to hit them in anger is on very old Unix workstations.
There are other features (e.g. alpha blending) that will never work on
8-bit displays either because it's computationally awful and likely to
fail bizarrely too.

IMHO it's very reasonable to s

to do loading of XPMs into either
photo or bitmap images (the XPM format supports both colour and
monochrome information) but introducing a new image type for it seems a
bit anachronistic, and will make it harder for people to combine XPMs
with general image manipulation...

Donal.

David S. Cargo

2004-05-18, 6:32 pm

"Donal K. Fellows" <donal.k.fellows@man.ac.uk> wrote:

>Andreas Leitgeb wrote:
>
>I'm tempted to urge people to just ignore 8-bit displays. The only place
>you're likely to hit them in anger is on very old Unix workstations.
>There are other features (e.g. alpha blending) that will never work on
>8-bit displays either because it's computationally awful and likely to
>fail bizarrely too.

When I'd doing testing with android, I use remote desk tops (when
driving Windows); this is a lot more efficient with an 8-bit display.

escargo

David S. Cargo (escargo@skypoint.com)

Sponsored Links