[GRASS-dev] Re: lib/image

[Brad Douglas]

On Fri, 2006-06-16 at 04:08 +0100, Glynn Clements wrote:
> Brad Douglas wrote:
> > Do you have any objections to me including functions from lib/gis into
> > lib/image (read: link against lib/gis.so...)?  I'm most interested in
> > using the endian/memory allocation/text message, etc. functions.  I'd
> > prefer not to duplicate code.
> 
> I don't mind the use of the the memory/message functions, but
> [de]serialisation should use endian-neutral code rather than
> short-circuiting the case where the host's byte order is the same as
> the external byte order.
> 
> Actually, given that the only code which uses that library is
> lib/ogsf/gsd_img.c, I would suggest simply eliminating that library
> and either:
> 
> a) dropping support for the RGB image format altogether (OGSF also
> supports TIFF and PPM, both of which are far more widely used), or

I like this option best.  There's really no need to keep it around
anymore since so many other image formats are supported (and nviz
already supports PPM and TIFF).

> b) adding the necessary code directly to gsd_img.c, based upon the
> description in lib/image/SGIIMAGESPEC.
> 
> Regarding a), NVIZ uses GS_write_rgb(), but it could just use PPM
> instead.

Definitely A.  The SGI image format isn't even widely supported by many
viewers these days.  In order to check the images, I have to load them
up in GiMP.

> Regarding b), GS_write_rgb() always uses 1-byte VERBATIM format, which
> simplifies the code signficantly. Essentially, you just need to write
> the header then dump out the raw RGB data in BIL order.

I can do it either way, but have a preference toward option A.


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785