This is not necessarily the current version of this TIP.
| TIP: | 166 |
| Title: | Reading and Writing the Photo Image Alpha Channel |
| Version: | $Revision: 1.4 $ |
| Author: | Donal K. Fellows <donal dot k dot fellows at man dot ac dot uk> |
| State: | Draft |
| Type: | Project |
| Tcl-Version: | 8.5 |
| Vote: | Pending |
| Created: | Wednesday, 19 November 2003 |
| Keywords: | Tk, image get, image put |
This TIP describes how to update the image get and image put subcommands so as to allow script-level access to the full alpha channel information that has been present in the photo image data model since Tk 8.3.
Alpha channels. We've had them in Tk's photo image data model (which is currently 8-bits-per-channel RGBA) for quite some time now. We can copy the alpha data around inside the image. We now display them correctly on deep-enough displays (many thanks to the people who have worked on that!) But can we write alpha data into an image? No. Not unless you have an image format handler that produces alpha data installed (e.g. the PNG from tkimg.) I think we should fix this so that people can read and write the full alpha data from scripts.
I propose to update the photoImageInstance get subcommand so that it returns four values instead of three, with the fourth being the contents of the alpha channel for the pixel.
I also propose to update the photoImageInstance put subcommand so that alpha channel information may be specified in the following ways when using the list-of-lists-of-pixel-data format (the image-format format will be up to the particular image format code, as always.)
If a pixel is specified as being the empty string, that pixel will be set to be completely transparent. This parallels the interpretation of the empty string as transparency elsewhere within the core (notably in [canvas] items.)
Any pixel colour format that is not the empty string (e.g. bisque2 or #abcdef) may have the following suffix added - @A - where A is a fractional alpha value in the range 0.0 to 1.0 (which values correspond to fully transparent and fully opaque respectively.)
Any pixel colour format that is not the empty string and which does not have a @A suffix may have a #XX suffix, where XX is a pair of hex digits that specify an integer alpha value in the range 0 (fully transparent) to 255 (fully opaque).
All pixel colours that have neither of the foregoing suffixes are to be interpreted as being fully opaque, which is the current situation anyway.
An additional pixel format is to be supported, consisting of a Tcl list of three or four integers in the range 0 to 255, being the value of the red channel, green channel, blue channel and alpha channel respectively in that order. An absent alpha channel is to be interpreted as full opacity.
Additionally, the photoImageInstance transparency command's subcommands will be updated in the following way:
The get subcommand will be modified to take an extra option, -alpha (to be placed after the coordinates), that modifies the result to be the integral alpha value (in the range 0 to 255) for the specified pixel. Without the option, the result shall continue to be a boolean that is true exactly when the pixel is wholly transparent. Also supported will be a -boolean option (in the same position) which will be interpreted as meaning the current behaviour. Only one of the two options will be allowed.
The set subcommand will be modified to take an extra option, -alpha (to be placed after the coordinates), that modifies the interpretation of the following value so that it is the integral alpha value to be set for the pixel. Similarly to the get command, there will also be a -boolean option to indicate the current behaviour, and which will mutually exclusive with the -alpha option.
Nothing yet.
This document is placed in the public domain.
This is not necessarily the current version of this TIP.