テクノナビ

Raspberry Piフォトフレーム：主なスライドショーオプションと温度監視スクリプト

Raspberry Piフォトフレーム：主なスライドショーオプションと温度監視スクリプト

デジタルフォトフレーム

以前の投稿で、リビングルームにRaspberry Piで動くデジタルフォトフレームを作ったと書きました。1時間ごとに240枚の写真が15秒間隔で切り替わります。以前は、R Pi 3でフレームバッファ画像ビューア「fbi」を使っていました。Raspberry Pi OS（Debianのリスキン版で、以前はRaspbianと呼ばれていました）を最新バージョンにアップグレードしたかったので、R Pi 5に移行する時期だと判断しました。

fbiはRaspberry Pi OS（別名Bookworm）でも動作しますが、夜間にHDMIのオン/オフを切り替えるtvserviceコマンドは動作しません。そのため、 前述の通り、これを再設計する必要がありました。そのため、Xウィンドウベースのセットアップに移行する必要があり、Raspberry PiまたはLinuxでフルスクリーンスライドショーを実行するための主要なオプションをいくつか挙げてみたいと思います。

周辺インフラ

この環境では、1時間ごとに作成される画像の「​​プレイリスト」を作成しています。これには、1920×1080の背景に撮影日を表示し、季節ごとのポスターやインスピレーションあふれるポスターを交互に表示するコードが含まれています。これについてはここでは詳しく説明しませんが、ImageMagickを使えば素晴らしいことができるということをお伝えしておきます。

重要なのは

  • 毎時間240枚の画像からなる新しいプレイリストを作成しています。中には、有名なモニュメントや心に響く名言などをフルスクリーンで表示したJPG画像もあれば、背景に配置した写真もあります。
  • 後者の場合、ImageMagickでUUID名のJPGを作成します。
  • 1時間ごとに既存のスライドショーを終了し、その時間のプレイリストで再開します。

ソフトウェアオプション

ImageMagick animate:これは次のようになります

これを選択しなかったのは、私のプレイリスト（ファイルのリスト）が、日付やテーマなどでソートされた複数のディレクトリにあるファイルを指しているからです。また、これらのファイルの多くは動的に作成されるため、以下のような名前になっています。 animate -pause 15 *.jpg

 /pictures/img_gen/ photo_ffe5a9b2-7087-4b29-9d26-77dfe948fce4.jpg

これは65文字で、240×65 = 15,600文字となり、Linuxのコマンドラインの最大文字数（4Kだったと思います）を超えています。各ファイル名を明示的に「animate…」と指定しても、ディレクトリ内のすべてのファイルを「*.jpg」と指定しても、シェルがワイルドカードを展開するので、実際には問題ありません。

Eye of Gnome (eog):これは…まあいいや。インストールしたけど

  • manページは非常に簡潔です
  • eog –help はマニュアルページには記載されていないフラグについて説明しています
  • プロジェクトのホームページにはドキュメントが全くない

私にとってはちょっと長すぎるようです。

mplayer:実際に試したわけではないのですが、調べているときにこのアプリについて言及されているのを見ました。mplayer は、もちろん動画プレーヤーですが、スライドショー アプリとして利用することもできます。

ふー： mplayer mf://*.jpg -mf fps=10

いよいよ本格的な競合相手が登場します。fehは「軽量で、設定変更も容易で、多機能な画像ビューア」で、コマンドラインユーザー向けに設計されています。例えば、次のようにスライドショーとして使用できます。

 feh --verbose --geometry 1920x1080 --borderless --hide-pointer \
--スライドショー遅延 15 -f ファイルリスト.txt

これが最初の選択肢だったのですが、どういうわけか、私のRPiではfehが頻繁にハングアップしてしまいました。画面が真っ暗になり、再起動するまでそのままの状態でした。この現象を特定の写真に絞り込もうとしましたが、ランダムで、私の写真や生成された画像はすべてfbiと次のアプリで完璧に切り替わりました。また、--verboseオプションが実際には冗長表示になっていなかったのにはがっかりしました。cronから呼び出されたスクリプトからfehを呼び出し、stdoutとstderrを出力ファイルにリダイレクトしていたのですが、常に空でした。

公平を期すために言うと、これはR Pi OSパッケージマネージャーのfeh 3.9.1-2でした。fehのウェブサイトにはそれ以降のバージョン（3.10）が掲載されているので、これらの問題は解決されているかもしれません。

しかし、その後私は発見しました…

優勝者: 素晴らしい

マニュアルページによると、 Impressiveは「見た目が美しいプレゼンテーション ツール」です。

Impressiveは、PDF文書、画像ファイル、または動画ファイルのスライドショーを表示できるシンプルなプレゼンテーションプログラムです。レンダリングはOpenGLで行われるため、視覚的に美しい効果が得られます。

これはSourceForge でホストされています…ゾッとします…しかし、それが唯一の欠点です。

以下にコマンドラインの例を示します。

印象的 --verbose --cache memory --wrap --auto 15 \
--fullscreen --geometry 1920x1080 @/some/path/to/filelist.txt

–auto フラグは、各「スライド」（私の場合は画像）が何秒前に自動で進むかを指定します。–wrap は「最後のスライドの後に最初から再生」という意味なので、おそらく必要ないと思います。ファイルリストの「@」に注意してください。

