Tk_FindPhoto(3)

πŸ’… Tk_FindPhoto(3) β€” Tk Library Procedures πŸŽ€

okay bestie, so like β€” this is the Tk_FindPhoto(3) page from the Tk Library Procedures, and it's literally the whole glow-up guide for manipulating the image data stored in a photo image. photo image data? yes. manipulation? yes. we're getting into it ✨


✨ NAME ✨

Bestie, this page is a whole squad, not just one function. Say hi to:

  • Tk_FindPhoto
  • Tk_PhotoPutBlock
  • Tk_PhotoPutZoomedBlock
  • Tk_PhotoGetImage
  • Tk_PhotoBlank
  • Tk_PhotoExpand
  • Tk_PhotoGetSize
  • Tk_PhotoSetSize

and collectively? they manipulate the image data stored in a photo image. that's the whole vibe. periodt πŸ’–


🌸 SYNOPSIS 🌸

here's the whole friend group arriving at the function, fr fr β€” copy these exactly, no cap:

#include <tk.h>

Tk_PhotoHandle
Tk_FindPhoto(interp, imageName)

int
Tk_PhotoPutBlock(interp, handle, blockPtr, x, y, width, height,compRule)

int
Tk_PhotoPutZoomedBlock(interp, handle, blockPtr, x, y, width, height,zoomX, zoomY, subsampleX, subsampleY, compRule)

int
Tk_PhotoGetImage(handle, blockPtr)

Tk_PhotoBlank(handle)

int
Tk_PhotoExpand(interp, handle, width, height)

Tk_PhotoGetSize(handle, widthPtr, heightPtr)

int
Tk_PhotoSetSize(interp. handle, width, height)

ok lowkey Tk_PhotoPutBlock and Tk_PhotoPutZoomedBlock are the main characters here β€” look at all those parameters. icon behavior. πŸ‘‘


πŸ¦‹ ARGUMENTS πŸ¦‹

every single argument, in order, no skips, no cuts β€” this is the full roster πŸ’œ

  • Tcl_Interp *interp (in) β€” the interpreter where the image was created, and also where the error reporting happens. so like, it's the group chat and the drama-reporting channel all at once. 😭
  • const char *imageName (in) β€” the name of the photo image. that's the ID you're searching for, bestie. πŸ”
  • Tk_PhotoHandle handle (in) β€” an opaque handle that identifies which photo image is getting affected. opaque means you don't peek behind the curtain, you just hold it and vibe. 🫢
  • Tk_PhotoImageBlock *blockPtr (in) β€” specifies the address and storage layout of the image data. like, where it lives and how it's arranged. very "here's my address and also my star sign". ✨
  • int x (in) β€” the X coordinate where the top-left corner of the block gets placed inside the image. left-to-right placement, slay. ➑️
  • int y (in) β€” the Y coordinate where that same top-left corner of the block lands inside the image. down we go. ⬇️
  • int width (in) β€” the width of the image area being affected (that's for Tk_PhotoPutBlock) or the desired image width (that's for Tk_PhotoExpand and Tk_PhotoSetSize). same word, two moods, iykyk. πŸ’…
  • int compRule (in) β€” the compositing rule used when combining transparent pixels in a block of data with a photo image. this one matters, bestie, so listen up: it must be one of these two, no substitutions:
    • TK_PHOTO_COMPOSITE_OVERLAY β€” which puts the block of data over the top of the existing photo image, with the previous contents showing through in the transparent bits. like a cute sheer layer. 🧚
    • TK_PHOTO_COMPOSITE_SET β€” which discards the existing photo image contents in the rectangle covered by the data block. brutal. no survivors. πŸ’€
  • int height (in) β€” the height of the image area being affected (for Tk_PhotoPutBlock) or the desired image height (for Tk_PhotoExpand and Tk_PhotoSetSize). matching set with width, obviously. πŸŽ€
  • int *widthPtr (out) β€” pointer to the location where the image width gets stored. note the (out) β€” this one gives, it doesn't take. 🎁
  • int *heightPtr (out) β€” pointer to the location where the image height gets stored. also a giver. 🎁
  • int subsampleX (in) β€” the subsampling factor in the X direction for input image data. πŸ“
  • int subsampleY (in) β€” the subsampling factor in the Y direction for input image data. πŸ“
  • int zoomX (in) β€” the zoom factor applied in the X direction to pixels being written to the photo image. make it bigger horizontally, obsessed. πŸ”₯
  • int zoomY (in) β€” the zoom factor applied in the Y direction to pixels being written to the photo image. and vertically too. glow-up achieved. 🌈

✨ DESCRIPTION ✨

Okay bestie, so Tk_FindPhoto is your little backstage pass 🎟️ β€” it returns an opaque handle that you use to identify one specific photo image to all the other procedures. The parameter you hand it is the name of the image, aka the name you gave to the image create photo command, or the name that command assigned it if you didn't specify one. And if imageName doesn't exist, or exists but isn't a photo image? Tk_FindPhoto just returns NULL. No drama, no notes. πŸ’€


