Flipped TGA file when Image Origin isn't BottomLeft

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
Teteros
Posts: 2
Joined: 2018-09-21T14:28:43-07:00
Authentication code: 1152

Flipped TGA file when Image Origin isn't BottomLeft

Post by Teteros » 2018-09-21T16:23:22-07:00

Default convert to Targa image-origin seems to be BottomLeft (using build-in stock rose image as demo):

Code: Select all

convert rose: rose.tga
equivalent to convert rose: -define tga:image-origin=BottomLeft rose.tga
Image isn't flipped.

Simulating Krita TGA export in ImageMagick:

Code: Select all

convert rose: -define tga:image-origin=TopLeft -alpha on rose_32bpp.tga
(Krita outputs TGA files with Image Origin TopLeft (0x10) and Alpha channel added)

Code: Select all

identify -verbose rose_32bpp.tga | grep image-origin
tga:image-origin: TopLeft
Image is flipped vertically

i.e changing -define tga:image-origin=BottomLeft to other values flips the image around.
(BottomRight for horizontal flip)

Context: I've wanted to remove alpha channel from Krita's TGA exports to save filesize,
e.g: convert rose_32bpp.tga -alpha off rose_24bpp.tga
but ImageMagick kept flipping the image vertically, making it very confusing to see what's going on before i diff'd the TGA metadata between converted TGA images.

It looks like ImageMagick preserves the origin set in TGA input to output, but uses BottomLeft internally?
I would have expected alpha channel to be removed without flipping the image.

Platform: Linux x64
convert -version
Version: ImageMagick 7.0.8-11 Q16 x86_64 2018-08-29 https://www.imagemagick.org
Copyright: © 1999-2018 ImageMagick Studio LLC
License: https://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenCL OpenMP
Delegates (built-in): bzlib cairo fontconfig freetype gslib heic jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png ps raw rsvg tiff webp wmf x xml zlib

User avatar
magick
Site Admin
Posts: 11099
Joined: 2003-05-31T11:32:55-07:00

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by magick » 2018-09-21T17:24:59-07:00

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

Teteros
Posts: 2
Joined: 2018-09-21T14:28:43-07:00
Authentication code: 1152

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by Teteros » 2018-09-24T06:58:51-07:00

Thank you for the patch, I've checkout master and have questions:
As of commit c9595dd

ORIENTATION being one of
magick -list orientation

It looks like
-define tga:image-origin=ORIENTATION
is deprecated and
-orient ORIENTATION
now preferred?

rose.png to rose.tga, is created upside down unless we add in -flip

Code: Select all

magick convert rose: -orient TopLeft -flip rose.tga
magick identify -format "%[orientation]" rose.tga
also identify now lists "Orientation" instead of "image-origin" for TGAs so we know we're on git master build.

Doing something to this rose.tga will flip it back, eg:

Code: Select all

magick convert rose.tga -depth 5 rose_5bpc.tga
It's neccesary to specify -orient BottomLeft or manually know how to orient the image (-flip in this case)

Alternatively, if mogrify is done twice (on new TopLeft rose.tga) without any orient parameters, it orients the file too:

Code: Select all

magick mogrify -depth 5 rose.tga
which is strange because the Orientation tag in the TGA file stays the same.

Maybe -auto-orient should work for TGAs too since BottomLeft is default?

maruno
Posts: 4
Joined: 2018-09-25T04:17:57-07:00
Authentication code: 1152

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by maruno » 2018-09-25T04:21:17-07:00

After this change all our TGA images are being flipped on a simple conversion. Are we sure the fix is correct? I don't quite understand the original issue, but there seems to be some regression here.

lushkava
Posts: 3
Joined: 2019-11-19T23:09:43-07:00
Authentication code: 1152

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by lushkava » 2019-11-19T23:28:59-07:00

I registered so as to be able to echo maruno's sentiments. I convert to the TGA format in order to feed the mozjpeg image encoder as part of my image processing pipeline, and was greatly surprised to find images being vertically flipped after a long-overdue ImageMagick upgrade. As such, I was forced to roll back to v6.9.5.10. Thus far, I have determined that using the -auto-orient option is sufficient to trigger the issue and that even source images lacking any defined orientation in the EXIF header are affected. I don't see how this new behaviour can possibly be correct.

EDIT: Here's a sample image for which a direct conversion with -auto-orient demonstrates the issue: https://i.imgur.com/Lq8r3RU.jpg

lushkava
Posts: 3
Joined: 2019-11-19T23:09:43-07:00
Authentication code: 1152

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by lushkava » 2019-11-20T01:05:38-07:00

I did a little more testing by injecting orientation values into the header of the sample image from the previous post. For each permutation, I performed a direct conversion to TGA with the -auto-orient option. I then opened both the input and output images in Eye of GNOME, so as to discern the effect of the orientation value. Here are the results.

Code: Select all

Outcome for all possible orientations in ImageMagick 6.9.5-10 ...

ORIENTATION     | EFFECT ON JPEG           | EFFECT ON TGA            |
----------------+--------------------------+--------------------------+
U (Undefined)   | None                     | None                     |
1 (TopLeft)     | None                     | None                     |
2 (TopRight)    | flip X                   | Same as for JPEG         |
3 (BottomRight) | flip X & Y               | Same as for JPEG         |
4 (BottomLeft)  | flip Y                   | Same as for JPEG         |
5 (LeftTop)     | flip X; rotate 90° left  | Same as for JPEG         |
6 (RightTop)    | rotate 90° right         | Same as for JPEG         |
7 (RightBottom) | flip X; rotate 90° right | Same as for JPEG         |
8 (LeftBottom)  | rotate 90° left          | Same as for JPEG         |

And for ImageMagick 7.0.9-5 ...

ORIENTATION     | EFFECT ON JPEG           | EFFECT ON TGA            |
----------------+--------------------------+--------------------------+
U (Undefined)   | None                     | flip Y                   |
1 (TopLeft)     | None                     | flip Y                   |
2 (TopRight)    | flip X                   | flip X & Y               |
3 (BottomRight) | flip X & Y               | flip X                   |
4 (BottomLeft)  | flip Y                   | None                     |
5 (LeftTop)     | flip X; rotate 90° left  | rotate 90° left          |
6 (RightTop)    | rotate 90° right         | flip X; rotate 90° right |
7 (RightBottom) | flip X; rotate 90° right | rotate 90° right         |
8 (LeftBottom)  | rotate 90° left          | flip X; rotate 90° left  |

User avatar
fmw42
Posts: 25762
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by fmw42 » 2019-11-21T15:06:10-07:00

Perhaps the issue is with Eye of GNOME. Does it look correct when you open in other tools such as GIMP?

lushkava
Posts: 3
Joined: 2019-11-19T23:09:43-07:00
Authentication code: 1152

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by lushkava » 2019-11-21T16:45:23-07:00

fmw42 wrote:
2019-11-21T15:06:10-07:00
Perhaps the issue is with Eye of GNOME. Does it look correct when you open in other tools such as GIMP?
Thank you for commenting. I do not think that the issue is with Eye of GNOME. GIMP honours the orientation value, if present. As such, the visible results are the same as reported, for both the JPEG inputs and the TGA outputs.

To borrow from this page on EXIF orientation, the effect of setting a particular orientation value should be as follows (as demonstrated with a crude depiction of the letter F).

Code: Select all

  1        2       3      4         5            6           7          8

888888  888888      88  88      8888888888  88                  88  8888888888
88          88      88  88      88  88      88  88          88  88      88  88
8888      8888    8888  8888    88          8888888888  8888888888          88
88          88      88  88
88          88  888888  888888
These depictions match exactly my verbal descriptions of the effect of injecting these same values into the provided JPEG sample before viewing. Note that the effects upon the TGA outputs for the conversion I am performing are exactly the same as this depiction, in the case of v6.9.5-10. For v7.0.9-5, however, there is no orientation value - of all eight that are supported - for which the resulting TGA image does not render in a contradictory way in all of the tools I've tried. Not a single one!

To provide a little background, the images I work with are produced - and consumed - by users of a wide variety of feature and smart phones. I use -auto-orient for several reasons:
  • some of the images received have a legitimate orientation value, owing to the existence of a sensor in the producing device
  • for my workflow, it is safer to use -auto-orient up front rather than trust the downstream (highly diverse) decoder/viewer implementations
  • because of the use of intermediate formats for certain conversions, adapting to TopLeft at the earliest stage ought to be safer
  • I need to strip as much metadata as possible, for privacy reasons
After upgrading ImageMagick, I was deluged with complaints that images were appearing as "upside down". After learning of this, I was quickly able to identify v6.9.5-10 as being the last 'safe' version for me to use. In the overwhelming majority of cases, I believe that users were uploading JPEG images with either no orientation value, or a value of 1 (TopLeft). As noted in my previous post, both cases do indeed result in a vertical flip in newer versions.

Code: Select all

ORIENTATION     | EFFECT ON JPEG           | EFFECT ON TGA            |
U (Undefined)   | None                     | flip Y                   |
1 (TopLeft)     | None                     | flip Y                   |
But all of the conversions are actually wrong, in my case. This seems like a major regression to me.

User avatar
magick
Site Admin
Posts: 11099
Joined: 2003-05-31T11:32:55-07:00

Re: Flipped TGA file when Image Origin isn't BottomLeft

Post by magick » 2019-11-22T06:32:14-07:00

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ http://www.imagemagick.org/download/beta/ by sometime tomorrow.

Post Reply