<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 11:24 AM, Bborie Park <span dir="ltr"><<a href="mailto:dustymugs@gmail.com" target="_blank">dustymugs@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How does OpenJPEG 2000 compare to other formats, such as GeoTIFF, HDF5 or NetCDF?</div></blockquote><div>
All of the mentioned, formats use libz compression, a loss less compression scheme. With the exception that GTiff offers plain jpeg compression along with a fax format??<br></div><div>I think it may be a good idea to also ofter libz (deflate) and or LZMA compression.<br>
</div><div><br></div><div>Before I move on to the next questions a little background on my thought process.<br></div><div>I see three different use types:<br></div><div>1. Active Server<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div></div><div>Before deciding on a replacement format, we should identify if a replacement is required? What are the current short-comings? Where are the performance limitations? What are the wish-list items for a replacement format?</div>
<div><br></div><div>I have spent some time at poking at what I considered short-comings, where I think performance is suffering, and what features are missing. I'm not ready to publicly share my list though.</div><div>
<br></div><div>I wasn't involved with the original PostGIS raster binary format but from my understanding while working it with, it appears as though the goal was to keep things simple as all input and output goes through PostgreSQL, which can (should?) be considered a black-box.</div>
<div><br></div><div>-bborie</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, Feb 17, 2014 at 6:32 PM, Nathaniel Clay <span dir="ltr"><<a href="mailto:clay.nathaniel@gmail.com" target="_blank">clay.nathaniel@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Hi all,<br><br><br></div>This is just some food for thought and discussion. I've take a cursory look at JPEG 2000 openjpeg. I think it may hold promise for a possible future format or co-format for Postgis Raster in database storage.<br>
<ul><li>Supports both Loss less and Lossful Compression approaching the performance of ERDAS ( uncompressed Gtif 200M, openjpeg JP2 25M Lossfull and 80M Lossless, ERDAS JP2 15M)</li><ul><li>I don't have a ERADAS encoder license, but this image was of the same original</li>
<li>Openjpeg lossfull compression in my opinion visually identical to the original with default settings<br></li></ul><li>Supports N band imagery</li><li>Multi-Resolution Packing <br></li><ul><li>eg more than one raster resolution with in the "code stream"</li>
<li>can be ordered by user specification, default smallest to largest<br></li><li>This would allow us to get rid of the overview tables or make them views.</li><li><a href="http://ericportis.com/posts/2014/resolution-progressive-jpeg2000-performance/" target="_blank">http://ericportis.com/posts/2014/resolution-progressive-jpeg2000-performance/</a><br>
</li></ul><li>Extensible header</li><ul><li>SRID, IPX,IPY, etc<br></li></ul><li>Area of interest specification </li><ul><li>Allows you to specify a region with in the same raster to have a higher bitrate, etc</li></ul><li>
Error Detection and Correction</li><li>Openjpeg project seems to be alive last commit was a few days a go.</li><li>BSD License</li></ul><p><br></p><p>Possible Concerns identified so far:</p><ul><li>Writes require a recode of the entire tile, however the tile size is user specifiable</li>
<li>takes a long time to encode image, ~10 sec on my system with the test image ( 3067x3777 8bit 4bands) </li><ul><li>I dont have anything to compare it to, so I dont know if this is a good or bad</li><li>I havent tested on small image size and other possible scenarios. <br>
</li></ul><li>Memory Usage seemed high during decode and encode, ~2G, I believe this is due to the decoder and encoder preallocate memory for all of the "Pyramids" and bands at once. (but have not investigated thoroughly) ( Image Res 3067x 3777 8bit 4 bands)</li>
<li>Its included decoder application has weird issues with tif, other formats are fine. ( Dont think it has anything to do with the openjpeg lib)</li><ul><li>May be indective of other problems<br></li></ul></ul><p>If I were to start on this project it would be some time in the future and I would most likely require help and lots of input, but I thought I it would be a good idea to bring, it up as a discussion point.</p>
<p>Any thoughts,<br></p><p><br></p><p>Nathaniel Hunter Clay<br></p></div>
<br></div></div>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div>
<br>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div></div>