From: Debian U. <st...@su...> - 2005-02-22 12:52:42
|
Hi everyone I recently proposed changing the image reading/writing routines to use a common image structure. This patch is an attempt in that direction. Currently, a gray scale image is a matrix with values in [0,255] while an RGB image consists of three such gray-scale images. Some image routines expect values between [0,1] while others prefer [0,255]. By using the appropriate numerical classes, I hope to remove this inconsistency. The suggested image format (as used by the other brand) is: Image Type Matrix Size Numerical Class -------------------------------------------------- B&W MxN logical Gray-level MxN uint8 or uint16 (depends on depth) RGB MxNx3 uint8 or uint16 (depends on depth) I attach two functions which achieve this: imread2.m (a replacement for imread.m) and imshow2.m (a wrapper for imshow.m). 'imshow2' can be installed using dispatch: dispatch('imshow', 'imshow2', 'any') imread2 uses pngread and jpgread when available, or otherwise resorts to the ImageMagick utilities 'convert' and 'identify'. Paul mentioned that we might want to look at libgd. This is a good idea because of two reasons I can think of immediately: 1. Fast image loading of multiple formats While ImageMagick supports many formats, it forces us to convert images to raw portable gray-maps before loading them into octave. libgd supports many formats and can be linked directly into an oct-file. 2. Image manipulation libgd has built-in support for popular image processing functions, such as histogram equilization. Also, lines, text and other primitives can be drawn onto images. These functions can simply be wrapped in .oct files. I have not updated all the functions in the image toolbox to use the new format. I will do so once we all agree on the image structure. I would like some ideas on the use of colour-maps and how they fit into the bigger picture. Regards Stefan |