GeoTIFF within JP2
|
|
David Smiley (@MITRE.org)
|
I have Jpeg2000 images with GeoTIFF headers in them. I've been monkeying with the JAI ImageIO library which has Jpeg2000 support to get at the UUID metadata box and then using the data there to get the TIFF image which contains the right metadata. I noticed that in Geotools there is a "jp2kak" module but it is based on Kakadu (non-Java native code), not Sun's pure-Java implementation available here: https://jai-imageio.dev.java.net/. Can someone tell me what the status of this geotools module is and why it uses Kakadu instead of Sun's code?
By the way, I did have to use Sun's latest 1.2 from source control because there was a bug fix in there that is not in 1.1 resulting in NPEs. ~ David Smiley MITRE |
Simone Giannecchini
|
Ciao David,
please read below... ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Wed, Oct 14, 2009 at 8:10 PM, dsmiley <[hidden email]> wrote: > > I have Jpeg2000 images with GeoTIFF headers in them. I've been monkeying > with the JAI ImageIO library which has Jpeg2000 support to get at the UUID > metadata box and then using the data there to get the TIFF image which > contains the right metadata. You are talking about geojp2 right? > I noticed that in Geotools there is a "jp2kak" > module but it is based on Kakadu (non-Java native code), not Sun's pure-Java > implementation available here: https://jai-imageio.dev.java.net/. We have worked a lot in the past with the JPEG2000 support in Imageio and we found that for large imagey it was not suitable. Therefore we decided to use kakadu. Notice that Imageio include JJ2000 (pure java) as well as a wrapper around Japser (c code). > Can > someone tell me what the status of this geotools module is and why it uses > Kakadu instead of Sun's code? The module is not finished yet, it still needs some work to be completed as well as some extensive testing. You interested in helping out? Beside we could make the code configurabel so that we can use also the pure java JJ2000 implementation, even though that is going be inefficient on large raster data (if my memory serves me right, it does implement the ability to use decomposition levels) Simone. > > By the way, I did have to use Sun's latest 1.2 from source control because > there was a bug fix in there that is not in 1.1 resulting in NPEs. > > ~ David Smiley > MITRE > -- > View this message in context: http://n2.nabble.com/GeoTIFF-within-JP2-tp3824530p3824530.html > Sent from the geotools-gt2-users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Geotools-gt2-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Geotools-gt2-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users |
||||||||||||||||
|
David Smiley (@MITRE.org)
|
On Oct 15, 2009, at 6:41 AM, Simone Giannecchini wrote: > ... > On Wed, Oct 14, 2009 at 8:10 PM, dsmiley <[hidden email]> wrote: >> >> I have Jpeg2000 images with GeoTIFF headers in them. I've been >> monkeying >> with the JAI ImageIO library which has Jpeg2000 support to get at >> the UUID >> metadata box and then using the data there to get the TIFF image >> which >> contains the right metadata. > > You are talking about geojp2 right? I am referring to this specification: http://www.lizardtech.com/support/kb/docs/geotiff_box.txt And according to this spec, the trademark "geojp2" should not be used. > >> I noticed that in Geotools there is a "jp2kak" >> module but it is based on Kakadu (non-Java native code), not Sun's >> pure-Java >> implementation available here: https://jai-imageio.dev.java.net/. > > We have worked a lot in the past with the JPEG2000 support in Imageio > and we found that for large imagey it was not suitable. Therefore we > decided to use kakadu. > Notice that Imageio include JJ2000 (pure java) as well as a wrapper > around Japser (c code). In my case I only have basic needs of the JP2/GeoTiff file to determine where on the earth the image is. Ultimately I want a lat/ lon box and as I write this I'm not certain how to do it. I don't even need to render the image. >> Can >> someone tell me what the status of this geotools module is and why >> it uses >> Kakadu instead of Sun's code? > > The module is not finished yet, it still needs some work to be > completed as well as some extensive testing. You interested in helping > out? > > Beside we could make the code configurabel so that we can use also the > pure java JJ2000 implementation, even though that is going be > inefficient on large raster data (if my memory serves me right, it > does implement the ability to use decomposition levels) > > Simone. I am interested in helping out but there are caveats: 1. I have very little experience with the geo-spatial field. 2. Anything I contribute back would first need to be cleared through copyright/IP with my employer (MITRE). 3. I don't have a lot of time. I am inclined to attempt to make jp2kakadu work without Kakadu... or perhaps make the geotiff module work with jp2, not just tiff. Ideally the Kakadu implementation would plug in via totally standard JAI ImageIO APIs. But JP2KReader explicitly depends on Kakadu. I don't see that as necessary since the UUID data can be extracted without it. It's in the IIOMetadata tree. ImageIO specifies what the structure is for JP2s: http://download.java.net/media/jai-imageio/javadoc/1.1/index.html imageio-ext-kakadu should use the same element names, IMO. ~ David ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Geotools-gt2-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users |
||||||||||||||||
|
Simone Giannecchini
|
Ciao David,
late answer, but I have been traveling for a while. PLease, see below... ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Thu, Oct 15, 2009 at 6:46 PM, Smiley, David W. <[hidden email]> wrote: > > On Oct 15, 2009, at 6:41 AM, Simone Giannecchini wrote: >> ... >> On Wed, Oct 14, 2009 at 8:10 PM, dsmiley <[hidden email]> wrote: >>> >>> I have Jpeg2000 images with GeoTIFF headers in them. I've been >>> monkeying >>> with the JAI ImageIO library which has Jpeg2000 support to get at >>> the UUID >>> metadata box and then using the data there to get the TIFF image >>> which >>> contains the right metadata. >> >> You are talking about geojp2 right? > > I am referring to this specification: > http://www.lizardtech.com/support/kb/docs/geotiff_box.txt > And according to this spec, the trademark "geojp2" should not be used. > cool >> >>> I noticed that in Geotools there is a "jp2kak" >>> module but it is based on Kakadu (non-Java native code), not Sun's >>> pure-Java >>> implementation available here: https://jai-imageio.dev.java.net/. >> >> We have worked a lot in the past with the JPEG2000 support in Imageio >> and we found that for large imagey it was not suitable. Therefore we >> decided to use kakadu. >> Notice that Imageio include JJ2000 (pure java) as well as a wrapper >> around Japser (c code). > > In my case I only have basic needs of the JP2/GeoTiff file to > determine where on the earth the image is. Ultimately I want a lat/ > lon box and as I write this I'm not certain how to do it. I don't > even need to render the image. > >>> Can >>> someone tell me what the status of this geotools module is and why >>> it uses >>> Kakadu instead of Sun's code? >> >> The module is not finished yet, it still needs some work to be >> completed as well as some extensive testing. You interested in helping >> out? >> >> Beside we could make the code configurabel so that we can use also the >> pure java JJ2000 implementation, even though that is going be >> inefficient on large raster data (if my memory serves me right, it >> does implement the ability to use decomposition levels) >> >> Simone. > > I am interested in helping out but there are caveats: > 1. I have very little experience with the geo-spatial field. > 2. Anything I contribute back would first need to be cleared through > copyright/IP with my employer (MITRE). > 3. I don't have a lot of time. > > I am inclined to attempt to make jp2kakadu work without Kakadu... or > perhaps make the geotiff module work with jp2, not just tiff. Ideally > the Kakadu implementation would plug in via totally standard JAI > ImageIO APIs. But JP2KReader explicitly depends on Kakadu. I don't > see that as necessary since the UUID data can be extracted without > it. It's in the IIOMetadata tree. ImageIO specifies what the > structure is for JP2s: http://download.java.net/media/jai-imageio/javadoc/1.1/index.html > imageio-ext-kakadu should use the same element names, IMO. Imageio-ext-kakadu uses IIOmetada to transfer JP2/JPX boxes but rely on kakadu to load them. Anyway, looking at the geotools kakadu plugin that Daniele (cced) is creating on gt trunk right now, creating a similar plugin which would use the ImageIO reader/writer should be quite straightforward. That would easily allow you to extract the bbox from jp2 images without using kakadu. In principle it would also be possible to make the gt plugin that daniele is making generic in a way that it could draw from whatever jp2 plugin that we have at the imageio level; what do you suggest daniele? Simone. > > ~ David > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geotools-gt2-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users |
||||||||||||||||
|
David Smiley (@MITRE.org)
|
By the way, I have since in fact modified jp2kakadu to use the pure Java ImageIO codec implementation (com.sun....) and it works. It was about 170 lines of added/changed code. I figured out the code I needed to get the lat/lon box which is in another email thread on this list. I'm working to resolve copyright/IP issues where I work (MITRE) to ensure I can share this openly.
~ David Smiley On Nov 11, 2009, at 6:50 PM, Simone Giannecchini wrote: >> >> I am interested in helping out but there are caveats: >> 1. I have very little experience with the geo-spatial field. >> 2. Anything I contribute back would first need to be cleared through >> copyright/IP with my employer (MITRE). >> 3. I don't have a lot of time. >> >> I am inclined to attempt to make jp2kakadu work without Kakadu... or >> perhaps make the geotiff module work with jp2, not just tiff. Ideally >> the Kakadu implementation would plug in via totally standard JAI >> ImageIO APIs. But JP2KReader explicitly depends on Kakadu. I don't >> see that as necessary since the UUID data can be extracted without >> it. It's in the IIOMetadata tree. ImageIO specifies what the >> structure is for JP2s: http://download.java.net/media/jai-imageio/javadoc/1.1/index.html >> imageio-ext-kakadu should use the same element names, IMO. > > Imageio-ext-kakadu uses IIOmetada to transfer JP2/JPX boxes but rely > on kakadu to load them. > Anyway, looking at the geotools kakadu plugin that Daniele (cced) is > creating on gt trunk right now, creating a similar plugin which would > use the ImageIO reader/writer should be quite straightforward. That > would easily allow you to extract the bbox from jp2 images without > using kakadu. In principle it would also be possible to make the gt > plugin that daniele is making generic in a way that it could draw from > whatever jp2 plugin that we have at the imageio level; what do you > suggest daniele? ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geotools-gt2-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users |
||||||||||||||||
|
Simone Giannecchini
|
Ciao David,
if/when you will sort out your copyright/IP issues we will be hapy to try and include your code. Ciao, Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Thu, Nov 12, 2009 at 2:23 PM, Smiley, David W. <[hidden email]> wrote: > By the way, I have since in fact modified jp2kakadu to use the pure Java ImageIO codec implementation (com.sun....) and it works. It was about 170 lines of added/changed code. I figured out the code I needed to get the lat/lon box which is in another email thread on this list. I'm working to resolve copyright/IP issues where I work (MITRE) to ensure I can share this openly. > > ~ David Smiley > > On Nov 11, 2009, at 6:50 PM, Simone Giannecchini wrote: > >>> >>> I am interested in helping out but there are caveats: >>> 1. I have very little experience with the geo-spatial field. >>> 2. Anything I contribute back would first need to be cleared through >>> copyright/IP with my employer (MITRE). >>> 3. I don't have a lot of time. >>> >>> I am inclined to attempt to make jp2kakadu work without Kakadu... or >>> perhaps make the geotiff module work with jp2, not just tiff. Ideally >>> the Kakadu implementation would plug in via totally standard JAI >>> ImageIO APIs. But JP2KReader explicitly depends on Kakadu. I don't >>> see that as necessary since the UUID data can be extracted without >>> it. It's in the IIOMetadata tree. ImageIO specifies what the >>> structure is for JP2s: http://download.java.net/media/jai-imageio/javadoc/1.1/index.html >>> imageio-ext-kakadu should use the same element names, IMO. >> >> Imageio-ext-kakadu uses IIOmetada to transfer JP2/JPX boxes but rely >> on kakadu to load them. >> Anyway, looking at the geotools kakadu plugin that Daniele (cced) is >> creating on gt trunk right now, creating a similar plugin which would >> use the ImageIO reader/writer should be quite straightforward. That >> would easily allow you to extract the bbox from jp2 images without >> using kakadu. In principle it would also be possible to make the gt >> plugin that daniele is making generic in a way that it could draw from >> whatever jp2 plugin that we have at the imageio level; what do you >> suggest daniele? > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geotools-gt2-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
