完了した画像バッチは、受け入れられた出力で数えます。

オリジナルに触れずに入力を棚卸しする

ファイルを数え、そのフォーマット、寸法、特性を記録します：写真、イラスト、透過、テキスト、細部、または非常に大きな画像。開けることを確認します。設定のせいにする前に、読めないファイルを見つけ出します。

元のファイルは別のフォルダに保管してください。各エントリに識別子を割り当て、完全なパスを一覧に記録しておきましょう。2つのサブフォルダにそれぞれ image-01.png という名前のファイルが存在する場合があります。そのコンテキストを削除すると上書きのリスクが生じます。この区別を保ち、納品時に想定される名前と互換性のある出力ルールを選んでください。

ソフトウェアを起動する前に出力基準を書く

サイズ、フォーマット、構図、透過の有無を定義します。変更してよい範囲を明確にします：背景の削除は、ロゴや文字を変更してよいことを必ずしも意味しません。製品カタログでは、細部の忠実さが、全体的に見栄えが良くなることより重要かもしれません。

リサイズとトリミングを区別します。1,600×1,200ピクセルの画像は4:3の比率です。比例を保って幅400ピクセルに縮小すると、高さは300ピクセルになります。したがって400×400の出力には追加の選択が必要です：トリミング、余白の追加、または変形。この選択をサンプルで承認させ、デフォルト設定にフォルダ全体を決めさせないようにします。

• 期待する寸法と構図ルール。
• 保持すべきファイル形式と透過。
• 損なってはならないテキスト、ブランド、被写体の細部。
• 命名と、出力を開くツール。
• 結果を承認する担当者。

向き、透過、保持された情報を確認する

プレビューはピクセルとその表示情報の違いを隠すことがあります。一部の画像にはEXIFの向きが付いています。Pillowのドキュメントでは、この指示に従ってピクセルを転置し、その後に向き情報を削除する操作が説明されています。どのツールを使うにせよ、エクスポート後にファイルを開き直して、回転が欠けたり二重に適用されたりしていないか確認してください。

透明性も確認すべき情報の一つです。Pillowは主に、3つのカラーチャンネルを持つRGBと、追加のアルファチャンネルを持つRGBAを区別します。変換や書き出しによって、保持される情報が変わることがあります。納品物を複数の媒体に組み込めるようにする必要がある場合は、明るい背景と暗い背景の両方でオブジェクトの輪郭を確認してください。

ソフトウェア内部のプレビューだけに頼らないでください。いくつかの出力を使い先のツールで開き、使用サイズで寸法とディテールを確認します。プロジェクトが正確なカラープロファイルやメタデータを必要とする場合は、それらの保持も基準に加え、書き出したファイルのプロパティを確認してください。

不具合を明らかにできる12件のケースを選ぶ

大小の画像、ベタ塗り、テクスチャ、暗い領域、文字、透過など、該当する場合は多様な12件の入力を選びます。この数は出発点であり、代表性を保証するものではありません。表は、架空の計画における12件のうち4つの識別子を説明したものです。これらの基準を定めるために処理されたファイルはありません。

まず1枚の画像から始め、次に小さなグループへ進みます。設定とバリアントは分けて保存します。処理後は、受理または修正が必要のいずれかを、確認された理由とともに記録します。表の基準は結果ではありません。

Pillow の verify メソッドは、ピクセルを実際にデコードせずにファイルの欠陥を探します。レタッチの忠実性を評価するものではないため、この技術的チェックに加えて開いて目視で確認してください。

速度とメモリを混同せずにグループを増やす

同時に処理される画像の数は、ソフトウェア、寸法、手法、そして実際に使用されるメモリによって異なります。グループサイズを決める前に、大きな入力で試験してください。完了した数、エラー、そしてメモリや時間に関する観察を、その条件とともに記録します。

メモリ不足でグループが失敗した場合は、まず同時に処理する画像の数を減らしてください。それでも単一の入力が失敗する場合は、ソフトウェアの文書化されたオプションと、別の容量の必要性を検討します。画像の分割を提案するツールもありますが、その有無とつなぎ目への影響を確認する必要があります。

小さな画像1枚の所要時間を、そのまま300個の異なるファイルに当てはめないでください。読み込み、入力サイズ、やり直し、確認によって合計は変わります。最初の一区切りは、この変動性を観察するためでもあり、GPU モデルだけから処理能力を約束するものではありません。

実例：300点のビジュアルを納品まで追跡する

ショップ用の300枚の画像のバッチを想定します。12件のパイロットケースはこの300件の入力に含まれ、合計に追加されるものではありません。受理されると、その識別子は完了済みとしてマークされたままになります。その後、新規18件を含む最初の30件の区分を完了させてから、処理を広げます。

初回の処理の後、286件が受理、9件が修正待ち、5件が判読不能だとします：286 + 9 + 5 = 300。9件の修正から新たに7件が受理され、2件は依然として不正解です。入力の所有者は、判読可能な差し替えファイルを3件提供し、その出力はその後検証されます。

集計は 286 + 7 + 3 = 296 件が承認となり、4件が未解決です。これらの数字は追跡の一例であり、測定された結果ではありません。案件を300枚の納品として提示せず、4件の例外の処理を相手に判断してもらうか、この制限を明示的に了承してもらったうえで296ファイルを納品します。

各ファイルに正確な状態を付ける

追跡表は、入力ID、出力パス、使用した試行、判定、再作業の理由を結び付ける必要があります。「未着手」「進行中」「要確認の成果物」「承認済み」「要再作業」といった状態により、ディスク上に存在するだけでファイルを完了と宣言することを避けられます。

中断した場合は、この一覧から始めましょう。停止前に生成されたファイルを確認し、ソフトウェアの機能に応じて、承認されていないものだけを再実行します。フォルダ全体をやみくもに再開すると、バリエーションが再生成されたり、良い結果が上書きされたり、集計が複雑になったりする可能性があります。

新しいバリエーションは別の場所に書き出しましょう。採用した出力は、確認が済んでから置き換え、一覧内のリンクを更新します。バリエーション名が変わっても、入力IDは変わりません。

回収したコピーから納品を確認する

区別なくファイルを数えるのではなく、期待されるIDを数えましょう。1つの元データに複数のバリエーションがある場合があります。承認された各入力が、納品用に採用した出力を正確に1つ持つことを確認してください。サムネイル一覧は全体的なずれを見つけるのに役立ちますが、細部の輪郭やテキストはより詳細な確認が必要です。

採用した画像、一覧、有用なパラメータを保存先にコピーしましょう。このコピーから代表的なファイルを開き、重要な修正が必要だったすべてのケースも開きます。納品物と却下したバリエーションは分け、残っている例外を明記します。

最後に、レビュー・フィードバック・エクスポートを、3日・7日・30日の中から選んだ期間に組み込んでください。連続するシリーズでは、各バッチの間に長い待ち時間が生じることがあります。単発のバッチでは、複数回の修正が必要になることもあります。期間はプロジェクトの実際のスケジュールに基づいて決めるべきで、長期間だからといってより多くのビジュアルが保証されるわけではありません。