[GRASS-user] Viewing ecw files

[Glynn Clements]

Brad Douglas wrote:

> > >> It would be really nice if GRASS had a wavelet based scheme for imagery,
> > >> but that would require significant development and many of us don't have
> > >> the spare time available.  At the moment, Hamish's suggestion is about
> > >> the best that can be done.  GRASS cannot handle such large datasets with
> > >> efficiency.
> > > 
> > >> ECW is a wonderful format.  It is hard to beat the compression and speed
> > >> of scale change.
> > > 
> > > Isn't Ogg Theora working on wavelet compression for imagery?
> > 
> > Do you mean Tarkin? That's wavelet compression for video. Is it usable
> > for still images too?
> 
> No, it's not appropriate for GIS.  Wavelets can be highly tunable to the
> application at hand.  We want more of what wavelets have to offer than
> just compression.
> 
> I did notice that there is an add-on r.wavelet module, but I have not
> used it.  The backend library seems to be license-free and GPL, IIRC.
> 
> Wavelets for GRASS as an imagery format is "pie in the sky". :-\  There
> are too many other issues that need attention at the moment.
> 
> I'd be interested in what Glynn's opinion is.  It may be more trouble
> that its worth (we'd need someone dedicated to implementing and
> supporting it).  However, I do see it becoming increasingly popular at
> municipalities who regularly deal with very large imagery sets (10G-1T
> sizes) and not being able to support a comparable format is a major
> disadvantage.
> 
> Beyond getting Glynn's input, it's probably a waste of time discussing
> it further unless someone stands up and offers their expertise and time
> to implement it as an optional format (it is not appropriate for
> non-contiguous rasters).  Even so, I'd still recommend that person work
> on other pressing issues before adding a new imagery format.

The main requirement for the existing raster I/O code is that you need
to be able to read rows in an arbitrary order without needing to store
the entire uncompressed data in memory. It wouldn't be particularly
hard to generalise the lower levels of the raster input code to allow
reading from any format which supports seeking (i.e. any uncompressed
format, or any compressed format which uses independently-compressed
segments of a reasonable size).

Writing isn't an issue; if you want to be able to write rows in random
order, you have to assert this when you create the map, by using
G_open_cell_new_random() (in 6.x, nothing actually uses random
output).

However, when reading maps, there's no way for the library to tell
whether the module will read sequentially or randomly, so it has to be
able to cope with random access.

[Assuming sequential I/O then failing the first time that the client
seeks backwards is a possibility, but somewhat less than ideal.]

For the future, any new raster API should require the client to
provide some indictation of the access strategy at open time. Formats
which use a single compressed data stream wouldn't allow arbitrary
seeking, although it would be possible to skip forwards (just discard
unneeded data) and to skip backwards up to a pre-selected limit
(allocate a sufficient cache).

-- 
Glynn Clements <glynn at gclements.plus.com>