<div dir="ltr"><div>Yes, enabling TLM generation for future products would already be an important first step, and we have asked ESA about this recently.</div><div>Given that the full archive of Sentinel-2 was reprocessed recently (Collection-1), we can assume that we won't get a full reprocessing before a few years, which is why we are looking for alternatives to make Sentinel-2 more accessible.<br></div><div><br></div><div>Modifying the JP2 files in-place would be preferable for everyone compared to adding .tlm files, but it would incur additional cost to perform those disk writes, and update checksums. Maybe it's not such an issue.<br></div><div><br></div><div>If you are not against the .tlm sidecar idea in GDAL/OpenJPEG, that's good enough for me for now, and it might allow further discussions with ESA.</div><div><br></div><div>Jérémy<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le ven. 13 déc. 2024 à 17:08, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Someone should just tell the team at ESA (are you reading us ESA by the <br>
way?) in charge of producing those JPEG2000 files to turn on the Kakadu <br>
switch to generate TLM markers. A 5 minute change on their side, ok <br>
maybe 1 hour to update unit tests.<br>
<br>
What you suggest about sidecar .tlm sidecar could certainly be <br>
implemented, but one would have to rescan the archive to generate them. <br>
At that point, you'd probably just want to insert the TLM marker inside <br>
existing files with a dedicated utility that wouldn't need to decompress <br>
the pixel values.<br>
<br>
See also <a href="https://mastodon.social/@EvenRouault/113556023446290151" rel="noreferrer" target="_blank">https://mastodon.social/@EvenRouault/113556023446290151</a> for an <br>
alternate idea (not necessarily better).<br>
<br>
Even<br>
<br>
<br>
Le 13/12/2024 à 16:50, Jérémy Anger via gdal-dev a écrit :<br>
> Dear GDAL maintainers,<br>
><br>
> Thank you for the release of OpenJPEG 2.5.3, with the support of TLM <br>
> markers!<br>
> Following up on [1], Sentinel-2 JP2 files currently do not have TLM <br>
> markers. However, it is theoretically possible to generate an external <br>
> index file for each JP2 raster, and the index could be formatted <br>
> exactly as a JP2 TLM marker. Such sidecar file is not part of the <br>
> JPEG2000 standard, but given the gains that are achievable with TLM <br>
> markers, this strategy sounds reasonable. The entirety of the <br>
> Sentinel-2 collection (archive and live) is concerned.<br>
><br>
> GDAL could be modified to look for these sidecar .tlm files (although <br>
> I'm not too familiar with the sidecar system), and give the TLM marker <br>
> content to JP2 implementations (OpenJPEG in particular, after changes).<br>
><br>
> Do you think this approach is reasonable? Would it be reasonable to <br>
> implement such a feature in GDAL and OpenJPEG?<br>
> Do you have ideas for a better solution?<br>
><br>
> Best regards,<br>
> Jérémy<br>
><br>
> [1]: <a href="https://lists.osgeo.org/pipermail/gdal-dev/2024-November/059805.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/gdal-dev/2024-November/059805.html</a><br>
><br>
> _______________________________________________<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" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.<br>
<br>
</blockquote></div>