Impressiveの…いや、ちょっと待ってください…素晴らしい機能リストの1%くらいしか使っていないと思います。Pythonという組み込みスクリプト言語を使えば、非常に高度なプレゼンテーション制御が可能です。このアプリで私がやっているのは、おそらく最もシンプルなことなのでしょう。

Impressiveのいいところは、単純に各号に切り替えるのではなく、ワイプやフェードなどのトランジションをランダムに使うところです。本当に目を楽しませてくれます！もちろん、トランジションなどを選ぶこともできますが、私は特に指定せずに「すべて使う」ようにしています。

Impressive は起動時に Pillow ライブラリから非推奨の API に関する警告をいくつか出力します。アプリのニュースを見ると、これらの警告は Impressive の最新バージョン (0.13.2) で修正されていることがわかりますが、私はパッケージマネージャーから入手した 0.13.1 を使用しています。これらは単なる警告であり、アプリの動作には影響しません。

Impressiveのキャッシュ

Impressiveを使い始めた当初は、フリーズしてしまいました。CPU使用率も100%まで上がりました。リビングに入ってくると、画面遷移の途中でフリーズしてしまうことが何度かありました。本当に残念でした。

諦めようと思っていたところ、 --cache memoryオプションに気づきました。

キャッシュがない場合、Impressive は各ページを表示する前に事前にレンダリングする必要があります。これはプレゼンテーションソフトウェアなので、.PDF ファイルを扱っていると想像してみてください。Impressive は次のページを解析し、ページ上でどのように表示されるかをレンダリングするなど、処理が必要になります。

Impressiveはデフォルトでディスクにキャッシュします。これは一般的なラップトップでは問題ありませんが、Micro SDカードを搭載したR Piではディスクを酷使していました。--cacheメモリオプションは、マニュアルページに記載されており、「最速」です。  方法、  しかしそれは  必要  非常に大きなメモリ量（ 1024×768 解像度で 1 ページあたり約 3 MiB）

少しナイーブかもしれませんが、私の考え方は次のとおりです。

  • 1024×768 = 786,432ピクセル
  • 1920×1080 = 2,073,600ピクセル
  • つまり、1920×1080は1024×768よりも約2.6倍サイズが大きくなります。つまり3倍です。
  • つまり、おおよそ 1920×100 では 1024×768 の 3 倍、つまり 9MiB の RAM が必要になります。

1時間あたり240枚の画像で「プレゼンテーション」すると、(240*9MiB = ) 2.16GBになります。私のR Pi 5は4GBのRAMを搭載しているので、問題ありません。

Impressiveは実際にメモリ使用量を報告します。呼び出しとレンダリング後、以下のように出力されます。

バックグラウンド レンダリングが終了しました。メモリは 1423.8 MiB 使用されました。

つまり、画像 1 枚あたり 6 MB 弱になります。

Impressive の実行では、まだ十分な余裕があります。

 # 無料 -m
               合計        使用済み        無料      共有  バフ/キャッシュ  利用可能
メモ:            4042        2166        879        101        1170        1876
スワップ：            99          0          99

熱衝撃

以前のR Piとは異なり、R Pi 5は熱に少し敏感です。大量の処理を実行してボードが熱くなることはありませんが、ボードは冷却されるまでパフォーマンスが低下します。この熱ストレスはボードにとって良くなく、当然パフォーマンスも低下します。

ファンの代わりにアルミ製ヒートシンクケースを採用したのは、24時間365日稼働するファンはいずれ交換が必要になると思われ、Piをそれほど激しく駆動する予定もなかったためです。

しかし、私はこう考えました…実際、Impressive は 1 時間ごとにキャッシュとレンダリングを実行しており、バックグラウンドでは ImageMagick が動作し、通常の OS の処理で Wi-Fi とディスプレイが駆動しています…これらすべてが実行中の間、ボードに負荷をかけているのでしょうか?

1 分ごとに温度情報をファイルにダンプする cron ジョブを作成しました。

 /usr/bin/echo "$(/usr/bin/date) $(/usr/bin/vcgencmd measure_temp)" \
>> /pictures/log/temperature.$(date '+%Y-%m-%d').log 2>&1

これにより、ログ ファイルに次のような行が作成されます。

月 15 1 月 12:10:01 PST 2024 気温=42.2'C

次に、データを分析するための簡単なスクリプトを作成しました。

 #!/usr/bin/perl -w

my $file = shift || die "ファイルがありません!\n";
%ピーク = ();
$peak{'temp'} = 0;

オープン(IN,$ファイル);
while (<IN>) {
むしゃむしゃ食べる;
$info = $temp = $_;
$temp =~ s/^.*=//;
$temp =~ s/\'.*$//;
もし $temp > $peak{'temp'} であれば
$info =~ s/ temp=.*$//;
$peak{'date'} = $info;
$peak{'temp'} = $temp;
}
}
閉じる（IN）;
$ファール = sprintf("%.1f",( $peak{'temp'} * 1.8 ) + 32);
# 115.0ではなく115を出力します
if ( int($fahr) == $fahr ) { $fahr = int($fahr); }
print ("ピーク温度: $peak{'temp'}C (${fahr}F)、$peak{'date'}時\n");

今日の私の R Pi はこう言っています:

最高気温: 47.2℃ (117℉) 2024年1月15日月曜日 12:02:01 PST

おすすめの記事