AMG: Would the image loading/processing/saving code go into the Tcl core or into a separate package required by Tk? Would this separate package be bundled with the Tk sources, possibly with an option to build and install it independently of the rest of Tk? Or would it be bundled with the Tcl sources, with options to build or skip it? Or would it be a new project that would subsume Img? As much as I'd like to be able to process images without having a GUI, I don't want to see Tk get any new dependencies.

I recently wrote a Tcl image processing extension for a specialized application; I made a separate "tk" version of the extension that interfaced its internal image format (a Tcl binary array) with Tk photos. It worked out pretty nicely.

DKF: I'd like it to be a separate package that Tk would package require, though I'm less sure about whether it would be distributed with Tcl or Tk.

AMG: I assume the color name parsing code would also have to be factored out of Tk, since it's needed by the image code. This can get very tricky, since parsing color names is done by the X server (evidence: [L1 ]), and I imagine we wouldn't want any X dependencies in a standalone image library. What can be done about this?

DKF: Colors of the format “#rrggbb” can be handled internally – actually, we might already do this to avoid round-tripping the server; can't remember if that patch of mine got committed :-) – and we can add the “web-safe” color names too. Basically, it comes down to putting the color names into a hashtable and doing lookups against it (after following application of some standardized normalization rules I presume, or maybe they'd be applied lazily if the lookup fails? Not done a design study yet…)

AK: The above is a diagram I made tracing out the structures and linkages. The Tk_ImageType is the bad structure.

KBK: I'm wondering if we're looking - to some extent - at the wrong layer. When people are talking about "separating images from Tk", they really don't care about the display mechanism. And hardly anyone cares about 'bitmap's: they're more than a little strange, and not as useful as one might think (they are quite distinct from 1-bit-depth photos). So I wonder whether the appropriate layer to cut is the "photo image" rather than the "image" - leaving the 'photo' image type as shown in Tk_ImageType nearly alone.

DKF: My original idea was that there would be a photo package which would provide the master structure plus operations on it (notably including load and save, plus probably at least the majority of other things that you can ask for a photo to do) and that there would be a separate piece of code (independent package or piece of Tk) that handles the display of photo images. Note however that the photo code is already mostly separated; this task is about completing that separation.