Hi,
I have been assigned (as in got some business work time) to do the implementation for jpip and gdal as per RFC 24, and then to reshape RFC 24 with the implementation as a guide. Apologies for the delay in doing this. Whilst with the approach I am proposing of separating the jpip communication layer from the decompression so that we can do true http(s) (as opposed to the hand spun version of http in kakadu), we could probably use any jpeg2000 decompression library, but kakadu would be the fastest - and the easiest to do first. As such, I am struggling a bit with the kakadu license, particularly when it comes to plugging into a developer library. I have asked on the kakadu mailing lists but no reply, Frank (and others) can you clarify your stance with kakadu in the JP2KAK plugin? I think my primary concern is that with jpip the sequence of operations for adding to the kdu_cache object is pretty fixed when reading the jpip stream, hence is any plugin to gdal a derivative work? Thanks, Norman
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
