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