[Bins] Bug in image conversion?

[Daniel Martin]

Nicolas <bins_album at oxstone.com> writes:

> Hello,
>
> When I look at my galleries, I can sometimes see like a bug on the
> scaled pictures. Look at there:
> http://www.europephoto.com/moto/200502/20050220_Ballade_Repaire_Peters/dsc_0757_Pt.jpg.2.html
>
> The picture right border seems to come from the left border of the
> picture!

I believe that this feature is a consequence of how bins uses
jpegtran; basically, jpegtran has funny behavior when rotating images
with dimensions are not an even multiple of the jpeg compression block
size, usually 8 or 16 pixels.

Quoting from the jpegtran manpage:

  jpegtran's default behavior when transforming an odd-size image is
  designed to preserve exact reversibility and mathematical
  consistency of the transformation set. As stated, transpose is able
  to flip the entire image area. Horizontal mirroring leaves any
  partial iMCU column at the right edge untouched, but is able to flip
  all rows of the image. Similarly, vertical mirroring leaves any
  partial iMCU row at the bottom edge untouched, but is able to flip
  all columns. The other transforms can be built up as sequences of
  transpose and flip operations; for consistency, their actions on
  edge pixels are defined to be the same as the end result of the
  corresponding transpose-and-flip sequence.

A 90-degree right rotation is represented as transpose followed by
horizontal flip - you'll notice that the extra strip on the right of
the image is not only taken from the lhs of the image but also is
reversed left-to-right.

So the way out of this?  Three ways I can think of:
1. Don't use jpegtran to rotate images (that's part of the config.),
OR
2. apply jpegtran only to properly sized images by setting explicit
sizes within bins so that every image that bins rotates will be a nice
size, OR
3. apply jpegtran only to proper images by letting bins rotate the
original image (another config. setting), which should be a "nice"
size by jpegtran's standards.