[gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing

[Even Rouault]

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.rouault at 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 at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html