堕天使の煉獄
2022-08
13
03:56:12
夏だビールだ
とりあえず某氏んとこの夏コミ原稿料も入ったので、久しぶりにサッポロ黒ラベルなんか買ったりして。
普段はやっすい発泡酒ばっかりなので。
たまにはビール。
それも黒ラベル好きなんですよね。
んでなんとなく丁度黒ラベル買ったドラッグストア(税込価格で安いので)の隣にあるからあげ専門店のでっかい唐揚げとセットでプチ打ち上げして胸焼けコース(ぉ
なにげに親のお中元でアサヒスーパードライ(とジュースの詰め合わせのやつ)なんかもあったので、もう10年は飲んだ記憶のないスーパードライも飲んでみたのですが。
あれ? スーパードライってば後味が鉄さび臭い味しなかったっけか?
それがなんか何の特徴もない普通のビールって感じになってたり。
ぐぐってみたら今年2022年に「36年ぶりに味をフルリニューアル」したんだそうな。
へぇ~そりゃ印象全然かわっちゃうわなと納得。
まあ、スーパードライは個人的には貰い物でもなけりゃ今後も飲む機会あんまなさそうなのでどうでもいいけど(ぉ
そんな感じで、〆切明けってことで、ここ数日だらけた生活を。
んで、そろそろ動き出すべーってことで。
当面の予定としては、絵のレベルを上げる修行……の前に。
夏コミ原稿のときにも、ああ、さっさと用意しておくべきだった……と思ってた、susieの代替ツールの作成。
似たようなツール探したんだけども、それっぽいやつはあったものの(comono ImageViewerっていうやつ)唯一にして最大の欠点があって、ウィンドウを最前面に出来ないってことなんですよね。それ以外は表示形態といい、わりと欲しい機能網羅してたりしてたんだけどな……。
資料用の画像を表示しながら作画……ってのに最前面化してくれないとペイントツールと供用出来ないわけで。
とりあえず画面を選択してキャプチャするツール「Rapture」っての(コレめちゃくちゃ便利でもはやなくてはならないってぐらい使ってる……)でビューワで開いた画像をキャプチャして表示する。このツールは最前面表示できるので、これでしのいでたのだけども。
ビューワの方はマウスホイールで画像の拡大縮小を多段階で細かく変更できるのに対してRaptureのほうは25%または50%単位でしか変更できない&コンテキストメニューから倍率指定&拡大縮小が汚なくて使えないので、ちょっと資料のサイズ変えたいなってときに、ビューワの方でサイズ変えて、Raptureで再キャプチャ……と二度手間感あって、イライラ。
その辺、自分の使いやすい機能ぶちこんだsusie代替のビューワ作ろうと思ってたところで夏コミ作業期間のほうが先に来てしまった感じなんですよね。
これは今後のお絵かきの効率にも関わるのでさっさと作ってしまいたい。
ただ一つ決めかねてる部分があって、その所為でなかなか開発進んでなかったところがあって。
画像ファイル開くたびにアプリを個別に開く感じにするのか、子ウィンドウとして追加して開く感じにするのか……というところ。
子ウィンドウ形式だと、一括で開いてる窓を表示・非表示切り替えたりできるというメリットと、タスクバーも占領しない(画像いくつ開いても実質一個しか立ち上げてないので)っていうメリットあるのだけども。
コードが複雑になりがちというデメリットと、Qtはクロスプラットフォームな開発環境なので、win固有の機能とかないわけで。
アプリの多重起動禁止なんかも自前で処理書かないと行けなくてwinAPIでやるしか無い部分出てくるので面倒ってのもあったりして。
一方、個別のほうは作りやすくはある。
コードがシンプルに書けて複雑にならないし。
それ一つで完結するので。
んで、アプリの設定の保存とか、開いた画像の履歴をどう管理するのかとか、その辺、子ウィンドウ形式か個別起動かで変わってくるので、そこ決めなきゃ進められないんですよね。
今のところは、もう個別アプリ起動でいいかなてな方向に傾いてたりする。
上記のcomono ImageViewerていうビューワがその方式で、使ってる感じ、子ウィンドウ方式と比べて特にデメリット感じなかったりしたし。
そもそもの用途として、ペイントツールで作業しながら複数の資料画像を表示するかんじなので、個別に閉じたり出来たほうがよく、一括で閉じるのとかはかえって迷惑。
あと資料なんかは、今回のだと「2022_summer」とかフォルダ作ってその中にまとめて放り込んだりするので、ビューワ立ち上げるのは一個で、フォルダ内の画像を切り替え表示すれば複数立ち上げる必要も薄いわけで。
なので画像開きすぎてタスクバーがうまるって事態もあんまり起こらないかなぁと。
そんな知見も今回の作業中得られたので、個別アプリ案のほうに固まりつつあったりして。
というわけで、さっさと作ってしまおう。
と思ったのだけども。
最近avifファイルも結構増えてきてたりするっぽい?
Qtだと対応してたっけ。
と調べてみると、Qt6.4 betaとかでもまだ対応してないっぽい。
というか対応予定みたいな話すら出てきてないぽ。
というかavifて、数年前に調べた時点でまたフォーマットがまだ固まってないとか言ってたので、最近で回りだしたってことは仕様が固まったのだろうか?
とおもってググってみたのだけども、オフィシャル的なものなのかなんなのかもわからないけど、とりあえずlibavifてのが一番に出てくるのだけども、verが0.10.xと、まだver1.0とかになってないのね。
あとライセンス的にも今後どういうあつかいになるん?
とかちょっと不透明なところがあるらしく、そのへんでQtもまだ採用見送ってる感じっぽい?
webpはQtの対応速かったのにね。
やっぱその辺で揉めてる感じなのかなぁ。
次期verのQt6.4でもサポート無いので、まだまだサポートあるとしても先の話になりそうなので、自前でavifフォーマットも読めるようにしとこうかなとおもったのだけども。
このlibavif……なんかすんげぇめんどくさい。
コーデックやらなんやらのビルドにninjaとかいうビルドシステムが要ったりとか他にも色々と必要だーとか書かれてて、なんかいろいろとめんどくさそう……。
このためだけにごちゃごちゃ入れるの嫌ぁ……って感じで。
……ていうかちょっと前にavifとりあえず表示できるようにってことで、susieプラグイン入れたんだっけ。
ってのを思い出す。
……あ、じゃあsusieプラグインからavifデコード→QImageしたらええやんけ。
ってことに思い至る。
どうせビューワにはsusieプラグインとか対応する予定だったし。
じゃあそれで解決じゃん。
てことになる。
そんでもって、susieも代替ほしいって理由の一つに、もはや開発停止して久しく、最近のwindowsだと結構動作がおかしい部分出てきちゃってるってのもたったりする。
ただプラグインの仕様は便利なのでそこだけ未だに開発、ユーザーともに利用者多い感じなのだけども。
ここ最近は64bitビルドで作るのが基本になってきてるので、プラグインも64bit版の.sph(32bitは.spi)を使うことになるのだけども。
そうなると古い32bitのしか無いやつは使えなくなるなーとか(なんか方法はあるらしいけど)
susieAPIの解説なんかみると32bit版のものしか見当たらないのだけども、64bitでもおんなじなのかなコレ? とか。
もはや界隈廃れまくってて情報が1999年とか20世紀で止まってるw
なんかそゆのみちゃうと、なんかちょっとさみしい気分になるな……。
あとavifのsusieプラグイン、gitにあるソースコード見ると、内部ではlibavif使ってるみたいなんだよね。
とかおもってたら、どうもこのsusieプラグイン、単体だけではだめっぽい?
結局winにav1のコーデック入ってないと駄目っぽい。というかコーデック呼び出してデコードしてるだけのものっぽい? みたいなことが某巨大掲示板に書かれてたりして。
もうよく分かんねぇなコレw
ただウチでは普通にこのプラグインでavifは表示できるので、コーデックは入ってるっぽい。
winアップデートで入ったのか、忘れてるだけで昔に自分で入れたのかしらんけど(ぉ
あとはこのavif用のsusieのプラグイン、libavifのverが0.8.2とか使ってたりして(最新は0.10.x)まだまだ今後変更がありそう&現状開けないavifもぼちぼちあるっぽいなかんじで、まだまだフルサポートとは行かない状況っぽい。
まあとりあえず32bitのsusieプラグイン使って画像デコードして~てのは昔に組んだことあるので64bitでも変わらずできるんかいなーってところから試してみるかな。
……そんでもってもう一つ謎が。
avif用のsusieプラグイン。
ifavif.intel64.gcc
ifavif.intel64.clang
と大まかには二種類あるんだけど(あとはARMていうモバイル用のcpu向けのやつもあるけど関係ないので除外)
まあ、gccとclangはコンパイラの種類だってのはわかるのだけども。
試しにgccの方をマンガミーヤのプラグインフォルダに入れてみる。
avif表示普通にできる。
clang版のをいれてみる。
ぶち落ちるw
あるぇー?
マンガミーヤはMSVC製だとおもうのだけども。
gccてのは実際はMinGWとかのWindows環境で動くgccのことで、vc++とバイナリ互換あるから問題なく動いてる感じなのかな?
clangのほうはどうもMSVCとバイナリ互換がないっぽい??
正直良くわからんw
いよいよ見限られ始めた「Microsoft Visual - 趣味人倶楽部
ttps://smcb.jp/diaries/7625603
したらこんな記事が。
たしかに_sとか頭になんかついたりとか、msvcの所為でカオスになってる部分あるものなぁ。
その辺関係なく後発ゆえに洗練されてるわけだし。
vc++存亡の話きけばたしかにそうなるのかもなーて感じの印象ぽ。
そもQtではそういうの一切使う機会ないし、DXライブラリでも、そういう部分はラップしたりライブラリ化してもう直接触ること無い(触りたくもない)感じにしちゃうし。
そういう流れだよなーと。
なのでclang版があるってこと自体、時代の変遷を感じるべき所だったのかなーと。
とはいえ、Qtもclangビルド版とかまだ無いしなぁ。
でも来たら移行する……かな?
閑話休題。
とりあえずgcc版の方を使えばいいのかなコレは?
実際にテストコード書いてみないと分かんないですね。
というか使えてくれないと困る。
libavif自前でビルドは面倒くさすぎるのでやりたくないでござる。
まあ最悪、avifはQtで正式サポート来るまでシカトするのも有りかと。
ていうか……なんとなくwebpは根付きそうなきがするけど、avifはなんか流行らないような気もしてたりするんだけど、どうなんでしょ。なんか今回調べた結果、色々めんどくさそうて印象もっちゃってる所為か。
んまあ、とにかくこのビューワ作っちゃわないと、色々と捗らない感じなのでさっさと作ってしまいたい所。
普段はやっすい発泡酒ばっかりなので。
たまにはビール。
それも黒ラベル好きなんですよね。
んでなんとなく丁度黒ラベル買ったドラッグストア(税込価格で安いので)の隣にあるからあげ専門店のでっかい唐揚げとセットでプチ打ち上げして胸焼けコース(ぉ
なにげに親のお中元でアサヒスーパードライ(とジュースの詰め合わせのやつ)なんかもあったので、もう10年は飲んだ記憶のないスーパードライも飲んでみたのですが。
あれ? スーパードライってば後味が鉄さび臭い味しなかったっけか?
それがなんか何の特徴もない普通のビールって感じになってたり。
ぐぐってみたら今年2022年に「36年ぶりに味をフルリニューアル」したんだそうな。
へぇ~そりゃ印象全然かわっちゃうわなと納得。
まあ、スーパードライは個人的には貰い物でもなけりゃ今後も飲む機会あんまなさそうなのでどうでもいいけど(ぉ
そんな感じで、〆切明けってことで、ここ数日だらけた生活を。
んで、そろそろ動き出すべーってことで。
当面の予定としては、絵のレベルを上げる修行……の前に。
夏コミ原稿のときにも、ああ、さっさと用意しておくべきだった……と思ってた、susieの代替ツールの作成。
似たようなツール探したんだけども、それっぽいやつはあったものの(comono ImageViewerっていうやつ)唯一にして最大の欠点があって、ウィンドウを最前面に出来ないってことなんですよね。それ以外は表示形態といい、わりと欲しい機能網羅してたりしてたんだけどな……。
資料用の画像を表示しながら作画……ってのに最前面化してくれないとペイントツールと供用出来ないわけで。
とりあえず画面を選択してキャプチャするツール「Rapture」っての(コレめちゃくちゃ便利でもはやなくてはならないってぐらい使ってる……)でビューワで開いた画像をキャプチャして表示する。このツールは最前面表示できるので、これでしのいでたのだけども。
ビューワの方はマウスホイールで画像の拡大縮小を多段階で細かく変更できるのに対してRaptureのほうは25%または50%単位でしか変更できない&コンテキストメニューから倍率指定&拡大縮小が汚なくて使えないので、ちょっと資料のサイズ変えたいなってときに、ビューワの方でサイズ変えて、Raptureで再キャプチャ……と二度手間感あって、イライラ。
その辺、自分の使いやすい機能ぶちこんだsusie代替のビューワ作ろうと思ってたところで夏コミ作業期間のほうが先に来てしまった感じなんですよね。
これは今後のお絵かきの効率にも関わるのでさっさと作ってしまいたい。
ただ一つ決めかねてる部分があって、その所為でなかなか開発進んでなかったところがあって。
画像ファイル開くたびにアプリを個別に開く感じにするのか、子ウィンドウとして追加して開く感じにするのか……というところ。
子ウィンドウ形式だと、一括で開いてる窓を表示・非表示切り替えたりできるというメリットと、タスクバーも占領しない(画像いくつ開いても実質一個しか立ち上げてないので)っていうメリットあるのだけども。
コードが複雑になりがちというデメリットと、Qtはクロスプラットフォームな開発環境なので、win固有の機能とかないわけで。
アプリの多重起動禁止なんかも自前で処理書かないと行けなくてwinAPIでやるしか無い部分出てくるので面倒ってのもあったりして。
一方、個別のほうは作りやすくはある。
コードがシンプルに書けて複雑にならないし。
それ一つで完結するので。
んで、アプリの設定の保存とか、開いた画像の履歴をどう管理するのかとか、その辺、子ウィンドウ形式か個別起動かで変わってくるので、そこ決めなきゃ進められないんですよね。
今のところは、もう個別アプリ起動でいいかなてな方向に傾いてたりする。
上記のcomono ImageViewerていうビューワがその方式で、使ってる感じ、子ウィンドウ方式と比べて特にデメリット感じなかったりしたし。
そもそもの用途として、ペイントツールで作業しながら複数の資料画像を表示するかんじなので、個別に閉じたり出来たほうがよく、一括で閉じるのとかはかえって迷惑。
あと資料なんかは、今回のだと「2022_summer」とかフォルダ作ってその中にまとめて放り込んだりするので、ビューワ立ち上げるのは一個で、フォルダ内の画像を切り替え表示すれば複数立ち上げる必要も薄いわけで。
なので画像開きすぎてタスクバーがうまるって事態もあんまり起こらないかなぁと。
そんな知見も今回の作業中得られたので、個別アプリ案のほうに固まりつつあったりして。
というわけで、さっさと作ってしまおう。
と思ったのだけども。
最近avifファイルも結構増えてきてたりするっぽい?
Qtだと対応してたっけ。
と調べてみると、Qt6.4 betaとかでもまだ対応してないっぽい。
というか対応予定みたいな話すら出てきてないぽ。
というかavifて、数年前に調べた時点でまたフォーマットがまだ固まってないとか言ってたので、最近で回りだしたってことは仕様が固まったのだろうか?
とおもってググってみたのだけども、オフィシャル的なものなのかなんなのかもわからないけど、とりあえずlibavifてのが一番に出てくるのだけども、verが0.10.xと、まだver1.0とかになってないのね。
あとライセンス的にも今後どういうあつかいになるん?
とかちょっと不透明なところがあるらしく、そのへんでQtもまだ採用見送ってる感じっぽい?
webpはQtの対応速かったのにね。
やっぱその辺で揉めてる感じなのかなぁ。
次期verのQt6.4でもサポート無いので、まだまだサポートあるとしても先の話になりそうなので、自前でavifフォーマットも読めるようにしとこうかなとおもったのだけども。
このlibavif……なんかすんげぇめんどくさい。
コーデックやらなんやらのビルドにninjaとかいうビルドシステムが要ったりとか他にも色々と必要だーとか書かれてて、なんかいろいろとめんどくさそう……。
このためだけにごちゃごちゃ入れるの嫌ぁ……って感じで。
……ていうかちょっと前にavifとりあえず表示できるようにってことで、susieプラグイン入れたんだっけ。
ってのを思い出す。
……あ、じゃあsusieプラグインからavifデコード→QImageしたらええやんけ。
ってことに思い至る。
どうせビューワにはsusieプラグインとか対応する予定だったし。
じゃあそれで解決じゃん。
てことになる。
そんでもって、susieも代替ほしいって理由の一つに、もはや開発停止して久しく、最近のwindowsだと結構動作がおかしい部分出てきちゃってるってのもたったりする。
ただプラグインの仕様は便利なのでそこだけ未だに開発、ユーザーともに利用者多い感じなのだけども。
ここ最近は64bitビルドで作るのが基本になってきてるので、プラグインも64bit版の.sph(32bitは.spi)を使うことになるのだけども。
そうなると古い32bitのしか無いやつは使えなくなるなーとか(なんか方法はあるらしいけど)
susieAPIの解説なんかみると32bit版のものしか見当たらないのだけども、64bitでもおんなじなのかなコレ? とか。
もはや界隈廃れまくってて情報が1999年とか20世紀で止まってるw
なんかそゆのみちゃうと、なんかちょっとさみしい気分になるな……。
あとavifのsusieプラグイン、gitにあるソースコード見ると、内部ではlibavif使ってるみたいなんだよね。
とかおもってたら、どうもこのsusieプラグイン、単体だけではだめっぽい?
結局winにav1のコーデック入ってないと駄目っぽい。というかコーデック呼び出してデコードしてるだけのものっぽい? みたいなことが某巨大掲示板に書かれてたりして。
もうよく分かんねぇなコレw
ただウチでは普通にこのプラグインでavifは表示できるので、コーデックは入ってるっぽい。
winアップデートで入ったのか、忘れてるだけで昔に自分で入れたのかしらんけど(ぉ
あとはこのavif用のsusieのプラグイン、libavifのverが0.8.2とか使ってたりして(最新は0.10.x)まだまだ今後変更がありそう&現状開けないavifもぼちぼちあるっぽいなかんじで、まだまだフルサポートとは行かない状況っぽい。
まあとりあえず32bitのsusieプラグイン使って画像デコードして~てのは昔に組んだことあるので64bitでも変わらずできるんかいなーってところから試してみるかな。
……そんでもってもう一つ謎が。
avif用のsusieプラグイン。
ifavif.intel64.gcc
ifavif.intel64.clang
と大まかには二種類あるんだけど(あとはARMていうモバイル用のcpu向けのやつもあるけど関係ないので除外)
まあ、gccとclangはコンパイラの種類だってのはわかるのだけども。
試しにgccの方をマンガミーヤのプラグインフォルダに入れてみる。
avif表示普通にできる。
clang版のをいれてみる。
ぶち落ちるw
あるぇー?
マンガミーヤはMSVC製だとおもうのだけども。
gccてのは実際はMinGWとかのWindows環境で動くgccのことで、vc++とバイナリ互換あるから問題なく動いてる感じなのかな?
clangのほうはどうもMSVCとバイナリ互換がないっぽい??
正直良くわからんw
いよいよ見限られ始めた「Microsoft Visual - 趣味人倶楽部
ttps://smcb.jp/diaries/7625603
したらこんな記事が。
たしかに_sとか頭になんかついたりとか、msvcの所為でカオスになってる部分あるものなぁ。
その辺関係なく後発ゆえに洗練されてるわけだし。
vc++存亡の話きけばたしかにそうなるのかもなーて感じの印象ぽ。
そもQtではそういうの一切使う機会ないし、DXライブラリでも、そういう部分はラップしたりライブラリ化してもう直接触ること無い(触りたくもない)感じにしちゃうし。
そういう流れだよなーと。
なのでclang版があるってこと自体、時代の変遷を感じるべき所だったのかなーと。
とはいえ、Qtもclangビルド版とかまだ無いしなぁ。
でも来たら移行する……かな?
閑話休題。
とりあえずgcc版の方を使えばいいのかなコレは?
実際にテストコード書いてみないと分かんないですね。
というか使えてくれないと困る。
libavif自前でビルドは面倒くさすぎるのでやりたくないでござる。
まあ最悪、avifはQtで正式サポート来るまでシカトするのも有りかと。
ていうか……なんとなくwebpは根付きそうなきがするけど、avifはなんか流行らないような気もしてたりするんだけど、どうなんでしょ。なんか今回調べた結果、色々めんどくさそうて印象もっちゃってる所為か。
んまあ、とにかくこのビューワ作っちゃわないと、色々と捗らない感じなのでさっさと作ってしまいたい所。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
04
05
■
■
ひぃ
06
07
08
09
10
11
[山の日]
12
13
■
■
夏だビールだ
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
■
■
もう涼しい
30
31
total:2080294 t:2664 y:180
■記事タイトル■
■年度別リスト■
2024年
2024年12月(0)2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp