<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='mso-fareast-language:EN-US'>I agree that JP2 usage is likely to continue for a long time. One of the key differentiators is the ability to support higher bit depth. <o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>However I don’t see it being as popular for new applications in the same way. It feels like there is a push / shift to “something newer”, and that (to me) looks like HEIF with AV1. There are definitely options on both the file format side – a newer GeoTIFF / COG or MXF could also be candidates; and on the codec side (especially for HEVC aka H.265). That movement is likely 5+ years though, unless something disruptive happens in sensing.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>For “non-display” purposes, where the primary use is analysis rather than visualisation, I think there will be increasing desire to keep the source values (potentially floating point) – maybe a point cloud of LIDAR, or data cube of hyperspectral imagery.  That looks like HDF5 at the moment, although maybe the back-end format and compression matters less than the access approach.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Difficult to see advanced codecs making much progress here. <o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Brad<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> gdal-dev <gdal-dev-bounces@lists.osgeo.org> <b>On Behalf Of </b>Kurt Schwehr<br><b>Sent:</b> Wednesday, 31 March 2021 3:12 AM<br><b>To:</b> Aaron Boxer <boxerab@gmail.com><br><b>Cc:</b> gdal dev <gdal-dev@lists.osgeo.org><br><b>Subject:</b> Re: [gdal-dev] Long Term Prognosis for JPEG 2000<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Jp2k is likely to continue with heavy use for a long time to come.  There are lots of hardware encoders in our solar system and the existing base of data in that format is massive.  And with the improvements in Openjpeg, it's support seems viable.  It's not the first choice for most, but that's okay.<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Mon, Mar 29, 2021, 7:22 AM Aaron Boxer <<a href="mailto:boxerab@gmail.com">boxerab@gmail.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>Hello There,<o:p></o:p></p><div><p class=MsoNormal>I'm curious what folks here think about the future of JPEG 2000 in geospatial?<o:p></o:p></p></div><div><p class=MsoNormal>I was having a little discussion about this over here:<o:p></o:p></p></div><div><p class=MsoNormal><a href="https://github.com/USGS-Astrogeology/ISIS3/issues/4237" target="_blank">https://github.com/USGS-Astrogeology/ISIS3/issues/4237</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>To me, the features that made JP2 unique amongst the many codecs were:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>0. royalty free<o:p></o:p></p></div><div><p class=MsoNormal>1. support for lossy and lossless compression in a single framework<o:p></o:p></p></div><div><p class=MsoNormal>2. support for TB images<o:p></o:p></p></div><div><p class=MsoNormal>3. fast on-the-fly random access into large images<o:p></o:p></p></div><div><p class=MsoNormal>4. decoder can determine what sort of progression it uses at decode time: resolution,<o:p></o:p></p></div><div><p class=MsoNormal>quality, component or spatial.<o:p></o:p></p></div><div><p class=MsoNormal>5. precise rate control<o:p></o:p></p></div><div><p class=MsoNormal>6. error and re-compression resilience<o:p></o:p></p></div><div><p class=MsoNormal>7. JPIP protocol for progressive transmission over low-bandwidth networks<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The cons to JP2 were:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>0. computational complexity i.e. dog slow<o:p></o:p></p></div><div><p class=MsoNormal>1. (until recently) buggy and slow OSS implementations<o:p></o:p></p></div><div><p class=MsoNormal>2. patent questions (largely resolved)<o:p></o:p></p></div><div><p class=MsoNormal>3. poor support from HW and browsers<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Do you think there is currently a viable alternative which covers enough of the advantages while lacking enough of the negatives that plague JP2 ?  I'm curious because I have been devoting quite a bit of time to addressing some of those negatives, as discussed at length previously,<o:p></o:p></p></div><div><p class=MsoNormal>The standard remains essential in digital cinema, medical imaging and in the archive community. But, those last two fields may also be ripe for change.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In digital cinema, precise rate control is a must, so I think it is here to stay in the area.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal>Aaron<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>gdal-dev mailing list<br><a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><o:p></o:p></p></blockquote></div></div></body></html>