OPENJPEG v2

366 views
Skip to first unread message

Jerome Fimes

unread,
Mar 14, 2008, 5:18:39 AM3/14/08
to open...@googlegroups.com
Hi everyone,
My name is Jérôme Fimes.


The openjpeg team at UCL and CS (Communications & Systems, the company I work for) achieved a project from the French National Space Studies Center (CNES) which goal is to provide a jpeg2000 codec that :
  1. allows a tile based coding/decoding
  2. supports mega images
  3. allows only specific areas to be decoded
  4. implements a subset of the MCT part 2.
I was the one who developed the library from the existing openjpeg implementation.
Some of you may have heard of the "version 2.0" from François-Olivier, and here is the change log.
 
  • Streaming System. The 2.0 features a proper streaming system. The user provides some specific read/write/skip functions. These functions are used to implement from an abstract stream a custom stream. Optionally, if the stream is "seekable", the user may provide a seek function. The seek is required for the cinema configuration and the jp2 file. Upon creation, the user chooses the size of a forward buffer from/to which data is read/written.
  1. see : opj_stream_create_default_file_stream, opj_stream_create_file_stream, opj_stream_default_create and opj_stream_create.
  2. The whole file is no more stored in memory.
  • The library is provided with 2 tutorials to encode/decode (see the directories test_V2_tile_handling and test_Free_image_V2_tile_handling).

These tutorials show the use of the new encoding/decoding system with calls to opj_write_tile, opj_read_tile_header and opj_decode_tile. The user calls opj_write_tile for each tile. When decoding, the user first call a read_tile_header to find out the tile being decoded and the size of the data that will be necessary to decode the tile.
  • The data is no more aligned on 32 bits boundary. The user data is composed of the n0 elements of the component 0, then the n1 elements of the component 1, …
  • If the component size is between 1 and 8, the elements in the user data are 8 bit long, between 9 and 16 -> 16 bits, between 17 and 32 -> 32 bits.
  • The data member of the struct image is used no more.
  • The library does not perform the t1 decoding of non-needed resolutions any more => increase in performance.
  • The MCT array based decorrelation is implemented along with the use of an offset buffer. Only float data is supported for encoding/decoding at the time. (opj_set_MCT)
  • j2k.c and jp2.c have seen dramatic changes to help with a simpler extension mechanism. Developers wanting to add features for the library only have to add their custom procedures for validation/encoding. See for example functions like j2k_setup_*
  • The user may need to decode only a sub part of the whole image. This is done with a specific call to the d_parameters with opj_restrict_decoding. The user passes the image area that should be decoded and only the relevant tile will be decoded. No filtering is performed at the precinct level, the whole tiles that overlap will be decoded.
  • The sub part decoding can also be performed after reading the header of the code stream with a call to opj_set_decode_area (overwrites opj_restrict_decoding if any).
  • A lot of code has been simplified/factored in order to lower the memory consumption. 
All these modifications, and the few time I had to perform them made me break some 1.3 features :
  • The JPWL code has not been ported
  • The codestream_info feature is completely broken. The UCL team is working on it at the time.
  • No more support for jp2 boxes of unknown size. I am working on it at the time.
  • No more jpt stream supported at the moment, but some of the code has already been ported.
  • I am sorry, second life users, but the decoding of incomplete tile is no more possible (at the time). It may be quite easy to add the support for incomplete stream with changing the return values of some functions. I may have some time to correct this next week. Just provide me with some samples and I'll try to fix this.
TODO :
  • You may notice the warning about setup_decoder and setup_decoder being deprecated. The goal is to get rid of this 2 calls and replace them by appropriate getter/setter function on the codec. The struc d_parameters and c_parameters should disappear. Due to the lack of time, I could not finish it, but I started it. Anyone wanting to complete the work is welcome.
 I am sure I forget some other minor modifications. Feel free to ask me some questions if needed.
The version 2 in alpha version is available for download at http://www.openjpeg.org/index.php?menu=download

I hope the "new" library will be useful to some users.

Cheers,

Jérôme

François-Olivier Devaux

unread,
Mar 14, 2008, 1:27:44 PM3/14/08
to open...@googlegroups.com

Thanks a lot Jerome for the great work you've achieved with this version 2.
Among the main improvements you've worked on, I think the ability to process efficiently tiled mega-images is a feature that was expected by many users, as well as the new i/o streaming.
More subtle changes improve the library efficiency and flexibility. Again, congratulations for this v2!

Here is the roadmap for OpenJPEG that I propose for the next month.

1) Release of v1.3.1, stable version of OpenJPEG. To do this, we should investigate the problems with MAC OSX that have recently discovered by Michael Cayanan.

2) At the same time, discussion through this mailing list about the major changes to V2. As Jerome pointed out in his email, the library interface still needs to be slightly changed in order to ease in the future the implementation of new options. During this period, we won't create a new branch for V2. Let's give some time to all of you to test version 2 and give us suggestions about MAJOR changes. We're not expecting any patches to solve potential bugs at this stage.

3) Once release 1.3.1 is released, we'll put V2 on the SVN, and start implementing the changes / collecting patches discussed during the previous period.

This process might seem slow, but there is a good reason to this: for the next month, the team at UCL managing the library will be quite busy on other projects (like myself finishing my PhD). Everything will come back to normal in July/September. So let's do things nice and slow, in order to keep the project on track.
Antonin Descampe and Parvatha Elangovan at UCL are the two persons that will follow the OpenJPEG project for the next months, while I'll be working in my igloo somewhere near the North Pole. Thanks guys, I'll send you postcards.

Enjoy Version 2 !

Cheers,

François-Olivier

Jerome Fimes a écrit :
Reply all
Reply to author
Forward
0 new messages