GIMP JPEG error, Spaced World File error

[adam@…]

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?

[adam@…]

Worldfile with spaces fix, GIMP JPEG fix

[adam@…]

GIMP create JPEG

[adam@…]

World file with blank lines

[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. 

[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?

[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.

[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?

[warmerdam]

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!

[Mateusz Łoskot]

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

[warmerdam]

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.

[Mateusz Łoskot]

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