My favorites ▼ | Sign in
Project Home Downloads Wiki Issues Source
Search
for
FolderReorgProposal  
New folder organization and naming convention
Updated Jul 18, 2011 by savmick...@gmail.com

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 basic J2K/JP2 library none Rename to "libopenjp2k" to disambiguate from JPEG format ? or is it too late ?
libopenjpwl basic J2K/JP2 library with JPWL capabilities none
libopenjpip JPIP library none
libopenjp3d JP3D library none

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: image_to_j2k_JPWL libopenjpwl, libtiff, libpng, liblcms
opj_jpwl_decompress was: j2k_to_image_JPWL 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
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

New directory structure

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

  • openjpeg
    • src/
      • lib/ (where the code for the libraries are located)
        • openjpeg/
        • openjpip/
        • openjpwl/
        • openjp3d/
      • bin/ (where the code of binaries are located)
        • common/
        • opj_compress/
        • opj_decompress/
        • opj_dump/
        • opj_jpwl_compress/
        • opj_jpwl_decompress/
        • opj_server/
        • opj_dec_server/
        • opj_jpip_viewer/
        • opj_viewer/
        • opj_mj2_compress/
        • opj_mj2_decompress/
        • opj_mj2_extract/
        • opj_mj2_wrap/
      • include/ (the location of exported headers)
    • data/
    • doc/
    • tests/

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 ?

Comment by project member savmick...@gmail.com, Jul 11, 2011

For me it is a good idea to follow this source directory organization. Some remarks:

If you move to libopenjp2k, use the prefix opj2k for the new executable names.

Move the data repository out of the trunk, to avoid to increase dramatically the size of the trunk (and the time to checkout the source).

Use only the doc repository to store the code to generate the documentation not the generated documentation as it is the case now.

Finally I think that third-party directory should be put at the same level to the src directory because we don't know if in the future we don't need to add some dependencies to the core lib.

Mickaël

Comment by project member szukw...@arcor.de, Jul 18, 2011 
If you really want to rename files and directories, you have to: 

rename 'openjpeg.h' perhaps to 'openjp2k.h'
and set a link 'openjpeg.h -> openjp2k.h'

rename 'libopenjpeg1.pc' perhaps to 'libopenjp2k1.pc'
and set a link 'libopenjpeg1.pc -> libopenjp2k1.pc'     

winfried
Comment by project member vincent....@gmail.com, Jul 27, 2011

I'm against the symlink. This idea has been taken in the libpng project. Although there is no problem in the libpng project as they don't break API, also there will be BIG problems with openjpeg v1 vs openjpeg v2.

For me, all those links should go away (in openjpeg, as well as in libpng)

Comment by project member szukw...@arcor.de, Jul 30, 2011 
Without symlink you can not rename 'openjpeg.h', as applications
already exist using

#include <openjpeg.h>

winfried
Comment by project member vincent....@gmail.com, Aug 5, 2011

unfortunately, yes. I know that it's too late, now

but for the v2, the header name must be different (openjpeg2.h) and the .pc too (libopenjpeg2.pc), and no link anymore in v2.

Comment by project member vincent....@gmail.com, Aug 5, 2011

about the bin/ folder, I'm not sure that putting each binary in a separate folder is useful. Using the same folder structure than in lib/ should be sufficient

Comment by project member szukw...@arcor.de, Aug 12, 2011 
If the directory 'applications/jpip/' should be
moved and renamed to 'src/lib/openjpip/',

then the contents of 'jpip/libopenjpip/bool.h' 
should be changed.

bool        should be renamed to opj_bool
true/TRUE   should be renamed to opj_true
false/FALSE should be renamed to opj_false

winfried
Comment by project member mathieu.malaterre, Sep 20, 2011

Quick question: libopenjpwl, libopenjpip and libopenjp3d should link to libopenjpeg, right ? The first table state that there is no dependencies for those libs.

Comment by project member savmick...@gmail.com, Sep 20, 2011

I am not sure that including data repository into the openjpeg directory is a good idea because this folder is quite big and the great majority of users don't need to activate the build testing option.

Mickaël

Comment by project member vincent....@gmail.com, Sep 27, 2011

@mathieu : no : they all have their own source files.

Comment by project member vincent....@gmail.com, Jan 11, 2012

Another proposal (simplify a bit the original proposal)

  • openjpeg
    • src/
      • lib/ (where the code for the libraries are located)
        • openjpeg/
        • openjpip/
        • openjpwl/
        • openjp3d/
      • bin/ (where the code of binaries are located)
        • common/
        • openjpeg (3 binaries : compress, decompress, dump)
        • openjpwl (2 binaries : compress, decompress)
        • openjpmj2 (4 binaries : compress, decompress, extract, wrap)
        • openjpip (2 binaries : server, client)
      • include/ (the location of exported headers)
    • data/
    • doc/
    • tests/

It should simplify a bit the organisation of the directories structure.

I think that all the viewers must be standalone applications (somes are using java, others are using wxwidgets, etc...). They should not be part of the library source code. The other binaries are tools around the library, so being part of the source code is legitimate, imho.

Having the viewers being stand alone applications should in addition factorize the code. Better : having one unique viewer that unify the old code.

About the test directory, maybe it's not good to have it in the tree. It's for developpers. In case it's in the tree, it must not be included in the tarballs.

The question of having openjp3d in the source code is still debatable.

what do you think ?


► Sign in to add a comment
Powered by Google Project Hosting