Hi, The GML way to georeference JPEG2000 images is really an OGC standard. It it rather close to the GeoJP2 system which means practically inserting geotiff tags inside JPEG2000 file. GeoJP2 has a proprietary history, one company invented it but after some legal struggle the company behind MrSID bought it away and then we had the MrSID-JPEG2000. GeoJP2 taggins system is free enough for GDAL to insert by default both them and the OGC style GML georeferencing information inside the JPEG2000 files it creates. And of course ESRI style world files (.j2w) can be used or all the other various systems based on external georeferencing like MapInfo .tab, some xml files etc. For my mind the problem with JPEG2000 is not georeferencing.
I do not conseder that the patents or licenses of the format itself are preventing open source use. There are patented parts in the standard but those companies involved have announced that they will not defence their patents when they are utilised for JPEG2000. The real hinder in using JPEG2000 is that there has not been any free JPEG2000 library which is good and fast enough for serious geospatial work. Very different case than with libtiff. Jasper has been there from the very beginning and there is Open JPEG and for sure others too. They have been very slow compared with commercial SDKs like Kakadu, ECW JPEG 2000, MrSID-JPEG2000, Pegasos and Lurawave. There are some others on the medical imagery side but I have not played with them. Perhaps there are special SDKs for digital cinema and Motion JPEG2000 too. If someone gets interested in JPEG2000 I would suggest using the very good Kakadu executables (kdu_compress, kdu_expand, kdu_show etc.) first because they show how really fast and fine JPEG2000 can be. There are slow and crappy applications around but it is not due to file format itself. The crappy ones often just read the whole image into memory before doing anything else and while it works with digital camera images it will not work with multigigabyte multichannel satellite images. Geojasper is worth having a try for creating geospatial JPEG2000 images. Kdu_compress can be used too, and is recommended to use for seeing something good in action to compare other systems with, but it is allowed only for personal use. And ECW JPEG 2000 SDK 3.3 can be used for compression too, for sure safely up till 500 MB original image size and for example FWTools 2.4.7 includes the driver. ECW JPEG 2000 SDK based viewers (like OpenJUMP) are rather good for viewing JPEG2000. Kakadu based clients may be faster but there are not many available for GIS use. IAS viewer that was developed originally by the Kodak space imaging division, which was bought later by ITT, was half way to that direction, but nowadays there seems to be only the Jave Web Start on-line version available at http://iasdemo.ittvis.com/iasdemo/ When it comes to open source and JPEG2000, perhaps Open JPEG is the one that begins to be good enough. GDAL has a support for that but because it is not included be default I have not tried it yet. -Jukka Rahkonen- ________________________________________ Lähettäjä: edgar.sol...@web.de [edgar.sol...@web.de] Lähetetty: 8. lokakuuta 2011 0:32 Vastaanottaja: OpenJump develop and use Aihe: [JPP-Devel] Fwd: jpeg2000 seems like the jp2 georeferencing is an ogc standard http://en.wikipedia.org/wiki/JPEG_2000#GML_JP2_Georeferencing ..ede On 07.10.2011 22:46, Michaël Michaud wrote: > I would say open standard like wkt, gml or jp2 must be as far as i understand is the jp2 standard documented openly but still patented by the members of the the jpeg group. they decided to make the Part 1, Core coding system (intended as royalty and license-fee free - NB NOT patent-free) available for free. see http://www.jpeg.org/jpeg2000/ http://en.wikipedia.org/wiki/JPEG_2000#Legal_issues so there are two issues here: 1. i can't find a license that assures that the Part1 stays free forever 2. all other parts have to be licensed by the jpeg group, speak to be paid for and i'd really like to know if the georeferencing in jp2 is covered by Part1. i doubt that. i think the jpeg group themselves has their part in the missing success. > native datasources for openJUMP whilst close format like ecw must just > be made possible (if possible). I cannot imagine that the wide > adoption of > ecw is not related to the slow adoption of jp2. funny enough is the ecw sdk the only way to open jp2 files for us now ;) ..ede ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel