Skip to content

FolderReorgProposal

Jump to bottom
Antonin Descampe edited this page Apr 28, 2015 · 1 revision

New names for libraries and executables

In order to make the openjpeg project libraries and executables more consistent, we plan to rename some of them. The current proposal is the following (italic indicate optional dependencies).

Libraries

name description dependencies remarks
libopenjpeg -> libopenjp2 basic J2K/JP2 library none Rename to "libopenjp2k" to disambiguate from JPEG format ? or is it too late ? MM: I do not like 'jp2k' since we either talk about j2k or jp2...
libopenjpwl (broken??) basic J2K/JP2 library with JPWL capabilities none
libopenjpip JPIP library libopenjpeg
libopenjp3d JP3D library none
libopenjpegjni OpenJPEG Java binding libopenjpeg

Library Symbols

Goals: When implementing the JPEG 2000 standard using OpenJPEG API, it should be possible to re-use as much code as possible.

Implementation details: When implementing any parts after Part 2, it should be possible to link to openjp2. For instance in the case of JPIP, to prevent code duplication, we had to re-use all the cio* & function_list* functionalities. Furthermore another low level change had to be done:

http://code.google.com/p/openjpeg/source/diff?spec=svn2067&r=2067&format=side&path=/trunk/src/lib/openjp2/jp2.h

See line 211 ('Point location for split...') just above 'jpip_iptr_offset'.

  1. It seems to me (MM) that this is a desirable goals to maintain a clean separation in between all the Parts of JPEG 2000. Multiples reasons: maintenance, clean design, separation...
  2. It seems for other dev (MSD) that it is potential harmful to expose low level functionalities such as cio* and as such it would be better to move back anything related to file writing (JPIP extention) back into the OPENJP2 folder.

How do we solve both (1) and (2) ? Possible solutions:

  1. We do not install cio.h. This means people would have to guess the types used by cio* functions. This would clearly indicate this is a private API.
  2. document them as being implementation details functions.
  3. Another more complex solution would be something like this:
$ cat CMakeLists.txt
add_library(libCore STATIC internal.c)
add_library(libA SHARED a.c)
target_link_libraries(libA LINK_PRIVATE libCore)
add_library(libB SHARED b.c)
target_link_libraries(libB LINK_PUBLIC libA LINK_PRIVATE libCore)
install(TARGETS libA libB
  EXPORT myexport
  RUNTIME DESTINATION bin
  LIBRARY DESTINATION lib
)
install(EXPORT myexport DESTINATION share)
#set_target_properties(libA PROPERTIES
#  PRIVATE_HEADER "internal.h"
#)

All the above possible solutions, are brute-force solutions. Another way at solving (1) & (2) would be to go over the exact API that poses issues and maybe extend openjp2 to provide a clean API that is easy to maintain while provide the same functionalities (or better) and help reduce code redundancy with openjpip.

Executables

name description dependencies remarks
opj_compress was: image_to_j2k libopenjpeg, libtiff, libpng, liblcms
opj_decompress was: j2k_to_image libopenjpeg, libtiff, libpng, liblcms
opj_dump was: j2k_dump libopenjpeg, libtiff, libpng, liblcms
opj_jpwl_compress was: JPWL_image_to_j2k libopenjpwl, libtiff, libpng, liblcms
opj_jpwl_decompress was: JPWL_j2k_to_image libopenjpwl, libtiff, libpng, liblcms
opj_server JPIP server libopenjpeg, libopenjpip_server, libfastcgi
opj_dec_server JPIP decoding server libopenjpeg, libopenjpip_local
opj_jpip_viewer was: opj_viewer ; JAVA JPIP viewer none technically there are actually two viewers: opj_viewer and opj_xerces_viewer, this is confusing for user, we should build one and only one depending whether or not user wants xerces (and found on system).
opj_viewer was: OPJviewer ; JAVA viewer libopenjpeg should be merged with opj_jpip_viewer
opj_mj2_compress was: frames_to_mj2 libopenjpeg currently, it does not use the openjpeg API correctly
opj_mj2_decompress was: mj2_to_frames libopenjpeg currently, it does not use the openjpeg API correctly
opj_mj2_extract was: extract_j2k_from_mj2 libopenjpeg currently, it does not use the openjpeg API correctly
opj_mj2_wrap was: wrap_j2k_in_mj2 libopenjpeg currently, it does not use the openjpeg API correctly
opj_jpip_test_jp2 was: test_index libopenjpeg
opj_addxml?dont like the name! was: addXMLinJP2 libopenjpeg
opj_jpip_transcode was: jpip_to_j2k libopenjpeg
opj_jpip_transcode was: jpip_to_jp2 libopenjpeg
opj_jp3d_decompress was: jp3d_to_volume libopenjp3d
opj_jp3d_compress was: volume_to_jp3d libopenjp3d
opj_jpip_compress was: image_to_j2k -jpip libopenjpip

Java binding

The openjpeg.jar will remain called 'openjpeg.jar' it is meant to provide the full OpenJPEG API. This means that the openjpeg.jar will load the individual components (openjp2, openjp3d...).

Single Build System

See:

New directory structure

A new directory structure is also proposed for the svn repository. Based on Vincent Torri suggestion+Addition from Mathieu Malaterre, here is the current proposal :

  • openjpeg
    • src/ (where the code for the libraries are located)
      • lib/ (where the code of libraries are located)
        • openjp2/
        • openjpip/
        • openjpwl/
        • openjp3d/
      • bin/ (where the code of binaries are located)
        • common/ [opj_dump, ...]
        • jp2/ [opj_compress, opj_decompress]
        • jpwl [opj_jpwl_compress, opj_jpwl_decompress]
        • mj2 [opj_mj2_compress, opj_mj2_decompress, opj_mj2_extract, opj_mj2_wrap]
        • jpip [opj_server, opj_dec_server]
        • wx
        • jp3d
    • cmake/
    • doc/
    • tests/
      • apps/
      • src/
    • wrapping/
      • java/
    • thirdparty/

Remaining questions :

  • Where do we put the code of thirdparty libraries, as only executables depend on them ?
  • Another proposal is to create different projects : openjpeg, openjpip, openjp3d, each with its 'branches', 'trunk' and 'tags' folders. Good idea ?
Clone this wiki locally