Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6757 closed defect (fixed)

error creating jpeg compressed geotiff with tile size bigger than 400

Reported by: ccjklppp Owned by: warmerdam
Priority: highest Milestone: 2.2.0
Component: GDAL_Raster Version: 2.1.2
Severity: critical Keywords:
Cc:

Description

from version 2.1.2/2.1.1 there is an error creating geotiff with jpeg compression and tile size that is bigger than 400

when trying to run the next command:

gdal_translate -of GTIFF -co COMPRESS=JPEG -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 D:\input.tif D:\output.tif

I get the following errors:

ERROR 1: JPEGLib:Failed to create temporary file
ERROR 1: WriteEncodeTile/Strip() failed.
ERROR 1: JPEGLib:Failed to create temporary file
ERROR 1: WriteEncodeTile/Strip() failed.

this happens for all tiff files I've checked (RGB) when the input is a grayscale tiff, it fails from tile size bigger than 688

Change History (10)

comment:1 by Even Rouault, 7 years ago

Are you using a OSGeo4W build ? I can't reproduce on Linux. I'm wondering if it not the same issue as https://trac.osgeo.org/gdal/ticket/6677 ?

comment:2 by ccjklppp, 7 years ago

I used version 2.1.2 that I built myself (on windows) and tried also an installation from GISinternals: http://www.gisinternals.com/query.html?content=filelist&file=release-1600-x64-gdal-2-1-2-mapserver-7-0-2.zip

comment:3 by ccjklppp, 7 years ago

I've tested some more versions of the installaion from GISinternals
when used the installation that was compiled with VS2010, I get the errors.
when used the installation that was complied with VS2013 - no errors.
what can be the problem? older versions worked fine also when compiled with VS2010

Last edited 7 years ago by ccjklppp (previous) (diff)

comment:4 by Even Rouault, 7 years ago

I've downloaded http://download.gisinternals.com/sdk/downloads/release-1600-x64-gdal-2-1-2-mapserver-7-0-2.zip and cannot reproduce your error when running :

E:\dev\release-1600-x64-gdal-2-1-2-mapserver-7-0-2>gdal_translate small_world.tif out.tif -co compress=jpeg -co tiled=yes -co blockxsize=512 -co blockysize=512

The "Failed to create temporary file" error message would make me think that you lack free space in the temporary directory of your account.

comment:5 by ccjklppp, 7 years ago

I have plenty of space on the disk + i tried it on several PCs and got the same error. try using this tiff file as an input: http://www.terracolor.net/download/tc_ng_baghdad_iq_geotiff.zip
the error occured for some more input tiff files (bigger than the one i gave u as a sample)

comment:6 by Even Rouault, 7 years ago

I've tried your tc_ng_baghdad_iq_geotiff.zip dataset on a Windows 7 VM and it works fine for both the gisinternals build or a custom build of mine with VS2010.

comment:7 by Even Rouault, 7 years ago

I can finally reproduce your observations on Windows 10. The "JPEGLib:Failed to create temporary file" error is due to tmpfile() implementation being silly on Windows (trying to create a file in c:\ where most users don't have write permission). This is known as https://trac.osgeo.org/gdal/ticket/1795

What is mysterious is why the VS2010 build needs to go through that code path (the behaviour of the VS2013 build not requiring tmpfile() is logicial). Not sure I'll pursue the investigation deeper.

comment:8 by ccjklppp, 7 years ago

it's also strange that it did work fine on windows 10 / windows server 2012 with all previous versions of GDAL (that was built with VS2010)

comment:9 by Even Rouault, 7 years ago

Resolution: fixed
Status: newclosed

In 37061:

Internal libtiff: resync with upstream CVS to increate the max memory usable by libjpeg on compression. This helps when creating files with big tiles, without using libjpeg temporary files (fixes #6757)

comment:10 by Even Rouault, 7 years ago

I've committed something that should fix / workaround the issue. My conclusion is that the C runtime / redistributable of VS2012 or above has a smarter implementation of tmpfile() regarding Win10 than the one of VS2010. I see no obvious reason why older versions of GDAL would work better when running against the same runtime. Are you sure to test with identical versions of the C runtimes ?

Another way to workaround the issue is to define the JPEGMEM environmenet variable for example to 10M

If you appreciated the fix, my 2017 good resolution is to suggest postcard thanks. My address is given on http://www.spatialys.com/en/contact/

Note: See TracTickets for help on using tickets.