Subject: lossless crop 'n' drop (cut & paste)
        Date: Fri, 21 Jan 2000 19:21:08 +0100
        From: Guido Vollbeding <guivol@labsoft.de>
Organization: Labsoft GmbH
          To: jpeg-l@ijg.org


Tom Lane wrote:
> 
> BTW, I am going to try to get off my duff and pull together a v6c
> release of libjpeg next month sometime.  If you have any features,
> tweaks, portability improvements, or what-have-you sitting around,
> now would be a great time to dust them off and send them in.

I will try to provide my preliminary results for the following
jpegtran extensions:

  Switches for modifying the image:
    -crop WxH+X+Y  Crop to a rectangular subarea
    -drop filename +X+Y          Drop another image
    ...

The cropping code is the stable patched version with Tom Lane and
Ben Jackson, plus a recent extension (see below) which was especially
necessary for my application in connection with the new "drop" feature.

The new "drop" code is in an early "hack" state (pre-alpha), but it
already works great in my application and is essential, despite the
'apparently' (see below) limiting conditions.
I'm not sure whether the term "drop" is right here.  Please let me know
if it is not adequate.  First I had the term "overlay" for this feature,
but then "drop" sounded better in connection with "crop".
The meaning is that "filename" overlays the part of the source image at
position +X+Y.

I'm not sure whether we can finalize the "drop" code until next month.
Although the major design seems good, there are still a lot of special
cases to consider and decisions to make.

So I will try to provide a web page with explanations and pointers to
the code in the next days.  Let me say either the coming or the
following weekend.

Here some first notes:

1. Extension to the "croppatch" (see http://sylvana.net/jpegcrop/):
The extension allows the W and H parameters to exceed the image
dimensions.  The current code simply rejects processing in this case.
The new code "extends" the source image to the desired size, setting
the extra area to zero (neutral gray) and placing the source image
at position +X+Y.  This is useful as a first step for combining
several small images to a big image with subsequent "drop" operations
without extra tools.  If the gray ground should not be desired, it is
still possible to prepare another ground image with extra tools.
But with this extension, extra tools are not necessary.

2. The restrictions of the "drop" feature regarding block alignment
and matching sampling ratios are less important than one might think
in my application:
We take digital images with a microscope camera.  Due to the limited
magnification/zoom possibilities, only a small part of the images
contains the interesting subject.  The crop size can easily be trimmed
to the block alignment.
The application (an extension of "jpegcrop", see
http://sylvana.net/jpegcrop/jpegcrop.zip) lets you select crop parts
from several images to form a big image for database archiving.  See
http://sylvana.net/jpegcrop/labsample.jpg as an example result.
Note that the logo and legend images are also inserted with the "drop"
function.  Processing is based only on the following two functions
according to the jpegtran options, with the usage of several temporary
files:

  int docrop( const char * src, const char * des,
              int crop_xoffset, int crop_yoffset,
              int crop_width, int crop_height,
              int optimize_coding,
              int crop_copyoption );

  int dodrop( const char * src, const char * drop, const char * des,
              int drop_xset, int drop_xoffset,
              int drop_yset, int drop_yoffset,
              int optimize_coding,
              int crop_copyoption );

A major issue in the "drop" code design is the addition of a second
decompression object, so we have to handle three objects totally.
As said, it works for me, but the current organization may not be
optimal regarding memory allocation.
Another issue is, of course, the handling of different quantization
tables.  Currently I do a component wise adaption technique which
guarantees exact losslessness:  If the tables are identical, then
this table is used.  If one table element is different, then a
destination qtable of all 1's is used while dequantizing the block
coefficients.
'Smoother' techniques are possible:  element-wise adaption and
common-denominator adjustment.  Also possible is reference scaling
while giving up exact losslessness.
The example image above has qtables of all 1's due to different
in-camera quantization selection.  This makes the image file
relatively large, while maintaining full quality of the selected
subjects.

The crop/drop feature set in the given form is flexible enough as
a base for several other applications, for example building
overwiews of thumbnail images.

Regards,
Guido

--
Sent via IJG mailing list, jpeg-l@ijg.org
Administrivia: majordomo@ijg.org