JP2 quality differs between Kakadu installs

  • David

    David - 2011-10-11

    Hi all

    Apologies for posting a potentially very Kakadu specific question on this
    forum, but here at the National Library of Wales we're struggling with the
    .tif -> .jp2 conversion and I was hoping someone could offer an insight into
    the problem...

    The situation is that we have Kakadu installed in 2 locations, one of them is
    able to produce the .jp2s successfully with our compression settings, and the
    other is producing a completely different representation altogether which
    appears to be lossy and missing tiles when used in the IIP Viewer.

    The corrupted version appears to have less visible layers and, when used
    within the viewer, is only ever 50% rendered (one half of the image is
    completely missing) - producing HTTP 500 errors for that half from the IIP

    Any ideas as to why these different installations are producing wildly
    different results ? The only inkling I have is the differing versions of the
    linked libtiff library...


    The specs of each workstation are as follows:

    Compression - used within both workstations

    ./kdu_compress -i input.tif -o output.jp2 -rate 0.5 Creversible=yes Clevels=7 Corder="RPCL" ORGgen_plt="yes" ORGtparts="R" Cblk="{64,64}" Stiles="{128,128}"


    Fedora 13
    Kakadu v6.4.1
    libtiff v3.9.4

    Example image:

    Not Working

    OS: Solaris 10 64-bit SPARC update 8 (10/09)
    Kakadu v6.4.1-01151L
    libtiff v3.9.5

    Example image:

  • Edu Hackenitz

    Edu Hackenitz - 2011-10-12


    We did succeed to create jp2's on both Solaris9+10 with kakadu + standard
    You may drop us a tiff to see if your command will produce a valid jp2 on our

  • Ruven

    Ruven - 2011-10-13

    Both your examples work on my machine, but there does seem to be a problem
    with the CVT output. I will look into this ...

  • David

    David - 2011-10-14

    Thanks all, if anyone wants to try the compression with our tifs, an example
    can be downloaded here:

  • Edu Hackenitz

    Edu Hackenitz - 2011-10-18


    Find your converted tiff at
    We use the latest kakadu on SunOS leharz1 5.10 Generic_144488-09 sun4v sparc
    SUNW,SPARC-Enterprise-T5120 Solaris
    We also use the oldmaps online command line ...something like kdu_compress
    args = strrchr(KAKADU_COMPRESS,'/') + 1;
    args = "-i";
    args = img_in;
    args = "-o";
    args = img_out;
    args = "-rate";
    args = "0.30";
    args = "Clayers=1";
    args = "Clevels=7";
    args = "Cprecincts={256,256},{256,256},{256,256},{128,128},{128,128},{64,64},{
    args = "Corder=RPCL";
    args = "ORGgen_plt=yes";
    args = "ORGtparts=R";
    args = "Cblk={64,64}";
    args = "Cuse_sop=yes";
    args = "-quiet";
    args = NULL;

  • David

    David - 2011-10-21

    Thanks for running that compression, how does it perform in the IIPViewer for
    you ? Would it be possible to try the compression in my original post, we
    would really appreciate a direct comparison. Thanks.

    Our results can be seen below - very blocky and corrupted. We've had similar
    results with other compression settings, with only the settings listed in my
    original post producing images that don't resemble the following screenshot.

    Is anyone else seeing a similar result in their viewer ? Could it be related
    to our IIPServer config:

    # Set our environment variables for the IIP server
    FcgidInitialEnv VERBOSITY "5"
    FcgidInitialEnv LOGFILE "/tmp/iipsrv.log"
    FcgidInitialEnv MAX_IMAGE_CACHE_SIZE "10"
    FcgidInitialEnv JPEG_QUALITY "50"
    FcgidInitialEnv MAX_CVT "3000"
    # Define the idle timeout as unlimited and the number of
    # processes we want
    FcgidIdleTimeout 0
    #FcgidMaxClassProcessesPerClass 1


  • David

    David - 2011-11-08

    Edu - many thanks for experimenting with our images, we've now solved the

    Eoghan - it turned out to be exactly the case and switching to a 64bit server
    resolved the problem, thanks for the heads up.




Cancel  Add attachments