[OSGeo-Standards] Idea: GeoTIFF box in JPEG to add georeferencing
Even Rouault
even.rouault at mines-paris.org
Sat May 10 13:21:50 PDT 2014
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/standards/attachments/20140510/5923a5b1/attachment.jpg>
More information about the Standards
mailing list