leei@McRCIM.McGill.EDU (Lee Iverson) (04/23/91)
This is to announce the availability of a new image viewing *widget*. It is available as /contrib/vimage.tar.Z on export.lcs.mit.edu and in /pub/maspar on moe.mcrcim.mcgill.edu. I guess if pushed, I'd have to call it Alpha test status, but the best indicator is a note of the version number. When it gets to 0.9 I'll call that the Beta, and 1.0 will be a release. --- vimage.README vimage 0.6 April 21, 1991 -- Lee Iverson This package is the first pass at a general image visualization tool. It is a collection of Xt widgets which create a cohesive image viewing tool. Why another one? The answers are of two types. 1) I wanted a widget that could be easily used either standalone or embedded in a larger application. An earlier poll of comp.windows.x searching for such a beast turned up nil. 2) I needed something that would alow arbitrary user-defined extensibility to new image types and display variations. This meant the adoption of an objected-oriented image type heirarchy (a la Xt). Eventually such things as EdgeMap and ImageFlow can be implemented and seamlessly integrated into the overall application. Required tools: - An ANSI C compiler. To this point (for my own convenience more than anything else) I've written this thing in ANSI C (it's easier to debug). If you don't have an ANSI compiler (GCC is available in aeneas.mit.edu:/pub/gnu/gcc-1.39.tar.Z), then you are (for the moment) out of luck. Recommended tools: - libXukc: This is a widget set which extends the functionality of the Athena widgets considerably. They are available as part of the Dirt interface builder system (export.lcs.mit.edu:dirt.A1.10.tar.Z). Currently, the three components of this system I depend on are included with this package. - ad2c. This is an extremely useful way of providing a consistent set of fallback application defaults. It essentially compiles the .ad file for an application into a set of strings which should be loaded into the application context at startup. Actually, ad2c is only required if you change VImage.ad and want the new defaults compiled in as fallback resources. Features: - ImageViewport widget. A general viewport widget that deals well with arbitrary resizing of the child widget. It is clearly derived from the Xaw Viewport widget, and includes both it's copyright and my own. There are actions and accelerators for moving the image around inside the viewport. - Image widget. A general purpose image viewing, zooming, and examining base. This is the part of the system which is the most volatile at the moment, since I have plans to extend this to an ImageStack widget (i.e. a number of images overlayed on on another!). A set of interaction primitives enable arbitrary image zooming. - FileDialog widget. A Mac-like modal File dialog widget. Needs some work, but is quite functional and has a nice interface for only selectively seeing certain files. Depends on the regexp(3) library functions (included). - CMManage. A set of routines for managing a consistent colormap within an application in which there are a potentially broad variety of different areas of the program which are trying to allocate colors. This overrides the standard Xt StringToColor translations, so that resource manager color definitions will work properly even when this color manager is being used. - An Xt-like class heirarchy of Image types. The analog for Core is the GenericImage type. Two standard Image types are currently provided: BitImage and ByteImage, both rectangular bitmaps. ByteImage has a colormap associated with it. The image reading functions (currently supporting only PBM, PGM and GIF) create one of these types. The Image widget interfaces to a set of generic object-oriented calls which are redefined (as necessary for the image types). Caveats: - There is currently NO DOCUMENTATION (except this file). A little bit of application default browsing and source code reading should elucidiate things for now, but real docs will come along soon. - I've only really tested this on a Sun4 OS 4.1 with mono and 8bit color displays. VAX/Ultrix 4.1 is next, but my ability to get close to other hardware is limited, so no guarantees that this will run on other visual types that StaticGrey and 8 bit PseudoColor. Sigh! - I still see occasional extremely large pixmaps being created. Haven't manage to track it down yet, so be careful and watch server memory. You'll know when it goes through the roof! Planned Extensions: - Documentation. Some. Any... - As mentioned above, conversion of the Image widget to an ImageStack. - A Boomerang-like extension for easier file system navigation in the FileDialog widget. - Menu interface to Image/Viewport actions. - Better color management including gamma correction, color dithering, better image dezooming (mag < 1). - More image formats including full color images. - A dynamic loading interface for image formats and associated support functions. One of the really essential things for supporting an experimental image-processing environment is the ability to define special image types (e.g. EdgeMap or OpticalFlow) and allow the user to use them in as transparent a manner as possible. - Adoption of a generic image format that supports cross-platform portable images with arbitrary data formats (also using dynamic loading). I'm not sure whether something out there already will work (maybe CGM), but if nothing really fits what I need, then (sigh!) another image format. - A shared memory image manager (probably a separate program) for fast and efficient communication between image processing programs and the viewer. ------------------------------------------------------------------------------ Lee Iverson McGill Research Centre for Intelligent Machines leei@mcrcim.mcgill.edu Computer Vision and Robotics Lab McGill University, Montreal -- Lee Iverson McGill Research Centre for Intelligent Machines leei@mcrcim.mcgill.edu Computer Vision and Robotics Lab McGill University, Montreal