【固定した記事】デジタルアーカイブシステムの技術ブログへようこそ
デジタルアーカイブシステムの技術に関するブログです。特に、OmekaやIIIF、TEIなどに関する記事を執筆します。
Omekaの使い方に関する情報は、以下の記事にまとめています。
Omeka.net(Classic)の使い方に関する情報は、以下の記事にまとめています。
カテゴリ「IIIF」の記事は以下です。
カテゴリ「TEI」の記事は以下です。
その他の記事については、カテゴリなどからご確認ください。
「Google ドライブでエラーが発生しました。」が生じた時の対処方法:共有ドライブのゴミ箱を空にするスクリプト
概要
共有ドライブに対して大量のファイルを作成した際、以下のように「Google ドライブでエラーが発生しました。」が表示され、ファイルを保存できなくなる事象に出会いました。
上記の原因として、以下に示す共有ドライブの制限に引っかかったことが考えられます。
https://support.google.com/a/answer/7338880?hl=ja
共有ドライブに保存できるアイテム数の上限 共有ドライブに保存できるアイテム数は最大 40 万個です。これにはファイル、フォルダ、ショートカットが含まれます。
1 日のアップロードの上限 個々のユーザーがマイドライブおよびすべての共有ドライブにアップロードできるのは、1 日あたり 750 GB までです。
2つ目の「1日のアップロードの上限」に引っかかってしまった場合には、1日待つほかないと思います。
一方、1つ目の「共有ドライブに保存できるアイテム数の上限」について、不要なファイルを削除することで対応することができます。
ただし、単にファイルを削除しただけでは、それらがゴミ箱に残ってしまい、(おそらく)先の制限を解除することができません。そこで、共有ドライブのゴミ箱を空にするスクリプトを探したところ、以下の記事に辿り着きました。
以下、上記で紹介されているスクリプトの使用方法について説明します。これにより、先述した「共有ドライブに保存できるアイテム数の上限」に引っかかってしまった際、その制限を解除することができます。
共有ドライブのゴミ箱を空にするスクリプトの実行方法
以下のスクリプトをコピペして利用します。
const driveId = "<共有ドライブのID>"; function myFunction() { var optionalArgs={driveId, 'includeItemsFromAllDrives':true, 'corpora': 'drive', 'supportsAllDrives': true, 'q':'trashed = true' } while(true){ var trashed=Drive.Files.list(optionalArgs).items; console.log("削除対象のファイルサイズ", trashed.length) for(var i=0;i<trashed.length;i++){ //console.log(i, trashed[i].id) try { Drive.Files.remove(trashed[i].id, {'supportsAllDrives':true}) } catch (e){ //console.log({e}) } } if(trashed.length == 0){ break } } }
まず、以下のURLにアクセスしてください。
https://script.google.com/home
そして、下図に示す、「新しいプロジェクト」をクリックします。
先のスクリプトをコピペしてください。コピペ後、一行目の「driveId」を変更し、画面上部の「保存」ボタンを押してください。
次に、サービスを追加します。「サービス」から「Drive API」を追加してください。
その後「実行」ボタンを押します。
初回は承認が求められます。
以下に示すように、100件ずつ削除されていきます。
一定時間が経過すると、以下のようにエラーが発生します。その場合には、再度「実行」ボタンを押してください。
まとめ
よりよい解決策があるかもしれませんが、「Google ドライブでエラーが発生しました。」等でお困りの方の参考になりましたら幸いです。
追記
2022.05.06
GASでは、スクリプトの実行時間が6分間という縛りがあるそうです。
https://developers.google.com/apps-script/guides/services/quotas#current_limitations
そのため、上記スクリプトを5分または10分おきに実行することで、ゴミ箱を自動的に空にすることができます。
具体的には、以下のように、トリガーを選択して、「トリガーを追加」ボタンをクリックします。
そして以下のように、「時間主導型」「分ベースのタイマー」「X分おき」を選択します。
参考になりましたら幸いです。
Google Colabを用いたgcv2hocrの実行例:Google Vision APIを用いた透明テキスト付きPDFファイルの作成
概要
gcv2ocrは、Google Cloud Vision OCR出力からhocrに変換して、検索可能なpdfを作成するリポジトリです。
https://github.com/dinosauria123/gcv2hocr
今回、上記リポジトリをGoogle Colabで実行するノートブックを作成しました。
以下のように、検索可能なpdfファイルを作成することができます。
使い方
以下のノートブックにアクセスします。
まず、Google Cloud Vision APIを使用するためのAPIキーを取得します。以下の記事などが参考になります。
https://zenn.dev/tmitsuoka0423/articles/get-gcp-api-key
APIキーを入力したら、以下の初期セットアップに関する3つの再生ボタンを押します。
その後は、以下に示す実行オプションから、適切なものを選択します。
- 画像
- 画像のURL
- 画像のアップロード
- PDF
- PDFのURL
- PDFのアップロード
- IIIF
- IIIF
例えば、「画像のURL」を指定する場合、以下に示す「設定」と「実行」の2つの再生ボタンを押します。
実行後、PDFファイルがダウンロードされます。また、認識結果等が出力されるパスが表示されます。
まとめ
gcv2ocrやhocr-toolsなど、便利なツールを開発してくださった方々に感謝いたします。
Google Colabを用いたGoogle Drive上のファイルの削除方法
Google Drive上のファイルをGoogle Colabを用いて削除する例を示すノートブックを作成しました。Google Drive上に不要なファイルを大量に作成してしまった際など、ご活用いただけますと幸いです。
Google Colabを用いたNDLOCRアプリのVersion 2を作成しました。
概要
Google Colabを用いたNDLOCRアプリを作成し、以下の記事で紹介しました。
今回は、上記ノートブックの改良版であるVersion 2を作成しましたので紹介します。以下からノートブックにアクセスいただけます。
https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ndl_ocr_v2.ipynb
特徴
複数の入力形式に対応しました。以下のオプションを使用できます。
- 画像
- 単一の画像ファイルのURLを指定する場合
- 単一の画像ファイルをアップロードする場合
- 複数の既にダウンロード済みの画像ファイルを対象にする場合(Sigle input dir mode)
- 複数の既にダウンロード済みの画像ファイルを対象にする場合(Image file mode: 単体の画像ファイルを入力として与える場合)
- PDF
- 単一のPDFファイルのURLを指定する場合
- 単一のPDFファイルをアップロードする場合
- 単一の既にダウンロード済みのPDFファイルを対象にする場合
- 複数の既にダウンロード済みのPDFファイルを格納したフォルダを指定する場合
- IIIF
PDFファイルやIIIFマニフェストファイルの入力をサポートします。また、Version 1では事前にGoogle Driveに画像ファイルをアップロードする必要がありましたが、Version 2では画像ファイルのURLの指定や、アップロードフォームによる登録機能を提供しています。
さらに、上記のいくつかのオプションにおいて、実行後に推論結果をマージしたテキストファイルをダウンロードする機能を提供します。ダウンロードしたテキストファイルをVoyantツールなどの他のアプリケーションに使用することができます。(なお本格的な分析にあたっては、認識結果の修正やトークナイズの方法など、各種調整が必要です。)
使用方法
1.初期セットアップ
以下に示す2つの実行ボタンを押してください。Googleドライブのアクセス許可が求められるので、許可してください。
2.設定
上述したオプションから、目的に応じたものを選択してください。各オプションに付与されたリンクをクリックすると、当該オプションの設定画面に遷移します。
実行後
実行後は、以下のように、出力フォルダが表示されます。設定において選択したprocessの値が「@(アットマーク)」とともにフォルダ名に付与されます。また既に出力フォルダが存在する場合には、フォルダ名の末尾に実行時間に基づくIDが「_(アンダーバー)」とともに付与されます。
また単一のファイルを処理するオプションを選択した場合、実行後、以下のようにテキストファイルがダウンロードされます。
まとめ
NDLOCRアプリの利用にあたって、参考になりましたら幸いです。
Nuxt 2を用いたMirador 3の使用例を紹介するGitHubリポジトリの修正
Nuxt 2を用いたMirador 3の使用例を以下のGitHubリポジトリで紹介しています。
https://github.com/nakamura196/nuxt-mirador
ただ上記のリポジトリにおいて、production環境において不具合が生じることがわかりました。具体的には、ページ遷移後にMiradorの表示が崩れてしまう不具合です。
送っていただいたissue
https://github.com/nakamura196/nuxt-mirador/issues/1
このissueについて、さらに不具合を修正したPull requestも送っていただきました。
https://github.com/nakamura196/nuxt-mirador/pull/2
具体的には、以下に示すように、beforeDestroyでunmountする必要がありました。
https://github.com/nakamura196/nuxt-mirador/pull/2/files
自分では不具合の解消方法が分かりかねたので、大変助かりました。
Nuxt(Vue)におけるMirador 3の使用において、参考になりましたら幸いです。
Google Colabを用いたNDLOCRアプリの更新:Sigle input dir modeの追加
概要
先日以下の記事およびノートブックを作成しました。
上記の記事執筆時点では、以下の入力形式にのみ対応していました。
Image file mode(-s f
で指定) (単体の画像ファイルを入力として与える場合はこちら)
ただ、以下の記事での検証により、複数の画像に対して上記のオプションを適用することは、オーバーヘッドが大きいことがわかりました。
そこで、以下の入力形式にも対応できるようにノートブックを修正しました。
Sigle input dir mode(-s s
で指定)※デフォルト
以下、上記入力オプションの使い方について説明します。
使い方
「2.設定」の「input_structure」において、「s」を選択してください。従来の「Image file mode」を使用する場合には、「f」を選択してください。
「input_structure」で「s」を選んだ場合、「extensions」の項目は無視されます。
また、入力フォルダの作成方法に注意点があります。以下の入力フォルダのパスを指定する場合を例とします。
/content/drive/MyDrive/ndl_ocr/input/
この時、以下のように、「input」フォルダの下に「img」フォルダを作成し、その下に画像を格納します。
上記の準備および設定を行なった上で実行を行うと、「Sigle input dir mode」によりOCR処理を実行することができます。
まとめ
今回作成したノートブックについて、「f(Image file mode)」を選択した場合、指定した入力フォルダ内の階層構造を特に意識せずに実行することができます。ただしこのモードでは画像ファイル毎にプログラムを実行するため、一部オーバーヘッドが生じます。大量の画像ファイルを対象に実行する場合には、「s(Sigle input dir mode)」を選択することをお勧めします。
誤った理解をしている点があるかもしれませんが、参考になりましたら幸いです。
Google Colabを用いたNDLOCRの実行にかかる時間について
先日、以下の記事を執筆しました。
今回は、Google Colabを用いたNDLOCRの実行にかかる時間について、かんたんな調査を行なったので、その結果をまとめます。
設定
GPUは以下です。
Fri Apr 29 06:26:29 2022 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 460.32.03 Driver Version: 460.32.03 CUDA Version: 11.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla V100-SXM2... Off | 00000000:00:04.0 Off | 0 | | N/A 35C P0 23W / 300W | 0MiB / 16160MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+
以下の画像を用いました。サイズは5000 x 3415 px で、 1.1 MB でした。
https://dl.ndl.go.jp/info:ndljp/pid/3437686/6
推論の処理内容として、以下の4つがありますが、今回は「レイアウト抽出」と「文字認識(OCR)」のみを実行しています。
- '-p 0': ノド元分割
- '-p 1': 傾き補正
- '-p 2': レイアウト抽出
- '-p 3': 文字認識(OCR)
Googleドライブの場合
マウントしたGoogleドライブをファイルの入出力に使用する場合について考察します。以下の入力オプションを使用します。
Sigle input dir mode(-s s
で指定)※デフォルト
1ファイルを対象に実行したところ、以下のような結果になりました。
ID | 処理 | タイムスタンプ | かかった時間(秒数) |
---|---|---|---|
p1 | 開始 | 2022-04-29 05:30:58 | 11 |
p2 | 推論の開始 | 2022-04-29 05:31:09 | 2 |
p3 | 終了 | 2022-04-29 05:31:11 | (合計) 13 |
p1からp2までの間は設定ファイル等のロードを行なっている時間です。画像に対する推論時間は2sでした。
同じ画像をもう1件登録して、2ファイルを対象に実行しました。
ID | 処理 | タイムスタンプ | かかった時間(秒数) |
---|---|---|---|
p1 | 開始 | 2022-04-29 05:38:02 | 10 |
p2 | 推論の開始 | 2022-04-29 05:38:12 | 6 |
p3 | 終了 | 2022-04-29 05:38:18 | (合計) 16 |
さらに、同じ画像をもう1件登録して、3ファイルを対象に実行しました。
ID | 処理 | タイムスタンプ | かかった時間(秒数) |
---|---|---|---|
p1 | 開始 | 2022-04-29 05:40:26 | 10 |
p2 | 推論の開始 | 2022-04-29 05:40:36 | 8 |
p3 | 終了 | 2022-04-29 05:40:44 | (合計) 18 |
上記の結果から、設定ファイルの初期ロードに10s程度かかり、各画像に対して、2~3s程度の処理時間がかかることがわかります。
冒頭で共有した私が作成したノートブックでは、複数の入力画像があっても、以下のオプションにより、画像ファイル毎にプログラム main.py を実行するようにしていました。
Image file mode(-s f
で指定) (単体の画像ファイルを入力として与える場合はこちら)
このことから、各画像ファイルに対して、1ファイル目を除き、初期ロードに要する10s程度の時間が不要にかかっていることになります。
実際、 Image file mode を用いて2つのファイルを対象に実行したところ、 Sigle input dir mode に比べて、ちょうど10s(初期ロードに要する時間)増加していることが確認できました。
ID | 処理 | タイムスタンプ | かかった時間(秒数) |
---|---|---|---|
p1 | 1ファイル目の開始 | 2022-04-29 05:52:59 | 11 |
p2 | 推論の開始 | 2022-04-29 05:53:10 | 2 |
p3 | 終了 | 2022-04-29 05:53:12 | 1 |
p4 | 2ファイル目の開始 | 2022-04-29 05:53:13 | 10 |
p5 | 推論の開始 | 2022-04-29 05:53:23 | 2 |
p6 | 終了 | 2022-04-29 05:53:25 | (合計) 26 |
(当たり前のことではありますが、)処理対象の画像数が多い場合には、 Sigle input dir mode を使用することをお勧めします。
(参考)GCS(Google Cloud Storage)の場合
今回は、Google ColabからマウントしたGCSを使用した場合についても計測してみました。各種設定によって結果は変わってくると思いますが、上述したGoogleドライブとの比較が目的です。
以下の入力オプションを使用します。
Sigle input dir mode(-s s
で指定)※デフォルト
1ファイルの場合
ID | 処理 | タイムスタンプ | かかった時間(秒数) |
---|---|---|---|
p1 | 開始 | 2022-04-29 06:06:08 | 13 |
p2 | 推論の開始 | 2022-04-29 06:06:21 | 13 |
p3 | 終了 | 2022-04-29 06:06:34 | (合計) 26 |
2ファイルの場合
ID | 処理 | タイムスタンプ | かかった時間(秒数) |
---|---|---|---|
p1 | 開始 | 2022-04-29 06:04:08 | 12 |
p2 | 推論の開始 | 2022-04-29 06:04:20 | 27 |
p3 | 終了 | 2022-04-29 06:04:47 | (合計) 39 |
初期ロードの時間はあまり変化がありませんが、1画像あたりの処理時間が約5倍程度になりました。推論結果の画像やテキストファイルの保存に時間を要していました。
(これも当たり前のことではありますが、)大量の画像を扱う際には、今回のノートブックの入出力にGCSを使うのはお勧めできないことがわかりました。
まとめ
Google Colabを用いたNDLOCRの実行時間を調べてみました。さまざまな設定によって結果は変わってくるかと思いますが、参考になる部分があれば幸いです。