スキャン日記 作業の価値は

最近、通信機能が壊れたスマホから歩数計データを移行しようと頑張ったり、動画配信サイトの期間限定無料お試しを始めたりと、他のことを頑張っていて、その中でスキャン作業の価値を疑っている。なぜなら、このスキャン作業は頑張ってスキャンしてもその結果が質の悪いものだからだ。ちゃんと残すデータという形に仕上がることは少なく、色々な種類の問題が生じる。このスキャナを「高価なオモチャ」と称したのは私自身であり、始めからそのつもりで、たとえば辛いことから気を逸らす目的で、あるいは何年も手に取っていない本にもう一度接するために、作業を楽しめれば良いと思っていた。しかし他に満足度の高い作業が存在すると、それと比較して作業の価値を疑う。

作業で気づいたことがひとつある。前々から、本の最初や中ほどのページでは領域自動認識がうまく行っても、最後のほうのページになるとしばしば右手がまるまる写り込むと思っていた。今回もそうなった。注意して再スキャンすれば右手は写り込まないのだが、でも私はまだ、何がいけないのかがわからない。注意してと書いたが、初回スキャン時にも注意はしている。作業を1時間近く続けて疲れた結果右手の位置や角度が変わったのか、それとも本の右半分が本の厚みの分だけ下がることが影響しているのか。

「別のAndroid搭載端末」まではたどり着いた

factory reset後の画面で「この端末はリセットされました」と出るのが引っ掛かった。それを認識するということは、パソコンで言うところのクリーンインストール状態ではないということだ。だから他のスマホの歩数計データを自分の初期値として引き継げないのではないか？　この認識を無効化する方法をネット検索した。設定の「開発者向けオプション」の「OEMロック解除」をONにする。

そしてfactory reset。自動でセットアップ「ようこそ」開始。選択肢として「別のAndroid搭載端末」が出た！　以前にこれが出なかったのは、リセットされた端末だという認識がAndroidにあったからだ。

Wi-Fiに接続する所までは良かったが、「情報を確認しています」の後、フリーズする。何度もタップしたり電源を切ろうとしたりするうちに「『Google Play開発者サービス』は応答していません」と出る。何度やっても同じ。システムを更新すれば良いかと思い、一度「新規としてセットアップ」し、システムが最新だと確認してから再factory resetして試しても同じ。

ネットで調べたところ、factory resetの前にOEMロック解除しておかないと「この端末はリセットされました」が出るのは、Googleアカウントの情報が残っているから。Googleアカウントを削除してからオールリセットをすると「この端末はリセットされました」は出ない。これを試してみた。しかしセキュリティキー入力はGoogleアカウントがなくても求められた。再度ネット検索。

https://sharpmobile.zendesk.com/hc/ja/articles/115000259831--AQUOS-L2-%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AD%E3%83%BC%E3%82%92%E5%A4%89%E6%9B%B4%E3%81%97%E3%81%9F%E3%81%84
に
引用ここから〉〉＞＞
お買い上げ時は暗証番号「1234」
＜＜引用ここまで

やっと見つけた。オールリセットを試した。しかし、これでも「情報を確認しています」の後、フリーズする。

エラー表示から、Google Play開発者サービスがフリーズしていると思われる。Google Play開発者サービスを動かすにはどうするか。システムはすでに最新の状態。設定の「ストレージ」からすべてのアプリのキャッシュデータを削除。しかし、これでも「情報を確認しています」の後、フリーズする。

Google Play開発者サービスさえ動けば先へ行ける。Wi-Fi通信機能が壊れた歩数計用スマホは現在BluetoothテザリングでGoogle Playストアに接続中だ。（Bluetoothテザリングは超低速で、時々勝手に切れる。）

「データ引継」は電話帳しか引き継がない

「からだメイト」を引き継ごうとしているスマホを今まで何回リセットしセットアップしたことだろう。セットアップが完了すると、「からだメイト」の引き継ぎは失敗するがスマホは使えるようになる。たいていはすぐにまた次の実験のためにリセットするのだが、ある時ホーム画面をスワイプしていて「データ引継」アイコンを発見した。タップしてみた。

「データ取り込み」をタップすると、「シャープのスマートフォン」という選択肢があった。これはシャープが作った引き継ぎアプリだ。ということは、自社スマホの「からだメイト」なども引き継ぐのではないか？　にわかに期待ができる状況になった。

「シャープのスマートフォン」をタップ。「microSDを使わない場合はこちら」にBluetoothのアイコンが付いている。Bluetooth経由とは、Wi-Fiを使わないということか。これならば通信機能が壊れた歩数計用スマホでも何とかなる！　そこをタップ。その後Bluetooth接続を進めたが、結局このアプリは電話帳の引き継ぎしかしてくれなかった。スマホのセットアップ時に「アプリとデータを保持」を選んでも「新規としてセットアップ」を選んでも、どちらも同じ結果だった。「新規としてセットアップ」では「セットアップ時にネットワークを使用しない」を選んでも家のWi-Fiを選んでも同じ結果。「からだメイト」を一度も起動せずに試しても、初回起動で歩数計をONにしてから試しても同じ結果。つまりどんな状況でもこのアプリは電話帳しか引き継いでくれない。

これだけ頑張って駄目だともうマニュアルは信じられない

私は、まだやれることを思いついた。私の歩数計用スマホは確かに何度Wi-Fiパスワードを入れても使えないが、世の中にはBluetoothテザリングというものがあると聞く。

私はスマホを3つ持っている。通信機能が壊れた歩数計用スマホ、からだメイトを移そうとフルリセットして色んなものが消えた同型機、そして現在モバイル会社と契約している、スペックはすごいが使いにくさはひどいX3-KC。このX3をBluetooth親機として歩数計用スマホにBluetooth接続できれば、歩数計用スマホにGoogleアカウントを加えることができる。それができればGoogleアカウント経由で普通に歩数計データを移せるかもしれない。

https://www.au.com/online-manual/shv44/shv44_01/m_07_14_00.html
から、無断転記ですみません、どうかお目こぼしください

引用ここから＞＞
累積データの引き継ぎかた
からだメイトに記録した歩数や体重などのデータは、Googleアカウントによってバックアップされ、機種変更しても引き継ぐことができます。からだメイトに対応した新しい端末の初回起動時に、初期設定で機種変更前と同じGoogleアカウントを設定し、データを復元してください
＜＜引用ここまで

私はこの記述がマニュアル通りだということを信じる。でも、これだけ頑張って、頑張りが無駄に終わると、そもそも現実はマニュアル通りでないと確信しつつある！

たとえば
https://support.google.com/googleplay/thread/28041476?hl=ja
には、こんな苦労をなさった方の書き込みがある

引用ここから＞＞
googleアカウントの同期機能を使ってgoogle関連のアプリデータの引き継ぎをしました。
この作業で、ほとんどのアプリのでデータの引き継ぎが行えたのですが、からだメイトに関連するデータの、歩数や体重といったデータが反映されません。
両機種ともすべての項目を同期の対象にしています。
両機種ともOS、アプリは、最新版に更新しています。
からだメイトのデータを反映させるには、何か追加で設定が必要なのでしょうか。教えてください。
＜＜引用ここまで

ああっ、私はマニュアルをもう信じられないが、この方の書くことをものすごく信じているッ！



https://androrank.com/?id=jp.co.sharp.android.karadamate
から、貴重なレビューを写させていただいた

