New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDAL GetMetadataItem('BLOCK_SIZE_%d_%d' % (c, r), 'TIFF') #1077
Comments
@ruitaodong Could you try There have been some changes to Rasterio's |
Sorry that I closed it by mistake
What's interesting is that with goal from osgeo import gdal |
@ruitaodong that is interesting. Rasterio is using the same GDAL function as |
Upstream bug report: https://trac.osgeo.org/gdal/ticket/6961. As a workaround, we could call |
@sgillies, good catch. Thanks for looking into it and thanks for rasterio. |
@ruitaodong Even Rouault pointed out in the GDAL tracker that dumping all the block sizes (possibly hundreds or thousands) into a dict might not be user friendly. I agree with that. I feel like we should be able do better than this
Perhaps a new dataset method like
could return something like
Such a method would also serve users who want to get the window (indexes) of a single block. |
I think that makes sense. I know that my use case is very specific. However, it is a little weird as BLOCK_SIZE is not actually per band. It is compressed jpeg size (minus huffman table size) for the whole tile (in ycrcb in my case). |
BLOCK_SIZE is in the general case a per band property. In fact it depends on the TIFF PlanarConfig tag value (in GDAL INTERLEAVE metadata item). If PlanarConfig=Separate (INTERLEAVE=BAND), then you have indeed one block for each band. If PlanarConfig=Contig (INTERLEAVE=PIXEL), then the block is shared by all bands. So in the general case, it is safer to ask at the band level. |
block() return the window and size in bytes of a TIFF block. The size is undefined for other formats and will be None. Resolves #1077
@ruitaodong I've got a try at the new feature in #1085 if you want to take a look. |
Hmm. This code is crashing the Travis CI servers for GDAL versions < 2. I must have overlooked a version requirement. |
This is definitely a GDAL 2.0 new feature. But in any case you should be ready to raccept NULL as return value. That might potentially happen on corrupted TIFFs or if wrong indices are provided |
I tried both fed3bca & master, (Ubuntu 16.04 with gdal 2.1.0), but I got import rasterio |
@ruitaodong I suspect that you need to upgrade attrs. I've modified my branch to require attrs >= 16.0.0, the versions where slots were introduced. I've also guarded against NULL results and am pleased with how this feature turned out. Look out for my switch to a named tuple (with window and size attributes) for the return value of |
I have been using GDAL/QGIS (carry over from my remote sensing days) for deep learning in digital pathology. We primarily deal with JPEG tiles in TIFF pyramid images. I have since found rasterio which is so much more convenient. However, one feature I need is to access jpeg length of each block (tiffinfo -s), which is a good indicator of empty or nearly empty space. In gdal, it is
GetRasterBand(1).GetMetadataItem('BLOCK_SIZE_%d_%d' % (c, r), 'TIFF')
However, it doesn't show up in tags(), tags(1), or tags(ns='TIFF')
I'm using version 0.31.0
The text was updated successfully, but these errors were encountered: