<div dir="ltr">Hi Even,<div><br></div><div>why not simply add the geotransform and WKT or PROJ.4 string as exif tags? simple to read outside of gdal (any exif reader will support this) and implement using libexif.</div><div>
<br></div><div>just my 2 cents.</div><div>Etienne</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 10, 2014 at 5:21 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm wondering if there's some interest in standardizing a way of embedding<br>
georeferencing information in popular image formats like JPEG or PNG.<br>
<br>
I've just been doing an experiment with JPEG. My solution is to use a GeoTIFF<br>
box as specified in § 2.2 "Box contents" of<br>
<a href="http://www.lizardtech.com/download/geo/geotiff_box.txt" target="_blank">http://www.lizardtech.com/download/geo/geotiff_box.txt</a> , a.k.a GeoJP2 and<br>
heavily used to add georeferencing to JPEG2000 images.<br>
The GeoTIFF file is put in an JFIF APP1 segment with a "GeoTIFFBox\0" signature<br>
to begin the payload.<br>
<br>
So the structure is the following :<br>
<br>
\xFF \D8 <-- SOI marker (Start Of Image)<br>
[ Any optional JPEG segment ]<br>
<br>
\xFF \xE1 <-- APP1 marker<br>
Size <-- Number of byte of signature (11) +<br>
size of {geotiff-file}. little-endian uint16<br>
GeoTIFFBox\0 <-- Signature (to distinguish from Exif, etc...)<br>
{geotiff-file} <-- A GeoTIFF image of size 1x1 (cf § 2.2 Box contents)<br>
<br>
[ Any optional JPEG segment ]<br>
[ JPEG baseline segments ]<br>
\xFF \D9 <-- EOI marker (End Of Image)<br>
<br>
End of spec !<br>
<br>
Such a solution should have a good compatibility level, since the GeoTIFFBox<br>
APP1 segment should be ignored gracefully by JPEG readers not aware of the<br>
spec. My few tests with various readers would confirm that.<br>
<br>
A working implementation based on GDAL trunk can be found here :<br>
<a href="https://github.com/rouault/gdal2/tree/geotiffbox_in_jpeg" target="_blank">https://github.com/rouault/gdal2/tree/geotiffbox_in_jpeg</a><br>
<br>
The patch is :<br>
<a href="https://github.com/rouault/gdal2/compare/geotiffbox_in_jpeg" target="_blank">https://github.com/rouault/gdal2/compare/geotiffbox_in_jpeg</a><br>
<br>
Example of such a file attached to this email. Generated by :<br>
<br>
gdal_translate <a href="http://svn.osgeo.org/gdal/trunk/autotest/gcore/data/byte.tif" target="_blank">http://svn.osgeo.org/gdal/trunk/autotest/gcore/data/byte.tif</a><br>
byte.jpg -of jpeg<br>
<br>
And<br>
<br>
$ gdalinfo byte.jpg<br>
Driver: JPEG/JPEG JFIF<br>
Files: byte.jpg<br>
Size is 20, 20<br>
Coordinate System is:<br>
PROJCS["NAD27 / UTM zone 11N",<br>
GEOGCS["NAD27",<br>
DATUM["North_American_Datum_1927",<br>
SPHEROID["Clarke 1866",6378206.4,294.9786982139006,<br>
AUTHORITY["EPSG","7008"]],<br>
AUTHORITY["EPSG","6267"]],<br>
PRIMEM["Greenwich",0],<br>
UNIT["degree",0.0174532925199433],<br>
AUTHORITY["EPSG","4267"]],<br>
PROJECTION["Transverse_Mercator"],<br>
PARAMETER["latitude_of_origin",0],<br>
PARAMETER["central_meridian",-117],<br>
PARAMETER["scale_factor",0.9996],<br>
PARAMETER["false_easting",500000],<br>
PARAMETER["false_northing",0],<br>
UNIT["metre",1,<br>
AUTHORITY["EPSG","9001"]],<br>
AUTHORITY["EPSG","26711"]]<br>
Origin = (440720.000000000000000,3751320.000000000000000)<br>
Pixel Size = (60.000000000000000,-60.000000000000000)<br>
Metadata:<br>
AREA_OR_POINT=Area<br>
Corner Coordinates:<br>
Upper Left ( 440720.000, 3751320.000) (117d38'28.21"W, 33d54' 8.47"N)<br>
Lower Left ( 440720.000, 3750120.000) (117d38'27.92"W, 33d53'29.51"N)<br>
Upper Right ( 441920.000, 3751320.000) (117d37'41.48"W, 33d54' 8.71"N)<br>
Lower Right ( 441920.000, 3750120.000) (117d37'41.20"W, 33d53'29.75"N)<br>
Center ( 441320.000, 3750720.000) (117d38' 4.70"W, 33d53'49.11"N)<br>
Band 1 Block=20x1 Type=Byte, ColorInterp=Gray<br>
Image Structure Metadata:<br>
COMPRESSION=JPEG<br>
<br>
There are many potential other solutions, like adding the GeoTIFF tags in a<br>
proper EXIF segment, since it is already a TIFF structure, but that would have<br>
made my implementation a bit harder, and I'm wondering how some EXIF readers<br>
would react when facing GeoTIFF tags. Another solution would be to use the<br>
heavy GMLJP2 specification ( <a href="http://www.opengeospatial.org/standards/gmljp2" target="_blank">http://www.opengeospatial.org/standards/gmljp2</a> ),<br>
which is an OGC standard, but it is still evolving (<br>
<a href="http://www.opengeospatial.org/standards/requests/118" target="_blank">http://www.opengeospatial.org/standards/requests/118</a> ), and is rather verbose<br>
which defeats the purpose of JPEG being a compressed format...<br>
<br>
Any opinion/interest ?<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</font></span><br>_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br></blockquote></div><br></div>