WindowsのシフトJISの文字リストを作るシェルスクリプト

シェルスクリプト フォント

文字、を作る数字を作るシェルスクリプト


画像みたいなテキストファイル、を作る数字の羅列を作る、シェルスクリプトです。
作るのはテキストファイルそのものでなくて、ただの数字。平たく言うと、ただの連番製造機。
この数字の書かれたテキストファイルを、xxdコマンドなどでバイナリファイルに変換すると、いわゆるWindowsのシフトJISのテキストファイルが作成されます。メモ帳なんかで読めます。

武蔵システムのTTEditに「文字一覧テキストファイルを作成」という機能があるんですが、これと同じ文字列、ってか、同じデータになります。

個人的に文字リストが必要になったんですが、ネットに沢山あるだろ、と思ったら、これが意外と見つかんない。表は見つかっても文字列がない。

続きを読む

【配布しない】Rounded M+の白黒反転フォント


http://jikasei.me/font/rounded-mplus/
自家製フォント工房さんのRounded M+の一つを、白黒反転してみたサンプル。やっぱり元がいいと綺麗っすね。
私は配布はしません。作ってみたのでサンプル画像だけ、ってことで。


私が配布してる「ぬかみそ闇夜」が、なんだか、微妙に需要があるっぽくてですね。おそらく他にこういう作りをしたのが無いからだろうと。決してnukamisoが認められてるんではない。
ということで、誰かnukamisoじゃなくて綺麗なフォントを作って、配布やら維持管理やらやってくんねーかなと……まぁ需要が無かったとしても、私は責任持てんっすが。

「ぬかみそ闇夜」は、何も難しいこともないし、手間もかかってません。TTEditのサンプルのマクロを、少しだけ改造して、一括処理してます。不具合も手直ししてません。マイナー個人製作遊びフォントだからできること。

↑簡単なマクロを流用すると、たとえばこういう不具合が出てきたりします。
ちゃんと作るのなら、自動処理っていっても、私がやるような杜撰なのじゃダメです。普通にマクロ組んで、普通に品質チェックは必要になると思います。


改変フォントといえば改変だけれど、どっちかというとルール違反じみたフォントな気はしてます。たとえるなら、表計算ソフトで地図を描くような。
私も、自分のフォントを改変して、遊び目的、特殊な実用目的でなら公開できますけどね。でも人様のフォントで改変して公開するっつうなら、なんか違うというか、失礼な気がしないでもないというか。ルール違反に他人を巻き込んでるような気がしないでもないというか。

でも確かに、便利っちゃあ便利なんすよねぇ……。

書くだけ書いて後悔する類の話

2011年頃に書いてた文章が出てきた。一部を置いてみる。

この頃、ファミコンの中からビデオ信号を取り出してテレビに繋ぐ、「ファミコンAV化」ってのをネットで調べてて、これについて書こうとしてた。でも思うところがあったり、疲れてたり、何より私に資格が無くて、アウトラインまで書いて、回路を組んだり測定したりは、しなかった。

トランジスタ1個の回路なのに、ファミコンが出てから四半世紀も、正常動作しない回路がネットで広まるという、なんともしょうもない現状が、この頃あったんだと記憶してます。「昭和とは違うぜ、インターネットで情報収集して情報強者だぜ」なんてのは、いったいどこにあったのか。
最近は高度化？　してるというか、海外勢も含めた、なんか凄そうな回路もあるみたいで、今とは状況が違うみたいですけれど。


この頃、ニセ科学批判界隈ででも、私個人として不満に思うこともあった、んだったか。確かそうだったはず。私は今も
http://b.hatena.ne.jp/Narr/%E6%B0%B4%E3%81%8B%E3%82%89%E3%81%AE%E4%BC%9D%E8%A8%80/
水伝ブックマーク続けてますけど、水伝にしてもゲーム機改造にしても、これらの話の中身よりは、「ある主張に批判をすると、その批判をする行動に対して、主張の正誤とは別の点から異論を言う」態度、批判行為批判に関心を持ってました。


回路については、回路の正誤がそれなりに問題ではあるだろうけれど、主問題はそこでなくて、社会性の問題。特に水伝については、中身の正誤は本当に問題でないんだろう、と私は今もそう考えてますけどね。
もちろん、長いこと水伝ブログ見てても、彼らが心底で何を考えてるかなんて、私には分かりません。想像は簡単だが、確認できないことは分かると言ってはいけない。
もっとも、世間には凄い人がいるから、週末に水伝で喧嘩をしてるところを見るだけで、彼らの内心を看破できる人もいて、それが正しいらしいけれど。