Tk_PhotoPutBlock is the vibe where you actually feed blocks of image data in to be displayed. The call affects an area of the image that's width x height pixels, with its top-left corner sitting at coordinates (x,y). All of width, height, x, and y must be non-negative β€” do not come in here with negatives, that's not the energy. 🚫

If part of this area lies outside the current bounds of the image, the image expands to include the area β€” unless the user specified an explicit image size with the -width and/or -height widget configuration options (peep photo(n) for that). In that case? The area is silently clipped to the image boundaries. Just quietly trimmed, no warning, no text back. πŸ™ˆ

The block parameter is a pointer to a Tk_PhotoImageBlock structure, defined exactly like this:

typedef struct {
    unsigned char *pixelPtr;
    int width;
    int height;
    int pitch;
    int pixelSize;
    int offset[4];
} Tk_PhotoImageBlock;

Let's break down the gossip πŸ‘‡

  • The pixelPtr field points to the first pixel, that is, the top-left pixel in the block.
  • The width and height fields specify the dimensions of the block of pixels.
  • The pixelSize field specifies the address difference between two horizontally adjacent pixels. It should be 4 for RGB and 2 for grayscale image data. Other values are possible, if the offsets in the offset array are adjusted accordingly (e.g. for red, green and blue data stored in different planes). Using such a layout is strongly discouraged, though. Due to a bug, it might not work correctly if an alpha channel is provided. (see the BUGS section below β€” foreshadowing πŸ’€).
  • The pitch field specifies the address difference between two vertically adjacent pixels.
  • The offset array contains the offsets from the address of a pixel to the addresses of the bytes containing the red, green, blue and alpha (transparency) components.
    • If the offsets for red, green and blue are equal, the image is interpreted as grayscale.
    • If they differ, RGB data is assumed.
    • Normally the offsets will be 0, 1, 2, 3 for RGB data and 0, 0, 0, 1 for grayscale.

It is possible to provide image data without an alpha channel by setting the offset for alpha to a negative value and adjusting the pixelSize field accordingly. This use is discouraged, though (see the BUGS section below). Sorry bestie, the fine print keeps calling us out. 😭


The compRule parameter to Tk_PhotoPutBlock specifies a compositing rule that says what to do with transparent pixels:

  • TK_PHOTO_COMPOSITE_OVERLAY β€” the previous contents of the photo image should show through 🫢
  • TK_PHOTO_COMPOSITE_SET β€” the previous contents of the photo image should be completely ignored, and the values from the block be copied directly across πŸ’…

For the record, the behavior in Tk8.3 and earlier was equivalent to having TK_PHOTO_COMPOSITE_OVERLAY as a compositing rule. History, but make it relevant. ⭐


Okay so the values you give for the width and height parameters to Tk_PhotoPutBlock do not have to correspond to the values specified in block. Iconic flexibility:

  • If they are smaller, Tk_PhotoPutBlock extracts a sub-block from the image data supplied.
  • If they are larger, the data given are replicated (in a tiled fashion) to fill the specified area.

These rules operate independently in the horizontal and vertical directions. Two axes, two moods, no crossover. πŸ¦‹

Tk_PhotoPutBlock normally returns TCL_OK, though if it cannot allocate sufficient memory to hold the resulting image, TCL_ERROR is returned instead and, if the interp argument is non-NULL, an error message is placed in the interpreter's result. Memory said no. πŸ˜”


Tk_PhotoPutZoomedBlock works like Tk_PhotoPutBlock except that the image can be reduced or enlarged for display. Main character behavior fr. ✨

  • The subsampleX and subsampleY parameters allow the size of the image to be reduced by subsampling. Tk_PhotoPutZoomedBlock will use only pixels from the input image whose X coordinates are multiples of subsampleX, and whose Y coordinates are multiples of subsampleY. For example, an image of 512x512 pixels can be reduced to 256x256 by setting subsampleX and subsampleY to 2. Math ate. πŸ”₯
  • The zoomX and zoomY parameters allow the image to be enlarged by pixel replication. Each pixel of the (possibly subsampled) input image will be written to a block zoomX pixels wide and zoomY pixels high of the displayed image.
  • Subsampling and zooming can be used together for special effects. Combo move, no cap. πŸŽ€

Tk_PhotoGetImage can be used to retrieve image data from a photo image. It fills in the structure pointed to by the blockPtr parameter with values that describe the address and layout of the image data that the photo image has stored internally. Important: those values are valid until the image is destroyed or its size is changed. So don't get comfy with them. πŸ‘‘

It is possible to modify an image by writing directly to the data the pixelPtr field points to. But listen:

  • The size of the image cannot be changed this way. Nope, not happening.
  • Changes made by writing directly to pixelPtr will not be immediately visible, but only after a call to Tk_ImageChanged or after an event that causes the interested widgets to redraw themselves.

