<div dir="ltr"><div>Good,<br></div>maybe the postgres list would have some advice about the classical problem of dealing with images in base ?<br><br>Cheers,<br>Rémi-C<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-02-20 14:45 GMT+01:00 Nathaniel Clay <span dir="ltr"><<a href="mailto:clay.nathaniel@gmail.com" target="_blank">clay.nathaniel@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div>Remi,<br><br></div>JPEG 2000 offers several formats, one being JP2C or code stream. This format breaks down the file (intended for streaming across the wire) internally into tiles with markers then inside the tile markers packets containing the data for the specified tile. My initial thought is to store each of the tile packet streams in a row that is indexed in a table with in row separation of the packets for each of the resolutions (this appears to be able to be done with out an decode or encode for reassembly). Thus Union and simple Clip (with out trimming) operations would be copy and modify the header information operation back into a valid JP2C code stream to be sent directly to the client or consuming function/application for decode. JPEG 2000 is a large specification with many subparts, I am in the process of preparing two emails one to the list answering Bories' questions (more general and format neutral) , and another with more specifics of my idea for JPEG 2000, internal database format storage.  I am taking the time to confirm the specifics as related to the JPEG 2000 specification and postgresql.<br>

<br></div>Thanks,<br><br></div>Nathaniel Hunter Clay<br><div><div></div></div></div>
</blockquote></div><br></div>