usage_examples.txt

Kakadu V6.1 for Win32 Kakadu 是JPEG2000编解码的实现之一

       (ORGgen_plt=yes); 2) the use of a packet sequence (RPCL) which places
       all packets of each precinct consecutively within the code-stream
       (otherwise, it is hard to efficiently represent or use the PLT
       marker information); and 3) the use of relatively small precincts.
       The additional "ORGtparts=R" attribute introduces tile-part headers
       immediately before each resolution level and locates the packet length
       information with the header of the tile-part to which the packets
       belong.  This has the effect of delaying the loading and parsing of
       packet length identifiers (hundreds of thousands of packets were
       generated in the 500 MByte image example) until an interactive
       viewer or browser requests the relevant resolution.
s) kdu_compress -i small.pgm -o small.jp2 -rate 1 Clayers 5 -no_info
   -- The `-no_info' option prevents Kakadu from including a comment (COM)
      marker segment in the code-stream to identify the rate-distortion slope
      and size associated with each quality layer.  This information is
      generated by default, starting from v3.3, since it allows rendering
      and serving applications to customize their behaviour to the properties
      of the image.  The only reason to turn off this feature is if you
      are processing very small images and are interested in minimizing the
      size of the code-stream.
t) kdu_compress -i massive.ppm -o massive.jp2 -rate -,0.001 Clayers=28
                Creversible=yes Clevels=8 Corder=PCRL ORGgen_plt=yes
                Cprecincts={256,256},{256,256},{128,128},{64,128},{32,128},
                           {16,128},{8,128},{4,128},{2,128} -flush_period 1024
   -- You might use this type of command to compress a really massive image,
      e.g. 64Kx64K or larger, without requiring the use of tiles.  The
      code-stream is incrementally flushed out using the `-flush_period'
      argument to indicate that an attempt should be made to apply incremental
      rate control procedures and flush as much of the generated data to the
      output file as possible, roughly every 1024 lines.  The result is that
      you will only need about 1000*L bytes of memory to perform all
      relevant processing and code-stream management, where L is the image
      width.  It follows that a computer with 256MBytes of RAM could
      losslessly an image measuring as much as 256Kx256K without
      resorting to vertical tiling.  The resulting code-stream can be
      efficiently served up to a remote client using `kdu_server'.
u) kdu_compress -i im32.bmp -o im32.jp2 -jp2_alpha -jp2_box xml.box
   -- Demonstrates the fact that "kdu_compress" can read 32-bit BMP files
      and that you can tell it to regard the fourth component as an alpha
      channel, to be marked as such in the JP2 header.  The "kdu_show"
      application ignores alpha channels only because alpha blending is
      not uniformly supported across the various WIN32 platforms.  The
      Java demo application "KduRender.java" will use an image's alpha
      channel, if any, to customize the display.
   -- The example also demonstrates the inclusion of additional meta-data
      within the file.  Consult the usage statement for more on the structure
      of the files supplied with the `-jp2_box' argument.  To reveal the
      meta-data structure of a JP2 file, use "kdu_show"'s new "meta-show"
      capability, accessed via the `m' accelerator or the view menu.
v) kdu_compress -i im.ppm -o im.jpx -jpx_space ROMMRGB
   -- demonstrates the generation of a true JPX file.
   -- demonstrates the fact that any of the JPX enumerated colour space
      descriptions can now be used; assumes, of course, that the input image
      does have a ROMM RGB colour representation (in this case).
   -- you can actually provide multiple colour spaces now, using `-jp2_space'
      and/or `-jpx_space', with the latter allowing you to provide
      precedence information to indicate preferences for readers which are
      able to interpret more than one of the representations.
w) kdu_compress -i frag1.pgm -o massive.jp2 Creversible=yes
                 Clevels=12 Stiles={32768,32768} Clayers=30
                 -rate -,0.0000001 Cprecincts={256,256},{256,256},{128,128}
                 Corder=RPCL ORGgen_plt=yes ORGtparts=R Cblk={32,32}
                 ORGgen_tlm=13 -frag 0,0,1,1 Sdims={1500000,2300000}
   kdu_compress -i frag2.pgm -o massive.jp2 Creversible=yes
                 Clevels=12 Stiles={32768,32768} Clayers=30
                 -rate -,0.0000001 Cprecincts={256,256},{256,256},{128,128}
                 Corder=RPCL ORGgen_plt=yes ORGtparts=R Cblk={32,32}
                 ORGgen_tlm=13 -frag 0,1,1,1
   kdu_compress -i frag3.pgm -o massive.jp2 Creversible=yes
                 Clevels=12 Stiles={32768,32768} Clayers=30
                 -rate -,0.0000001 Cprecincts={256,256},{256,256},{128,128}
                 Corder=RPCL ORGgen_plt=yes ORGtparts=R Cblk={32,32}
                 ORGgen_tlm=13 -frag 0,0,2,1
   ...
   -- demonstrates the compression of a massive image (about 3.5 Tera-pixels
      in this case) in fragments.  Each fragment represents a whole number of
      tiles (in this case only one tile, each of which contains 1 Giga-pixel)
      from the entire canavs.  The canvas dimensions must be explicitly
      given so that the fragmented generation process can work correctly.
   -- To view the codestream produced at any intermediate step, after
      compressing some initial number of fragments, you can use
      "kdu_expand" or "kdu_show".  Note, however, that while this will work
      with kakadu, you might not be able to view a partial codestream using
      other manufacturers' tools, since the codestream will not generally
      be legal until all fragments have been compressed.
   -- To understand more about fragmented compression, see the usage statement
      for the `-frag' argument in "kdu_compress" or, for a thorough
      picture, you can check out the definition of `kdu_compress::create'.
   -- In this example, the codestream generation machinery itself produces
      TLM (tile-part-length) marker segments.  This is done by selectively
      overwriting an initially empty sandpit for TLM marker segments in the
      main header.  TLM information makes it easier to efficiently access
      selected regions of a tiled image.

x) kdu_compress -i volume.rawl*100@524288 -o volume.jpx -jp2_space sLUM
                -jpx_layers * Clayers=16 Creversible=yes Sdims={512,512}
                Sprecision=12 Ssigned=no Cycc=no
   -- Compresses an image volume consisting of 100 slices, all of which are
      packed into a single raw file, containing 12-bit samples, in the
      least-significant bits of each 2-byte word with little-endian byte order
      (note the ".rawl" suffix means little-endian, while ".raw" means
      big-endian).
   -- The expression "*100@524288" means that the single file "volume.rawl"
      should be unpacked into 100 consecutive images, each separated by
      524288 bytes (this happens to be 512x512x2 bytes).  Of course, we
      could always provide 100 separate input files on the command-line but
      this is pretty tedious.
   -- The "-jpx_layers *" command instructs the compressor to create one
      JPX compositing layer for each image component (each slice of the
      volume).  This will prove particularly interesting when multi-component
      transforms are added (see examples Ai to Ak below).  Take a look at
      the usage statement for other ways to use the new "-jpx_layers" switch.

y) kdu_compress -i geo.tif -o geo.jp2 Creversible=yes Clayers=16 -num_threads 2
   -- Compress a GeoTIFF image, recording the geographical information tags
      in a GeoJP2 box within the resulting JP2 file.  Kakadu can natively
      read a wide range of exotic TIFF files, but not ones which contain
      compressed imagery.  For these, you need to compile against the public
      domain LIBTIFF library (see "Compilation_Instructions.txt").
   -- From version 5.1, Kakadu provides extensive support for multi-threaded
      processing, to leverage parallel processing resources (multiple
      CPU's, multi-core CPU's and/or hyperthreading CPU's).  In this example,
      the `-num_threads' argument is explicitly used to control threading.
      The application selects the number of threads to match the number of
      available CPU's by default, but it is not always possible to detect
      the number of CPU's on all platforms.  To force use of the single
      threaded processing model from previous versions of Kakadu, specify
      "-num_threads 0".  To use the multi-threading framework of v5.1 but
      populate the environment with only 1 thread, specify "-num_threads 1";
      in this latter case, there is still only one thread of execution in
      the program, but the order in which processing steps are performed
      is driven by Kakadu's thread scheduler, rather than the rigid order
      associated with function invocation.

