Image manipulation without Tk

[Explain motivation (cron, possible sneer at Java, portability, ...]

LV Can someone go into the technical details of what parts of Tk require a display and what parts do not?

For instance, if one were to write a C app which created a canvas, placed things onto the canvas, configured various colors, text, etc., then commanded the canvas to create PostScript, would a display be necessary for any of this?

According to Robert Heller in a comp.lang.tcl posting, the canvas postscript generating code uses various bits and pieces of Xlib, relating to things like colors, fonts, and conversions of 'image' type data to something that can be converted to postscript.

[Explain alternatives:

• utility X server
• Xvfb
• VNC
• TclDG [L1 ]
• Image [L2 ]
• Xbit [L3 ]
• gdtclft
• [explain use of "ssh -X ..."]
• xwd
• TclMagick
• Investigate use of http://netpbm.sf.net/ to generate/transform graphics.
• Pixane
• megaimage
• Pure Tcl solutions. An example DKF offered is

  #! /usr/local/bin/tclsh8.3
  puts "Content-Type: image/x-portable-graymap"
  puts ""
  puts "P2"                          ;# ASCII PGM "magic number"
  puts "10 10"                       ;# width and height
  puts "18"                          ;# Max grey value
  for {set i 0} {$i<10} {incr i} {
     set line ""
     for {set j 0} {$j<10} {incr j} {
        lappend line [expr {$i+$j}]
     }
     puts $line
  }
  exit

AM Here is a little variation on this - it produces a PPM file (type "P6"):

 # Create a simple PPM file (type: P6)
 #
 global width
 global height
 set width  200
 set height 200

 set total_length [expr {$width*$height*3}]

 set image [binary format "a$total_length" ""]

 proc setpixel {imageName i j r g b} {
    upvar $imageName image
    global width
    global height

    set posb [expr {3*$width*$j+3*$i}]
    set pose [expr {3*$width*$j+3*$i+2}]
    set image [string replace $image $posb $pose [format %s%s%s $r $g $b]]
 }

 for { set i 0 } { $i < $width } { incr i } {
    setpixel image $i $i \uff \uff \uff
 } 
 for { set i 0 } { $i < $width } { incr i } {
    setpixel image $i 10 \uff \u0 \u0
 }

 set outfile [open "image.ppm" "w"] 
 puts $outfile "P6"
 puts $outfile $width
 puts $outfile $height
 puts $outfile "255 $image"
 close $outfile

A small and incomplete TGA image reader which reads a file into a format that can then later be fairly easily manipulated without the requirement of Tk. The format is compatible with one of the accepted (albeit undocumented) formats for Tk photos.

See: TGA image reader.

See also "strimj - string image routines" and "barchart". GIF has code snippets for writing image files in pure Tcl.

[Do something about Tk's "-nodisplay" ...]

DKF: Another way would be to split the image master stuff out of Tk into its own package which could be loaded from Tcl [L4 ]. Note that the image display code would have to remain in Tk, but that's quite reasonable IMHO.

12 Sept 2003 Mike Tuxford: Now this is exactly what I'd like to see but is far beyond my abilities to accomplish, and I don't feel particularly comfortable making a call for others to do it, because it's something I am unqualified and unable to contribute to.

AM I have started to build a Tcl-only package that will manipulate images via the above algorithm. It is slow, but when I replace the culprit (setpixel) with a C implementation, it should be quite acceptable :). At the moment, it is merely an exercise - see if it can be made practical. Most probably the isolation of Img is more important.

DKF: FWIW, I'm working on improving the performance of the setting of pixels of photos in 8.5, but it is not a very high priority thing. (Alas, pay-work comes first...)

dzach 2006-8-27: Splitting Tk sounds like a great idea that could lead to a native solution to Image manipulation without Tk. Has there been any progress on this issue since 2003? I know, progress doesn't grow on trees, and I should propably follow Mike Tuxford's words above, but abstracting a display-less part of Tk, especially the Tk widgets, and providing a mapping mechanism to it from the real world, could lead to the development of other very interesting device drivers, besides getting the benefit of rendering graphics on different devices/formats. For instance, a hardwired panel where the canvas would be represented by an LCD touch screen or e-ink display, a series of (hardwired)buttons that drive the new abstract Button class, a potentiometer that maps to a scale widget, all readily interchangable with their software Tk widget counterpart. A Tool Command Language coming back to its origins and readily embedable to harware devices.

Isn't this the Tcl/Tk 10.0 wishlist page?