TIGORA(ティゴラ)の トレッキング シューズを買いました。
メインの靴がアシックスウォーキングで街歩き用なのですが、これまではこれで高尾山などの軽い山も登っていました。
今回、靴底があまりに摩耗したこともあってアシックスウォーキングを買い替えたのですが、ついでに消耗が激しそうな山歩き用は別の靴を用意して履いてみよう、という感じです。
私が調べたときはamazonで「ティゴラのトレッキングシューズ」とすると背が高いトレッキングシューズしか出てきませんでしたが、ある程度街歩きもできる普通サイズのトレッキングシューズも出ています。
裏側はこんな感じです。
靴底の中敷きにも厚みがあり、期待できそうです。
靴を買い替えました。
それまでは靴は適当に入った店で最安のスニーカを買っていたのですが、4年ほど前に「足に合う靴」を求めて一念発起し、アシックスウォーキングを買ったのが初めて真剣に靴選びをしました。
そのときはアシックス直営店で足のサイズを測り、中敷きも調整オプションを入れてもらっています。
その後、2年ほどで履き潰したアシックスウォーキングを同じ型番で買い直し、 それもまた2年ほどで履きつぶしたため、同じものを探して買い換えたものです。
現在はフィールドウォーカーという名前になっており、後で見ていくように細部のデザインも違うため、厳密には違う靴なのかもしれません。
（あまり関心がないためこういう認識になってます。）
最初の選定時に見た目はあまり気にしていなかったのですが、革というかフェルト革風のデザインも靴としては珍しく、今では気に入っております。
というわけで上から撮った写真。
中敷きは真っ赤です。とはいえ靴紐のように外からは見えないので悪目立ちのようなことはしません。
購入時ではなくちょっと履いたあとですが、足裏はこんな感じです
内側の写真。比較写真はないですが比べてみると、靴のべろが被覆でくっついているように変わっています。
後ろ側もデザインが違います
後部を横から見ると、紐の衣装があったのが省略されています
側面としてはメッシュ風のラインが入る感じに変更されています。
FireFoxでchrome.*()系APIを使うとき、content_scriptだけpromiseなAPIで、ほかはコールバックな模様
そもそも、
- FireFoxはChrome拡張機能互換の一環として、chrome.storage.local.get()といったchrome.*()系APIを実装している
https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/API/storage/StorageArea/get
> この API は Chromium の chrome.storage API に基づいています。
- MDNのドキュメントではchrome.*()系APIはコールバックで非同期を返すものとなっている
(前述のURLにて。2024年現在も)
- Chromeブラウザのchrome.*()系APIは実際にコールバックのAPIで、Primise非対応だった
（おそらく当初、あるいはmanifest V2の頃は）
- 2023年時点のFireFoxでは、chrome.*()系APIはPrimise非対応だった
(当時の挙動からおそらくそう思われる)
- 一方、現在のChromeはchrome.storage.local.get()はPromiseを返すようになっている
(2024年現在。ドキュメントに記載されている通りならば)
https://developer.chrome.com/docs/extensions/reference/api/storage?hl=ja
> chrome.storage.local.get(["key"]).then((result) => {
- 2024年、FireFoxのchrome.*()系APIは、content_script内ではpromiseを返すようになった模様
(とりあえずchrome.storage.local.get()は。全てのAPIが対応しているかは不明。)
気づいたのはdaisy AddCharaIconブラウザ拡張の開発中で、これはページ内のゲーム登場人物名の横に顔アイコンを付与するブラウザ拡張。
毎回アイコン画像をloadするのは負荷が高いため、ローカルでキャッシュするためにWebExtensionsのstorage APIを叩いていて気づいた。
https://github.com/MichinariNukazawa/add_chara_icon_webextensions
```: option_page/option_page.js
```
面白いのはoption_pageでもPromise()構文自体は有効であることで、これはcallback版をPromiseでwrapして機能していることからわかる。
つまりFireFoxではchrome.storage.local.get() API側が2種類あるということで、content_scriptとそれ以外で同じAPIのインタフェースが異なる、ということを示しているのだと考えられる。
Linuxコマンドライン上でSVGベクタ画像をJPG等へラスタライズ変換することができるが、上手く変換されない場合がある。
以前作った魔法陣イラスト素材をイラスト素材ストックサイトへ登録しようと思い立ち、改めて素材用にラスタライズ変換をかけようとした。
ラスタライズ変換にはImageMagickの convert が使用でき、DPI的な設定 -density 600 でサイズ調整している。
元画像はこちら
30枚の画像をSVGからJPGへ変換した結果、6枚ほど結果が明らかにおかしい。
失敗しているものを拡大した抜粋。
真っ白で明らかに変換できていないものもあれば、circle要素などSVG画像から一部が抜け落ちてしまっているものもある。
また上のような真っ白な変換失敗や大きなパーツの欠損は明らかに見てわかるのでまだ良いが、小さなパーツの漏れ欠けがあるかもしれないし、そうなると今回のように多数の画像を扱っている中では見落としが起こると思う。
コマンドラインでバッチ処理したのだが、いくつかはエラーが通知されている。
```
```
ただ、 ` memory allocation failed` とはいうものの、メモリはかなりとっているのだが。
``` /etc/ImageMagick-6/policy.xml
```
小さなサイズで出力してみる。
```convert -density 600 $filename.svg $filename-ss.jpg
convert -density 90 $filename.svg $filename-3ss.jpg
```
小さなサイズで出力すると、たしかに結果が改善する。
とはいえ、ストックサイトへ登録するにあたっては大きいサイズでほしいのだが。
GIMPでもSVGをインポートしてラスタライズすることができる。
GUI操作で読み込むと任意のスケールで問題なく読み込めるのだが、CLI呼び出しでバッチ処理に使おうとすると、きちんと変換された結果が出ない。
画像のような変換結果になる。変換されているごく一部のパーツを見るだけでも、明らかに画質が悪い。
またこの場合は背景を 白背景で書き出せば上手く行きそうに見えるが、試した範囲では、変換結果が真っ白になるだけで上手く行かなかった。
以下、うまく行かなかったGIMPでのSVGインポート変換を一応抜粋。
```
# GIMPのコマンドを使ってSVGを読み込む
gimp -i -b - <<EOF
(let* (
(image (car (gimp-file-load RUN-NONINTERACTIVE "$input_file" "$input_file")))
(drawable (car (gimp-image-get-active-layer image)))
(new-width $size)
(new-height $size)
)
(gimp-image-scale image new-width new-height)
(file-jpeg-save RUN-NONINTERACTIVE image drawable "$output_file" "$output_file" 0.9 0 1 0 "" 0 1 0 1)
(gimp-image-delete image)
)
(gimp-quit 0)
EOF
```
またGIMP操作にはもう１つ、Pythonからgimpfuを経由して呼び出す方法もあり、こちらは上野LISPな古いGIMPスクリプトより高度な操作ができるのだが、現状GIMPがPython3に対応していないとかで、今回は断念した。
本件は、2023/09頃には解決しているはずの話です。
Q. chromeで動いたwebextensionsがFireFoxでcontent_scripts内のconsole.log()のメッセージをコンソールに出力しないのはなぜか？
A. FireFoxが 2023/06 FireFox 114.0時点でmanifest v3に対応していないにもかかわらずエラーを全く出さないため。
```: ディレクトリ構成
DaisyWarekiConv/
├── manifest.json
├── icons/icon128.png
└── my_content_script.js
```
```: my_content_script.js
```
```: manifest.json
```
FireFoxのwebextensionsのconsole.log()メッセージはF12キーで開くWebコンソールではなく、Ctrl+Shift+Jで開くブラウザーコンソールに表示される、らしい。
https://qiita.com/mouseofmicky/items/05dc51f792e16e25ae29
Fコレ自体が相当にFireFox固有の落とし穴感があるが、こちらをチェックしていてもやはりログメッセージは出力されない。
また、開発ツールのコンソール（一時的な拡張機能の読み込み>調査 ボタンから開く ）もあるが、こちらにも表示されない。これはbackgroundのメッセージが表示される（のだったと思う）。
そもそもcontent_scriptsがデフォルトでページ読み込みが完了したこのあたり（雑）のタイミングで読み込まれるものであるし、console.log()の出力成否はページの描画状況とは関係ない。
console.logが出ないならDOMでページ上に直接出してしまえばいいじゃない、のアプローチ。
content_scriptsが走っていないので DOM書き換えが行われず、うまくいかない。
manifest v2(MV2)に変更する。
```
```
FireFoxはまだMV3未対応できちんと動かないなら、最初から読み込まないとか、動かないというエラーログを出してほしい。
レンダリング結果の画像が編集画面と一致せずおかしくなる場合が有ります。
編集画面ではこれで、
レンダリング結果の色がおかしくなっています。
原因はWorldの背景色が反射でオブジェクトに映っているためです。
Scene>Surface>Color から設定できます。
また右上のViewを選択することでRenderingプレビューで表示して編集することもできます。
またViewの設定ではSceneWorldのチェックを外すと背景色がオブジェクトに映らなくなります。
以上です。
ImageMagickでPNGをJPGに変換しようとしたところ、 エラーが発生。
使用コマンド：
`find *.png | xargs -I{} convert "{}" "{}.jpg"`
エラーメッセージ：
```
convert-im6.q16: no images defined `Shinden144_Camera.FreeTop-fs8.png.jpg' @ error/convert.c/ConvertImageCommand/3229.
```
エラーメッセージは原因を指しておらず、またコマンドのファイルパスやオプションによるものではなく、原因はリソース不足でした。
PCの性能ではなく、ImageMagickの設定上のリソース上限です。
10000*10000pxを超えるようなサイズの大きい画像をImageMagickで変換するには、ImageMagickのリソース上限Upが必要となります。
Ubuntu24.04の場合のパスは次の通り。
`sudo vim /etc/ImageMagick-6/policy.xml`
次のように上限変更してリソース使用量を増やしました。
参考：
http://www.imagemagick.org/discourse-server/viewtopic.php?t=34044
TIGORA(ティゴラ)の トレッキング シューズを買いました。 メインの靴がアシックスウォーキングで街歩き用なのですが、これまではこれで高尾山などの軽い山も登っていました。 今回、靴底があまりに摩耗したこともあってアシックスウォーキングを買い替えたのですが、ついでに消耗が激...
