[gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing

[Even Rouault]

Hi,

I'm wondering if there's some interest in standardizing a way of embedding 
georeferencing information in popular image formats like JPEG or PNG.

I've just been doing an experiment with JPEG. My solution is to use a GeoTIFF 
box as specified in § 2.2 "Box contents" of 
http://www.lizardtech.com/download/geo/geotiff_box.txt , a.k.a GeoJP2 and 
heavily used to add georeferencing to JPEG2000 images.
The GeoTIFF file is put in an JFIF APP1 segment with a "GeoTIFFBox\0" signature 
to begin the payload.

So the structure is the following :

\xFF \D8                  <-- SOI marker (Start Of Image)
[ Any optional JPEG segment ]	

\xFF \xE1                <-- APP1 marker
Size                        <-- Number of byte of signature (11) +
                                    size of {geotiff-file}. little-endian uint16
GeoTIFFBox\0         <-- Signature (to distinguish from Exif, etc...)
{geotiff-file}           <-- A GeoTIFF image of size 1x1 (cf § 2.2 Box contents)

[  Any optional JPEG segment ]	
[  JPEG baseline segments ]
\xFF \D9                 <-- EOI marker (End Of Image)

End of spec !

Such a solution should have a good compatibility level, since the GeoTIFFBox 
APP1 segment should be ignored gracefully by JPEG readers not aware of the 
spec. My few tests with various readers would confirm that.

A working implementation based on GDAL trunk can be found here : 
https://github.com/rouault/gdal2/tree/geotiffbox_in_jpeg

The patch is :
https://github.com/rouault/gdal2/compare/geotiffbox_in_jpeg

Example of such a file attached to this email. Generated by :

gdal_translate http://svn.osgeo.org/gdal/trunk/autotest/gcore/data/byte.tif 
byte.jpg -of jpeg

And

$ gdalinfo byte.jpg
Driver: JPEG/JPEG JFIF
Files: byte.jpg
Size is 20, 20
Coordinate System is:
PROJCS["NAD27 / UTM zone 11N",
    GEOGCS["NAD27",
        DATUM["North_American_Datum_1927",
            SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
                AUTHORITY["EPSG","7008"]],
            AUTHORITY["EPSG","6267"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4267"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-117],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","26711"]]
Origin = (440720.000000000000000,3751320.000000000000000)
Pixel Size = (60.000000000000000,-60.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Corner Coordinates:
Upper Left  (  440720.000, 3751320.000) (117d38'28.21"W, 33d54' 8.47"N)
Lower Left  (  440720.000, 3750120.000) (117d38'27.92"W, 33d53'29.51"N)
Upper Right (  441920.000, 3751320.000) (117d37'41.48"W, 33d54' 8.71"N)
Lower Right (  441920.000, 3750120.000) (117d37'41.20"W, 33d53'29.75"N)
Center      (  441320.000, 3750720.000) (117d38' 4.70"W, 33d53'49.11"N)
Band 1 Block=20x1 Type=Byte, ColorInterp=Gray
  Image Structure Metadata:
    COMPRESSION=JPEG

There are many potential other solutions, like adding the GeoTIFF tags in a 
proper EXIF segment, since it is already a TIFF structure, but that would have 
made my implementation a bit harder, and I'm wondering how some EXIF readers 
would react when facing GeoTIFF tags. Another solution would be to use the 
heavy GMLJP2 specification ( http://www.opengeospatial.org/standards/gmljp2 ), 
which is an OGC standard, but it is still evolving ( 
http://www.opengeospatial.org/standards/requests/118 ), and is rather verbose 
which defeats the purpose of JPEG being a compressed format...

Any opinion/interest ?

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: byte.jpg
Type: image/jpeg
Size: 857 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140510/5923a5b1/attachment.jpg>