<div dir="ltr">Hey all,<div><br>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.<br><br>This failure only started occurring after <a href="https://github.com/OSGeo/gdal/commit/3bdc81a205bad8342688873e4ed5716f1208e8f5" target="_blank">https://github.com/OSGeo/gdal/commit/3bdc81a205bad8342688873e4ed5716f1208e8f5</a>.<br><br>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:<br>E.g., 255 0 255 255 becomes 255 255 ... 255 255 0 0 ... 0 0 255 255 ...<br><br>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. <div><br></div><div>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).</div><div><br></div><div>Here's a gist containing an example test that fails at head but previously succeeded: <a href="https://gist.github.com/orglofch/40cf4d9136978b0384141cc74d1039b6" target="_blank">https://gist.github.com/orglofch/40cf4d9136978b0384141cc74d1039b6</a>.</div><div><br></div><div>Thanks,</div><div>Owen</div></div></div>