ページの作成日を確認のうえご覧ください。内容が古くなっている場合があります。bridgeはすぐれたソフトウエアですが、使用実態によっては動作がひどく重くなるだけでなくOSや他のソフトウエアの動作にも影響を与える場合があります。原因は読み込んだ画像のキャッシュをメモリ(RAM)につくることに起因し、動作を観察するとメモリの消費量は読み込む画像の総容量に匹敵するのがわかりました。bridgeを使ううえであまり説明されていない点に言及しています。はじめにソフトウエアの操作感や動作が重い、ぎこちない、処理が待たされる場合、コンピュータの処理能力不足であったり、呼び出すデータが巨大であったり、メモリをバカ食いしていたりと複数の原因が考えられる。これは特定のソフトウエアに限った困りごとではなく、同時に起動している他のソフトを巻き込んでやっかいな問題になるし、OSの挙動そのものを怪しくする場合すらある。2021に至っても使う環境、使い方次第で動作がとてつもなく重くなるケースに直面する。Bridgeは画像管理ソフトの代表格だ。画像を並べて表示してメタデータ等をチェックして、書き換えをしたり、分類したり、他のソフトウエアに処理を橋渡ししたりする。多くの人がカメラRAWやカメラRAWから書き出した画像を整理・管理・処理するため使用していると思うが、こうした使い方をしているならメモリにキャッシュとして容量がかなり大きいデータを書き込んでいる。キャッシュの有無による結果の違いは、アシスタントに「あれ出して」と命じたときさっと出してくるか、待たされるかの違いに相当するだろう。Bridgeと同時に起動しているソフトウエアに悪しき影響がもたらされている。Bridgは起動すると前回終了時に表示していたフォルダ内の画像を再び表示しようとする。前回何も表示していない状態で終了しているなら、起動後の操作でフォルダー内の画像を表示させようとしたとき以下のプロセスがはじまる。Bridgは画像を読み込んでディスプレイにサムネイルを表示する。Bridgは読み込んだ画像をキャッシュとしてローカルストレージ内に保存する。[お気に入り]に登録しているフォルダ内の画像だけでなく、一時的に読み込んで表示したフォルダ内の画像も保存される。過去に読み込まれた画像は保存期間内なら保存されたままだ。キャッシュは以下のフォルダ内にある。CS[バージョン番号]/Cache/元画像がPhotoshop形式だった場合キャッシュはPNG形式で保存される。RAW、TIFF、JPEG形式の場合はJPEGで保存される。これは憶えておいたほうがよい。Bridgの環境設定で指定している保存期間が過ぎたら消去されるのだろう。ローカルストレージ内のキャッシュは小サイズのサムネイル用、中サイズのサムネイル用、100%プレビューをキャッシュする設定になっていれば[full]フォルダーに実寸の画像が保存される。いずれも前述のファイル形式に変換されている。(100%プレビュー用の実寸画像は、等倍プレビューをした段階でつくられる)起動中から起動後、ディスプレイ上に表示する画像がメモリにロードされキャッシュされる。ここまでが起動してサムネイルが表示される段階で行われる処理だ。Bridgの動作を、使用メモリー量と仕分けがリアルタイムでわかるソフトウエアを使って観察してみた。Bridgは大量のキャッシュをメモリ上につくる。後述するが、表示させようとしているフォルダ内の画像の総容量に等しいほどメモリを消費する。これがメモリ食いの原因と言ってよい。次に別のフォルダ内の画像を表示させると、メモリ上のキャッシュが更に増える。これを繰り返して行くと全メモリーを食い尽くす勢いで使用量が増える。逐次フォルダに画像を保存するたびローカルストレージだけでなくメモリにもキャッシュがつくられるからメモリの消費は増える。いずれも画像の総容量に等しいほどの容量だ。Bridgeに表示させているなら、このフォルダ内の画像をあらためて表示させてもメモリ上のキャッシュは増えない。キャッシュされているのだからあたりまえだし、そうでなかったらキャッシュする意味はない。Bridgeはメモリ上に大量のキャッシュを用意して可能な限りの領域を占有しようとする。他のソフトウエアが起動していたり、あらたに起動させたりするとメモリを譲るが、いずれにしろメモリー食いであるし他のソフトウエアの起動から動作まで悪影響を及ぼす場合がある。コンピュータの動作が重く怪しくなったり、プチフリーズやフリーズするとき搭載メモリのすべてを使い切っているか、空き領域があっても100MB以下だったりするのがわかった。Bridgのメモリ消費がここまでとは思っていなかったので驚いた。Bridgを終了させるとメモリ使用量が減るのは当然だが、起動1回目の終了時にキャッシュ含めきれいに片付いたかと思うと、2回目の起動後に終了したときおびただしい容量が残されたままになっていたりする。このような場合、OSの整理整頓機能が有効に働かないようなのでメモリ管理ソフトを積極的に使ってメモリの開放・圧縮を行うほかないようだ。Bridgがメモリを大量に確保して消費するため、同時に起動させている他のソフトウエアが十分なメモリを確保できず巻き添えになって挙動が怪しくなる場合がある。Bridge......という連携・組み合わせは珍しくないのだから頭の痛い問題だ。Bridgにはストレイジ内につくられたキャッシュを管理する機能、消去する機能はあるが、ユーザーはメモリ上のキャッシュについてほぼ手出しできない。1フォルダ内に保存している画像点数、画像の総容量が多いならメモリを搭載可能な上限まで積めるだけ積んでおけとなりかねない。メモリをさらに搭載する余地があるなら容量を増やす選択肢があるが、そうしても限りなくキャッシュをつくる性格のソフトウエアなのでいつか限界に達する可能性があるのは前述の通りだ。表示するフォルダ内の画像容量を少なくする。同時に使用するソフトウエア数を制限する。メモリ管理ソフトを使ってメモリの開放・圧縮を行う。以外の対策は思いつかない。Bridgなみにキャッシュをつくらないソフトウエアがあり他の要素が納得行くなら変えてみるのも手だ。人それぞれ画像管理に何を求めるものが違うので、具体名を挙げてどれがいいと私は言えない。最終的に行き着くのは「表示するフォルダ内の画像容量を少なくする。画像点数を減らす」=必要最小限にすることでキャッシュの容量を小さくする方法だ。1]を実行するとして、1フォルダーあたり何GB程度までならよいのだろうか。次のような実験をしてみた。Bridgがローカルストレージにキャッシュをつくっていないフォルダ=まったく新規のフォルダを開いて、ローカルストレージに何GB、メモリに何GBのキャッシュが生成されるか計測する。元フォルダ(TIFF画像のみ)=7.8GB、ローカルストレージ内のキャッシュ=計82MB、キャッシュ=7GB程度であった。Bridgと他ソフトウエアで6GBくらいメモリを使用し、その他のメモリ使用量が4GBだったとする[32GB-(6GB+4GB)]。Bridgがキャッシュで埋め尽くせる容量は20GBを超えるが、空き領域がすべて使用されてしまっては他のソフトウエアが動作するうえでまったく余裕がない状態になる。余裕がないからOSさえもいっぱいいっぱいになってプチフリーズやフリーズに至る。メモリを64GBなど更に搭載しているならキャッシュに使える空き領域は増えるが、可逆圧縮画像が200点を超えるなら50GBくらいになるだろうから複数のフォルダを行き来して画像を見たり操作しているうちにさっそくメモリ不足に陥るし、1フォルダに多数の画像があったり1画像あたりの容量が大きいならそれだけ空き領域が圧迫される。メモリ上にキャッシュされていない画像を追加するなら次々とキャッシュでメモリが圧迫されて行く。Bridgだけで作業するならまだよいが、他のソフトウエアでも同時に作業をするなら開くフォルダーの総容量は搭載メモリ容量の1/3以下にするのが理想のように思われるし、実態と照らし合わせてどのあたりまで不都合がないか各自の環境で探ってみたほうがよい。メモリ管理ソフトを使ってメモリの開放・圧縮を行って、常に余裕ある空き領域を確保するのもよいだろう。メモリ管理はOSの仕事だが、メモリ開放の条件を設定できたり強制的に開放可能な管理ソフトは便利だ。当記事の結論としては、画像を保存するうえでフォルダ単位でどのように分類すべきか整理法から再検討したほうがよいということになる。私は単発の写真でないなら、テーマごと基本的に1年単位(画像が増えすぎたなら半年単位)1フォルダで整理してきた。同一RAWデータからつくった制作バージョン違いの画像も、この年単位のフォルダに放り込んでいた。これらはともすると数十GBから100GBにまで膨れ上がるのだった。bridgeで操作したいのだがメモリ問題の壁にぶつかる。そこでいま、整理法の再検討に入った。Bridgの使い勝手と、そもそも整理法が合理的ではない点もあるのだからしかたないと思っている。・スタジオ助手、写真家として活動の後、広告代理店に入社。・2000年代初頭の休止期間を除き写真家として活動。