Re: [gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
so which ones are remaining, following the clarification you mention below? Hi Peter, thanks for the clarifications. To be honest, my main reluctance to GML-based standards is that they are very rich, and thus difficult to understand and implement. A rather large chain of depending standards : GMLJP2 refers to GMLCov which refers to GML which refers to etc And generally there are many ways in GML to express the same thing, which makes it difficult to implement the reading part. I had some fun a few weeks ago with that with polygons : http://erouault.blogspot.fr/2014/04/gml- madness.html ... To come back to more concrete considerations, the axis order issue, as confirmed by Jukka, is something that we constantly have to face and have troubles to get right. Jukka, in his review of the new proposed GMLJP2 ( http://lists.opengeospatial.org/pipermail/requests/2014-March/000220.html ), also raised an interesting question about all the different forms of urn/uri that might be found to express SRS. Another related point is: how do you encode a SRS that is not in the EPSG database ? In GDAL's code related to generation of GMLJP2, I see that when we write a GMLJP2 with a SRS that is not linked to an EPSG code, we build a local GML definition of the SRS, put it in a CRSDictionary.gml JP2 box and link to it with gmljp2://xml/CRSDictionary.gml#ogrcrs1 in the GMLJP2 box. So, to use GMLCov in PNG/JPEG/etc... we would likely need both a GMLCov box and a CRS box. Not very convenient. And for fun, you'll find below in [1] how the proj.4 string +proj=utm +zone=36 +ellps=WGS84 is translated into GML... Another practical issue is that the current export/import code in GDAL from/into the GML definition is limited to Transverse Mercator and Lambert Conformal Conic. No fundamental reason that it couldn't be improved, but someone would have to do it. Besides, I'm not sure if many other software packages implement that GML definition of SRS either. For example, it looks like GeoTools doesn't : http://osgeo-org.1560.x6.nabble.com/Parsing-GML-CRS-definitions-td4963620.html I agree with Frank that it is difficult to get excited by GeoTIFF either. The main advantages I can see is that : * it is already rather well supported by most geo-enabled software due to its long existence and maturity. So basing something on it shouldn't involve a lot of work. * its binary form makes it rather compact, which is good for example if you want to add georeferencing to small PNG/JPEG tiles. Best regards, Even [1] gml:ProjectedCRS gml:id=ogrcrs1 gml:srsNameUTM Zone 36, Northern Hemisphere/gml:srsName gml:baseCRS gml:GeographicCRS gml:id=ogrcrs2 gml:srsNameWGS 84/gml:srsName gml:usesEllipsoidalCS gml:EllipsoidalCS gml:id=ogrcrs3 gml:csNameellipsoidal/gml:csName gml:csID gml:name gml:codeSpace=urn:ogc:def:cs:EPSG::6402/gml:name /gml:csID gml:usesAxis gml:CoordinateSystemAxis gml:id=ogrcrs4 gml:uom=urn:ogc:def:uom:EPSG::9102 gml:nameGeodetic latitude/gml:name gml:axisID gml:name gml:codeSpace=urn:ogc:def:axis:EPSG::9901/gml:name /gml:axisID gml:axisAbbrevLat/gml:axisAbbrev gml:axisDirectionnorth/gml:axisDirection /gml:CoordinateSystemAxis /gml:usesAxis gml:usesAxis gml:CoordinateSystemAxis gml:id=ogrcrs5 gml:uom=urn:ogc:def:uom:EPSG::9102 gml:nameGeodetic longitude/gml:name gml:axisID gml:name gml:codeSpace=urn:ogc:def:axis:EPSG::9902/gml:name /gml:axisID gml:axisAbbrevLon/gml:axisAbbrev gml:axisDirectioneast/gml:axisDirection /gml:CoordinateSystemAxis /gml:usesAxis /gml:EllipsoidalCS /gml:usesEllipsoidalCS gml:usesGeodeticDatum gml:GeodeticDatum gml:id=ogrcrs6 gml:datumNameunknown/gml:datumName gml:usesPrimeMeridian gml:PrimeMeridian gml:id=ogrcrs7 gml:meridianNameGreenwich/gml:meridianName gml:greenwichLongitude gml:angle gml:uom=urn:ogc:def:uom:EPSG::91020/gml:angle /gml:greenwichLongitude /gml:PrimeMeridian /gml:usesPrimeMeridian gml:usesEllipsoid gml:Ellipsoid gml:id=ogrcrs8 gml:ellipsoidNameWGS84/gml:ellipsoidName gml:semiMajorAxis gml:uom=urn:ogc:def:uom:EPSG::90016378137/gml:semiMajorAxis gml:secondDefiningParameter gml:inverseFlattening gml:uom=urn:ogc:def:uom:EPSG::9201298.257223563/gml:inverseFlattening /gml:secondDefiningParameter /gml:Ellipsoid /gml:usesEllipsoid /gml:GeodeticDatum /gml:usesGeodeticDatum /gml:GeographicCRS /gml:baseCRS gml:definedByConversion gml:Conversion gml:id=ogrcrs9
Re: [gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
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.roua...@mines-paris.orgwrote:
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.orgwrote:
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,50],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AUTHORITY[EPSG,26711]]
Origin = (440720.000,3751320.000)
Pixel Size = (60.000,-60.000)
Metadata:
AREA_OR_POINT=Area
Corner Coordinates:
Upper Left ( 440720.000, 3751320.000) (117d38'28.21W, 33d54' 8.47N)
Lower Left ( 440720.000, 3750120.000) (117d38'27.92W, 33d53'29.51N)
Upper Right ( 441920.000, 3751320.000) (117d37'41.48W, 33d54' 8.71N)
Lower Right ( 441920.000, 3750120.000) (117d37'41.20W, 33d53'29.75N)
Center ( 441320.000, 3750720.000) (117d38' 4.70W, 33d53'49.11N)
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 (
Re: [gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
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.orgwrote:
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.orgwrote:
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,50],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AUTHORITY[EPSG,26711]]
Origin = (440720.000,3751320.000)
Re: [gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
PS: not sure all on this list are aware of this overview page: http://external.opengeospatial.org/twiki_public/CoveragesDWG/CoveragesBigPicture -Peter On 05/12/2014 11:38 PM, Peter Baumann wrote: Hi all, just saw this, thought I'd chime in being the editor of GMLCOV :) Any questions, I'll gladly try to answer, I'm just on the road currently, so expect a delay of a day or so. Trying to respond to what has been raised below: On 05/12/2014 11:18 PM, Even Rouault wrote: Le lundi 12 mai 2014 23:05:21, Jukka Rahkonen a écrit : Even Rouault even.rouault at mines-paris.org writes: ... 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. What GMLJP2 gives as a bonus is the axis order trouble actually, no. GMLJP2 relies on GMLCOV which defines axis order. Each coverage has a Native CRS which is defined via an OGC URI (which, in the case of EPSG, refers to the OGP maintained database). In the CRS definition the axis is given unambiguously. If you don't want to go to that database, use the axisLabels attribute in the Envelope, it lists axes in their proper sequence. and not totally clear interpretation if origin is in the centre (probably it is) or in the corner of a pixel, naively, GMLCOV follows the pixel-in center interpretation. However, encodings may override this, such as GeoTIFF (see the pertaining adopted spec [1]). [1] https://portal.opengeospatial.org/files/?artifact_id=50118 and rectified grid does not support ground control points. yes, because it is rectified. If you want more degree of freedom do not use RectifiedGridCoverage but ReferenceableGridCoverage. In conjunction with GML 3.3 ( a compatible enhancement of GML 3.2.1) this gives you irregular and warped grids. We're not completely done, though, and would be glad about your support in some advanced issues. Note that this work is all voluntary and relies on some project financing to be done. Up to now, EC and ESA have been generous, and so we are going ahead step by step. Thus GMLJP2 is at least not better in everything, it has also drawbacks. Hi Jukka, Yes, for all your above reasons, I would prefer to avoid it. so which ones are remaining, following the clarification you mention below? cheers, Peter Although the axis order trouble (the one of EPSG) and interpretation of origin (pixel center) should be mostly clarified with the revised version. As far as ground countrol points are concerned, I've not really looked at the capabilities of GMLCov, so perhaps there's something in it for that. Otherwise, that would be indeed a drawback. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
Hi, This is just a small detail and I may be wrong, but I fear that axisLabels element does not universally remove the need to go to the database because there are systems which use X and Y as axis names, but the meaning of X and Y can be different. For example for EPSG:3857 X means Easting but for the old Finnish KKJ is means Northing. I can also be wrong in saying the X is an axis name because in the following EPSG reports the names seem to be Easting and Northing and X and Y are abbreviations. However, by looking at the EPSG:3857 example from the package https://portal.opengeospatial.org/files/?artifact_id=50118 just the ambiguous abbreviations are used as axisLabels. gml:axisLabelsx y/gml:axisLabels Am I right or am I wrong? http://epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::2393reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=Finnish%20KKJ http://epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3857reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3857 Regards, -Jukka Rahkonen- Peter Baumann wrote: Hi all, just saw this, thought I'd chime in being the editor of GMLCOV :) Any questions, I'll gladly try to answer, I'm just on the road currently, so expect a delay of a day or so. Trying to respond to what has been raised below: On 05/12/2014 11:18 PM, Even Rouault wrote: Le lundi 12 mai 2014 23:05:21, Jukka Rahkonen a écrit : Even Rouault even.rouault at mines-paris.org writes: ... 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. What GMLJP2 gives as a bonus is the axis order trouble actually, no. GMLJP2 relies on GMLCOV which defines axis order. Each coverage has a Native CRS which is defined via an OGC URI (which, in the case of EPSG, refers to the OGP maintained database). In the CRS definition the axis is given unambiguously. If you don't want to go to that database, use the axisLabels attribute in the Envelope, it lists axes in their proper sequence. and not totally clear interpretation if origin is in the centre (probably it is) or in the corner of a pixel, naively, GMLCOV follows the pixel-in center interpretation. However, encodings may override this, such as GeoTIFF (see the pertaining adopted spec [1]). [1] https://portal.opengeospatial.org/files/?artifact_id=50118 and rectified grid does not support ground control points. yes, because it is rectified. If you want more degree of freedom do not use RectifiedGridCoverage but ReferenceableGridCoverage. In conjunction with GML 3.3 ( a compatible enhancement of GML 3.2.1) this gives you irregular and warped grids. We're not completely done, though, and would be glad about your support in some advanced issues. Note that this work is all voluntary and relies on some project financing to be done. Up to now, EC and ESA have been generous, and so we are going ahead step by step. Thus GMLJP2 is at least not better in everything, it has also drawbacks. Hi Jukka, Yes, for all your above reasons, I would prefer to avoid it. so which ones are remaining, following the clarification you mention below? cheers, Peter Although the axis order trouble (the one of EPSG) and interpretation of origin (pixel center) should be mostly clarified with the revised version. As far as ground countrol points are concerned, I've not really looked at the capabilities of GMLCov, so perhaps there's something in it for that. Otherwise, that would be indeed a drawback. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
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,50],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AUTHORITY[EPSG,26711]]
Origin = (440720.000,3751320.000)
Pixel Size = (60.000,-60.000)
Metadata:
AREA_OR_POINT=Area
Corner Coordinates:
Upper Left ( 440720.000, 3751320.000) (117d38'28.21W, 33d54' 8.47N)
Lower Left ( 440720.000, 3750120.000) (117d38'27.92W, 33d53'29.51N)
Upper Right ( 441920.000, 3751320.000) (117d37'41.48W, 33d54' 8.71N)
Lower Right ( 441920.000, 3750120.000) (117d37'41.20W, 33d53'29.75N)
Center ( 441320.000, 3750720.000) (117d38' 4.70W, 33d53'49.11N)
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
Re: [gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
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.roua...@mines-paris.orgwrote:
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,50],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AUTHORITY[EPSG,26711]]
Origin = (440720.000,3751320.000)
Pixel Size = (60.000,-60.000)
Metadata:
AREA_OR_POINT=Area
Corner Coordinates:
Upper Left ( 440720.000, 3751320.000) (117d38'28.21W, 33d54' 8.47N)
Lower Left ( 440720.000, 3750120.000) (117d38'27.92W, 33d53'29.51N)
Upper Right ( 441920.000, 3751320.000) (117d37'41.48W, 33d54' 8.71N)
Lower Right ( 441920.000, 3750120.000) (117d37'41.20W, 33d53'29.75N)
Center ( 441320.000, 3750720.000) (117d38' 4.70W, 33d53'49.11N)
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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing
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.orgwrote:
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,50],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AUTHORITY[EPSG,26711]]
Origin = (440720.000,3751320.000)
Pixel Size = (60.000,-60.000)
Metadata:
AREA_OR_POINT=Area
Corner Coordinates:
Upper Left ( 440720.000, 3751320.000) (117d38'28.21W, 33d54' 8.47N)
Lower Left ( 440720.000, 3750120.000) (117d38'27.92W, 33d53'29.51N)
Upper Right ( 441920.000, 3751320.000) (117d37'41.48W, 33d54' 8.71N)
Lower Right ( 441920.000, 3750120.000) (117d37'41.20W, 33d53'29.75N)
Center ( 441320.000, 3750720.000) (117d38' 4.70W, 33d53'49.11N)
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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
