tags 523948 + pending thanks Hi,
First the good part: I can easily fix your special problem (see the attached
patch which will be uploaded with the next revision in Debian). Now the bad
one: This is just part of a bigger problem described in the the rest of the
mail.
On Monday 13 April 2009 21:30:56 you wrote:
> Package: exactimage
> Version: 0.7.1-1
> Severity: normal
>
> Econvert crashes when called as follows:
>
> econvert -i 4000x3000.jpg --size 1280x1280 --rotate 270 -o zz.jpg
As said before, this one is not doing what you think. I've still had a look at
this problem and noticed that the handling of errors is... mostly missing.
Just as explanation what is happening here:
* image is loaded using the codecs (just imagine for now that this is a png
file to make it easier to understand without this extra raw jpeg
modification handling later on)
* size is applied -> the raw data is deleted and set to NULL
* rotate (rot90 to be more exactly) tries to get the raw data -> NULL is
returned, rot90 still tries to operate on it and will crash later
Handling the rawdata == NULL case in the rotate.cc doesn't really solve the
problem because it will just crash later on when it tries to write the stuff
to the output.
Now to the special problem showed by your example:
JPEG will not get decoded in the first step but a codec is used instead....
but the rotation still wants to to operate on the raw data. So, how does it
come to this problem? Yes, the modified bit is set in step 2 and step 3 will
check it and try to operate on the raw data. These are now getting decoded...
which should not have happened in the first place (but this is rather low
priority). The code assumed that it is already decoded and the meta
information are already available before the getRawData call.
So, it looks slightly like the rawdata handling has to be checked in over 100
different place. Maybe upstream has a better idea. And maybe an explanation
what other reason there are to have to use --size (which kills all previous
loaded images) besides to define the size of the raw image to be loaded next.
Another quick hack for Debian would be to disable operation in econvert on
images which have: rawdata == 0 && (modified || !hasCodec).
But maybe, this creates other problems and I am relativ sure this doesn't
solve problems in other components.
Kind regards,
SvenDescription: Decode image before accessing the stride attribute for rotation Bug-Debian: http://bugs.debian.org/523948 Author: Sven Eckelmann <s...@narfation.org> --- diff --git a/lib/rotate.cc b/lib/rotate.cc index 86c639e4fa7cbd0ad158b785184b258300dac691..4c05ad6c8a052b59a53f2807189b4935e90aa230 100644 --- a/lib/rotate.cc +++ b/lib/rotate.cc @@ -33,9 +33,9 @@ void flipX (Image& image) if (!image.isModified() && image.getCodec()) if (image.getCodec()->flipX(image)) return; - - const int stride = image.stride(); + uint8_t* data = image.getRawData(); + const int stride = image.stride(); switch (image.spp * image.bps) { case 1: @@ -103,9 +103,9 @@ void flipY (Image& image) if (!image.isModified() && image.getCodec()) if (image.getCodec()->flipY(image)) return; - - const unsigned int bytes = image.stride(); + uint8_t* data = image.getRawData(); + const unsigned int bytes = image.stride(); for (int y = 0; y < image.h / 2; ++y) { int y2 = image.h - y - 1; @@ -128,10 +128,9 @@ void rot90 (Image& image, int angle) bool cw = false; // clock-wise if (angle == 90) cw = true; // else 270 or -90 or whatever and thus counter cw - - int rot_stride = (image.h * image.spp * image.bps + 7) / 8; uint8_t* data = image.getRawData(); + int rot_stride = (image.h * image.spp * image.bps + 7) / 8; uint8_t* rot_data = (uint8_t*) malloc(rot_stride * image.w); switch (image.spp * image.bps)
signature.asc
Description: This is a digitally signed message part.