引用ここから＞＞
また，調べている内に「からだメイトの記録は過去2年まで．それより古いのは消えます」という衝撃の仕様が明らかに．これまでUI操作かったるくて遠い過去に遡って見ることをしてなかったのですが，調べてみたら確かにその通り綺麗に消えていました．
＜＜引用ここまで

私の場合は時々出てくる「東京〜マニラ」などのヴァーチャル外国旅行が目的なので、過去の個々のデータは目的でなかった。2年を過ぎても累積歩数は保存されるらしく、3年後もマニラまで行けた。でも記録が2年までしか保存されない仕様ならば、健脚な方が2年かけて歩ける距離までしかヴァーチャル外国旅行できないかもしれない。その後はたとえ10年歩いても何の表示も出ないかも。

歩数計のデータ、後日談じゃ！

クラウドを介さずに「からだメイト」のデータを別スマホに移すことは失敗した。

転送先スマホを初期化し、壊れたスマホから全アプリデータを移す機能はないか。私は2代目スマホから3代目スマホへデータを移行する時に、2つのスマホを背中合わせにするというのをやった記憶があるのだが、あれは何だったか。とにかく転送先スマホを初期化して試そう。

転送先スマホをオールリセットしようとしたら、「セキュリティキー入力」画面が出た。そんなものを設定した覚えはない。デフォルト値としてありがちな0000や9999のほか、自分が使いそうなものは試したが、暗証番号が違いますと出た。でもネット検索したところ、
https://bbs.kakaku.com/bbs/J0000019080/SortID=21050649/
という記事を発見。この方法で転送先スマホをオールリセットできた。

リセットされたスマホは予想通り、初期設定を済ませようとする。「アプリとデータを保持」を選択。「データの引き継ぎ」画面には
Google アカウント
iPhoneまたはiPad端末
の2選択肢しかなかった。だから「Google アカウント」を選択。結果は、既存のアカウントからデータをダウンロードする羽目になった。これは違う。

もう一度スマホをオールリセット。「データの引き継ぎ」画面に選択肢以外に「不明な場合」があり、これはただの説明が表示されるが、その解説には「別のAndroid搭載端末」という第3の選択肢がある。それなのに、実際にタップできる項目はない！
（追記：これの事情は後日わかった。詳細は、この後3つ目の記事「『別のAndroid搭載端末』まではたどり着いた」に記す）

転送先スマホをオールリセットして全データを旧スマホからネット通信以外の方法で移す試みも失敗した。

もうとっくに精神的に疲れているが、毒を食らわば皿までもという。転送先スマホはリセットしてしまったからホーム画面の様子も中のアプリの数もがらりと変わり、もうさんざんだ。最後に旧スマホの中身まるごとコピーを試してやれ。

adb backup -f d:\all.ab -apk -shared -all

adb restore d:\all.ab
転送先スマホをオールリセットしたのを忘れていた。USBデバッグをONにするだけでなく、一度adbコマンドを送ってスマホ側でUSBデバッグを許可するためにチェックを付けてOKをクリックしなければならない。再度adbコマンドを送ったら「データを復元する」許可もする。

restoreが終わった。スマホをパソコンから取り外し電源ボタンを押して画面を点けた。おお、壁紙が旧スマホの壁紙に変わっている！　そして「からだメイト」は・・・まだ歩数計を使えるようになっていない！　全部restoreしたのだから、歩数計は使用中、歩数も引き継いでいるはずではないか。歩数計を使用するをタップ。この時点で嫌な予感。初期化されて0から始まるのでは？　案の定0から始まった。

それならば歩数計を使えるようにしてからrestoreしたらどうか。またadb restoreした。結果は、今日から開始。5歩。嫌じゃ！もう嫌じゃ！

歩数計のデータ、終わった、何もかも

私が指定した場所D:\に、ファイルサイズ95.4MBのkaradamate.dbが出来ていた。

スマホ（通信機能が壊れた歩数計用スマホ）のUSB接続を解除する。代わりに別のスマホ（同型で「からだメイト」はプリインストールされていたが無効化してある）をUSB接続する。このスマホも前もってUSBデバッグをONにしてある。

パソコンのコマンド プロンプトから
adb restore d:\karadamate.ab
を入力する。するとパソコンにエラーが表示され、少し遅れてスマホの画面に「USBデバッグを許可しますか？」が出た。USB接続のスマホを代えたから、こちらのスマホではまだUSBデバッグをしたことがない。許可の前にコマンドを送信したからエラーになったのだろう。スマホの画面にチェックを付けてOKをクリックする。

改めてパソコンのコマンド プロンプトからadb restoreのコマンドを入力。スマホ側に「完全な復元」という表示と共に、「データを復元する」許可を求める画面が出た。許可する。

Now unlock your device and confirm the restore operation.
が表示されたまま、しばらく変化がない。いいかげんに心配になってきた頃、処理が終わってプロンプトが出た。

私はスマホをパソコンから取り外し、無効にしてあった「からだメイト」を有効にした。アプリのアイコンがホーム画面に出た。それをタップした。日付は今日から、歩数は0歩となっていた。終わった、何もかも。

「データのバックアップ」がONになっていたのを思い出した。念のために「データのバックアップ」をOFFにし、Wi-Fiを切り、クラウドから昔の「からだメイト」のデータが来ないようにして、再度「からだメイト」を無効にし、再度adb restoreを実行した。「からだメイト」を有効にした。日付は今日から、歩数は0歩となっていた。終わった、何もかも。

歩数計アプリのデータ、いまだ救えず(5)

私の環境ではAndroid Studioのセットアップ（ダウンロード）に何十分かかるかわからなかったので、始まってから1時間40分くらいでスリープするようにタイマーをセットして寝た。翌朝、すべてのダウンロードと解凍・インストールは終わり、Finishボタンだけが有効になっていた。ただし、ひとつインストールに失敗したものがあった。
（下の引用のうちアドレスの部分が、ブログの機能で勝手にリンクになってしまった。私は引用しただけでリンクする気はない。どうかクリックなさらないでほしい。）
Intel (R) HAXM installation failed. To install Intel (R) HAXM follow the instructions found at: https://software.intel.com/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-windows

ネット上にはその解決策が複数出ていたが、私がしたいのはAndroid Studioを使うことでなく、その一部であるadbとかいうものを使うことにすぎない。Android Studioのセットアップ（ダウンロード）中に、ダウンロードしたコンポーネント？をどこにインストールするかのパスがしつこく出ていたので、その場所はわかっていた。自分のユーザー名フォルダ内を隠しファイルが見えるようにして覗くと、その
AppData\Local\Andriod\Sdk
の中だ。そこにtoolsフォルダとplatform-toolsフォルダが生成されていることを確認した。この2つへのパスを通すことが次の目的だから、この2つが生成されていれば問題ないはずだ。

通信機能が壊れた歩数計用スマホをパソコンにUSB接続し、USBデバッグをONにし、パソコンのコマンド プロンプトを出してコマンドラインから次のコマンドを試した
adb backup -f d:\karadamate.ab -shared jp.co.sharp.android.karadamate

するとパソコンにエラーが表示され、少し遅れてスマホの画面に「USBデバッグを許可しますか？」が出た。許可の前にコマンドを送信したからエラーになったのだろう。スマホの画面にチェックを付けてOKをクリックすると、Wondershare Dr.Foneを試した時にも障害となったあのメッセージが出て拒まれた：

