Currently, there is no obvious way to read images from a file and display them on a pane in McCLIM. If you know the secret rites, you can use CLIM-INTERNALS::XPM-PARSE-FILE, but:
1) It is limited to XPM files. 2) It is internal and looks scary.
To rectify this, I think we should bundle some simple library with McCLIM for converting image files to CLIM patterns, just like CLIM-INTERNALS::XPM-PARSE-FILE does. (I see something called rgb-image.lisp in mcclim/Extensions, what is it used for?) It would not be loaded by default, but applications could depend on a MCCLIM-IMAGES ASDF system that would define a package, load some simple scaffolding code and export a symbol, LOAD-IMAGE, from its package. The MCCLIM-IMAGES system would not actually support any image formats, and thus not have any dependencies, and applications with specific needs could thus depend on systems like MCCLIM-IMAGES-XPM, MCCLIM-IMAGES-GIF, etc., all of which depend on MCCLIM-IMAGES and whatever libraries necessary to read the specific image file format. These format-support-systems would define a method on LOAD-IMAGE for the specific image format(s) handled by them. This way, an application that needs to read JPEG files would not have to drag in a library for reading, say, GIF files, and at the same time, the same well-defined function interface would be used for all image reading.
Since image formats are different, and may have unique options for controlling exactly how they are loaded, the LOAD-IMAGE function would probably take an unspecified set of keywords, permitting each image format to define their own keywords semantics.
Writing such a library would probably be extremely simple, if we are willing to use external libraries for most of the actual image reading. For example, here is how to turn the first image of a GIF file into a CLIM pattern using the Skippy library:
(defun gif-to-pattern (pathname) (let* ((data-stream (skippy:load-data-stream pathname)) (first-image (aref (skippy:images data-stream) 0)) (pattern-array (make-array (list (skippy:height first-image) (skippy:width first-image)))) (designs (coerce (loop with color-table = (skippy:color-table data-stream) for i below 255 collecting (multiple-value-bind (r g b) (skippy:color-rgb (skippy:color-table-entry color-table i)) (make-rgb-color (/ r 255) (/ g 255) (/ b 255)))) 'vector))) (dotimes (y (skippy:height first-image)) (dotimes (x (skippy:width first-image)) (setf (aref pattern-array y x) (skippy:pixel-ref first-image x y)))) (make-pattern pattern-array designs)))
Quoting Troels Henriksen (athas@sigkill.dk):
To rectify this, I think we should bundle some simple library with
Good idea.
I wonder whether that library could be external to McCLIM, so that other applications could also use it. As long as it just returns arrays of colors in the format CLIM wants, it would plug right into our image drawing routines and still not have to depend on CLIM internals itself.
McCLIM for converting image files to CLIM patterns, just like CLIM-INTERNALS::XPM-PARSE-FILE does.
The indexed pattern code would be used for images with a palette, like GIF and XPM.
(I see something called rgb-image.lisp in mcclim/Extensions, what is it used for?)
That's the second image format we would want to support, for 24 bit RGB colors (plus alpha channel), originally from Closure.
RGB-IMAGE is the right class to return when parsing JPEG or one of the formats that might or might not have a palette (PNG, BMP).
The format-specific image library could just return the (unsigned-byte 32) array as needed for RGB-IMAGE, with the latter being wrapped around it by CLIM code.
d.
David Lichteblau david@lichteblau.com writes:
I wonder whether that library could be external to McCLIM, so that other applications could also use it. As long as it just returns arrays of colors in the format CLIM wants, it would plug right into our image drawing routines and still not have to depend on CLIM internals itself.
I don't see much point in making it completely CLIM-independent, you can't use the loaded images for anything but displaying them.
The indexed pattern code would be used for images with a palette, like GIF and XPM.
(I see something called rgb-image.lisp in mcclim/Extensions, what is it used for?)
That's the second image format we would want to support, for 24 bit RGB colors (plus alpha channel), originally from Closure.
Ah, so we have two image-like things, CLIM patterns and RGB images? I guess the LOAD-IMAGE function would then be specified as returning a design object, with the actual implementation for each image type deciding upon what is most convenient. Perhaps it could even be checked dynamically - a JPEG image that is mostly monochrome might be efficiently represented as an indexed image.
At a minimum, it would be nice if closure and other McCLIM apps could use the same libraries.
Cyrus
On Jan 5, 2008, at 2:17 PM, David Lichteblau wrote:
Quoting Troels Henriksen (athas@sigkill.dk):
To rectify this, I think we should bundle some simple library with
Good idea.
I wonder whether that library could be external to McCLIM, so that other applications could also use it. As long as it just returns arrays of colors in the format CLIM wants, it would plug right into our image drawing routines and still not have to depend on CLIM internals itself.
McCLIM for converting image files to CLIM patterns, just like CLIM-INTERNALS::XPM-PARSE-FILE does.
The indexed pattern code would be used for images with a palette, like GIF and XPM.
(I see something called rgb-image.lisp in mcclim/Extensions, what is it used for?)
That's the second image format we would want to support, for 24 bit RGB colors (plus alpha channel), originally from Closure.
RGB-IMAGE is the right class to return when parsing JPEG or one of the formats that might or might not have a palette (PNG, BMP).
The format-specific image library could just return the (unsigned-byte 32) array as needed for RGB-IMAGE, with the latter being wrapped around it by CLIM code.
d. _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Cyrus Harmon ch-mcclim@bobobeach.com writes:
At a minimum, it would be nice if closure and other McCLIM apps could use the same libraries.
It would be exported McCLIM functionality, any McCLIM application would be able to call LOAD-IMAGE.
-
Cyrus Harmon -
David Lichteblau -
Troels Henriksen