Owen,
Please create a ticket about that.
Even
Le 13/02/2025 à 04:40, Owen Glofcheski via gdal-dev a écrit :
Hey all,
I work with Kurt Schwehr, and we've been debugging failures where an
explicit mask isn't preserved through a CreateCopy operation to create
a COG through the GTiff driver at HEAD.
This failure only started occurring after
https://github.com/OSGeo/gdal/commit/3bdc81a205bad8342688873e4ed5716f1208e8f5.
After the CreateCopy, when we read back the mask, the mask is expanded
from the 1-bit mask to the 8-bit mask inside of gtiffoddbitsband.h.
However, the mask is not a 1-bit mask when I add logging here;
instead, it's the original 8-bit mask (with 255s and 0s). So when it
gets expanded to 8-bits, it's no longer the original mask:
E.g., 255 0 255 255 becomes 255 255 ... 255 255 0 0 ... 0 0 255 255 ...
So my guess is that somewhere along the line we either copy the mask
without turning it back into a bitmask, or we lose metadata tracking
that the mask is encoded a certain way.
Does anything obvious jump out to folks here? The issue *does not*
occur when either COPY_SRC_OVERVIEWS="YES" is removed or INTERLEAVE is
set to PIXEL (it only fails on band interleaving).
Here's a gist containing an example test that fails at head but
previously succeeded:
https://gist.github.com/orglofch/40cf4d9136978b0384141cc74d1039b6.
Thanks,
Owen
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
