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

[Etienne Tourigny]

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140510/fd68b0de/attachment.html>