at backyard

Color my life with the chaos of trouble.

HEIC形式の画像ファイルをPNGへ変換するPythonスクリプト

Pythonで大量のHEIC形式の画像ファイルをPNGへ変換する必要に迫られたので、過去に非同期の書き方をメモしておいた自身のブログを読み返していた。

shinshin86.hateblo.jp

HEICファイルをPNGファイルに変換するためのPythonスクリプト

上のポストを参照しながら実装したのが、以下。
(ひとまずソースコードだけ上げていますが、READMEなどは後日追加します)

github.com

下記のように実行すれば対象ディレクトリ内のHEICファイルをPNGに変換する処理が動く。

git clone https://github.com/shinshin86/heic2png.git
cd heic2png

# 仮にtestディレクトリ内のHEICファイルを処理したいとした場合
python heic2png.py test

パフォーマンスについて

自身のM1 MacBook Airにて3000ファイルの画像を処理させて、1時間かからないぐらいの時間で処理が完了した。

M1 MacBook Airのコア数は以下で、アクティビティモニタで監視しているとだいたいスレッドは 13~20 ぐらい利用していたようだ。

8(パフォーマンス: 4、効率性: 4)

ちなみにPythonでasyncioを使った非同期処理を行う場合のスレッドプールなどの仕様は以下の通り。
(ただ、下記の説明を見ると8コアだと最大で12スレッドが動く形となりそうなので、 13~20 動いていたという自身の見解は誤りかも?一応アクティビティモニタのスレッドの数を参照していたが、仮想スレッドとかそういうのがあって実際のコア数よりも多かったりとかするのか?ちょっとここらへんは理解が浅いので適当なのことを言っているかもしれません。ご存じの方がいればコメントいただけると幸いです)

concurrent.futures -- 並列タスク実行 — Python 3.10.6 ドキュメント

Default value of max_workers is changed to min(32, os.cpu_count() + 4). This default value preserves at least 5 workers for I/O bound tasks. It utilizes at most 32 CPU cores for CPU bound tasks which release the GIL. And it avoids using very large resources implicitly on many-core machines. ThreadPoolExecutor now reuses idle worker threads before starting max_workers worker threads too.

同期処理だと途方も無い時間がかかる処理だったので、こういう形で一気に処理できるのはやはり気持ちいいなと思ったのでした。