>>>>> "Ludovic" == Ludovic Rousseau <[EMAIL PROTECTED]> writes:
Ludovic> And asked again one month later.
Ludovic> You never answered so I guess the problem is solved. Feel
Ludovic> free to reopen the bug and send us an image so we can
Ludovic> reproduce the problem and try to solve it.
I first sent the link to the image on "Wed, 05 Jan 2005 09:16:01 +1100".
It was not until "Fri, 4 Nov 2005 17:26:30 +0000" that somebody tried
to look at them.
I sent a link again on "Mon, 07 Nov 2005 12:24:31 +1100".
But it would appear nobody even looked at this one. It is now gone. I
can't keep my test cases around for ever. If I tried sending it to the
BTS, it didn't work, probably because the image was too big.
The documentation in my first email on exactly what the problem was
stills stands.
In addition, it is easy to reproduce following the instructions in my
first post on any image of correct orientation - I really don't see
what the issue is.
For example, what is so hard to comprehend that you need the -trim
flag with jpegtran? You just need to look up the man page:
For practical use, you may prefer to discard any
untransformable edge pixels rather than having a
strange-looking strip along the right and/or bottom edges of a
transformed image. To do this, add the -trim switch:
-trim Drop non-transformable edge blocks.
Obviously, a transformation with -trim is not reversible, so
strictly speaking jpegtran with this switch is not lossless.
Also, the expected mathematical equivalences between the
transformations no longer hold. For example, -rot 270 -trim
trims only the bottom edge, but -rot 90 -trim followed by -rot
180 -trim trims both edges.
Actually, I would argue exiftran is probably better these days then
jpegtran
Unfortunately I have lost interest in bins, and am reluctant to go out
of my way to take another photo that will get lost again in a years
time.
--
Brian May <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
