PDFの図形透かし除去をどう実現したか: 候補集約から精密削除までの振り返り

オンライン版: https://www.douyacun.com/pdf/remove-watermark

PDF の図形透かし除去は、やってみるまで軽く見積もりやすい問題です。最初は「同じ図形が何回も出ているなら、それを消せば終わりだろう」と考えがちです。

でも実際は、そこがいちばん危ないところでした。

図形透かしと正文の図形は、PDF の内部では同じ drawing/path として表現されていることがよくあります。アイコン、表の線、フローチャートのノード、ページ装飾と透かしが、ほぼ同じ種類のオブジェクトで並んでいるわけです。だからこそ、「繰り返しているから削除してよい」とは簡単に言えません。

結論から先に

結局のところ、図形透かし除去は「繰り返し図形を探す問題」ではなく、「どの繰り返し図形なら安全に消せるかを見極める問題」です。

位置だけを見ても足りません。色だけでも足りません。繰り返し回数だけでも足りません。実際に安定しやすかったのは、まず PDF の図形オブジェクトをきちんと取り出し、その断片を人間が判断しやすい候補へまとめ、最後に確認済みオブジェクトだけを消す、という流れでした。

この考え方は、図形透かしとスキャン透かしの違いにもつながっています。図形透かしは、可能なら PDF オブジェクト層にとどまった方が、結果がきれいで壊れにくいです。

図形透かしをどう見分けるか

最初の一歩は、スクリーンショットに枠を描くことではありません。ページの drawings や graphic blocks、content stream を読むことです。

ここで大事なのは、path の形、fill や stroke、bbox、stream scope、object ref といったオブジェクトの手掛かりです。後で精密に消せるかどうかは、ここで文脈を残せているかにかなり左右されます。

もう一つ大きかったのは、候補の出し方です。実際の透かしは、1 個の図形オブジェクトではなく、小さな drawing block の集まりになっていることが多いです。もし primitive をそのまま全部返すと、レビュー画面は断片だらけになります。近くにあって、形や色や繰り返し方が似ているものをまとめて 1 つの候補にした方が、ずっと判断しやすくなります。

そこまでできて初めて、「これは透かしっぽい」と言えるようになります。実際によく効くのは、位置の安定性、色の薄さ、テンプレートっぽい繰り返し、少し独立した stream から出てくること、といった地味な手掛かりです。それでも全部を自動削除候補にはしません。明らかなものは前に出し、迷うものはレビューに残します。

下の画像は 亿图图示水印.pdf の実ページです。見た目には灰色の繰り返し図形透かしが分かりますが、実際に安全に消すためには、その前に抽出と集約が必要です。

元のページだけ見ても、まだ半分しか分かりません。実際に何が検出されたのかを切り出して見ると、判断しやすくなります。下の画像は手描きの説明図ではなく、検出された図形オブジェクトをそのまま SVG にしたものです。

どうやって正確に消すか

図形透かし除去で避けたい失敗は、結局 2 つだけです。消し切れないことと、正文図形まで一緒に消してしまうことです。

そのためには、apply 段階で単なる矩形だけを渡すやり方では弱いです。ページ全体を画像として塗り直すやり方も、できるだけ避けたいです。やはり安全なのは、検出時に拾った graphic_items、object_ref、graphic_rect などをそのまま持ち越し、確認されたオブジェクトだけを編集することでした。

つまり、削除粒度はオブジェクト単位であるべきだということです。

亿图图示水印.pdf では、1 ページ目で 16 個の候補にまとまり、それが最終的に 62 個の実図形オブジェクトに展開されます。レビューで見えるのは少数の候補カードですが、実際に消しているのは content stream レベルで特定した図形です。これなら、近くにある正文アイコンやコネクタを巻き込みにくいですし、ページ全体を画像化せずに済みます。

下の局所プレビューは、集約後の実候補の 1 つです。単一路径ではなく、繰り返し図形のまとまりをレビューしやすい形で見せています。

確認後は、その候補に対応するオブジェクトだけを削除し、他の図形層には触れません。

ここで一番大事なのは、精度が画像補修のうまさから生まれるのではなく、オブジェクトをどれだけ正確に特定できるかから生まれる、という点です。

大きい PDF が遅くなる理由と対処

大容量 PDF が遅くなる理由は、たいてい削除そのものではなく、前段の図形解析と preview 生成にあります。

ページ数が多くて drawing が多いだけで、抽出と比較はかなり重くなります。そこに候補の膨張が乗ると、さらに厄介です。occurrence をそのまま全部返せば、レビュー画面も API payload もすぐ重くなります。

それに、すべてのページでフル preview を作る必要があるわけでもありません。見た瞬間に高複雑度だと分かるページは、まず compact な候補だけ返して、必要なものだけ後で preview を取る方が現実的です。

だから効果があった最適化は、むやみに並列化することではなく、うまく降格することでした。複雑度を先に見る、候補を早めにまとめる、重いページは軽く返す、それでも最終削除はオブジェクト単位を崩さない。このあたりが効きます。

下の画像は 图形水印-大文件_韩顺平.pdf の実ページです。この種のファイルで本当に重要なのは、不要な解析と不要な preview 生成を減らすことであって、すべてのページを同じ重い経路に流し込むことではありません。

一方、高考密练条约.pdf のようなより規則的なページでは、少数の安定候補だけで review が済みます。簡単なページと複雑なページを同じコストにするべきではありません。

実際のサンプルと結果

この記事のスクリーンショットは、全部実ファイルから取っています。

ケース1

亿图图示水印.pdf は、主経路を説明するのにいちばん向いている例です。1 ページ目では 16 個の候補にまとまり、最終的には 62 個の実オブジェクトに展開されます。下の 3 枚は、元ページ、検出された図形の SVG、削除後のページです。

ケース2

高考密练条约.pdf は、もっと軽いケースです。1 ページ目では候補は 1 つだけで、そこから 7 個の実図形オブジェクトに展開されます。こういうページは、重い review をしなくても進めやすいです。

ケース3

图形水印-大文件_韩顺平.pdf は、大容量ファイル側の例です。ここでは「大きいから重い」という話だけでなく、実際に元ページ、検出された図形、削除後の結果までそろえて見せられることが大事です。

この 3 つのケースを並べると、「見つけられる」だけでなく、「実際に消せる」ことまでかなり分かりやすくなります。

向いているケースと限界

このやり方がいちばん向いているのは、透かし自体が PDF の図形オブジェクトとして残っているケースです。スキャン画像に焼き込まれた透かしとは、やはり別問題です。

逆に、正文図形が極端に密で、しかも透かしとの見た目差が小さいページでは、無理に自動化しすぎると危ないです。

だから自分の中では、この機能のゴールは「何でも自動で消すこと」ではありません。オブジェクト層で確信が持てるところはしっかり消し、危ないページではちゃんと慎重に振る舞うこと。そのバランスがいちばん大事だと思っています。