[Gdal-dev] MrSID Driver v. 4.0.x overviews

[Michael P. Gerlek]

Julien and/or Andrey wrote:

> I' ve added overviews support in the new driver using MrSID DSDK v.
> 4.0.x and tested it (with OpenEV) under Windows with MrSID and
> JPEG2000 files ; and made minors modifications to update to the last
> DSDK "Geo_DSDK-4.0.9.713".

Thanks to Julien and Andrey their patchings!

PLUG: For those keeping score at home, this is our final, public 4.0
SDK release.  You can download it for free (click-through license) at
developer.lizardtech.com.


> I don't have the MrSID files other than 8 bit, do you have a samples? It
> will be enough for me to fix that bug.

...And I have way too many MrSID files that are other than 8 bit. :-(
I think there's at least shipping in the SDK examples directory now, if
not I will mail you one separately.


> Maybe one reason is that to read an RGB image I believe each tile is
> decompressed 3 time, one time per component... About the same problem
> with the GeoTIFF driver, Frank said that we can optimize this by
> reading interleaved data in one pass by using the
> GDALDataset::RasterIO() ; maybe we can also implement this for the
> MrSID Driver ? Maybe we can also try to remove the memcpy in the
> IReadBlock function and read directly data into the GDAL buffer.
> (Maybe there are some optimization to do using the MrSID API
> differently ?)

Yes, one scene read will decode all three bands at once (they are encoded
together, due to the RGB->YIQ color transform).

I think you can easily use the GDAL buffer instead of having to memcpy;
the LTISceneBuffer is designed specifically for this kind of thing.  What
is the format/organization of the GDAL buffer?


> I've a little question about JPEG2000 in MrSID : I see in
> Geo_DSDK-4.0.9.713/doc/README-3rdparty.txt that : "This application
> uses Kakadu software, licensed from Unisearch Software, Ltd." Is MrSID
> SDK use Kakadu for all its JPEG2000 support ?

Yes, the 4.0 release uses Kakadu internally (a modified 4.2 kernel).
I've been happy with it -- the performance is good and the low-level
interfaces are very, umm, "comprehensive".  However, our public SDK
are designed to be "codec-neutral" and we may choose to swap out the
use of Kakadu in the future.

Please note that our SDK will not (yet!) support all Part 1 JP2 files.
In particular, we don't support images that:
  - use >16 bits per component
  - use funky colourspaces (none, gray, and RGB are all okay)
  - have components of differing sizes
  - have components aligned to different grid sizes or origins
I doubt GDAL would support such images anyway, though..?

-mpg

-----------------------------------
Michael P. Gerlek
Software Architect / MrSID team
mpg/AT/lizardtech.com
LizardTech, a Celartem company
Seattle, Washington