Le lundi 12 mai 2014 21:15:35, Etienne Tourigny a écrit : > Right, I didn't think of the need to create new EXIF tags. > > I think it is a good idea to use existing GTIFF tags to encode this > information. > > 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.
I think we could also embed a full geotiff box in PNG or GIF. For example with PNG, you can create a private chunk : http://www.libpng.org/pub/png/spec/1.1/PNG-Encoders.html#E.Private-type-and- method-codes. So we could have a "gtif" chunk and its payload would be the geotiffbox. And for GIF, we would have "\x21\xff\x0b\GTIFFBoxGTB" + geotiff_file as the payload ( http://www.w3.org/Graphics/GIF/spec-gif89a.txt - § 26) And the "usual" trick to terminate GIF application extensions, i.e. a funny decreasing sequence \xFF\xFE\...\x01 so that non aware readers can resynchronize. > > 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. Yes, that's one possibility. Which comes back to GMLJP2 unless there are other standards... I'd want to build on something that is a "real" standard or a de-facto standard, but not reinvent everything from scratch. > > [1] > http://en.wikipedia.org/wiki/Extensible_Metadata_Platform#Embedding_of_XMP > > > On Sat, May 10, 2014 at 6:49 PM, Even Rouault > > <even.roua...@mines-paris.org>wrote: > > 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 -- 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