Because an app is obscuring a permission request, Settings can't verify your response.

このメッセージは短時間で消えてしまうため、今回はあらかじめ用意していた別のスマホで素早く写真に撮り、そのメッセージをネット検索した。原因と解決策を発見した：

https://blog.kassyi.com/2018/03/because-app-is-obscuring-permission.html

再度スマホをパソコンにUSB接続し、パソコンのコマンド プロンプトからadb backupのコマンドを入力。スマホ側に「フルバックアップ」という表示と共に、データをバックアップする許可を求める画面が出た。許可する。

パソコンのコマンド プロンプト側に
Now unlock your device and confirm the backup operation...
が表示されたまま、しばらく変化がない。いいかげんに心配になってきた頃、処理が終わってプロンプトが出た。

私が指定した場所D:\に、ファイルサイズ95.4MBのkaradamate.dbが出来ていた。

後はこれを同型スマホにrestoreすれば、データ移行が成功であろうと失敗であろうと私の作業は終る。でもここで休ませてくれ。理由は2つ。1.こういう時焦ってどこまでも続けると冷静な判断ができなくなる。2.椅子に座りすぎて持病の腰痛が心配だ。心が冷静になり腰が大丈夫になったら、続きを作業する。

歩数計アプリのデータ、いまだ救えず(4)

ネット上にこれを見つけた。
https://bbs.kakaku.com/bbs/J0000010685/SortID=17263914/
私は一時的に喜んだ。シャープのスマホの歩数計をSDKで他機にコピーすることに成功したと書いてある。しかしよく読むと、この歩数計の「パッケージ名」は「からだメイト」のそれとは違う。同じシャープ製でも別の歩数計だ。つまり同じ手順で私が成功するとは限らない。

とにかく試す必要はある。上記ページにあるリンク先
http://appllio.com/20131023-4343-android-app-data-backup-restore#ab4
を見に行った。でもそのリンク先ページ自体には具体的な方法は書かれていない。万人向けの方法ではないので自己責任でちゃんと調べてちゃんとやれる人は次のリンク先を参考にせよというわけだ。

次のリンク先
http://chimtty.blogspot.com/2011/07/android-sdk-for-windows.html
を見に行った。手順は3ステップだった。その1、JDKのダウンロード＆インストール。これは問題なく終わった。その2、ADT Bundle for Windowsのダウンロード。ここで困った。この記事が書かれた時から年月が過ぎ、リンク先ページにGet the Android SDKの文字がなくなっていた。Android Studioになっていた。巨大なAndroid Studioは要らない、Command line tools onlyでいいかなと考えたが、このCommand line tools onlyは違う物らしい。後でパスを通すべき場所が存在しない。結局、巨大なAndroid Studioをダウンロードすることにした。何も知らない私にとって、これは、より確実な方法のはずだ。

今どきの普通の人の環境ならば（光通信でなくてもスマホのテザリングでも）巨大なファイルも見る間にダウンロードされてゆくはずだが、私の環境は最低速度のADSLで、二十分くらいかかった。

私はAndroid Studioを二十分かけてダウンロードしたので、この中に必要なものは全部入っていると信じていた。ところがAndroid Studioの初回起動、と思ったらそれがAndroid Studioセットアップの始まりだった。また何かダウンロードし始めた。これ以上巨大になるつもりか。何度も書くが、私のネット環境は最低速度のADSLだ。また二十分かかるかもしれない。

それを待ちつつこの記事を書いているうちに、持病の腰痛が嫌な感じになってきた。残念だが椅子に座りすぎた。この続きはまた次回にしなければならない。

歩数計アプリのデータ、いまだ救えず(3)

前回の記事から続いている。私は頭の中をリセットしてから考えをまとめ、改めてネット検索した。

各アプリには固有の「パッケージ名」があり、Android/data内にはその「パッケージ名」でフォルダが作られる。スマホにインストール済みのアプリは、Aplinというアプリで「パッケージ名」を調べられる。私の歩数計用スマホはネット接続ができないからAplinをインストールできないが、同型のもうひとつのスマホはネット接続でき、無効状態の「からだメイト」が入っているから「パッケージ名」を調べられる。

調べたら、「からだメイト」の「パッケージ名」は
jp.co.sharp.android.karadamate
だった。そしてAndroid/data内にその名のフォルダはなかった。

駄目じゃん！！

Android/data内を探しても「からだメイト」のデータはないのだ。では、一体どこにある？

歩数計アプリのデータ、いまだ救えず(2)

Androidでは個々のアプリのデータはAndroid/data内にあると、ネット上の記事に書かれていた。Android11からは暗号化されているそうだが、私がデータを取り出したり入れたりしたいスマホは古いから大丈夫だ。

私は早速スマホをPCにUSB接続して内部ストレージを覗いた。せっかく覚えたUSBデバッグという設定も、関係ないかもしれないがしてみた。PC側で隠しファイルを表示する設定も、関係ないかもしれないがしてみた。

dataの中には色々なアプリを表すらしきフォルダ群があったが、それのどれが「からだメイト」に相当するのか、まだわからない。簡単にはわからないだろうと予想して、もうひとつのスマホ（同型だが「からだメイト」を使えなくしてある）とdata内フォルダを比較したが、それでもわからない。そもそもフォルダは沢山あるが、空フォルダが多く、ファイルは数えるほどしかなかった。本当にこの中に目的のファイルがあるのか？

「からだメイト」はエモパーと連携していたはず。そしてエモパーは単独のアプリではなくシャープ製スマホのシステムに近い位置にあるプログラムかもしれない。その設定がアプリ用のAndroid/data内にないという可能性は？

歩数計アプリのデータ、いまだ救えず

通信機能が壊れたスマホからアプリデータを他のスマホへ移すのは、方法はあるのだろうが私はまだ成功していない。なにしろ通信ができないから、Googleアカウントが使えないし、バックアップ用アプリもインストールできない。JSバックアップのPC版をパソコンにインストールしてパソコンとUSB接続したスマホを操作できないかと思ったが、JSバックアップPC版はそういうものではなかった。結局スマホ側にもアプリのインストールを求められ、そのスマホは通信ができないから、インストールもできない。Wondershare Dr.Foneだったか、スマホのUSBデバッグという開発者向けオプションを使うものがあった。この方法はたぶん正解なのだと思うが、PCを認識させようとスマホのOKをタップすると何やら英語でエラーメッセージが出て拒まれた。

このところ何週間もオーバーヘッドスキャナの記事を書いてきたのに、一気に記事内容が変わってしまった。歩数計アプリの歩数データを救うためだから仕方がない。

歩数計スマホ、バッテリーの寿命が近い

このブログの記事にたびたび書いてきた歩数計用スマホのことだ。初見の方のために簡単に前回までのあらすじを書くと、私はシャープの歩数計アプリ「からだメイト」がとてと気に入ったが、シャープ以外のスマホに買い換えた時点で使えなくなった。そこで電話用の新しいスマホの他に、古いスマホも歩数計専用として持ち歩くことになった。

その後バッテリー残量表示がおかしくなり、充電もしないのに残量が上がってゆくという笑える現象が起きた。実際には残量は減っていて、残量表示を見て安心していると残量ゼロでシャットダウンする。

それを報告する記事も回を重ね、この変な現象にも慣れてしまったから、もう歩数計スマホのことを記事にしないと思っていた。

