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

Even Rouault even.rouault at mines-paris.org
Mon May 12 12:59:31 PDT 2014 

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.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

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

More information about the Standards mailing list