<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Note that PgSQL will be applying libz compression to over-sized tuples automatically in the TOAST machinery, so applying it yourself won’t radically change anything, unless it’s being done carefully within a blocking scheme, perhaps.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Also note that no matter what you do, in-database data is going to be cut up into page-size hunks and dropped into tables, it’s never stored directly on the file system. That’s true for blobs, and true for toasted tuples too.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">P.</div> <div id="bloop_sign_1392746306849901056" class="bloop_sign"><div><br></div><span style="font-family:helvetica,arial;font-size:13px"></span>-- <br>Paul Ramsey<br>http://cleverelephant.ca<div>http://postgis.net</div></div> <br><p style="color:#A0A0A8;">On February 18, 2014 at 9:56:02 AM, Nathaniel Clay (<a href="mailto://clay.nathaniel@gmail.com">clay.nathaniel@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div>
<title></title>
<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>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>
<li style="list-style: none">
<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>
<li>Supports N band imagery</li>
<li>Multi-Resolution Packing<br></li>
<li style="list-style: none">
<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>
<li>Extensible header</li>
<li style="list-style: none">
<ul>
<li>SRID, IPX,IPY, etc<br></li>
</ul>
</li>
<li>Area of interest specification </li>
<li style="list-style: none">
<ul>
<li>Allows you to specify a region with in the same raster to have
a higher bitrate, etc</li>
</ul>
</li>
<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>
<li style="list-style: none">
<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>
<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>
<li style="list-style: none">
<ul>
<li>May be indective of other problems<br></li>
</ul>
</li>
</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>
_______________________________________________
<br>postgis-devel mailing list
<br>postgis-devel@lists.osgeo.org
<br>http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</div></div></span></blockquote></body></html>