そうしたら今朝、別件で記事を書く事態となった。

このスマホは歩数計にしか使わないから、一度満充電すると30日くらい使えた。それが前回気づいたら早めにシャットダウンしており、25日くらいだった。今回はその25日を目安に充電しようと思っていたら、22日くらいでシャットダウンした。わかる人にはわかるはず。これはバッテリーの寿命が来たということだ。

私は同型のシャープ製スマホをもうひとつ持っている。元は親が使っていたものを、通信会社との契約が切れた時点でもらった。今のうちに歩数計アプリのデータをそちらのスマホへ移したい。でも、どうやって？　新しいスマホへ全アプリのデータを移すのならば、スマホに手はずが整っている。画面の指示通りにすればいいだろう。でも古いスマホへデータを移すのは、どうすればいい？　移動先スマホを初期化しないと駄目？　それをすると移動先スマホの全アプリデータが消えてしまう。アプリデータの統合はできないか？　これから調べてみる。今日は、ここまで。


追記
なんてことだ、新たな問題発生。歩数計用スマホは歩数計にしか使わないので、ネット接続すると無駄に電池を食うから接続を切っておいた。今回Googleアカウントを再設定するためにWi-Fiに接続しようとしたら「認証に問題」と出た。パスワードの入れ直し（「パスワードを表示する」状態で）、SSIDから設定し直し、スマホの再起動、色々試したが駄目だ。ちなみに他のスマホやパソコンはWi-Fiが使えている。接続できない原因がわからない。最悪、歩数計用スマホの通信部分が壊れている。なんでそんなことを書くかというと、そもそもこのスマホは、買った時のスマホの通信部分が壊れ、係の人と電話でやりとりしたが改善せず、壊れたスマホと交換で送ってもらったスマホなのだ。私はすでに「通信部分故障」に縁がある人間だ。おまけに保証期間はとっくに過ぎている。壊れても不思議ではない。

スキャン日記 焼肉は焦げて炭になる

ひとつ前の料理本のスキャン結果がひどくなり、それでも再スキャンは思いとどまるべきだと思う私は、次の小さめの料理本に期待を寄せた。ところが、すぐに愕然とした。

私はまずサイドライトを使い、本を正位置で通してスキャンした。しかし画像の下方にどうしても我慢できない問題点が生じた。焼肉の影の部分は黒潰れを起こし、肉が焦げて炭になっているようにしか見えない。料理の写真として最悪だ。下半分に写真があるページは本を逆さにして再スキャンしたが、ページの上にも下にも写真がある場合は重要でないほうの写真を犠牲にした。

サイドライトでの再スキャンを終えても、どうしても我慢がならず、今度はメインライトで通して再スキャンした。メインライドの場合は、そのままでは緑がかっているのでXnViewの「自動レベル」をかけた。黒潰れはない。しかしすべてのページが何となく緑っぽくて変な感じだ。画像の中央にはテカりがある。

サイドライトを使ったほうの画像は、元の本では茶色い焼肉が赤っぽくなった。今回は中のページだけでなく表紙も同じ。ただし表紙の肉の色を茶色にしたら、中のページの肉がとんでもない色になった。各画像ごとに色調補正するのは大変すぎるので、ひとまず放ってある。メインライトを使ったほうの画像は焼肉がちゃんと茶色いが、メインライトを使ってすら肉が焦げて炭になったように見えることがある。つまりお手上げだ。

このスキャナで料理の写真をスキャンしてはならない。焼肉は焦げて炭になる。

スキャン日記 二日にわたる長き闘い

1日目

今回の本は料理本。これこそ私の求めていた本だ。美しい料理の写真に解説。しかしオーバーヘッドスキャナでスキャンするととんでもない低画質になる。つくづく仮保存にしか使えないと思い知らされる。単に解像度の問題ではなく、この本のスキャン結果はたいてい暗かった。本によっては元の本よりもやたらと明るい画像になることもあるのに、この本はやたらと暗い。何が違うのか。サイドライトを使わずメインライトを使えば明るくなるが、本の中央部がテカるから使いたくない。サイドライトはテカらないようにするために、撮影できるぎりぎりの光量なのだろう。しかも照明にムラがある。左右のサイドライトはどうやら光の出る部分がそれぞれ2つに分かれているようで、左右に2つずつテカる場所ができる。テカるのはサイドライトにもっとも近い場所だけなので、小さい本ならばそこを避けて置けるが、大判の本はそうできない。しかもサイドライトからもっとも遠い場所は光量が足りず暗くなる。とくに左下がなぜかしばしば限界を超えて暗い。このスキャナで撮影すると、モニターでうっすらと影になっていても、画像では光量がある閾値を下回るととたんにひどく黒くなるように思える。それと、被写体の色で自動的に明るさを変えているようだが、ひとつの被写体に白いテキスト部分と暗い写真部分があると、自動調節が誤動作して暗めになった結果、写真部分が黒潰れを起こすことがある。
この本は一部のページに端まで暗い写真があるので、最初は観念して「領域をスキャンする」モードで作業しようとした。でもそれだと補正がないからページの歪みがひどい。湾曲して出っ張っている所は大きく、ページの端は小さく見える。そのうちに、「湾曲した本」モードでも大丈夫そうなページもあると気づいた。そこで、可能な限り「湾曲した本」モードで頑張ってみることにした。結局、表紙、裏表紙は「フラットペーパー」で、見返しは暗緑色でとても領域認識できないので「領域をスキャンする」にしたが、その他のページはすべて「湾曲した本」モードで頑張った。

とにかく暗くなりやすかった。多くのページがモニターに映した時点で、元の本よりも明らかに暗かった。ただでさえ元の本よりも暗いので、ページの端が暗い写真だと領域誤認識で切れる。そこで、頭を使う必要と、妥協する必要があった。私はスキャンしながら、この本のレイアウトを見て行った。レイアウトは2種類に限られた。(1)料理の写真が左右両ページの下方にあり、上方は白地に解説のテキストが書かれている。(2)料理の写真が左右どちらかのページ一杯にあり、もう片方のページは綴じ代付近に写真の続きがあるものの、それ以外は白地に解説のテキストが書かれている。(1)の場合は、写真が暗い場合、本を正位置に置いてスキャンするとサイドライトからもっとも遠い所に暗い写真が来て、領域誤認識を起こして写真が切れる。そこで、(1)の場合は本を逆さにしてスキャンする。サイドライトのテカりが写真部分に来るのは妥協しなければならないが、被害を最小限にするために本をサイドライトからできるだけ遠ざける。本を逆さにした結果、サイドライトからもっとも遠い所には白地にテキストがあるから、遠ざけても領域は認識される。いっぽう(2)の場合は、本を正位置に置くか逆さに置くかは写真による。ページ端に少しでも明るい色のあるほうをサイドライトから遠い側にする。ライトから遠い部分はかなり暗くなるので、本をサイドライトにできるだけ近づける。その結果テカりが多く映るがそれは妥協しなければならない。(2)の場合は領域誤認識を心配したが、ページの端から次のページがわずかに覗き、それが白地のことが多く、おそらくその白が領域認識に有利に働いたようで、写真が切れなかった。


2日目

新たなる格闘が始まった。まずは前日のスキャン画像に一括して色調補正を加えるが、それをそのまま全画像に採用するのでなく、それを基本として、気に入らない画像は他の画像（再スキャン画像等）と入れ替える。

