Control: retitle -1 gm(1): improve targa (.tga) orientation bits support
>>>>> Bob Friesenhahn writes:
> However, I believe that this bug report is incorrect.
After reading [1] (and trying both ImageMagick and
GraphicsMagick on the samples*/ provided therein), I guess
my suggestions would be as follows.
1. GraphicsMagick .tga reader should support all the
combinations of the orientation bits, not just the default
‘bottom left’; (I gather that’s something already in Git?)
2. It should be possible to specify orientation explicitly
both when reading .tga files (my understanding is that files
produced by buggy .tga writers that get these wrong are not
uncommon in the wild) and when writing them (for the benefit
of legacy readers that only implement a specific orientation;
a quick look into LDPCXTGA’s ldtga.cpp has confirmed that it
ignores all the .tga metadata but width and height fields and
assumes the non-default TopLeft orientation.)
I haven’t checked the source, but it seems that at least
-orient is ignored by the GraphicsMagick .tga writer.
3. I’d think the documentation should feature -auto-orient
more prominently in the examples.
(I’ve retitled the bug report accordingly.)
TYC.
[1] http://gitlab.com/illwieckz/produce-reference-tga
> What has actually happened is that ImageMagick changed what it
> returns and more recent ImageMagick also changed what it does
> when it displays an image.
It sounds like the behavior of ImageMagick’s display(1)
was reversed exactly twice, which should’ve resulted in the
original behavior being restored, at least so long as the
user is concerned. What am I missing here?
> GraphicsMagick always returns an image in the common normal form
> (TopLeft). ImageMagick changed so that it returns an image in
> the same form as the file, but it sets an orientation option so
> that the user needs to use -auto-orient to see a correct image.
Seems to be the case for .tga images, indeed.
--
FSF associate member #7257 http://am-1.org/~ivan/
