<div dir="ltr">Sounds good to me too (not that I really have the background to say so).<div><br></div><div>1. Are there any plans to contribute JPEGXL in tiff to <a href="https://gitlab.com/libtiff/libtiff">https://gitlab.com/libtiff/libtiff</a>? </div><div>2. And what would one need to do to patch libtiff to use JPEGXL?</div><div><br></div><div>Thanks!</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jan 6, 2025 at 9:54 AM thomas bonfort via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">sounds good, +1</p>
<p dir="ltr">thanks,<br>
TB</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 6 janv. 2025, 18:44, Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</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>
Given that communication with Adobe in recent years has been similar to <br>
expecting to receive a signal from a black hole from outside its event <br>
horizon, up to now we have unilaterally attributed Compression=50002 to <br>
mean JPEGXL in TIFF. Recently I saw that the DNG 1.7 specification has <br>
registered value 52546 to mean JPEGXL in DNG <br>
(<a href="https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_0_0.pdf" rel="noreferrer noreferrer" target="_blank">https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_0_0.pdf</a> <br>
, page 122). DNG is a derivative of the TIFF spec, so I guess/hope Adobe <br>
makes sure that tag & tag value numbers don't collide between base TIFF <br>
and DNG. So it would seem to me that switching to using the 52546 value <br>
would be more future proof than our self-assigned 50002. If so, I'd do <br>
the change in master to using 52546 on write side and accepting both <br>
50002 and 52546 on read side, and backport read support for 52546 in 3.10<br>
<br>
(this is mostly a GDAL-only topic for now given that the JPEGXL TIFF <br>
codec is for the internal libtiff copy only)<br>
<br>
Thoughts?<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer 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>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" rel="noreferrer" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>
_______________________________________________<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>
</blockquote></div>