Opened 13 years ago

Closed 13 years ago

#1523 closed defect (fixed)

GIMP JPEG error, Spaced World File error

Reported by: adam@… Owned by: Mateusz Łoskot
Priority: normal Milestone: 1.4.1
Component: GDAL_Raster Version: 1.4.0
Severity: minor Keywords:
Cc:

Description (last modified by warmerdam)

JPEG files created from GIMP software seem to be created with Metadata that contain no entries, which reports an error. World files are starting to be created with spaces between the lines. The current version does not check for this.

Adam, can you confirm whether the intent was to just treat the files with blank lines as corrupt or to actually process them?

Attachments (3)

world_file_reader.patch (1.8 KB) - added by adam@… 13 years ago.
Worldfile with spaces fix, GIMP JPEG fix
image_test.jpg (805 bytes) - added by adam@… 13 years ago.
GIMP create JPEG
vickers_aerial.jgw (47 bytes) - added by adam@… 13 years ago.
World file with blank lines

Download all attachments as: .zip

Change History (14)

Changed 13 years ago by adam@…

Attachment: world_file_reader.patch added

Worldfile with spaces fix, GIMP JPEG fix

Changed 13 years ago by adam@…

Attachment: image_test.jpg added

GIMP create JPEG

Changed 13 years ago by adam@…

Attachment: vickers_aerial.jgw added

World file with blank lines

comment:1 Changed 13 years ago by warmerdam

I have confirmed, and applied the fix for jpeg exif files with no entries. 
The change is applied in trunk and 1.4 branch.

I have also written and comitted a new jpeg test script in autotest/gdrivers
that verifies some minimal operation of the jpeg driver.

I'm turning this over to Matuesz to deal with the blank-lines-in-world-files
issue. 

I feel the existing patch is not specific enough Mateusz.  I'd like it
adjusted to only assume blank lines if those lines have been confirmed
to be blank (not just zero valued).  So test that they consist of nothing
but white space type characters. 

The world file fixes should go into trunk and 1.4, and there should also
be a test added for this case in the test suite. 


comment:2 Changed 13 years ago by hobu

Description: modified (diff)
Milestone: 1.4.1

comment:3 Changed 13 years ago by Mateusz Łoskot

Status: newassigned

comment:4 Changed 13 years ago by Mateusz Łoskot

Frank, currently, the world file reader is a bit limited and only handles blank/non-blank lines occuring alternately in a file:

3.4

0

0

-3.4

2771374.7

334853.0

but I believe it should be blanksproof, and also handle more complex cases, like:


3.4

0

0

-3.4
2771374.7




334853.0

I propose to solve it this way:

1. Read all lines from a file

2. If lines count is > 5, rewrite the papszLines array removing all empty lines

3. Read transformation parameters from the new filtered array

What do you think?

comment:5 Changed 13 years ago by warmerdam

Mateusz,

I don't think we need, or even want to be this general. The alternating blank lines problem is apparently some particular bug in some generating program (perhaps relating to CRLF handling or something), and we are just trying to address that. Not support all malformed world files. And I specifically want to avoid doing a lot of extra processing or risk identifying files that are not world files as world files.

So, lets stick to the alternating problem for now.

comment:6 Changed 13 years ago by warmerdam

Description: modified (diff)

comment:7 Changed 13 years ago by Mateusz Łoskot

I have to say I feel lost, so I'd like to define exactly what we consider as a valid world file in GDAL.

According to World file definition on Wikipedia:

These world files are six-line files with decimal numbers on each line. 

From all stars on the sky, my understanding is that GDAL should scan first 6 lines of a world file and if there is any blank line in these first 6 lines, we consider this file as invalid.

Here is code representing assumptions from the statement above:

for( i = 0; i < 6; i++)
{
   CPLString line(papszLines[i]);
   if( line.Trim().empty() )
      bCorrupt = true; // Leave reading World file with error msg
}

Am I correct here?

comment:8 Changed 13 years ago by warmerdam

Description: modified (diff)

Assuming our goal is to treat the files with blanks as corrupt, this would be fine. To be careful to verify there are at least six lines before using the above loop!

comment:9 Changed 13 years ago by Mateusz Łoskot

Resolution: fixed
Status: assignedclosed

Fixed in trunk r11182 Backported to branches/1.4 (r11183)

comment:10 Changed 13 years ago by warmerdam

Resolution: fixed
Status: closedreopened

Mateusz,

It seems your patch for GDALReadWorldFile() removed the old condition that at least some particular lines had to have a non-zero value. Was that on purpose? I suspect you should restore the condition. Also, I'd like you to extend the test suite to check some of the new conditions.

comment:11 Changed 13 years ago by Mateusz Łoskot

Resolution: fixed
Status: reopenedclosed

I added missing tests of non-Zero parameters (r11185) and backported to branch 1.4. (r11186).

Note: See TracTickets for help on using tickets.