Changes between Initial Version and Version 3 of Ticket #1795
- Timestamp:
- Oct 12, 2007, 9:56:16 AM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1795
- Property Status new → closed
- Property Resolution → fixed
- Property Milestone 1.5.0 → 1.4.3
-
Ticket #1795 – Description
initial v3 14 14 gdalinfo failed - unable to open 'referenz.vrt'. 15 15 Open GDAL Datasets: 16 16 1 N DriverIsNULL 512x512x0 17 17 18 18 Any help is welcome. … … 26 26 Wolfgang, 27 27 28 This is an issue in the JPEG driver. 28 This is an issue in the JPEG driver. It seems that libjpeg tries to 29 29 create a temporary file when an operation (like processing a progressive 30 jpeg) would require quite a bit of memory. 30 jpeg) would require quite a bit of memory. If it fails to create the file 31 31 you get the message you see. 32 32 … … 34 34 instead of 1MB in the builtin libjpeg for GDAL (SVN trunk) 35 35 36 36 http://trac.osgeo.org/gdal/changeset/11706 37 37 38 38 If you are building GDAL from source, then you might want to apply the … … 50 50 jpeglib.h : 51 51 52 /* Limit on memory allocation for this JPEG object.(Note that this is53 54 * used for virtual-array buffers.)May be changed by outer application55 56 57 52 /* Limit on memory allocation for this JPEG object. (Note that this is 53 * merely advisory, not a guaranteed maximum; it only affects the space 54 * used for virtual-array buffers.) May be changed by outer application 55 * after creating the JPEG object. 56 */ 57 long max_memory_to_use; 58 58 59 59 60 60 So, an alternative to define JPEGMEM (which seems to do what I thought it 61 should do in my previous message) or 62 63 61 should do in my previous message) or could be to add the following lines : 62 if (getenv("JPEGMEM") == NULL) 63 poDS->sDInfo.mem->max_memory_to_use = 500 * 1024 * 1024; 64 64 just after creating the decompression object done by : 65 65 jpeg_create_decompress( &(poDS->sDInfo) ) ; 66 66 67 67 This way, we don't need to patch libjpeg and if the user wants to define it's