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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