では基本となる色調補正はどう決めるか。RalphaのToneCurveにCbCrの前回使用データとしてグラフ左下を少し下げたものが残っていた。基本的な色調補正はどうやらこれで大丈夫なようだ。それに加えて今回はYのグラフ左端を少し上げる。ここを上げると黒の最低レベルが底上げされて画像全体が白っぽくなるが、今回のスキャン結果は影が黒潰れしているので全体のイメージを良くするために敢行する。グラフのマス目ひとつ分上げるとさすがに画像が白っぽくなりすぎて薄っぺらく見えたので、マス目半分まで上げる。さらにColorAdjustのChromaを使う。これは今までの色調補正で使い慣れて、どの値にすると結果がどうなるかがわかっており、使いやすいから。今までの本では-99でオリジナルの本と同じくらい、-62でオリジナルの本よりも鮮やかめになった。

基本となる色調補正は以上のとおりに行った。次は、それでも気に入らない画像を他の画像と入れ替える作業に移る。この作業は全画像を3つに分け、それぞれについて行う。

[1/3]表紙と見返しは画像補正なしとChroma-62+Y+CbCr（以下、-62と記す）を比較してどちらかを採る：
表紙は画像補正なしで良いことを確認済み。裏表紙、見返しもこれに準ずる。扉の小さな絵の色調は悩んだ。画像補正なしのほうが鮮やかだが、他の写真に合わせて-62としよう。

[2/3]中のページ全部は2段階で作業する。まず-62とChroma-99+Y+CbCr（以下、-99と記す）を比較する：
思った通りだった。-62は不自然に色が濃い目だが、意図的にそうしたほうが料理は美味しく見えるかもしれない。-99はナチュラルな濃さだが、インパクトに欠けるかもしれない。これは全画像にあてはまった。そこで両方とも保存する。

次に、今朝一番で一部を再スキャンした画像と比較する。
再スキャンした画像とは何かというと、昨日スキャンした画像を-62画像補正したものを最初から見てゆき、全体の暗さや一部の黒潰れが気になるものを再スキャンしたものだ。再スキャンの方法は前回よりも改善する必要があった。具体的には、(1)本の上下を逆さにしてテカり／黒潰れの起こる場所を変えてみる。(2)どうやらスキャン領域の中心部に暗い写真が来ると明るさ補正が働いてモニター画像が明るくなるようなので、本を左右にずらしてモニター画像が明るくなる位置はないか探す。(3)どうしても画像が暗くなる場合はメインライトに切り替えて撮影する。ただしメインライトを使えば本の中央部にテカりが生じるのと、全体が緑がかった色調になるのは避けられない。

再スキャン画像もまずは色調補正しなければならない。サイドライトによるスキャン画像とメインライトによるスキャン画像に分け、サイドライトによるスキャン画像は上記「基本となる色調補正」を施す。メインライトによるスキャン画像は別に色調補正しなければならない。

メインライトで撮影した画像は、XnViewの「自動レベル」で白くあるべき部分が白くなった。ただしメインライトでの画像は緑がかる度合いが一定でなく、完全に白くなるのは緑がかる度合いが弱い場合。強く緑がかった画像はXnViewの「自動レベル」をかけても白くあるべき部分が完全に白にならず、薄い色が少し残る。そもそもレベルとは色相のことではないのだろうから仕方ない。個々に緑がかる度合いの違う画像をいちいち補正する気にはならない。これらの画像をそのまま-62の参考画像とする。-99のほうには上記「自動レベル」補正したものをさらにRalphaでChromaを-62として参考画像とする。数値的にまぎらわしいが、-62に追加するのはChroma0、-99に追加するのはChroma-62だ。これは見た目で判断し、「鮮やかめ」を-62に追加、「ナチュラル」を-99に追加した結果だ。本来ならば「オリジナルよりも鮮やかめ」「オリジナルと同程度」とすべきだが、今回は黒潰れ改善のためにあまりに画像をいじりすぎたのでアバウトな結果となった。

[3/3]巻末インデックスと裏見返しは画像補正なしと-62を比較してどちらかを採る：
巻末インデックスは画像が少し明るくなる-62を採用。裏見返しは明るくする必要がなく、画像補正なしを採用。カバーつき裏見返しはカバー袖の写真の色調を優先して-62を採用。

後記

1. こんな時間のかかる作業は、好きな本にしかできない。今回は料理の写真満載の本なので久しぶりに見て感動し、お腹を空かせながら作業できたが、そんな本ですら作業が終わる頃には写真を見ても食欲は湧かなくなった。見飽きるだけでなく、スキャン結果の画像がひどい。とくに黒潰れ。

2. 少し前にスキャン作業した本で初めてメインライトの必要性を理解したが、今回はさらに理解した。大判の本でサイドライトから遠い場所が黒潰れを起こす場合は、テカりを覚悟の上でメインライトを使わねばならない。どうせ大判の場合はどこかにテカりが出る。それが画像上部になるか中央部になるかの違いだ。中央部がテカってとくに困るのは、絵や写真でなく文字が書いてある場合だろう。読めなくなるから。メインライトはなぜか緑がかっているが、XnViewの「自動レベル」で白くあるべき場所をかなり白くできる。複数画像一括変換もできるらしい。こうしてメインライトを使うべきとわかっても、個々に違う度合いで緑がかった画像の補正についてはまだ何一つ試していないので二の足を踏んでしまう。サイドライトを使って黒潰れした画像よりもはるかに良いとわかってはいるのだが。

3. 今回のサイドライトによるスキャンは一部の画像にとんでもない黒潰れを出した。画像全体の明るさはオリジナルの本と見比べて、容認すべきはそのままとし、認められないものはメインライトで再スキャンしたので、極端な失敗画像はなくなったはずだ。それにもかかわらず、黒潰れ部分が炭のように黒く、まるでそこが焦げているかのように見える。私が持っている中でおそらく一番魅力的な料理本が、人に見せられる魅力のない画像になってしまった。私は今でも全体をメインライトで再スキャンしたい衝動にかられる。しかしそれはいけない。メインライトを使えば確かに全画像が明るくなり、細部まで見え、炭のような黒潰れはなくなるが、必ず中央あたりにテカりが出てそこの文字は見えない。たとえ再スキャンしてもそれが限界なのだ。この程度のスキャン結果のために、多くの時間をかけ健康を犠牲にして再スキャンするのは間違っている。

スキャン日記 大判本とサイドライトと黒潰れ

今回の本はちょうどA4判で、スキャナの下に台を置かなくてもスキャンできると考えた。台を置かずにスキャンしたが、実際には予想外の事態にてこずった。ある左ページの左下が妙に暗くなった。肉眼で見るとそんなに影になっていないのに画像化すると黒くなる。ページを持ち上げてみたり、パソコンのモニターを明るくして照らしてみたり、背後の蛍光灯の光が当たるように体をずらしてみたりしたが駄目だった。メインライトでは本中央部の湾曲して出っ張った所がテカる。

