Reading individual tiles

[praveen.b...@gmail.com]

Hi all,

I am writing an image loader that needs to support JPEG2000, for which
I am using OpenJPEG's new 1.3 release. I am able to load basic images
using the j2k_to_image example program as a template. However, I am
having issues with images with multiple tiles, e.g. p0_10.j2k in the
following link has 4 tiles in a 2x2 layout
http://www.gwg.nga.mil/ntb/baseline/software/testfile/Jpeg2000/profile0.htm.

My loader needs to load extremely large images and the interface
supports loading individual tiles. I looked into the libopenjpeg
source code a bit but could not find any easy way to do this.
j2k_to_image (which internally invokes opj_decode routine) handles
this image correctly and debug messages indicate that it is doing the
right thing internally -

[INFO] tile 1 of 4
[INFO] - tiers-1 took 0.003000 s
[INFO] - dwt took 0.001000 s
[INFO] - tile decoded in 0.005000 s
[INFO] tile 2 of 4
[INFO] - tiers-1 took 0.003999 s
[INFO] - dwt took 0.000000 s
[INFO] - tile decoded in 0.003999 s
[INFO] tile 3 of 4
[INFO] - tiers-1 took 0.004000 s
[INFO] - dwt took 0.000000 s
[INFO] - tile decoded in 0.004000 s
[INFO] tile 4 of 4
[INFO] - tiers-1 took 0.003999 s
[INFO] - dwt took 0.000000 s
[INFO] - tile decoded in 0.004999 s

Here's what I am doing right now -