For these reasons usually it is preferable to make changes to a copy of the image data and write it back with Tk_PhotoPutBlock or Tk_PhotoPutZoomedBlock. That's the healthy coping mechanism, bestie. 🌸

Oh and Tk_PhotoGetImage returns 1 for compatibility with the corresponding procedure in the old photo widget. Retro callback. πŸ“Ό


Tk_PhotoBlank blanks the entire area of the photo image. And blank areas of a photo image are transparent. Poof, gone, see-through. πŸ«₯

Tk_PhotoExpand requests that the widget's image be expanded to be at least width x height pixels in size. The width and/or height are unchanged if the user has specified an explicit image width or height with the -width and/or -height configuration options, respectively. If the image data are being supplied in many small blocks, it is more efficient to use Tk_PhotoExpand or Tk_PhotoSetSize at the beginning rather than allowing the image to expand in many small increments as image blocks are supplied. Efficiency is a love language. πŸ’–

Tk_PhotoExpand normally returns TCL_OK, though if it cannot allocate sufficient memory to hold the resulting image, TCL_ERROR is returned instead and, if the interp argument is non-NULL, an error message is placed in the interpreter's result.


Tk_PhotoSetSize specifies the size of the image, as if the user had specified the given width and height values to the -width and -height configuration options. Sneaky but legal. 😌

A value of zero for width or height does not change the image's width or height β€” but it does allow the width or height to be changed by subsequent calls to Tk_PhotoPutBlock, Tk_PhotoPutZoomedBlock or Tk_PhotoExpand. Zero = "no opinion, ask me later." πŸ’…

Tk_PhotoSetSize normally returns TCL_OK, though if it cannot allocate sufficient memory to hold the resulting image, TCL_ERROR is returned instead and, if the interp argument is non-NULL, an error message is placed in the interpreter's result.

And Tk_PhotoGetSize returns the dimensions of the image in *widthPtr and *heightPtr. That's it, that's the whole function, short king. πŸ‘‘


🧚 PORTABILITY 🧚

History lesson time, gather round. πŸ“–

In Tk 8.3 and earlier, Tk_PhotoPutBlock and Tk_PhotoPutZoomedBlock had different signatures. If you want to compile code that uses the old interface against 8.4 without updating your code, compile it with the flag:

-DUSE_COMPOSITELESS_PHOTO_PUT_BLOCK

Code linked using Stubs against older versions of Tk will continue to work. Backwards compatible, we love to see it. 🫢

In Tk 8.4, Tk_PhotoPutBlock, Tk_PhotoPutZoomedBlock, Tk_PhotoExpand and Tk_PhotoSetSize did not take an interp argument or return any result code. Also, if insufficient memory was available for an image, Tk would panic. Yikes. πŸ’€ This behaviour is still supported if you compile your extension with the additional flag:

-DUSE_PANIC_ON_PHOTO_ALLOC_FAILURE

Code linked using Stubs against older versions of Tk will continue to work. Again. Still iconic. ⭐


πŸ’€ BUGS πŸ’€

Okay so this is the part where we air the tea. β˜•

The Tk_PhotoImageBlock structure used to provide image data to Tk_PhotoPutBlock promises great flexibility in the layout of the data (e.g. separate planes for the red, green, blue and alpha channels). Unfortunately, the implementation fails to hold this promise. It's giving overpromise, underdeliver. 😭

The problem is that the pixelSize field is (incorrectly) used to determine whether the image has an alpha channel. Currently, if the offset for the alpha channel is greater than or equal to pixelSize, tk_PhotoPutblock assumes no alpha data is present and makes the image fully opaque. This means that for layouts where the channels are separate (or any other exotic layout where pixelSize has to be smaller than the alpha offset), the alpha channel will not be read correctly.

So in order to be on the safe side if this issue will be corrected in a future release, it is strongly recommended you always provide alpha data β€” even if the image has no transparency β€” and only use the "standard" layout with a pixelSize of 2 for grayscale and 4 for RGB data with offsets of 0, 0, 0, 1 or 0, 1, 2, 3 respectively.

Do not try to be clever with your layout. The implementation will humble you. πŸ™


πŸŽ€ CREDITS πŸŽ€

The code for the photo image type was developed by Paul Mackerras, based on his earlier photo widget code. Legend behavior, we stan. πŸ‘‘βœ¨


πŸ”‘ KEYWORDS πŸ”‘

photo, image


and that's the whole page bestie!! πŸ’–βœ¨πŸŽ€πŸ¦‹ this one's straight out of the Tk era, version 8.0, and it's the Tk_FindPhoto(3) page β€” go forth and put some pixels down, you absolute icon πŸ’…πŸ«ΆπŸŒΈ

πŸ“¦ where this page comes from