ページによっては全体が少し暗くなった。何をセンサーが認識して明るさを落とすのかがわからない。暗くなると心配なのが左ページ左下で、ここが黒くなりやすい。そうならない明るいページも多くあるが、時として出る暗いページのために本をサイドライトに寄せた。本をサイドライトに近づけるとページ上部がテカるがそれは犠牲にした。すると別の現象が現れた。ページ上辺が波打つ。初めは画像補正の影響かと思ったがそうではなかった。本をあまりにスキャナ側に寄せたせいだった。それがもしも平らな被写体ならば問題なかったが、実際にはページが湾曲した本だ。湾曲して出っ張った端がスキャナのカメラから見るとスキャン可能領域から外れる。こうして出っ張った所が切れた画像を平たんに補正した結果、切れた部分が逆にへこんだ。その証拠に、ページ上部にある水平飾り線はちゃんと水平になっている。前述のページ左下の件があるので本を下へずらすことができず、このままとした。

スキャン日記 端の画像処理で黒も白くなる

今回のスキャン対象は地図だ。地図といっても色々な形状があるが、大きな1枚の紙を山折り谷折りに折って、さらに3つ折りにしたのがあるだろう。あれだ。あれは、使いにくい。一度広げてから畳もうとするとうまく山折り谷折りができなかったり、折り目に無理がかかるので、長年使うとそこから切れてきたりする。オーバーヘッドスキャンもやりにくい。上から押さえないから山折り谷折りがスキャン結果に出る。谷折り部分は引っ込むので地図の下に敷いてあるマットが見えることになるが、今日はそこの話だ。

地図を「フラットペーパー」でスキャンしてから「領域をスキャンする」に切り替えてスキャンした。すると、「フラットペーパー」では地図周辺部が白いが、「領域をスキャンする」では黒いことに気づいた。黒いのは専用マットの黒だ。いっぽう白いのは、地図の縁にある幅の狭い余白部分が画像の端まで白として続いているのだった。「フラットペーパー」はただ四角い紙の領域を自動認識するだけでなく、紙が歪んでいる場合に端の画像処理もしていたのか。その時私の脳裏に、コミックスをスキャンした時にページ端の白や黒がそのまま画像端まで縞模様となって続く現象が浮かんだ。あれは「湾曲した本」モードだったが、同じ画像処理をした結果ではないだろうか。今回の地図のように端が白ければ、画像端まで専用マットの黒が見えずに綺麗に「ごまかし」が実行できるだろう。しかしコミックスのようにページ端まで絵が描かれている場合には妙な結果になるということだ。

スキャン日記 やっとメインライトが必要な被写体に出会った

今回の本は領域誤認識も傾きもなくうまく行ったが、ページの周辺部が妙に影になった。今までこんなに周辺部が暗くなったことがあるだろうか。この本はA4判で見開きA3だ。スキャン可能最大サイズだからだろうか。そこで改めてメインライトでスキャンしてみた。するとページの周辺部に影がなくなった。ここまでスキャンして、やっとサイドライトでなくメインライトが必要な被写体に出会った。ただし今までメインライトを点けた時と同じく、画像は少し緑がかった色合いになった。それと、ページの中で湾曲して反り上がっている部分にライト当たり少しテカった。その部分に文字があると、テカって見えにくい。

同一ページでサイドライト+デフォルト設定とメインライト+最高画質を比べてみた。ファイルサイズは410KB/930KBで、最高画質は大きくなっている。ところが画像の横x縦ピクセルは3880x2593/3868x2598で、これは同じと見るべきだろう。解像度設定がデフォルトで最高なので、これ以上どうしようもないのだろう。dpiは240dpi/300dpiだが、縦横ピクセルが変わらないのにdpiだけ変わるとは、これはJFIFの縦横解像度情報各2バイトだけを変えているのか。

スキャン日記 朝日の影響を確認した

以前に、本のページが赤に近い色でもないのにスキャン結果が赤みがかって再スキャンに苦労したことがあった。これは朝日の影響しか考えられないのだが、今回スキャン途中に朝日が出てきたのでそれを確認した。

スキャンしながらスキャン結果の色を確認することで、作業場左上のカーテン越しに天窓から入るオレンジ色の朝日の影響で紙の色が日に焼けたような色になることを確認した。その後太陽が動くと作業場左上の天窓からは光が入らなくなるが、部屋に入れた植物のためにカーテンを開けなければならなくなり、後部の窓から陽の光がまともに入る。しかしその時間帯にスキャンした画像の変色は、かなり少ない。作業場左上の天窓から朝日が差し込む時間帯が、天窓の近さと朝日のオレンジ色のせいで影響が大きいようだ。

うどうどん

親がご近所から春の食材「うど」を頂いた。そして冷蔵庫に磁石で付けたメモに自分で「うど」と書いて、後から自分でうどんと間違えた。私は、「それならば、いっそのこと『うどうどん』にしたらどうだろうか」と思った。

うどんは、これも頂いた「月山の雪」という細うどんが残っていた。ひやむぎ位の細さの乾麺で、茹でるとコシがありツルツルと喉越しが良い。

うどんつゆは真っ黒な関東風でなく、ぜひ関西風にしたい。といっても、既製品だ。我が家でよく使うヒガシマルの「うどんスープ」。この「うどんスープ」は、がんもどきを煮る時などにも使えて重宝する。ただし砂糖がまったく入っていない塩味なので、がんもどき等には砂糖も少々加えるのがコツだ。今回はうどんだから砂糖を加えない。

具がうどだけというわけに行かないので、かまぼこと青菜を加える。うどが主役だから、うどの香りが負けてしまいそうな濃い味の具は加えない。ほうれん草を茹でるつもりだったが、親が春菊のお浸しの残りを片付けてくれと言うのでの、渡りに船でこれを頂いた。

うどんは袋に書いてある時間どおりに茹で（9分）、その間にかまぼこを切り、土付きのうどを洗って包丁で皮をむき短冊切りにする。うどは切ったら短時間で変色するので、それを防ぐために酢水に漬けなければならない。うどんつゆ用に湯を沸かす（1人分250ml）。丼に「うどんスープ」粉末を入れ、湯が沸いたらそれも入れてかき混ぜる。うどんの茹で時間が残り1、2分になったら金属製のざるにうどとかまぼこを入れ、うどんを茹でている鍋の中に1分位漬ける。すると湯の温度が下がるので一時的に強火にする。うどは湯掻くのが目的、かまぼこは温めるのが目的だ。

茹で上がったうどんを丼に入れ、うど、かまぼこ、春菊のお浸しを載せる。出来上がり。

出来上がりの写真を撮るのを忘れた。私は料理をする時一生懸命になり、他のことをつい忘れる。

スキャン日記 ページ端の書き込みはビニョーン

今回の本は、私が若い頃に全部暗記しようとした単語集。随所に書き込みをした跡があり、私が当時努力したことが伺える。

この本の印刷自体は、ページの縁と文字の間にはっきりと空白があり、その意味ではスキャン作業に問題はなかった。しかし他の部分で大問題が起きた。上記のように、私はこの本の随所に書き込みをした。個人的な書き込みは、その個人にとって本の活字以上に意味がある。そして行間に書き込むスペースがないと、書き込みは余白に書かれる。つまり書き込みがページの端に達することがある。領域自動認識でページの端が切れることはなかったが、端の部分が極端に歪むことはあった。書き込みの端がビニョーンと横にゴムひものように伸びたスキャン結果が複数見つかった。こういう場所は、まともに再スキャンしても同じ結果になる。仕方がないので本を逆さにしたが、今度は領域認識が甘くて端が切れた。そこで本の下に紙を敷いて領域がもっと続くようにしたり、それでも駄目ならページ端を手で持ち上げてセンサーの認識を変えたりと苦労した。このスキャナは、「ページ端に活字はないだろう。ページ端が歪んでも構わないだろう。」というコンセプトで作られている。マニュアルのどこにもそんなことは書かれていないけれども、スキャン結果がそれを物語っている。

