[gdal-dev] Differences in behavior between pgsql query and use of GDAL API
Hi, I need to do the following request to find some data: - I have a bunch of towns (let's call them group A) - I retrieve the towns touching the group A (let's call them group B) - I make the union of group A and group B - I ask the towns covered by the resulting union For the moment, I use GDAL to do the processing like that: - I use OGRGeometry::Union to make the union of group A towns - I send a request to a postgis database with a ST_Touches where clause and the group A geometry as WKT - I make the union of the resulting geometries with OGRGeometry::Union - I send a request to a postgis database with a ST_Covers where clause and the union of group A and group B as WKT My problem is that I don't retrieve all the towns I initially have to build my geometry. If I try to do the same request totally in pgsql (union, touches and covers), I have the awaited result. If I compare the area of the geometry of the ST_Covers where clause (between generation with GDAL and computation by postgis), I ha ve the same area. What could explain the difference in the result ? Precision loss in GDAL ? Precision loss because of the use of WKT ? Should I use WKB instead of WKT ? Should I do all my computations in postgis ? -- Alexandre Gacon ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Differences in behavior between pgsql query and use of GDAL API
Hi Alexandre, if I well understood your problem, you're already doing half of the job (the queries)in PostGIS, so why not doing everything using PostGIS queries? Moreover, I think you don't need union. Assuming towns is a polygon layer, try: select distinct t.* from towns as t, (select distinct * from towns where town_in_group_A_condition) as t2 where t.fid = t2.fid or touches(t.geom, t2.geom); Let us know. All the best Sig Il giorno lun, 13/06/2011 alle 09.52 +0200, Alexandre Gacon ha scritto: Hi, I need to do the following request to find some data: - I have a bunch of towns (let's call them group A) - I retrieve the towns touching the group A (let's call them group B) - I make the union of group A and group B - I ask the towns covered by the resulting union For the moment, I use GDAL to do the processing like that: - I use OGRGeometry::Union to make the union of group A towns - I send a request to a postgis database with a ST_Touches where clause and the group A geometry as WKT - I make the union of the resulting geometries with OGRGeometry::Union - I send a request to a postgis database with a ST_Covers where clause and the union of group A and group B as WKT My problem is that I don't retrieve all the towns I initially have to build my geometry. If I try to do the same request totally in pgsql (union, touches and covers), I have the awaited result. If I compare the area of the geometry of the ST_Covers where clause (between generation with GDAL and computation by postgis), I ha ve the same area. What could explain the difference in the result ? Precision loss in GDAL ? Precision loss because of the use of WKT ? Should I use WKB instead of WKT ? Should I do all my computations in postgis ? -- Alexandre Gacon ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev _ PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] SDE driver: connecting to rasters never returns
Hello listers. So now that OGR connecting is solved by specifying the version name (or maybe by making a readonly connection), I'm stumbling on the same effect when connecting to a raster with gdalinfo or gdal_translate. But there is no option to specify version or readonly... My gdalinfo/translate commands never end... they keep going with 0 cpu... This is the same raster that I used when reporting #2063http://trac.osgeo.org/gdal/ticket/2063... One example command: gdal_translate -of vrt SDE:server,5151,database,user,pwd,user.MOSAIC_ORTO_10K_IGEOE,RASTER c:\temp\gdalteste.vrt Anyway I can debug this? Thanks. Duarte ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gisinternals GDAL builds
Hi Tamas and GDAL devs, I recently used Tamas' Win binaries (http://www.gisinternals.com/sdk/) to install Gdal 1.8 for Python 2.7, and everything is working fine---Tamas, thanks so much for providing those. However, I do have a question about selecting the correct release, and want to confirm if I "got lucky" on my first shot, or if there is something more I should know were I to pass advice along to others. Under "Compiler (Platform)", I chose MSVC2010 (Win32), which corresponds to release-1600-gdal-1-8-0-mapserver-6-0-0. But I am unclear as to what "CRT dependencies" are, as well as the MSVC acronym and the 1600-value prepended to the package name (as opposed to 1310, 1400, 1500). Would someone mind summarizing these for me? The various Win binaries include the same array of MSIs, so matching the correct Python version is obvious, as well as the 32/64 splitbut, would my install have worked if I used a different MSVC/number combo? Thanks in advance for your time, Elijah Robison ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] SDE driver: connecting to rasters never returns
On Jun 13, 2011, at 9:38 AM, Duarte Carreira wrote: Hello listers. So now that OGR connecting is solved by specifying the version name (or maybe by making a readonly connection), I’m stumbling on the same effect when connecting to a raster with gdalinfo or gdal_translate. But there is no option to specify version or readonly… My gdalinfo/translate commands never end… they keep going with 0 cpu… This is the same raster that I used when reporting #2063… One example command: gdal_translate -of vrt SDE:server,5151,database,user,pwd,user.MOSAIC_ORTO_10K_IGEOE,RASTER c:\temp\gdalteste.vrt Anyway I can debug this? set the environment variable CPL_DEBUG=on This should allow you to watch the connection happen and at the very least, see where it is hanging in either the SDE connection or query process. Note that I wrote the SDE driver, but I haven't had a running SDE instance for years, and I am in no position to test. sorry. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] SDE driver: connecting to rasters never returns
Howard, This is the output: GDAL: Auto register C:\OSGeo4W\bin\gdalplugins\1.8\gdal_MG4Lidar.dll using GDALR egister_MG4Lidar. GDAL: Auto register C:\OSGeo4W\bin\gdalplugins\1.8\gdal_MrSID.dll using GDALRegi ster_MrSID. GDAL: Auto register C:\OSGeo4W\bin\gdalplugins\1.8\gdal_SDE.dll using GDALRegist er_SDE. SDERASTER: Open(SDE:xxx,5151,database,,,sig_owner. MOSAIC_ORTO_10K_IGEOE,RASTER) revealed 7 tokens. SDERASTER: SDE Column name is 'RASTER' SDERASTER: 'sig_owner.MOSAIC_ORTO_10K_IGEOE' raster layer specified... using it directly with 'RASTER' as the raster column name. SDERASTER: minx: 174950.2, miny: 99950.2, maxx: 295049.8, maxy: 2100 49.8 SDERASTER: Tile origin: 174914.2, 210083.4 GDAL: GDALDeregister_GTiff() called. So it stops at SDERASTER: Tile origin: ... Because the last line appears only after pressing Ctrl-C (GDAL: GDALDeregister GTiff). I'm really sorry you don't have access to ArcSDE anymore... I can offer my time to test though. Duarte -Mensagem original- De: Howard Butler [mailto:hobu@gmail.com] Enviada: segunda-feira, 13 de Junho de 2011 16:28 Para: Duarte Carreira Cc: gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] SDE driver: connecting to rasters never returns On Jun 13, 2011, at 9:38 AM, Duarte Carreira wrote: Hello listers. So now that OGR connecting is solved by specifying the version name (or maybe by making a readonly connection), I'm stumbling on the same effect when connecting to a raster with gdalinfo or gdal_translate. But there is no option to specify version or readonly... My gdalinfo/translate commands never end... they keep going with 0 cpu... This is the same raster that I used when reporting #2063... One example command: gdal_translate -of vrt SDE:server,5151,database,user,pwd,user.MOSAIC_ORTO_10K_IGEOE,RASTER c:\temp\gdalteste.vrt Anyway I can debug this? set the environment variable CPL_DEBUG=on This should allow you to watch the connection happen and at the very least, see where it is hanging in either the SDE connection or query process. Note that I wrote the SDE driver, but I haven't had a running SDE instance for years, and I am in no position to test. sorry. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: gisinternals GDAL builds
Hi Elijah, With regards to the CRT dependency I would always recommend to use that version which corresponds to the CRT dep. of the application. You might use the Dependency Walker tool to identify which CRT dll the application depends on. For example the official python (python.org) windows builds (python.exe) use the following dependencies: Python 2.5 MSVC71 (1310) Pyrton 2.6 MSVC90 (1500) Python 2.7 MSVC90 (1500) Python 3.1 MSVC90 (1500) Best regards, Tamas 2011/6/13 Elijah Robison eli...@villagis.com Hi Tamas and GDAL devs, I recently used Tamas' Win binaries (http://www.gisinternals.com/sdk/) to install Gdal 1.8 for Python 2.7, and everything is working fine---*Tamas, thanks so much for providing those*. However, I do have a question about selecting the correct release, and want to confirm if I got lucky on my first shot, or if there is something more I should know were I to pass advice along to others. Under Compiler (Platform), I chose MSVC2010 (Win32), which corresponds to release-1600-gdal-1-8-0-mapserver-6-0-0http://PackageList.aspx?file=release-1600-gdal-1-8-0-mapserver-6-0-0.zip. But I am unclear as to what CRT dependencies are, as well as the MSVC acronym and the 1600-value prepended to the package name (as opposed to 1310, 1400, 1500). Would someone mind summarizing these for me? The various Win binaries include the same array of MSIs, so matching the correct Python version is obvious, as well as the 32/64 splitbut, would my install have worked if I used a different MSVC/number combo? Thanks in advance for your time, Elijah Robison ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] HDF5 metadata format problems
Hi all: I've ran into some troubles while trying to interpret an HDF5's metadata... Every field on HDF5 has it's own type(string, uchar, double) But GetMetadataItem(field_name) converts the data from the dataset into a C-style zero terminated string. This gives me a few problems: a-This string has a trailing space for some datatypes, but not for others (in unsigned char there is no space) ... There is no comment in the driver's code explaining if this is necesary or not(hdf5dataset.cpp from line 661)... I need to know if there will allways be a trailing space or not, to be able to perform type conversion on the data... b-Some items are type double and have more than 6 digits on the integer part, but the string show the output in exponential notation, that makes me lose some significant digits... I looked into the code and the problems seems to be on hdf5dataset.cpp on line 744, and changed the type on sprintf() from %g to %f, But now the number of decimal digits is fixed, which could bring me similar problems when using doubles... The question is: Is there a convention on how many decimal digits you have to show on the string? there could be another way to return a number from an item that doesn't truncate the digits? Given all this problems i wonder: Could somebody provide a way to retrieve the data in it's binary form with maybe some information on the metadata's type? or this would only be usefull on the HDF5 format? Sorry for the long mail Thanks in advance -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] HDF5 metadata format problems
On 11-06-13 04:53 PM, Alex Mantaut wrote: Hi all: I've ran into some troubles while trying to interpret an HDF5's metadata... Every field on HDF5 has it's own type(string, uchar, double) But GetMetadataItem(field_name) converts the data from the dataset into a C-style zero terminated string. This gives me a few problems: a-This string has a trailing space for some datatypes, but not for others (in unsigned char there is no space) ... There is no comment in the driver's code explaining if this is necesary or not(hdf5dataset.cpp from line 661)... I need to know if there will allways be a trailing space or not, to be able to perform type conversion on the data... Alex, I don't quite grasp why you need to know if there will be a trailing space. I see the spaces are being appended as a separator in the hdf5 driver in case the value is actually an array of values. I would suggest you just strip off trailing white space in your client code if it is an issue. b-Some items are type double and have more than 6 digits on the integer part, but the string show the output in exponential notation, that makes me lose some significant digits... I looked into the code and the problems seems to be on hdf5dataset.cpp on line 744, and changed the type on sprintf() from %g to %f, But now the number of decimal digits is fixed, which could bring me similar problems when using doubles... The question is: Is there a convention on how many decimal digits you have to show on the string? there could be another way to return a number from an item that doesn't truncate the digits? To preserve precision it is normal to format these as %.15g. I believe this does a pretty good job of preserving double precision floating point. I have changed the float and double code to use this format in trunk and 1.8 branches. Given all this problems i wonder: Could somebody provide a way to retrieve the data in it's binary form with maybe some information on the metadata's type? or this would only be usefull on the HDF5 format? This would be a substantial change to the metadata handling mechanism in GDAL and is unlikely to occur. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OpenJPEG2000 issues when reading blocks at a time
Hello, I have the following code: qDebug(tilePosX: %i , this-tilePosX); qDebug(tilePosY: %i , this-tilePosY); float * floatData = (float *) CPLMalloc(sizeof(float)*nXSize*nYSize); poBand-RasterIO( GF_Read, this-tilePosX*nXSize, this-tilePosY*nYSize, nXSize, nYSize, floatData, nXSize, nYSize,GDT_Float32, 0, 0 ); I am using this to read in tiles from a larger image, to avoid having to do massive read operations. This seems to work great for an uncompressed nitf, however, when trying it on a JPEG2000 image, it seems to be highly unstable. Sometimes my software crashes, and sometimes I get no data back, and usually it gives a splurge of info like below, whee tilePosX and tilePosY is the block in the file I am trying to read. nX/nY Size variables are obtained from the GetBlockSize() function on the band., which is this case is 1024x1024. Is there a problem with OpenJPEG2000? I have tried to use jasper already, and it was painfully slow. Starting to run out of options here. Also, as a side note, I am doing this operation in a separate thread from my GUI, and it should be waiting for the data to be returned before returning to my main..which like i said is working fine when it is uncompressed - but does this driver perhaps return a simple allocated array or something it is populated asynchronously? Some of the blocks come back looking right, some are scrambled, and some are all black in my viewer. ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 Loading Pixmap tilePosX: 1 tilePosY: 0 ERROR 1: Stream too short, expected SOT ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 1, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 1, Y block offset 0 Loading Pixmap tilePosX: 0 tilePosY: 1 Loading Pixmap tilePosX: 1 tilePosY: 1 Loading Pixmap tilePosX: 0 tilePosY: 1 Loading Pixmap tilePosX: 1 tilePosY: 1 ERROR 1: Stream too short ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 1, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 1, Y block offset 1 Loading Pixmap tilePosX: 1 tilePosY: 1 Loading Pixmap tilePosX: 1 tilePosY: 1 Loading Pixmap tilePosX: 2 tilePosY: 0 Loading Pixmap tilePosX: 2 tilePosY: 1 ERROR 1: Expected a SOC marker ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 0 ERROR 1: Marker is not compliant with its position ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 1 Loading Pixmap Loading Pixmap tilePosX: 2 tilePosY: 0 tilePosX: 2 tilePosY: 1 ERROR 1: Marker is not compliant with its position ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 1 ERROR 1: Stream too short, expected SOT ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 0 Loading Pixmap tilePosX: 2 tilePosY: 0 Loading Pixmap tilePosX: 2 tilePosY: 0 Loading Pixmap tilePosX: 0 tilePosY: 2 Loading Pixmap tilePosX: 1 tilePosY: 2 Loading Pixmap tilePosX: 2 tilePosY: 2 ERROR 1: Stream too short ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 2 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 2 Loading Pixmap tilePosX: 1 tilePosY: 2 Loading Pixmap tilePosX: 2 Loading Pixmap tilePosY: 2 tilePosX: 3 tilePosY: 0 Loading Pixmap tilePosX: 3 tilePosY: 1 Loading Pixmap tilePosX: 3 tilePosY: 2 ERROR 1: Expected a SOC marker ERROR 1: Expected a SOC marker ERROR 1: opj_read_header() failed ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 3, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 3, Y block offset 1 ERROR 1: IReadBlock failed at X offset 2, Y offset 2 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 2 ERROR 1: Marker is not compliant with its position ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 3, Y offset 2 ERROR 1: GetBlockRef failed at X block offset 3, Y block offset 2 ERROR 1: Stream too short, expected SOT ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 3, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 3, Y block offset 0 Loading Pixmap Loading Pixmap tilePosX: 2 tilePosX: 3 Loading Pixmap Loading Pixmap tilePosY: 0 tilePosX: 3 tilePosX: 3 tilePosY: 2 tilePosY: 1 tilePosY: 2 ERROR 1: Expected a SOC marker ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 2 ERROR 1: GetBlockRef failed at X block offset 2,
Re: [gdal-dev] OpenJPEG2000 issues when reading blocks at a time
Derek, Can you provide a screenshot of the displayed image. Especially the scrambled blocks. On Tue, Jun 14, 2011 at 4:22 AM, Cole, Derek dc...@integrity-apps.comwrote: Hello, I have the following code: qDebug(tilePosX: %i , this-tilePosX); qDebug(tilePosY: %i , this-tilePosY); float * floatData = (float *) CPLMalloc(sizeof(float)*nXSize*nYSize); poBand-RasterIO( GF_Read, this-tilePosX*nXSize, this-tilePosY*nYSize, nXSize, nYSize, floatData, nXSize, nYSize,GDT_Float32, 0, 0 ); I am using this to read in tiles from a larger image, to avoid having to do massive read operations. This seems to work great for an uncompressed nitf, however, when trying it on a JPEG2000 image, it seems to be highly unstable. Sometimes my software crashes, and sometimes I get no data back, and usually it gives a splurge of info like below, whee tilePosX and tilePosY is the block in the file I am trying to read. nX/nY Size variables are obtained from the GetBlockSize() function on the band., which is this case is 1024x1024. Is there a problem with OpenJPEG2000? I have tried to use jasper already, and it was painfully slow. Starting to run out of options here. Also, as a side note, I am doing this operation in a separate thread from my GUI, and it should be waiting for the data to be returned before returning to my main..which like i said is working fine when it is uncompressed - but does this driver perhaps return a simple allocated array or something it is populated asynchronously? Some of the blocks come back looking right, some are scrambled, and some are all black in my viewer. ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 Loading Pixmap tilePosX: 1 tilePosY: 0 ERROR 1: Stream too short, expected SOT ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 1, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 1, Y block offset 0 Loading Pixmap tilePosX: 0 tilePosY: 1 Loading Pixmap tilePosX: 1 tilePosY: 1 Loading Pixmap tilePosX: 0 tilePosY: 1 Loading Pixmap tilePosX: 1 tilePosY: 1 ERROR 1: Stream too short ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 1, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 1, Y block offset 1 Loading Pixmap tilePosX: 1 tilePosY: 1 Loading Pixmap tilePosX: 1 tilePosY: 1 Loading Pixmap tilePosX: 2 tilePosY: 0 Loading Pixmap tilePosX: 2 tilePosY: 1 ERROR 1: Expected a SOC marker ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 0 ERROR 1: Marker is not compliant with its position ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 1 Loading Pixmap Loading Pixmap tilePosX: 2 tilePosY: 0 tilePosX: 2 tilePosY: 1 ERROR 1: Marker is not compliant with its position ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 1 ERROR 1: Stream too short, expected SOT ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 0 Loading Pixmap tilePosX: 2 tilePosY: 0 Loading Pixmap tilePosX: 2 tilePosY: 0 Loading Pixmap tilePosX: 0 tilePosY: 2 Loading Pixmap tilePosX: 1 tilePosY: 2 Loading Pixmap tilePosX: 2 tilePosY: 2 ERROR 1: Stream too short ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 2, Y offset 2 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 2 Loading Pixmap tilePosX: 1 tilePosY: 2 Loading Pixmap tilePosX: 2 Loading Pixmap tilePosY: 2 tilePosX: 3 tilePosY: 0 Loading Pixmap tilePosX: 3 tilePosY: 1 Loading Pixmap tilePosX: 3 tilePosY: 2 ERROR 1: Expected a SOC marker ERROR 1: Expected a SOC marker ERROR 1: opj_read_header() failed ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 3, Y offset 1 ERROR 1: GetBlockRef failed at X block offset 3, Y block offset 1 ERROR 1: IReadBlock failed at X offset 2, Y offset 2 ERROR 1: GetBlockRef failed at X block offset 2, Y block offset 2 ERROR 1: Marker is not compliant with its position ERROR 1: opj_read_header() failed ERROR 1: IReadBlock failed at X offset 3, Y offset 2 ERROR 1: GetBlockRef failed at X block offset 3, Y block offset 2 ERROR 1: Stream too short, expected SOT ERROR 1: opj_decode_tile_data() failed ERROR 1: IReadBlock failed at X offset 3, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 3, Y block offset 0 Loading Pixmap Loading