↓以下、2011年の文章。ファミコンの改造の回路について書いてから、最後の雑感の文章。

                                      • -

非常に書きにくい

自分は何様なんだろうか、と、それは思う。ひとのこと言う前に自分の勉強したい。私なんかが解説記事を書かなくても、知識が欲しい人は、普通に本を買えばいいわけで……。
私が他人の言い分に賛同しないで口出しすると、ときどき「攻撃的だ！」と、通りすがりの人に怒られたりもする。
これは、私個人の問題だけとも思えない。以前、ゲーム機改造界隈で、自作回路を公開していた人が、通りすがりの人に回路の欠陥を指摘されて、「あんたが気になるなら、あんたが自分でなんとかしたら？　動けば正義だから、私は気にしてません」なんて、仲間と一緒に嘲笑する様子を見かけたことがある。

分かる人は、分かってる。このトランジスタ回路なら、回路図を一目見れば、実験しなくても、欠陥がわかる。私を含めた一般人の「実際にやってみた」はその程度のものなんだ、と私は思う。
見た人は、すぐわかる。なのに何も言われないのは、どうでもいいから無視されているだけ。やってることも、人間も、どっちもどうでもいいから。

中・長期的な視点ではどうだろう

ゲーム機から視点を他に向けると、素人が「実験」をして、何かしら珍しいことを発見した、と言い張るのはいろいろある。いわゆる「オーディオカルト」は定番だし、私はしばしば、「実際に実験して確かめました」を見てる。「水からの伝言」については、学校教育に使われたこともあって、問題視する人も多い。それに比べれば、ゲーム機の改造なんて、些細な話。
確かに、ファミコンのAV化そのものは、どうでもいいと思う。でも、やっていることは、回路の勉強と同じ。そして、こういう体験って強いのだ。自分の手を動かして自分で作った体験は、他人が言葉で打ち消そうとしても消せない。

初学者が最初におかしな回路を題材にしてしまうと、入り口で大幅に遠回りしちゃう。中途半端に「動く」回路だと、なおさらに。
入門で間違いに引っかかると、初学者は非常に多くの時間や労力を無駄にする。青少年時代に数年を犠牲にするのは大きいし、大人になっても引っかかっていると、何十年も無駄にする。失敗もいい経験だった、では済まない。「好きにさせればいい」なんてのは他人事だから言えることで、自分や家族のことなら、そういうわけにはいかない。

ファミコンの改造なんて小さい問題で、多くの人は放置する。でも小さな問題を「無視すべき」と主張しておいて、極端なオーディオカルトや「水からの伝言」に突っ込み入れるのは、何か違う気がしてる。
大きな勘違いで大きな迷惑を撒き散らす人は、大きな勘違いが凝り固まる前に、たくさんの小さな勘違いを積み重ねてるんじゃないんだろか。小さな勘違いを小さな手間で直すのも、悪くないやり方だと思うけれど。


「情報強者」は「情報判断が正確な人」ではない

Googleで「ファミコン AV化 改造」のキーワードで引っかかるのはファミコンの改造方法の体験記事で、トランジスタ回路の基礎知識ではない。
Google先生に質問して、ネット上の情報だけ収集すると、ネットで複数転載されてる回路は、「多くの人が試作して動作確認した定番回路」みたいに見える。
情報強者だからこそ、基礎知識を知る前に、今すぐ欲しい結論ばかり集めて、早とちりしてしまいやすい。

                                                                    • -


タイトルどおり、ブログで公開すると、一晩して消したくなる文章というか……。
回路を書いたりオシロの写真を載っけたら、なおさら消したくなるんだろうなぁと。
今さら他人の改造回路にケチつけるために半田ごて握るのもどうかと思うし、これだけ置いて一区切りってことにして、関連ファイルを処分しようと。
今、ファイルの掃除しとるんですわ。

書籍の「自炊」ファイルの名付けはどうするか？

紙の書籍をスキャナで読み込んでjpeg等の画像ファイルにして、zipでまとめる、いわゆる「自炊」をするときに、ファイル名をどうするのがいいか、の個人的な方法です。他人に推奨できないものもあるけれど、参考にはできるかもしれん。

zip？　7z？　rar？　cbz,cb7,cbr……

https://en.wikipedia.org/wiki/Comic_book_archive

有力候補はzipですが、zipにも問題はある。

  • ファイル名の文字コードの扱い。zipは文字化けすることがある。
  • アプリによって、拡張子がzipだと使えないが、cbzに変更すると使える、ことがある。
  • zipに限らず、データが化けると丸ごと展開できなくなる危険がある。本のページ単位でなく、本一冊がまるごと失われる。

zipが無難でしょうけれど、内部の文字コードが何なのかは、把握しておいた方がいいです。
日本語ファイル名を使いたいのなら、7zにする手もある。
リカバリレコードを使いたいなら、rarを買えばいい。

このへん踏まえて、私は、文字化けしない文字だけ使って、zipを使ってます。

以前は、フォルダに画像を突っ込むだけでした。一般的じゃないですが、ファイルが壊れても1ページで済む、という利点はあった。

自炊書庫の中身は「画像ファイルだけ」？　それとも「フォルダを作って画像ファイルを入れる」？


↑ピンと来ないかもしれないけど、こういう話です。
zipの直下のフォルダ名が文字化けしてると、フォルダの中の画像ファイルも展開できない、ことがあったような気がする。記憶が曖昧だけど。
なので、強いて言えば、フォルダなしでアーカイブする、のが無難だろうと。強いて言えば。

ファイル名は？

  • ファイル名によって、自炊書庫の中身が一目で分かるようにできるか？
  • ファイル名の並び方、ソートは大丈夫？　OSが変わると並びも変わったりしない？
  • ファイル名を工夫すると、自炊書庫を分類できる。どうやって分類する？　どこまで細かく分類する？
  • ファイル名に使う文字種を限定して、多種の環境やアプリに対応するか。それとも無制限か。

このへんのことを勘案して、以下を決める。

  • 自炊書庫の「中身の画像ファイル」のファイル名
  • 「自炊書庫そのもの」のファイル名


一例として、私のやり方。まず「中身の画像ファイル」。

【パターン1】zipの中身の画像ファイル名は「数字」と「_(アンダースコア、アンダーバー)」と「拡張子」のみ
  • 001_001.jpg
  • 001_002.jpg
  • 001_003.jpg
  • ………
  • 002_001.jpg
  • 002_002.jpg
  • 002_003.jpg
  • 002_004.jpg
  • 002_005.jpg
  • ………
  • 003_001.jpg
  • 003_002.jpg

「001_」は、本のカバーなど、ノンブルで振られてないもので、本文より先に出てきて欲しいもの。
「002_」は、本文。次の三桁が、ノンブルと一致する。
「003_」は、別冊付録など。

アラビア数字の前にローマ数字の序文がついてる本なんかにも、対応できます。ノンブルがふたつ以上あっても、前半の三桁で対応できるわけです。
本の半分半分で、右綴じと左綴じになっている本でも、同様です。

漫画雑誌などの連載作品を、作品ごとにまとめるときは、「[第ｎ話]_[ページ]」とします。第26話、第27話、第27話と第28話の間の特別編、第28話と続く例だと、

  • 026_001.jpg
  • 026_002.jpg
  • 026_003.jpg
  • ………
  • 027_001.jpg
  • 027_002.jpg
  • 027_003.jpg
  • ………
  • 027_101.jpg
  • 027_102.jpg
  • ………
  • 028_001.jpg
  • 028_002.jpg
  • 028_003.jpg

このように、特別編を27話の101から数えることで対応します。

凝ったルールにすると、まとまらなくなります。数字だけ、順番だけ、一冊単位で他の本とは無関係、にしたほうが無難です。

欠点は、他の本とファイル名が同じになることです。編集中に上書きの危険がある。

【パターン2】パターン1に加えて、ISBNを加える
  • 1234567890_001_001.jpg
  • 1234567890_001_002.jpg
  • 1234567890_001_003.jpg
  • ………
  • 1234567890_002_001.jpg
  • 1234567890_002_002.jpg
  • 1234567890_002_003.jpg
  • 1234567890_002_004.jpg
  • 1234567890_002_005.jpg
  • ………
  • 1234567890_003_001.jpg
  • 1234567890_003_002.jpg

ユニークな名前に、簡単にできる。ISBNのハイフンは取り除く。

【パターン3】パターン1に加えて、雑誌名などユニークな名前をつけておく
  • TR199805_001_001.jpg
  • TR199805_001_002.jpg
  • TR199805_001_003.jpg
  • ………
  • TR199805_002_001.jpg
  • TR199805_002_002.jpg
  • TR199805_002_003.jpg
  • TR199805_002_004.jpg
  • TR199805_002_005.jpg
  • ………
  • TR199805_003_001.jpg
  • TR199805_003_002.jpg

上の例は、「書籍を分類する独自のアルファベット」「1998年05月号」を意味してる。
たとえば、月刊誌で、連載記事を数か月分まとめて一つのアーカイブにできる。

これだけのことなのだけど、「書籍を分類する独自の」は、案外難しいんじゃないかと。ユニークではなくなりますが、発行年月日のみ頭につける、ので十分かもです。

【パターン4】

書庫の中にフォルダを作って、フォルダ名をISBNなどのユニークな名前にする。フォルダの中身の画像ファイルは、パターン1でつける。

【パターン5】追加編集と1000ページ超に対応する
  • 010_0001.jpg
  • 010_0002.jpg
  • 010_0003.jpg
  • ………
  • 020_0001.jpg
  • 020_0002.jpg
  • 020_0003.jpg
  • 020_0004.jpg
  • 020_0005.jpg
  • ………
  • 030_0001.jpg
  • 030_0002.jpg

1000ページ超への対応と、途中に新規ファイルを挿入可能にする、なんてのを思いついたけど、微妙な気が。
稀に、zipの先頭に表紙の画像を挿入したくなることはありましたが、「000_000.jpg」でも足ります。途中への画像ファイル大量挿入は、経験したことがありません。
1000ページ超えの本なら、「003_000.jpg」を1000ページとしても大きな問題ではないし、その前にアーカイブを前半後半に分けることも検討すべき。

【パターン6】ファイルの順番と名前を切り離す
  • 001_001.jpg
  • 002_002.jpg
  • 003_003.jpg
  • 004_001.jpg
  • 005_002.jpg
  • 006_003.jpg
  • 007_004.jpg
  • 008_001.jpg
  • 009_002.jpg
  • 010_003.jpg
  • 011_004.jpg
  • ………
  • 178_171.jpg
  • 179_172.jpg
  • 180_015.jpg
  • 181_014.jpg
  • 182_013.jpg
  • 183_012.jpg
  • 184_011.jpg
  • ………

上の三桁は連番で増加。下の三桁がページの名前を示します。上の三桁がページの並び順を決定して、下三桁が並び順に影響を与えないのがポイント。
上記例では、
001-003は、ブックカバーや帯。
004-007は、目次。目次だけノンブルがローマ数字の本など。ローマ数字と下三桁が一致する。
008-179は、本文。ノンブルがアラビア数字で、下三桁と一致する。
180-最後までは、索引。縦書きの文庫本に、横書きの索引がついてるときなど。ページの並びが逆になる。

利点は、ページの並びをきっちり決めることができること。下三桁を、ある程度自由に決めることができること。
欠点は、連番が二重になってるので、ファイル名を変換するツールの扱いに慣れなきゃいけないこと。

【良くない例】




珍しい例ではないのだけれど、個人的に失敗した例も含めて。
ありがちなのは、Windows標準の連番機能でズレること。昔の話かと思ってたけど、今のAndroidのファイラーでも上のような並びになるのがあった。
頭にアンダースコア、は、私が失敗した例です。WindowsとLinux-Android環境とで入れ替わりました。Androidのコミックビューアで入れ替わるものもあったし、Windowsと同じ順序になるのもあった。
最後のは、注意する必要は無いというか、ちょっと試しただけです。Windowsの禁止文字である、半角の疑問符「?」が入ったzipです。Windowsでは、ふつうは作れないはず。

「自炊書庫そのもの」のファイル名……に、使う文字のセットは？

zipの中身はともかく、zipのファイル名にまで、すべて半角英数字、は使いにくい。日本語は使うこととして、どこまで使うか。たとえば異体字やらまで使いますか、ということ。
私は「蔵書のリストをテキストファイルで作り(MD5も併記する)、文字コードをシフトJISで保存する」というルールにしてます。ある程度の制限があったほうが、かえって楽です。

ファイル名でソートし、分類する、のだけれど。
  1. [大分類][中分類][出版社][著者][書名][画像ファイルの種類].zip
  2. [モバイル端末で読める小さな本か、大型モニタが必要な大きな本か][出版社][著者][書名].zip
  3. [漫画か、漫画以外の本か][漫画雑誌][書名].zip
  4. [著者][書名].zip
  5. [書名のあいうえお][書名]
  6. [書名].zip

こういったルールを決めて、ソートで分類してほしい順に、頭っから名付けてゆくわけです。
凝れば良いってもんじゃなくて、結局はバランス踏まえて好みで決めるしかないんだと思います。

必要十分は？

この程度で必要十分じゃないかと思ってます。

[出版社(シリーズ、レーベル)]_[著者名]-[書名(第ｎ巻)]_[画像ファイルの種類].zip
例：
https://www.amazon.co.jp/dp/4061178776
講談BB277_インフェルト-アインシュタインの世界_webp.zip

↓zipファイルの直下に、ファイルを収納する。

  • 4061178776_001_001.webp
  • 4061178776_001_002.webp
  • 4061178776_001_003.webp
  • ………
  • 4061178776_002_001.webp
  • 4061178776_002_002.webp
  • 4061178776_002_003.webp
  • 4061178776_002_004.webp
  • 4061178776_002_005.webp
  • ………

webpのように、新しめな画像ファイル形式の場合は、末尾に_webpを追加しておく。jpegやpngは省略する。
講談社の他の本は、単に「講談」のみで済ませる。細かく分けすぎない。
必要なら、「講談週マガジン」等を追加する。このとき頭の「講談」は変えない。
「漫画少年」「漫画少女」「コンピュータ」「園芸」などに大分類しなくとも、出版社でだいたいは分けられるし、ほどほどに分けられれば自分の本は探せます。


出版社を最初に入れると困るのは、著者で分類したい場合です。
著者名でソートしたいのなら、出版社は削除して、著者名の前に平仮名を一文字だけ追加する。

[大分類]_[あいうえお順-著者名]-[書名]_[画像ファイルの種類].zip
新書_い-インフェルト-アインシュタインの世界_webp.zip

この「大分類」は、案外難しいんじゃなかろうか。
例では「新書」にしましたが、「物理学」にしたいかもしれない。そのへん毎回、考えなきゃならない。
また、個人の蔵書は偏るものだから、新書ばかり買う人は「新書岩波」「新書中公」などと分類する必要が出てくる。小説や漫画は殆ど買わないから「小説」「漫画」で一括りにしたら、5年後には趣味が変わって小説だらけになっていた、やっぱり小説も出版社くらいは分けたい、だとか。

なので、著者名を重視するなら、大分類は無しで、著者名と書名だけでも良いと思います。大分類は、必要なら手作業でフォルダ分けするほうが、適切な分類ができるのでは。

もともと、ファイル名で詳細に分類をするのは、難しいもんがあると思います。
なので、一般的な情報で迷わず決められる、出版社、著者名、書名程度に済ませるのが、無難で、ゴミ情報になりにくいです。



最後に、区切りについて。例ではアンダースコアとハイフンを使ってますが、全てアンダースコアがいいかもしれんです。記号に意味を持たせずに、単純な区切りにだけ使う。カッコなども使わないほうが、文字数の節約になるし、ミスが減ります。
伝記等の場合、書名と著者名がどっちがどっちよ、と混乱するかもしれないと思って、私はハイフンを使ったんですがね。「インフェルト『の』アインシュタイン」という感じで。でも、かえってミスが増えちまった。

ぞわぞわ



いちばん上がオリジナル。下の画像のうち、左の列がjpeg、右の列がwebp。品質は上からそれぞれ90、50、20。
紙の本をスキャナで読み込んだ画像データをjpegで保存すべきか、webpで保存すべきか、どうしようかと検討中で、ちょっと気になって試してみたもの。
これは極端すぎる例で、紙の本を保存するのとは別物だろうけれど、大雑把な傾向は分かる気がする。

jpegで保存するとき、私は大抵品質を85か90にしてるんだが、90でも文字のまわりに、ぞわぞわ～としたノイズが出てるのが、ちょっと気になってる。90まで上げてもノイズ出るんなら、そのへんwebpはどうなんよと。
品質高めの90でも、文字のまわりのぞわぞわ感で、既に差があるような。

そこそこ高画質に残したいのなら、jpegで90にするよりはwebpで90か80にしたほうが良いんじゃないかって、今はそんな気分。容量を減らすためっていうより、手軽に現実的なデータ量で、そこそこ高画質に、紙のスキャン画像を残すには。
もしwebpが今後流行らなかったとしても、無理に画質を落とさないようにしておけば、jpegの後継規格に再変換することもできるし。



左がjpeg,右がjpegXR。上から下に、YUVの色を削ってる。
jpegXRのほうは品質100にしてみたけど、色を削ったのは、やっぱ削れるんだな。100は無劣化だ、と思わんほうがいいな。

webp画像に対応した自炊ビューアはあるかいな。

書籍のスキャン、いわゆる「自炊」した画像を閲覧するソフトのうち、webpをそのままで使えた、プラグイン入れるだけで使えた、のリストで備忘録。
2019年01月前半調べ。

Windows10とUbuntu(18.04～18.10あたりの)で使えるものです。Macは知らん。
Windowsのアプリケーションは、susie-pluginに対応していて入れたら使えた、のも含めてる。というか、自分のための備忘録だからこれ。

・ZipPla(Win)
https://sites.google.com/site/riostoolbox/

・Leeyes(Win)
http://www3.tokai.or.jp/boxes/leeyes/

・HoneyView(Win)
https://www.vector.co.jp/soft/winnt/art/se507563.html

・NeeView(Win)
https://bitbucket.org/neelabo/neeview/

・QuickViewer(Win,Linux AppImage)
https://kanryu.github.io/quickviewer/

・Peruse(Win,Linux AppImage)
https://peruse.kde.org/
↑Win版は私のとこでは動かんかった。

・YACReaer(Win,Linux)
http://www.yacreader.com/
Ubuntuで.debパッケージ入れようとしたら、「libunarrが足りん」と蹴られた。
https://software.opensuse.org/package/libunarr
↑突っ込んだら動くことは動いたが、私は責任持てん。

・Okular(Linux)
https://okular.kde.org/
LinuxというかKDEの。Kubuntuに最初っから入ってる。拡張子がzipだとダメだけど、cbzに変更すると開ける。

・Pynocchio(Linux)
https://pynocchio.github.io/

・OpenComic
https://github.com/ollm/OpenComic


モバイルまわりは知らんです。Androidだけ少し調べましたけど、有名どころのビューワでも対応してないのもあった。でも、Linuxよりは選択肢が多いかもしれん。↓このへんは使えたし、そこそこ好みで選べそう。

・ComicScreen
https://play.google.com/store/apps/details?id=com.viewer.comicscreen
・PerfectViewer
https://play.google.com/store/apps/details?id=com.rookiestudio.perfectviewer



Windows環境だとsusiePlugInもあり、最初っから作者さんがwebp対応をしてたりで、あんまり困らんかった。上記の以外にもいくつもたくさんあった。ありすぎて試しきれない。
Ubuntuだと、ちとめんどくさいです。画像ビューワではwebp対応してないとか、aptで入れたコミックビューアでも使えなかったりとか。ライブラリがどうとか色々あるんだろうかなぁ。


2019-11-11 OpenComic追加

webp画像が個人的に使えないか試し中の備忘録


↑スキャナで読み込んだ、家電のパッケージ(YAZAWAのACM1000というACアダプタの説明書です)の説明書。bmpをpngにしたオリジナル。これを圧縮するのにwebpを使えないか、の備忘録。


↑jpeg品質85,129kB

↑jpeg品質30,50.8kB

↑webp品質80,63.7kB

↑webp品質30,30.3kB

私は素人で、個人的に試しただけなんで、上のは信用せんといてください。いちおうオリジナルのPNGはいちばん上の画像そのものなんで、これをjpegとwebpに変換すれば、誰でも追試はできるけど。
googleのコマンドラインのでやんなくても、探せばそこそこwebpのGUI変換ソフトはあったっす。上記のwebpは、 XnConvert Version 1.77 で変換してます。

個人的には、もし見られなくなっても諦めがつくようなものなら、これからは基本webpにしてしまおうか、くらいに考えてる。
意外と有難かったのは、無劣化のwebp。上記のとは別件だけど、画質を落としたくなくてPNGで残してた画像、64DDのキャプチャ画像とかなんだけれど、これらはwebpに変換してみた。そこそこデータ量も減って、無劣化だからやり直しができるし、便利かもです。