スキャン日記 新コンサイス英和辞典

メインライトはやはりテカってしまい、サイドライトを使った。辞書を全ページ保存する必要はなく、箱・表紙の他は最初のほうと最後のほうだけをスキャンした。箱の黒っぽい汚れや、表紙の梨地エンボス加工による黒っぽい部分は全然反映されず、箱はクリーム色、表紙は赤の単色になってしまった。これがこのスキャナの能力の限界だ。さらに表紙の本当の色は赤でなくオレンジだ。それが赤になった。表紙だけはオレンジに色調補正した。そのさい、箱や中のページに同じ補正を施すと色が変になることを確認した。やはりこのスキャナは、赤に近い色が大部分を占める被写体だとより赤みが増す。だから全ページを一括色調補正するのには無理があるかもしれない。

文字がピンボケ状態で読みにくい。ピンボケではなく解像度が足りなくてぼやけているのだろうが、見た目はちょうどピンボケだ。辞書のように活字の小さい本は読書に向かない低画質だ。これをグレースケールにすると、文字線のボケている周辺部が白くなり、文字線が少し細くなる。小さくて読みにくい活字はカラーのほうが良いだろう。

スキャン日記 最初にスキャンした画像を見直せ！

私が本をスキャンしているのには複数の理由がある。いずれ手放さなければならない本の画像を残しておきたいだけでなく、デジタル化して教材として使いたい本もある。遠く離れた大学まで重い本を持って行く気はなく、数百ページを金をかけてコンビニのマルチコピー機でデジタル化するつもりもないが、家で無料でデジタル化できればするというわけだ。次年度の授業の準備が進み、最初にスキャンした本を教材用に加工する時が来た。そして驚いた。ページが傾いたり、角が黒く欠けていたり、あるページはそれどころかまるでクシャクシャと握り潰したかのように歪んで、ページの幅が実際の半分しかなかった。機械の操作に慣れないうちは色々失敗すると思っていたが、その失敗に気づきもしないで保存していた。一番最初にスキャンした本の画像は後から見直したほうがいい。

スキャン日記 一体何の写り込みだ！？

今回の本はある外国人宅にニ度目に行った時にもらったもので、彼の町を紹介する本だ。彼はこの本を私に渡しながら「君がこの町に来るのも最後だからこの町のことがわかるように」と言った。この言葉をとりわけ覚えているのは、複数回外国に来ている私がこの町に来るのを、彼はなぜ今回が最後と思ったのかが引っ掛かったからだ。ひょっとすると、私を家に呼ぶことについて家族で反対意見があり、これが最後ということで決定したのかもしれない。（ホームステイのホストは相当ストレスが溜まるものなのだ。しかも彼とその家族はホストとしての資格や経験をもたない一般人だった。）

結局彼の家に行くのは本当にこれが最後になった。この本は記念の本だから、ちゃんとスキャンしたかった。

本のサイズはA3見開きに収まり、難しいことは何もないように思えた。最後までスキャンしてからWindowsの画像表示ソフトでチェックしたら、表見返しと裏見返しにまったく同じ絵があるのにスキャン結果の色が違った。裏見返しのほうは赤みがかっていた。全画像を調べると、スキャンの後半から画像が赤みをおび、しかも画像下方の一部がとくに赤みがかっていることがあった。何かの光が写り込んでいるようだ。しかし部屋はほぼ暗い。時は3月の午前8時で、窓のカーテンは閉まっている。私に近い所は雨戸1枚が閉めてあり、朝日が入るのは私のずっと背後にある窓と天窓だけで、そのどちらもカーテン越しだ。それでも、スキャナのサイドライト以外の光はカーテン越しの朝日しかない。私は試しに、着ていた上着をマントのように広げて背後の薄明るい朝日を遮った。するとスキャン画像は赤くならなかった。こんな遠い、しかもカーテン越しの朝日が色に影響するとは思わなかった。これから時が経つと陽射しは強くなるだろう。私は雨戸を全部閉めた。それから本の大部分を再スキャンした。先ほどと比べて赤みはほぼなくなったが、それでも画像下方の一部が赤みがかることがあった。朝日は遮った。一体何の写り込みだ！？　私はパソコンのモニターの明るさを最小にした。画像下方というと、机に敷いている暗緑色のマットが途切れて机本体の明るい茶色が出ている。パソコンのモニターの光がそこで反射しているのか？　私は今までライトのテカりを心配して本を出来るだけサイドライトから遠ざけていたが、それだと机の明るい茶色に本が近づくので、今回はサイドライトに近づけた。

スキャン日記 画像をトリムしたらファイルサイズが増えた

今回のスキャン対象はクリアホルダー。クリアホルダーとは、透明な袋が本のページのように束になっていて、中に書類などを入れるものだ。この中には昔外国人からもらったプレゼントの包み紙などが記念に保管してある。当時の私の感謝と感動の保存だ。このホルダーはずいぶん大きく見えるがA3見開きで大丈夫なんだろうかと思っていたが、B4版だった。これはもう片方のページずつスキャンしてゆくしかない。細かいことを考えてもどうにもならないので、スキャンサイズを「元のまま処理しない」にしてどんどんスキャンした。スキャン自体は元のままなので勝手に傾くことも領域が変になることもなく、モニター画面を見ながらどんどん進んだ。全部のスキャンを済ませてから、結果を確認して驚いた。なぜこんなに暗くなる。プリント写真をスキャンした時と同じだ。このスキャン結果は悪魔の仕業だ。モニター画面は普通に映るので、スキャン結果がこんなにひどいと気づかなかった。このスキャナは、苦手とする被写体どころか、地獄の結果になる被写体がある。気をつけねばならない。

今回のスキャン画像があまりにひどいので、保存はするが少しでもファイルサイズを小さくしたかった。それでスキャナ付属のソフトウェアを再起動し、リネーム保存しておいたフォルダのコピーを作り（これは、失敗した時のためにバックアップを作るため）、そのコピーフォルダをインポートし、時間をかけて全部の画像の不要な周囲部分をトリムした。それから、どれだけファイルサイズを節約できたかと調べた。トリム前の元画像は全部で51.9MB。トリム後の画像は全部で123MB。なんだこれは。画像をトリムしたのに2倍以上のファイルサイズになってしまったぞ。以前にも、カラー画像をグレースケールに変換したらファイルサイズが増えたことがあった。この付属ソフトウェアでの編集は十分に気をつけなければいけない。

スキャン日記 付属ソフトウェアがスキャナを認識しない

数日前から付属ソフトウェアでスキャナを認識しない現象が生じている。もちろんスキャナの電源入れ忘れや機能切り替え忘れではない。初回は数日前、2回目が昨日だ。付属ソフトウェアやスキャナ本体を再起動しても症状は改善しないが、コンピュータ自体を再起動すると直る。今後このまま行けば良いが、万一症状が悪化した時のために記録しておく。

スキャン日記 プリント写真のスキャン結果はあまりにひどい

初めてプリント写真をスキャンしたが、ひどすぎる。比較的暗い部分はほぼ黒く潰れ、そうでない部分も細部の表現は全部潰れて見るに堪えない。書籍ならばカラー写真入りでもそれなりにスキャンできるのに、どうしてネガからプリントした写真だとこうもひどいのか。本は白い紙だがプリント写真はそうでない。ひょっとして縁が白いと明るさ調整がなされるかもと思い、白い紙の上に写真を置いてスキャンしてみたが結果は同じ。このスキャナがプリント写真のスキャンにここまでひどい結果を出すならば、アルバムのデジタル化は無理ということか。

スキャン日記 カラーからグレースケールにしたらファイルサイズが増えた

この本は、私が外国の風習について度々メールで質問したから、外国の友人が贈ってくれた本だと思う。しかし絵も写真もなく白い紙に外国語が何十ページも印刷してあっては読む気になるはずがない。今回スキャンが終わったら処分だろう。

全ページに整然と並ぶ文字。ページ端との間にはしっかりと余白。これほどスキャナの「湾曲した本」モードに向いた本はない。予想通り、領域誤認識は一切なく、スキャン作業は滞りなく終わった。しかし本に興味がないと何とつまらない作業なことか。

全スキャンを終えてから、グレースケールでなくカラーでスキャンしたことに気づいた。カラーの必要はないのに。一度付属ソフトウェアを終了してしまったが、カラーからグレースケールにするのは後からでも可能だろう。ソフトウェアをまた起動し、フォルダをインポートし、表紙と裏表紙以外の画像を選択して「カラーモード」をグレースケールで実行した。グレースケール化は可能だった。グレースケールにすればファイルサイズが縮小できることは、スキャン画面の「グレースケール」をマウスでポイントしても表示される。どれだけ縮小されたかを知ろうと、グレースケール化した画像63枚と元画像のバックアップ63枚を比べた。すると驚いたことに、カラーは42.9MB、グレースケールは44.9MBだった。ファイルサイズは増えた。どういうことだ？

思いもよらぬ物が蓋にくっついた

まだ私が若かった頃、友人から恐怖の焼売弁当の話を聞いた。蓋にくっついていたという、あれだ。友人は引き続きおばあさんの話をした。巷では、おじいさんの話としても伝承されている。それから長い年月が経ったが、私は現実世界で蓋にくっついた焼売もおばあさんも見ずに過ごした。崎陽軒のシウマイは蓋にくっつかないようになっているし、人はもちろんくっつかない。ところが先日、思いもよらない物が蓋にくっついていて笑った。サンマだ。この時点で完全にネタバレだが、最後まで書かせてほしい。

このブログの記事に書いたが、我が家では少し前にグルメパンというフライパンを買った。これは2つのフライパンが蝶番でくっついた形をしていて、蓋をして中の食品を簡単にひっくり返せるアイデア商品だ。先日うちの親がサンマを買ってきて、真ん中から二つに切ってグルメパンで焼き始めた。うちの親は食品がフライパンの端に寄るのを異常に嫌う変な人で、せっかくのグルメパンだというのにフライパン ごとひっくり返さずに蓋を開けて箸で返す。その無意味な行為が私は嫌で、親がグルメパンで何か焼いているのを見つけると自分が代わりに焼く。グルメパンごとひっくり返してから蓋を開けて、端に寄った食品を整えれば良いではないか。なぜ親がそれをしないのか理解できない。今回もサンマを焼いていると言うので途中から私が交代して焼いた。蒸気穴から十分に蒸気が出てきたら頃合いだ。私はグルメパンをひっくり返して蓋を開けた。そして不思議に思った。二つに切ったサンマが三切れ入っていたからだ。一尾を二つに切れば二切れ。二尾を二つに切れば四切れ。それなのにフライパンの中にあるのは三切れ。一切れだけ焼かずに残してどうする気なのだろうか。私はそれを親に聞いてみた。すると親は四切れ焼いていると言う。そんな馬鹿な。フライパンの中には三切れしかないぞ。次の瞬間、親と私は蓋にくっついた一切れを見つけて大笑いした。

スキャン日記 色補正は本によって違う

今回は、きのこの本。私はきのこも図鑑も好きなので、この本に関しては不満足画像の再スキャンも楽しんで出来た。スキャン完了後にオリジナルの本と見比べて、色合いが少し違うことに気づいた。前回のスキャン作業のようにRalphaのToneCurveで一括変換しようとしたが、前回のスキャン作業で設定したToneCurveが今回のスキャンには当てはまらなかった。被写体の色合いやその他の条件により、スキャン時の色合いの変化は異なるようだ。結局、どうしてもオリジナル本と同じ色は再現できなかった。そのうちに、そもそも本の写真は自然界の実際の映像よりも印刷物っぽい色だと思えてきた。そこで、本と同じ色を再現するのでなく、画像の不自然さを解消しつつ自然界にありそうな色にする調整を試みた。スキャン画像の中には、不自然にどぎつく明るいものがある。オリジナル本と同じ色合いでなくても、とにかくもっとくすんだ色のほうが自然だ。そこで今回はToneCurveではなく、ColorAdjustのChromaを下げた。これで大抵のきのこは自然な色になったが、表紙のきのこは色の濃さが足りなくなった気がする。

スキャン日記 色調一括補正と、それも不可能な真っ赤

今回の本のスキャンは、赤いページを除いて領域誤認識がなく、順調に進んだ。この本は各ページの上辺近くに水平に飾り線が引いてある。スキャンを少し進めた時、見開き右ページの飾り線が少し右上がりになっているのに気づいた。再スキャンしたがどうしても右上がりが直らない。その時に考えてみた。本の開き方がＶ字になっていたら、左ページが水平で右ページが右上がりということもあるだろう。それで、右ページの押さえ方を変え、ページの上側のほうをさらに開き気味にしてみた。左ページのほうは今のままで飾り線が水平なのだから、ページの押さえ方を変えない。パソコンのディスプレイにスキャナのカメラから見た映像が写るので、それを見て左右ページの飾り線が水平になるように右ページの開き方を調節した。ページは湾曲しているのでディスプレイに写る飾り線も湾曲するが、湾曲で弓なりに上がった部分は無視して飾り線の端を左ページの線と水平になるようにした。

この本のスキャンには大問題がひとつあった。カラー写真が多数あるが、それら全てが、つまりスキャン画像全てが赤っぽくなった。このスキャナは赤に近い色の色調が変わってしまう。しかし付属のソフトウェアには色調補正が付いていない。「品質」にある項目はコントラスト、シャープネス、厚さ（明るさの間違い？）だけだ。パソコンにRalphaというフリーソフトが入っていた。画像の一括変換をするソフトだ。フォルダを読み込み、とくにオリジナルの色に近似させたいページを選択し、最初はColorAdjustのHueを試したが、調整しきれなかった。そこでToneCurveを試した。ChannelをRにし、たまたまいじった設定で茶色がかなりうまく出た。そのままでは全体が明るすぎたのでChannelをRGBにし、初めはグラフを直線のまま右端を下げて暗くした。しかしその設定で表紙を見ると、真っ白の表紙が少し青みがかっていた。そこでRGBグラフの右端は元のままとし、表紙が白く見える範囲で暗くなるカーブを模索した。結果として、最初にRGBグラフの右端を下げた時よりは明るくなったが、これで妥協した。数あるページの中には何をどう誤認識したのか、調整不可能なほど真っ赤になったものが少しあった。RalphaのToneCurveでも調整できなかったので再スキャンしたが、付属ソフトウェアの画面ですでに真っ赤でどうにもならなかった。