[Gdal-dev] Re: gdal fails on vrt (virtual raster) file

[Even Rouault]

Hi,

I've just had a quick look into libjpeg. You may not need to patch the #define 
DEFAULT_MAX_MEM, as the only indirect use of this I can see is in jmemmgr.c 
where it	can be overloaded by the JPEGMEM environment variable. So, even with 
FWTools, if you do "JPEGMEM=500M gdalinfo blah.jpeg", you should have the 
same behaviour as the gdal SVN patched libjpeg.
That's just theory. I haven't tested anything.

Best regards

On Wednesday 05 September 2007 18:04:47 Frank Warmerdam wrote:
> WolfgangZ wrote:
> > this patch is probably not jet applied in the FWTools. But I'm wondering
> > why even gdalinfo needs to create a temporary file? Why is there the
> > need from gdalinfo or gdal_translate to read in the full image? Do I
> > understand that that limit equals the maximum file size that can be
> > handled? Where is this temporary file usually generated? I'm working on
> > W2k.
>
> Wolfgang,
>
> I agree that the patch is likely not in FWTools because FWTools uses
> a stock external libjpeg instead of the adjusted GDAL libjpeg.
>
> I'm not exactly clear what the temp file is for.  I have the vague
> impression it is only needed with progressive jpegs, but I could be wrong.
>
> I don't know for sure where it is created.
>
> Best regards,
>
> -
> ---------------------------------------+-----------------------------------
>--- I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com light and sound - activate the windows |
> http://pobox.com/~warmerdam and watch the world go round - Rush    |
> President OSGeo, http://osgeo.org
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev