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: 10849
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: 1
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.

Post Reply