Bug report #1530

JPG rasterfile fails to load

Added by goggi - over 11 years ago. Updated about 11 years ago.

Status:Closed
Priority:Low
Assignee:ersts -
Category:Rasters
Affected QGIS version: Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:11590

Description

Iam trying to load raster file. JPG format. Proplem is that it only renders part of the file right. See attached image for screen shot. I can open those files in another programs so the file should not be damaged. Those files did work in preview 2 version. I can't send one of the files sadly since that is contract violation.

and if system info is of any help
Windows XP SP3
Graphic: NVidia Geforce 8500 GT Drive 181.22
CPU: Intel Quad core Q6600

QGisScreenshot.JPG (68.5 KB) goggi -, 2009-02-05 09:50 AM

History

#1 Updated by dthonon - over 11 years ago

I have the same problem. To reproduce it :
- create any JPEG image, for example using gimp fill with a texture. I tried 1000*1000, 5000*5000 and 10000*10000 and none worked correctly
- add it as raster to QGIS
- only the top part is displayed
- pyramids are also truncated to the top part.

The same raster work fine with 1.0 Preview II

Platform : Windows, using the http://trac.osgeo.org/osgeo4w/ download.

#2 Updated by ersts - over 11 years ago

  • Status changed from Open to In Progress

Replying to [comment:1 dthonon]:

I have the same problem. To reproduce it :
- create any JPEG image, for example using gimp fill with a texture. I tried 1000*1000, 5000*5000 and 10000*10000 and none worked correctly
- add it as raster to QGIS
- only the top part is displayed
- pyramids are also truncated to the top part.

I am actually having a problem reproducing this, but we have seen similar behavior in the past. Can anyone post a link to an image that is causing this behavior so we can be working with the same data?

dthonon: Can you explain how you created your pyramids? Are they internal? A while ago I removed the ability for QGIS to build pyramids internally for JPEGs because it often ended in data corruption that looked like the screenshot above (but the corrupted image was also red).

#3 Updated by goggi - over 11 years ago

Is this not just bug in the setup from osgeo4w? We are both using that, preview 2 was just normal windows installer. Some DLL (old or too new version) or some settings that is going wrong in the install.

#4 Updated by ersts - over 11 years ago

Kind of. It is going to end up being a GDAL issue in the OSGeo4W dist as nothing changed in the raster code between the preview and the version 1. Still we would like to find out what the problem is and maybe let GDAL folks know, or the builders depending on what the problem turns out to actually be.

#5 Updated by goggi - over 11 years ago

One intresting fact. I was playing with and learning on some of the GDAL tools. I tryed to convert one of the jpg files to tiff. I get error: Corrupt JPEG data: premature end of data segment. So there is something wrong with the jpg file.

I opened the file in just paint in windows. Saved the file again with out doing anything. Then it works 100% in GDAL and Qgis. Boring thing is that I have 66 of those but I live :)

#6 Updated by goggi - over 11 years ago

ok, sorry about this but. No I am wrong, it dont work to open in paint then save again. (Worked for one file then never again) But I downloaded GDALWIN 1.6 from GDAL home page. Running there gdal_translate works. But if I use the version that came with OSGeo4W dont. So there has to be something wrong with GDAL setup like it is in the OSGeo$W version.

Sorry about two comments same evening but I realy hate not beeing able to use version 1.0.0 and always using preview :)

#7 Updated by ersts - over 11 years ago

Can you provide an example image that does not load properly?

jpegs seem to be loading on my OSGeo4W install just fine. If your jpeg loads fine for me then I can figure start to diagnose which extra lib needs to be installed/reinstalled.

#8 Updated by Frank Warmerdam - over 11 years ago

I have confirmed this is a GDAL problem - migrating the issue to:

http://trac.osgeo.org/gdal/ticket/2845

#9 Updated by ersts - over 11 years ago

  • Status changed from In Progress to Closed
  • Resolution set to fixed

Thanks Frank! I can confirm the updates work with your test image.

Folks having the problem: This should now be resolved. Please update your version of OSGeo4W by running setup again.

#10 Updated by Anonymous about 11 years ago

Milestone Version 1.0.2 deleted

Also available in: Atom PDF