Package: exiftran Version: 2.14-1 Control: affects -1 loupe jpegtran
Grab a particular JPEG file, crop away the white margins a bit, and rotate the cropped image by 180°: wget -O 1.jpg "https://static.toom.de/produkte/bilder/9191028/9191028_3.png?width=1050&height=1050&format=jpg"; jpegtran -crop 970x794+32+128 -perfect -outfile 2.jpg -strict 1.jpg exiftran -1 -o 3.jpg 2.jpg loupe 1.jpg 2.jpg 3.jpg & Observe the difference between 2.jpg and 3.jpg. The image has been somehow rotated, but not quite. While 2.jpg does show a lamp in full and small white margins on all sides, its rotated version in 3.jpg doesn't have a white margin to the left of the label of the lamp but does have some artifacts on the right side, to the right of the white margin. (It looks like 10 rightmost columns might have been flipped upside down instead of being rotated around the center by 180°, though I didn't check it pixelwise.) This is wrong. No relevant command (jpegtran, exiftran, and loupe) issued an error or even a warning. I don't know whose fault it is, so I am issuing a bug report against exiftran (since the error gets visible with loupe afterward), and the maintainer may reassign if necessary. Not sure whether loupe is doing wrong itself, but if it is, so are firefox, display, and gimp, since you can see that something is wrong when viewing 3.jpg with any of these three commands. Simply changing the orientation tag in the metadata should not mutilate the image itself, so either the error silently happened during cropping, or exiftran does more than just changing the metadata, or the viewers are doing a lousy job afterward. A possibly related, closed bug: https://bugs.debian.org/289667 . Further, in the manpage of exiftran we see, “By default exiftran don't preserve image size of the images that do not meet a multiple of 8 pixels. He prefers to cut a strip of a few pixels rather than offering a damaged image.” First, there's a trivial grammatical error here: “exiftran don't” should read “exiftran doesn't”, and “He” should read “It” or better “Exiftran”. Second, “multiple” should read “integer multiple”, otherwise the phrase is void of meaning (e.g., 3 = 0.375 ⋅ 8). Third, both 2.jpg and 3.jpg have the same size, 970×794, and neither of these two dimensions nor their product is an integer multiple of 8. According to the manpage, the image size of 2.jpg is not preserved, so the image size of 3.jpg should be different from that of 2.jpg. Maybe the quotation in the manpage is too strong and should read, “By default, exiftran retains the image size if the dimensions are integer multiples of 8. If the dimensions are not integer multiples of 8, exiftran shrinks the image or leaves it of the same size. Exiftran prefers to cut a strip of a few pixels rather than offering a damaged image.” Also check whether you want each dimension or their product to be an integer multiple of 8 and whether you wish to refer to the dimensions of an MCU block instead of 8.
![https://static.toom.de/produkte/bilder/9191028/9191028_3.png?width=1050&height=1050&format=jpg"](https://static.toom.de/produkte/bilder/9191028/9191028_3.png?width=1050&height=1050&format=jpg"){kind=link}