ImageMagickのrotateはバージョンによってoFFsが付いたり付かなかったりする

試したのはCentOS 6と7の標準リポジトリに入っているImageMagick

CentOS 6

$ cat /etc/redhat-release
CentOS release 6.10 (Final)
$ convert --version
Version: ImageMagick 6.7.2-7 2017-03-22 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP
$ convert logo: -rotate -45 norepaged6.png
$ identify norepaged6.png
norepaged6.png PNG 792x792 792x792+0+0 8-bit DirectClass 147KB 0.000u 0:00.000

CentOS 6のImageMagick 6.7.2-7のrotateではoFFsチャンクは埋め込まれない。

CentOS 7

$ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
$ convert --version
Version: ImageMagick 6.7.8-9 2019-08-08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features: OpenMP
$ convert logo: -rotate -45 norepaged7.png
$ identify norepaged7.png
norepaged7.png PNG 794x794 794x794-77-157 8-bit DirectClass 119KB 0.000u 0:00.000

CentOS 7のImageMagick 6.7.8-9でrotateすると、「640x480の画像が左右77ピクセルずつ、上下157ピクセルずつ拡張された」という意味合いでかoFFsチャンクが埋め込まれる。

oFFsが埋め込まれていようといまいと単体で見る分には違いは出ないが、画像編集では影響が出てくる。

例えば先ほどrotateさせたoFFs有りの画像をImageMagickでcropすると

$ convert norepaged7.png -crop 200x200+100+100 norepaged7_crop.png
$ identify norepaged7_crop.png
norepaged7_crop.png PNG 200x200 794x794+100+100 8-bit DirectClass 21.5KB 0.000u 0:00.000

f:id:chryfopp:20191028224737p:plain
norepaged7_crop.png

こうなるが、rotate後にrepageしてoFFsを取り除いてからcropすると

$ convert logo: -rotate -45 +repage repaged7.png
$ identify repaged7.png
repaged7.png PNG 794x794 794x794+0+0 8-bit DirectClass 119KB 0.000u 0:00.000
$ convert repaged7.png -crop 200x200+100+100 repaged7_crop.png
$ identify repaged7_crop.png
repaged7_crop.png PNG 200x200 794x794+100+100 8-bit DirectClass 6.24KB 0.000u 0:00.000

f:id:chryfopp:20191028224702p:plain
repaged7_crop.png

こうなる。