THanks Mateusz, You're right. I'm trying it as we speak.
In my case I have a std::vector<GByte*> of the 3 bands, where the GByte* are allocated in the heap with new GByte[width*height]. I guess that won't work because the three bands have to be one single memory chunk, am I right? I guess the only solution is to switch to single band float and merge rgb to float. I'd prefer not having to refactor the rest of the code. Is it possible to have a different address for each band? All this is to support jpg as output. All the operations are done in my GByte array and it's only at the end that I create the dataset and image. At the moment I create a Tiff and finally createcopy to jpg. On Fri, Jun 3, 2016 at 9:10 PM, Mateusz Loskot <[email protected]> wrote: > On 3 June 2016 at 20:45, Pol Monsó Purtí <[email protected]> wrote: > > I've seen this mysterious article http://www.gdal.org/frmt_mem.html > which > > references the `DATAPOINTER` option. I've seen another reference > > [here]( > https://lists.osgeo.org/pipermail/gdal-dev/2006-November/010583.html) > > which does > > > > > > > sprintf(filename,"MEM:::DATAPOINTER=%d,PIXELS=%d,LINES=%d,BANDS=1,DATATYPE=%d,PIXELOFFSET=0,LINEOFFSET=0,BANDOFFSET=0",datpt,pixels,lines,datatype); > > dataset = GDALOpen(filename,GA_Update); > > > > How would this translate to c++? > > The line above is valid C++, isn't it. > If you followed to Frank's answer [1], you'd see it slightly corrected > but the technique remains the same. > > [1] https://lists.osgeo.org/pipermail/gdal-dev/2006-November/010603.html > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
