Le samedi 10 mai 2014 23:31:30, Etienne Tourigny a écrit : > Hi Even, > > 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.
You would have to create new EXIF tags for that. The advantage of using GeoTIFF is that it is already standardized. And it has a few bonus, like ground control points. > > just my 2 cents. > Etienne > > > On Sat, May 10, 2014 at 5:21 PM, Even Rouault > > <even.roua...@mines-paris.org>wrote: > > 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 -- 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