Ticket #1523 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

GIMP JPEG error, Spaced World File error

Reported by: adam@ctech.com Assigned to: mloskot
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

world_file_reader.patch (1.8 kB) - added by adam@ctech.com on 03/16/07 14:56:08.
Worldfile with spaces fix, GIMP JPEG fix
image_test.jpg (0.8 kB) - added by adam@ctech.com on 03/16/07 14:57:06.
GIMP create JPEG
vickers_aerial.jgw (47 bytes) - added by adam@ctech.com on 03/16/07 14:58:37.
World file with blank lines

Change History

03/16/07 14:56:08 changed by adam@ctech.com

  • attachment world_file_reader.patch added.

Worldfile with spaces fix, GIMP JPEG fix

03/16/07 14:57:06 changed by adam@ctech.com

  • attachment image_test.jpg added.

GIMP create JPEG

03/16/07 14:58:37 changed by adam@ctech.com

  • attachment vickers_aerial.jgw added.

World file with blank lines

03/16/07 15:59:46 changed 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. 


03/25/07 20:22:45 changed by hobu

  • description changed.
  • milestone set to 1.4.1.

04/01/07 07:52:27 changed by mloskot

  • status changed from new to assigned.

04/01/07 12:00:24 changed by mloskot

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?

04/01/07 12:07:57 changed 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.

04/01/07 17:43:55 changed by warmerdam

  • description changed.

04/02/07 07:50:01 changed by mloskot

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?

04/02/07 16:56:38 changed by warmerdam

  • description changed.

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!

04/02/07 20:27:55 changed by mloskot

  • status changed from assigned to closed.
  • resolution set to fixed.

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

04/02/07 20:52:50 changed by warmerdam

  • status changed from closed to reopened.
  • resolution deleted.

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.

04/02/07 21:08:43 changed by mloskot

  • status changed from reopened to closed.
  • resolution set to fixed.

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