z) kdu_compress -i frame.tif -o dci_frame.jp2 Sprofile=CINEMA4K
                Creslengths=1302083, Creslengths:C0=1302083,1041666
                Creslengths:C1=1302083,1041666 Creslengths:C2=1302083,1041666
   -- Compresses a 3-plane 12-bit per sample TIF image to a JP2 file whose
      embedded codestream is compliant with the 4K digital cinema profile,
      with rate constraints adjusted for a 24fps projection environment.
   -- This example demonstrates use of the new "Creslengths" parameter
      attribute for constraining the compressed size associated with
      resolution-specific and/or component-specific subsets of the
      codestream.  You can combine Creslengths with -rate or -slope, so that
      Creslengths just acts as a guard to prevent violation of constraints
      under unusual circumstances.  This is probably the best way to use
      Kakadu to generate Digital Cinema content.  The "Creslengths" attribute
      provides a rich set of potential constraints, well beyond what is
      required by Digital Cinema.  It allows you to bound the compressed size
      of any image resolution (globally), any image component at any resolution
      (globally), any resolution of any tile or any resolution of any
      tile-component (image component of a tile).  Moreover, it allows you to
      provide bounds (or omit bounds) for any or all of the quality layers
      you want to generate.

kdu_compress advanced Part-2 Features
-------------------------------------
    These additional examples look a lot more complex than the ones above,
    because they exercise rich features from Part-2 of the JPEG2000 standard.
    The signalling syntax becomes complex and may be difficult to fully
    understand without carefully reading the usage statements printed by
    "kdu_compress -usage", possibly in conjunction with IS15444-2 itself.
    In the specific applications which require these options, you would
    probably configure the relevant codestream parameter attributes directly
    from the application using the binary set/get methods offered by
    `kdu_params', rather than parsing complex text expressions from the
    command-line, as given here.  Nevertheless, everything can be
    prototyped using command-line arguments.

Aa) kdu_compress -i image.pgm -o image.jpx
                 Cdecomp=B(V--:H--:-),B(V--:H--:-),B(-:-:-)
    -- Uses Part-2 arbitrary decomposition styles (ADS) features to describe
       a packet wavelet transform structure, in which the highest two
       resolution levels of HL (horizontally high-pass) and LH (vertically
       high-pass) subbands are further subdivided vertically (HL) and
       horizontally (LH) respectively.  Subsequent DWT levels use the
       regular Mallat decomposition structure of Part-1.
    -- The decomposition structure given here is usually a little more
       efficient than the standard Mallat structure from Part-1.  This
       structure is also compatible with compressed-domain flipping
       functionalities which Kakadu uses to implement efficient rotation
       (for transcoding or rendering).
    -- Much richer splitting structures can be described using the `Cdecomp'
       syntax, but compressed domain flipping becomes fundamentally impossible
       if any final subband involves more than one high-pass filtering
       step in either direction.

Ab) kdu_compress -i image.ppm -o image.jpx
                 Cdecomp=B(BBBBB:BBBBB:B----),B(B----:B----:B----),B(-:-:-)
    -- Similar to example Aa), except that the primary (HL, LH and HH)
       subbands produced by the first two DWT levels are each subjected to
       a variety of further splitting operations.  In this case, the highest
       frequency primary HL and LH subbands are each split horizontally and
       vertically into 4 secondary subbands, and these are each split again
       into 4 tertiary subbands.  The highest frequency primary HH subband
       is split into just 4 secondary subbands, leaving a total of 36
       subbands in the highest resolution level.  In the second DWT level,
       the primary HL, LH and HH subbands are each split horizontally and
       vertically, for a total of 12 subbands.  All subsequent DWT levels
       follow the usual Mallat decomposition structure.