[gdal-dev] Incorrect image bytes from VSIGetMemFileBuffer in GDAL < 2.1.0

Sean Gillies sean at mapbox.com
Tue Sep 27 06:33:59 PDT 2016


On Tue, Sep 27, 2016 at 2:59 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Le mardi 27 septembre 2016 14:09:30, Sean Gillies a écrit :
> > Hi all,
> >
> > I've got code in Rasterio that calls VSIGetMemFileBuffer to get PNG or
> JPEG
> > image bytes. With GDAL 1.11, I found that I had to fix the resulting byte
> > array by moving the last byte to the head of the array. With GDAL 2.1.0
> and
> > 2.1.1 this is no longer needed and we can return an unshifted array (see
> > the changeset below).
> >
> > https://github.com/mapbox/rio-mbtiles/compare/master...
> brendan-ward:bad_byt
> > es?expand=1#diff-cfcb7125bae0f25564785b33fa38d6a1L45
> >
> > I haven't been able to find the change in the change log or tracker. Can
> > anyone point me to the commit that changed this so I can pin down the
> > versions when it changed?
>
> Sean,
>
> This is super weird and I'm pretty sure nothing has changed in that area.
> VSIGetMemFileBuffer() has been used for long by a number of drivers in
> GDAL and
> none of them has ever had to do such weird things, so I'm quite skeptical
> there's a bug in that area, or it is something more subtle. Did you check
> that
> the issue is in GDAL itself, by breaking with the debugger or adding debug
> traces in VSIGetMemFileBuffer to check the buffer values ?
>
>
I have looked more closely and ruled out GDAL and then combed through the
Cython and CPython trackers, eventually finding the culprit:

  https://bugs.python.org/issue12834

It's been fixed in Python 3.3+ for several years but not fixed in 2.7 until
version 2.7.10. I'm happy to report that it's specific to Cython
memoryviews and not a problem for GDAL Python users.

Thanks for the quick response, Even, and apologies for the false alarm.

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160927/af27a560/attachment.html>


More information about the gdal-dev mailing list