- Get the tiling information by reading first 64KB bytes into a buffer
(not sure if this is correct), setting cp_limit_decoding to
DECODE_ALL_BUT_PACKETS and calling opj_decode. The tiling information
is available in j2k->tile_len[] and j2k->cp->tileno_size.
- To read the individual tile, I make a second call to opj_decode
(with the default flags this time). I assume that j2k->tile_len[] is
the buffer sizes for each compressed tile. When I read j2k-
>tile_len[0] bytes and pass that buffer to opj_decode, I get the
following error -
Error: [J2K ERROR] read error: passed the end of the codestream (start
= 5430272, current = 5433740, end = 5433740

Can anyone point out any issues with my approach and guide me on the
best way to do this? I see that there is a tcd_decode_tile routine,
but I am not sure if I can invoke it directly to decompress individual
tiles.

Thanks for any help.

Regards,
Praveen

[David Burken]

Hi,

Is there an interest in exposing an interface for individual tile
encode/decode?

I would be willing to take a stab at coding this. I just don't want to
duplicate anyone else's effort out there. So if the effort is already
underway I can wait.

This would be very useful for file based reader/writers. I am up to the
point with my ossim plugin that we can read raw j2k (full image) and
single block nitf's. So you can now use our apps imagelinker or iview
or ossimplanet, to view j2k's using the openjpeg plugin. I'd like to
move on to be tile based.

Also any interest in "Geo Open JPEG"? A single xml block to contain
geographic geometry info (GEO marker)? This would be cool.
Alternatively, nitf with j2k compressed blocks is a good solution as it
has all the hooks for geographic info built in.

Please let me know.

Thanks in advance,
Dave

> Hi,
>
> I am up to the point with my ossim plugin where I need to decode
> individual tiles.
>
> Are there any plans to expose an "opj_decode_tile" method in openjpeg.h
> to decode an individual tile? Or is there a way to already do this?
>
> I was looking tcd_decode_tile but I believe this decodes to full image
> buffer as opposed to a single tile buffer.
>
> Thank you and happy holidays to everyone out there,
> Dave

[Dzonatas]

Yes,

I figured this was eventually going to be asked. I've already started to
write a C++ version of library. The goal mainly being for performance.

C++ makes a good low-level interface. The entire library does not need
to be converted to C++ at once, so it can be done over time. I've
already started on the DWT module. The TCD module would be the next step.

Besides performance, I hope to have some flexible classes for a signal
abstraction layer. That way one could interface to the wavelets/tiles in
n-dimensions. If it effects performance negatively, then I'll pass on
the abstraction layer. The n-dimensional wavelet/tile interface would
allow for images that may mix 2D and 3D data together. It's more of the
theory now for its practicality, but it at least allows us to combine
the current efforts that are being put separately into the 2D and 3D
openjpeg2000 libraries.

I'll release some source when I'm satisfied with performance and class
layout.

[David Burken]

Hey very cool.

Looking forward to it.

If you're interested, here's a link to the start of my ossim plugin.
Not sure if it would be of use as it's pretty generic.

https://svn.osgeo.org/ossim/trunk/ossim_plugins/openjpeg/

Take care,
Dave

[François-Olivier Devaux]

Hi Dave,

An important effort has been started to upgrade the library interface. Among other interesting new features, will be an interface for individual tile encode/decode. The plan is to release this in the next major release (it's currently hard to predict a date for this release)... So I guess you'll have to wait for that release before using JPEG 2000 tiles in an efficient way in your OSSIM plugin.

Geo OpenJPEG is a great idea !
I browsed the JPEG committe repository to see what has been done on that topic (in fact, I'm not really familiar with this field), and I found two interesting documents.
The first is issued by the OGC (open Geospatial Consortium) and specifies how to encode GML in JPEG 2000 for Geographic Imagery (GMLJP2).
It is available here http://www.opengeospatial.org/standards/gmljp2
The other one from Luratech describes how to including GeoTIFF information in JPEG 2000 codestreams. It's very close to what you suggest, except the GeoTIFF stream is inserted in the JP2 header with a UUID box and not a XML box.

I don't know if the second one has been approved, and which method people are usually using. It could be interesting to see what GeoJasper, Luratech and Lizartech have chosen to do, if we wish to be as compliant as possible.

Cheers,

François

David Burken a écrit :

[David Burken]

Thank you for the reply François,

I will wait for your next release.  Looking forward to it. 

I'm glad to hear about the gmlj2k ogc effort.  Norman Vine had actually suggested the GeoOpenJPEG idea.  I will need to read/write the gml or geotiff block and it would be cool if there was a "libgeotiff" like library for that.  I suspect the effort may be on the way already.  If not I could help with that if anyone is interested.

Take care,
Dave

[Carl Reed]

FYI

The OGC GMLJP2 standard is currently in revision. Revisions are based
primarily on implementation experience.

A description of the work items for the revision can be found at
http://www.opengeospatial.org/projects/groups/gmljp2-1.1swg

Regards

Carl

On Jan 8, 8:00 am, "David Burken" <dbur...@gmail.com> wrote:
> Thank you for the reply François,
>
> I will wait for your next release. Looking forward to it.
>
> I'm glad to hear about the gmlj2k ogc effort. Norman Vine had actually
> suggested the GeoOpenJPEG idea. I will need to read/write the gml or
> geotiff block and it would be cool if there was a "libgeotiff" like library
> for that. I suspect the effort may be on the way already. If not I could
> help with that if anyone is interested.
>
> Take care,
> Dave
>
> On Jan 8, 2008 9:24 AM, François-Olivier Devaux <
>

> francois.dev...@uclouvain.be> wrote:
> > Hi Dave,
>
> > An important effort has been started to upgrade the library interface.
> > Among other interesting new features, will be an interface for individual
> > tile encode/decode. The plan is to release this in the next major release
> > (it's currently hard to predict a date for this release)... So I guess
> > you'll have to wait for that release before using JPEG 2000 tiles in an
> > efficient way in your OSSIM plugin.
>
> > Geo OpenJPEG is a great idea !
> > I browsed the JPEG committe repository to see what has been done on that
> > topic (in fact, I'm not really familiar with this field), and I found two
> > interesting documents.
> > The first is issued by the OGC (open Geospatial Consortium) and specifies
> > how to encode GML in JPEG 2000 for Geographic Imagery (GMLJP2).

> > It is available herehttp://www.opengeospatial.org/standards/gmljp2
> > The other one from Luratech describes how to* *including GeoTIFF

> > information in JPEG 2000 codestreams. It's very close to what you suggest,

> > except the GeoTIFF stream is inserted in the JP2 header with a UUID boxand not a XML box.

>
> > I don't know if the second one has been approved, and which method people

> > are usually using. It could be interesting to see what GeoJasper<http://dimin.m6.net/software/geojasper/>,
> > Luratech <http://www.luratech.de/products/lurawave/jp2geo/> and Lizartech<http://www.lizardtech.com/products/geo/>have chosen to do, if we wish to be as compliant as possible.

> > praveen.bhanira...@gmail.com wrote:
>
> > Hi all,
>
> > I am writing an image loader that needs to support JPEG2000, for which
> > I am using OpenJPEG's new 1.3 release. I am able to load basic images
> > using the j2k_to_image example program as a template. However, I am
> > having issues with images with multiple tiles, e.g. p0_10.j2k in the

> > following link has 4 tiles in a 2x2 layouthttp://www.gwg.nga.mil/ntb/baseline/software/testfile/Jpeg2000/profil....

[François-Olivier Devaux]

Hi Dzonatas,

Good to hear you're still working to improve the OpenJPEG library !

It'll be very interesting to see the performance increase by converting part of the code to C++.

The JP3D library indeed uses 3D wavelets, but also requires other important parts like new contexts defined in t1.c, new markers, ... it would be great to merge the 2D and 3D into one library, but it really does represent a lot of work.

I believe that the next major increase in performances of the library will be enabled by algorithmic optimizations of the T1 module. Callum has done some great "computer" optimizations of the T1 (memory handling improvement, improvements of pointers, ...) that gave some very nice results. Now the next step is to jump into the understanding of the algorithm achieving the code-block (de)coding (also called T1 in the JPEG 2000 standard). Currently, the T1 implementation in OpenJPEG is very basic, following exactly what is defined in the standard.
Some pretty easy optimizations will give some major improvements, as a lot of data is processed in this module. Indeed each bit of each wavelet coefficient is encoded "independently" in the T1 (as opposed to the DWT which deals with entire coefficients).

The T1 part that should be optimized is called "Coefficient bit modeling" and is defined in the JPEG 2000 standard in the Annex D.
Stefan Westerfeld gave some very interesting hints in a post on this group to start this optimization work.

Cheers,

Francois

Dzonatas a écrit :

[Antonin Descampe]

Hi praveen,

As far as I understand, you're calling opj_decode with a
"reconstructed" code-stream containing only the tile you want to
decode. If you do it this way, you'll have to modify also the main
header of this reconstructed code-stream to adapt the image size and
total number of tiles. You will find information on the main header
syntax in the JPEG2000 standard (http://www.jpeg.org/public/
fcd15444-1.pdf).

cheers,

Antonin

Le 06-janv.-08 à 10:38, praveen.b...@gmail.com a écrit :

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "OpenJPEG" group.
> To post to this group, send email to open...@googlegroups.com
> To unsubscribe from this group, send email to openjpeg-
> unsub...@googlegroups.com
> For more options, visit this group at http://groups.google.fr/group/
> openjpeg?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

[Praveen Bhaniramka]

Hello all,

Given a JPEG 2000 compressed image, what is the recommended way to determine
whether it is a JP2 or J2K compressed image? In my application, I have a
compressed buffer that I need to decompress and need to figure out the type
so that I can pass the appropriate parameter to opj_create_decompress()
routine.

Thanks.

- Praveen

[François-Olivier Devaux]

Hi Praveen,

For a JP2 file, the first 12 bytes must be 0x0000 000C 6A50 2020 0D0A 870A
For a J2K file, the first 2 bytes must be 0xFF4F

So if you're sure you have or a JP2 file, or a J2K file, you can just
check the value of the first byte (0x00 -> JP2, 0xFF -> J2K).

Cheers,

François

Praveen Bhaniramka a écrit :

[Norman Vine]

François-Olivier Devaux <francois.dev...@uclouvain.be> wrote:
> Hi Dave,
>
> An important effort has been started to upgrade the library interface.
> Among other interesting new features, will be an interface for
> individual tile encode/decode. The plan is to release this in the next
> major release (it's currently hard to predict a date for this
> release)... So I guess you'll have to wait for that release before using
> JPEG 2000 tiles in an efficient way in your OSSIM plugin.
>
> Geo OpenJPEG is a great idea !

All

There is an interesting thread going at
http://lists.osgeo.org/pipermail/discuss/2008-February/003244.html

Cheers

Norman