[gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
Etienne Tourigny
etourigny.dev at gmail.com
Mon May 12 12:15:35 PDT 2014
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.
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.
[1]
http://en.wikipedia.org/wiki/Extensible_Metadata_Platform#Embedding_of_XMP
On Sat, May 10, 2014 at 6:49 PM, Even Rouault
<even.rouault at 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.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140512/62a8a343/attachment.html>
More information about the gdal-dev
mailing list