<div dir="ltr">Right, I didn't think of the need to create new EXIF tags. <div><br></div><div>I think it is a good idea to use existing GTIFF tags to encode this information.</div><div><br></div><div>On the other hand, the method used in jpeg files should ideally be the same used in other formats (e.g. png, gif) for which it is possible to add extra metadata.</div>
<div><br></div><div>In light of this, it may be better to use an xml or textual representation and embed it inside an XMP block, which is supported for many formats[1]. Also it would allow for easier human-reading.</div><div>
<br></div><div>[1] <a href="http://en.wikipedia.org/wiki/Extensible_Metadata_Platform#Embedding_of_XMP">http://en.wikipedia.org/wiki/Extensible_Metadata_Platform#Embedding_of_XMP</a><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, May 10, 2014 at 6:49 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">
Le samedi 10 mai 2014 23:31:30, Etienne Tourigny a écrit :<br>
<div class="">> Hi Even,<br>
><br>
> why not simply add the geotransform and WKT or PROJ.4 string as exif tags?<br>
> simple to read outside of gdal (any exif reader will support this) and<br>
> implement using libexif.<br>
<br>
</div>You would have to create new EXIF tags for that. The advantage of using<br>
GeoTIFF is that it is already standardized. And it has a few bonus, like<br>
ground control points.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> just my 2 cents.<br>
> Etienne<br>
><br>
><br>
> On Sat, May 10, 2014 at 5:21 PM, Even Rouault<br>
><br>
> <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>>wrote:<br>
> > Hi,<br>
> ><br>
> > I'm wondering if there's some interest in standardizing a way of<br>
> > embedding georeferencing information in popular image formats like JPEG<br>
> > or PNG.<br>
> ><br>
> > I've just been doing an experiment with JPEG. My solution is to use a<br>
> > 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"<br>
> > 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>
> ><br>
> >                                     size of {geotiff-file}. little-endian<br>
> ><br>
> > uint16<br>
> > GeoTIFFBox\0         <-- Signature (to distinguish from Exif, etc...)<br>
> > {geotiff-file}           <-- A GeoTIFF image of size 1x1 (cf § 2.2 Box<br>
> > 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<br>
> > GeoTIFFBox<br>
> > APP1 segment should be ignored gracefully by JPEG readers not aware of<br>
> > the 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<br>
> > <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>
> ><br>
> >     GEOGCS["NAD27",<br>
> ><br>
> >         DATUM["North_American_Datum_1927",<br>
> ><br>
> >             SPHEROID["Clarke 1866",6378206.4,294.9786982139006,<br>
> ><br>
> >                 AUTHORITY["EPSG","7008"]],<br>
> ><br>
> >             AUTHORITY["EPSG","6267"]],<br>
> ><br>
> >         PRIMEM["Greenwich",0],<br>
> >         UNIT["degree",0.0174532925199433],<br>
> >         AUTHORITY["EPSG","4267"]],<br>
> ><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>
> ><br>
> >         AUTHORITY["EPSG","9001"]],<br>
> ><br>
> >     AUTHORITY["EPSG","26711"]]<br>
> ><br>
> > Origin = (440720.000000000000000,3751320.000000000000000)<br>
> > Pixel Size = (60.000000000000000,-60.000000000000000)<br>
> ><br>
> > Metadata:<br>
> >   AREA_OR_POINT=Area<br>
> ><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>
> ><br>
> >   Image Structure Metadata:<br>
> >     COMPRESSION=JPEG<br>
> ><br>
> > There are many potential other solutions, like adding the GeoTIFF tags in<br>
> > a proper EXIF segment, since it is already a TIFF structure, but that<br>
> > would have<br>
> > made my implementation a bit harder, and I'm wondering how some EXIF<br>
> > readers<br>
> > would react when facing GeoTIFF tags. Another solution would be to use<br>
> > the heavy GMLJP2 specification (<br>
> > <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<br>
> > verbose<br>
> > which defeats the purpose of JPEG being a compressed format...<br>
> ><br>
> > Any opinion/interest ?<br>
> ><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>
> ><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>
<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>
</div></div></blockquote></div><br></div>