漫画ビューア総合スレ Part2

フリーソフトとして配布するなら一切の責任を負わなくてよかったはずなのに
いらんルールが出来たせいで面倒なことになった

>>46
無料ソフトとかでバカな事するキッズとかいるじゃんｗ
だからこそ利用規約などの規制が生まれるんだよ～

ちゃんと利用者全員がルールを守ってゲームしてれば利用規約や法律は生まれないｗ

？
フリーソフトを理解してんのか？
仮に不正利用されたとしても責任は無いんだぞ
ここで言ってんのはコードの権利関係

フレームワークやライブラリの権利ね

>>49
開発者側の方じゃなくてそれで被害に合う側の方だろ
おめーさんも理解が浅いやんけｗ
スシロー（＾ω＾）ﾍﾟﾛﾍﾟﾛみたいなのがいるから利用規約みたいなのは生まれるｗ

よく分からんが使用するだけの人の利用規約の話はしてないんじゃないのw

理解してないのなら書き込まないでな(´・ω・｀)
>>49もﾋﾟﾝﾄずれてるあほうなんだよな.....
利用規約ってのは開発側の制約じゃなくて利用者側の制約.....
後法律に関しては開発と利用者の双方に制約がかかる(´・ω・｀)

分かってるの50だけだ

こんなとこで配布してられんね

おろろ？？50だけなの？？ｗ

AIできてから粗製乱造のゴミソフトばっか湧いてくるようになったな

うるせぇよどうせ興味ねぇだろ

>>1
QuickViewer忘れないであげて

やっぱこだわって自炊している人が開発すると目指している到達地点が凄い
どこぞのランダム閲覧アプリとは違うよ

そういうdisりも要らんのよ

今話題の画像ビューアー
なんであんなに不具合が見つかるの？

>>59
いわゆる🤓くさいタイプかな？？？？
そもそもアプリも見ず触れずなライト層じゃ知識が付かないw

漫画ビューアーと画像ビューアーは違う
漫画ビューアーはブックビューアー系統です

確かに目的が違うな....漫画Viewは漫画だ・け・で
画像Viewは漫画も含めた画像全般だからなー
表示している色が違うし描画とかも画像Viewの方が繊細さを求められるような？？

マンガはモノクロ成分が多いかも？

https://github.com/suzunajp/suzunia-release

見つけた

.net
終了

24〜29msなら速い
FHD画像ページめくりが何fps出るのかの実測も欲しかった

設定画面は別アプリです
本体に設定 GUI を同居させると、GUI フレームワークのロードだけで起動が約10倍遅くなります (実測: 空ウインドウの表示まで Win32 は 24〜29ms、WPF は 266〜324ms)。動作を最速化するため、設定画面 suzunia-settings.exe は別プロセスにしてあります。設定画面での変更は、起動中の本体へ即時反映されます。

それと起動速度の計測方法によるのでしょうがWaitForInputIdle方式だと
空ウィンドウを出すだけなら17msですね
GDI描画まで持って行くと1フレーム増えて34ms
DirectX初期化までやると150ms~250ms

>>66
動作は低スペックでも軽快でいいね
ミーヤじゃなくLeeyes派には本棚というかファイラー表示ないと使いづらい点だけが残念
ソース非公開は仕方ないにしろsusieじゃなくdllだと敷居が高い
spiをdllにリネームしても動くんだっけ？仕組み忘れた

>>66
外部プログラム起動がなきゃmassigraの代わりにすらならん

FHD画像ごとき余程ひどくなければ今時先読みしなくても大丈夫じゃねぇか
8Kや6Kとかだとページめくりしんどくなってくる

ほらね
批判ばっかり

mImageって左クリックでページ進む、右クリックでページ戻る の設定って出来る？
操作設定をイジってみたけど分からなかった

すまん専用スレあったのね

>>70
逆に言うと設定アプリが別アプリになってるから
ファイラー部分も別アプリで作者作ってくれたりw

質問です。
MassiGraを使っているのですがDeleteを押して画像を削除する動作が遅くなってしまいました
以前はDeleteを押し続けるとダーーーーーーッと目にも止まらぬ早さで削除できたのですが今は一枚一枚画像が表示されてから削除される状態です。設定をいじった記憶はないのですが…
[Shift] + [Delete] でもスピードは遅いです。原因がわかりましたらお願いします。

MassiGraは専スレあるよ >>2

>>66
これ普通に良くないか？速いし凄くまともな挙動でMassigra代替レベルかも
外部プログラム起動(他のアプリで開く)とかファイル削除なんてMassigraでやる人は別だけど

自分はNeeViewが多重起動オフなのでNeeViewが塞がっているときにこう言った軽いのを使う

>>66
今気が付いたけどバージョンアップして対応してた
> ファイルの削除（ゴミ箱行き/直接削除）機能を追加しました。

Massigra代替>>77

>>78
サンクスコ

>>66
epub対応アップデート良いね、epubも凄く高速にページめくり出来る
ただし中華フォント問題が出ている

>>66
いいかなっておもったけどepub内の文字の大きさ変えれないのか
あとフォルダー内移動もできなさそう

Kinoppyの方が小説見るには使い勝手いいんだよな

>>77
meeyaの方が使い勝手よくない？
まあフォルダー内の書庫ファイルが多いと次の書庫がめっちゃ読み込み遅くなるって致命的な
バグがあるけど

軽くてmeeyみたいにフォルダ自体の削除とフォルダー内ファイル削除どっちもあるの
がいいんだけどな
色々使ってみたけど他のはフォルダー内ファイル削除機能しかないんだよな

書庫内の削除とかメンテナンスなんて頻繁にやらんし
そもそも自分で作った書庫を書庫化した後にメンテナンスするの？

ビュアに削除機能を持たせるのは推奨しないけどな
キー一つで削除とか怖くて使えん

>>88
デフォでオフ

>>88
確認のウィンドウでも出してくれれば

>>88
強制じゃなければあったら楽

>>88
他の例があるので分からんでもない

987 名無しさん＠お腹いっぱい。 2026/07/30(木) 13:29:42.78 ID:i3bL6g9L0
もっさりしてて困ったのが、ファイルを複数選択して削除したら選択してないつもりだったものも選択されたままで削除されてしまったこと。
ゴミ箱も空にしてから気づいたから終わってた。

>>66
suzuniaの場合は、ゴミ箱の時にも確認ダイアログを出す選択肢は有っても良い

ファイル操作
✅ファイル制御を許可する
「ファイルの削除」などのファイル操作メニューを有効にします。誤操作を防ぐため既定はオフです。
✅ファイル削除時にゴミ箱に入れる
ファイルを削除するとき、完全に削除せずゴミ箱へ移動します。オフにすると直接削除されます。
✅直接削除するときは確認ダイアログを出す
ゴミ箱を使わずに直接削除する際、確認ダイアログを表示します。

>>66
>>82-83
epubにはwebviewを使っているから技術的には簡単に解決できるけど設定画面がどんどん増えて行くな
早いうちに設定検索を付けないと文句出る

設定や履歴等のjsonファイルはサブフォルダに置かないといけない
いつも上書きアップデートで躓く人がチラホラ居るので

>>88
単にゴミ箱送りなんだからエクスプローラーの戻すで簡単に一つ前に戻せるぞ

>>88
ファイラーもキー一つで確認無しにゴミ箱だぞ

suzunia、neeview、mimageviewを試した
結論から言うとミーヤ使用続行。全般的にはプレイリストと割合移動がどれもない

なぜどれもデフォルトフォルダを求めるのか。
空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。
それだけで良いのになんでそれすらできないのか理解できない

suzunia　デフォの鳥サムネが気持ち悪いのに無効にできない、プレイリストがない。固定ページ移動はあるが割合移動がない

neeview　割合移動がない。「プレイリスト」名称の機能はあるがこんなのはプレイリストでもなんでもない

mimageview　根本的に漫画ビューアを誤解してるくさい。というか日本人が作ったかも怪しいレベル。
表示は？プレイリストは？操作設定のページ移動は？画像フルスクリーンてなに？なんで動画があんの？
列だのタグだのようやく消したと思ったら今度はなにも設定できないという。
これで400MBって本当になんなのこれ

>>96
> デフォルトフォルダ
何それ？異世界用語？

クセ強人間は自分で作るしかない

＞空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。

なんで毎回無駄な作業をするのが好きなの？
お気に入りをぶち込んでプレイリストを作るは理解出来るけど、毎回リセットされる意味が分からない。

デフォルトというかなんか別の表現したかった系？？
重度のMeeya依存症なのはわかったｗ
割合移動なんてミーヤにあったっけ？？？

>>96
>>空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。

NeeViewはD&Dやコンテキストメニューの「NeeViewで開く」or「送る」で可能
一時フォルダ配下に一時プレイリストが生成されてそれが本棚として開かれる仕組み。NeeView終了時に一時フォルダごと破棄される

割合移動についてもスクリプトを書けば可能（NeeViewはスクリプト次第で「何でも可能」と言ってもいいほど）
実際のところ「使いこなし」の問題に過ぎない

> 実際のところ「使いこなし」の問題に過ぎない
ほんそれ

「デフォの鳥サムネ」なんか初回起動の設定で普通に無効にした

＞空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。
えっ
駄目なの？
エクスプローラーからドラッグアンドドロップのOSのUXにあう方法でしょ
何が無駄な作業なの？

割合移動って何？

>>66
https://github.com/suzunajp/suzunia-release/releases/tag/v20260812
> 一旦、当初の想定で考えていた機能は全て揃った版
suzunia, 1週間足らずで完成したってよ

>>96
プレイリスト機能は想定外

>>104
10%, 20%とか設定して全体ページ数(例200なら) +20とか+40 毎にジャンプするのでは
Youtubeの数字キーみたく割合絶対位置ジャンプもあると良いね( 1で10%の位置、5で50%の位置など)

見開きでも1ページ表示でも割合だと計算しなといけないし
20ページスキップとかの方が実装は簡単かな

>>105
YouTubeにそんな機能あったんだなーｗ いつからなんだろ？

suzuniaシンプルで使いやすいけど
縦に収まってない時にホイールで普通にスクロールできる設定ないのかな
どのビューアもホイールがページ送りなんだよね

>>96
現行世代四天王、あと一つは？

>>106
実装が簡単とか利用者には関係ない話
固定ページスキップは使いづらい
理由は前スレ756

俺20/40ページ移動で実装することにした
固定方が簡単だし、バグ避けにもなるからね

>>110
ばかたれ、利用者(読み手)の利便性を考えろw
https://egg.5ch.io/test/read.cgi/software/1752914772/756

それはさておき、厳密な計算とか必要ないでしょ
10%スキップして10%戻ったら元のページになれば良いだけ

いや割合移動は大雑把でも計算ないときついぞ？？
単純に画像の場合は割合/総数で計算すればいいだけかな
動画とかは再生時間で割ってるんだろうけどな

開発者ごっこがしたいおじいちゃんを介護するスレに改名してもろて

>>113
テキストエディタでの次の行、前の行移動でのカーソル移動と同じイメージ
設定割合x1, x2, x3 ....で改行があって「行頭」からのオフセットを維持して割合移動する

割合移動を連発している間はオフセット更新はしない、他の操作でページが変わったら
その「行」でのオフセット値に更新する

オフセットは見開きの場合とか考えずに画像の数にする
(この部分が近似、アーカイブ内は整理されていて主に見開き結合済みか主に分離かが偏っている、と仮定)

>>115
通常のページめくり閲覧やユーザー操作での単ページシフトなどで
最初の決め打ち「設定割合x1, x2, x3 ....」が見開きを分断している事が判明したら「改行」ポイントは修正する
可能なら閲覧履歴情報に修正値も記録しておけば2度目以降は最初から正確になっている

>>108
縦につなげて表示したらスクロールできない？
mIVはその動作だし、NeeViewもマウスホイールスクロールを使用するにすればホイールでスクロールできる

>>117
1ページはそのページだけで上下させたいんよ
まぁそういう設定がないって事は自分の使い方が特殊なんだろうね

>>118
特殊もなにも、どのビューアも...、と言う事は
それが使い易いかは自分でも分かってないのでは

IrfanViewにあった記憶
縦に並べてスクロールするんだと画像下端がスクリーン下端に到達してから次ページの画像上端がスクリーン上端に移動する距離が邪魔だから
あったらあったで便利に使う人もいるでしょうな

>>68,72
> FHD画像ページめくりが何fps出るのかの実測も欲しかった

suzuna約30-31fps、NeeViewも約30-31fpsだった
調べたらシステム設定でキー入力のリピートが最大で31Hzになっていてこれでキャップされていると思う

キーを離していないという状態をアプリ側で判断して最速を出している訳ではなさそう

画像の表示はどのソフトも十分速くない？
PDFはソフトによる差が大きいように思う。ロード中にするか待たせるかとか
普通にページめくって読む分には気にならないけどね

動画とかなら割合移動欲しいとは思うけど画像で欲しい人いるんだなｗ
tubeのやつを使ってみたけどかなり使いやすくてそこだけはさすがYouTubeだなとはおもったｗ

ユーザーペインの肝要な部分を聞き取るより先に
プログラミング的な落とし込みに会話が進みがち

>>122
> 画像の表示はどのソフトも十分速くない？
十分の捉え方次第だね
レジストリいじって125Hzリピートにして4K60Hz画面で

miv(egui)/viewskater(egui)は平均50-52fps止まり
gashuu(slint)は平均60fps出る

他高速なneeview/suzunia/qview/quickviewer/slapは平均60fps出る

番外
massigra 21fps
RustMangaReader 15fps

失格
uviewer キーリピートでページ移動しない

>>125
https://github.com/ggand0/viewskater-egui
FPSオーバーレイがあって瞬間的に55-56fpsは出ているけど
今回の計測は555枚の画像でのタイムから平均を取った

>>126続き
キーリピートをレジストリで125Hz(8ms間隔)に設定してもwin32k.sysの制限でリピート生成は64Hz(15.625ms)になるそうなので
125Hzでキー送信するアプリを用意して計測し直した
画面の60Hz以上なので1フレームタイムで2回描画していることになるけど(Lap以外は)見た目はスムーズ

gashuu/neeview/qview 114fps
quickviewer 113fps
(lap 110fps ただしカクカク)
suzunia 102fps

114fps=(555-1)/4.85の様に0.05s精度でキー送信時間を設定して
554回のページ移動が完了する秒数を見つけて計算した
lapはカクカクだけど最終ページに飛ぶことは飛ぶのでその時間で計算した参考値

>>125
mIVのスレで作者がページ送り引っかかる事があるんで直すって言ってるな

キー入力
fps
描画枚数
体感
統一基準を出してもらわないと判断できないです
1枚1枚表示しているか確認したのですか？
高速ページ移動で描画スキップさせるのは体感向上のテクニックでしょうし
そもそも今どきFHD程度で遅いとか速いとか重要なのかな

画像の高速切替は光過敏性発作を引き起こす可能性があるから
画像・映像を扱うアプリ開発者は気をつけような

>>128 楽しみです

>>129
本当に描画をしているのかを調べるのは凄く大変だと分かった
RTSSでfpsが取れるかやって見たらeguiは数値が出るけどegui自体がオーバードローしてない
SlintとWPFはPresentMonで取れたけどAIが言うにはWPFが内部で合算してPresentしているので
オーバードローしていてもそのfpsは分からないと、Slintは何のAPIがさえ分からない(PresentRuntime=Other)
Qt系とsuzunaはGDI描画らしくPresentMonでデータが取れなくてAPIをフックすると言われて放棄した

という事で何を基準にするのが正確かを考え直すと

新基準
1. (ページ送り)キー処理に漏れがなく (554回送信で最終ページに到達する)
2. 描画は一部スキップしても良いけど全スキップや明らかに引っかかりや止まるのはダメ
(体感向上のテクニックとして見た目20-30fps位に落ちていても良しとする)

この基準内でキー送信出来る上限レートを探る事にする

そこで>>127の数値を振り返ると125Hzで送っている設定なのに114fpsと計算値が出るのは変だなと思い調べたら、キー送信するアプリ側のスリープ処理が単純過ぎてGUI更新のせいで125Hzで送信出来てない事が判明したので手直し中

自分が納得するまで試してから数字は出すけどneeviewやsuzuniaは凄い数値が出そう

FHD画像でやっているのは良くあるCPUペンチと同じ考え方、表示は4Kにしている

>>131
やっとキー送信アプリ側の手直しと検証アプリが出来た
https://i.imgur.com/Ses7cD5.png

>>132
右側がキー送信アプリで2000~2200Hz位までは正確に遅れる
左側が検証アプリで1900Hz位までは遅延なく受け取れて2000~2200Hzはわずかに遅延するけど受け取り漏れは無い(つまり送信アプリでのキー送信漏れも無い)

>>131
suzunia 1400 Hz
このレベルでは554回ページ送りが一瞬ではあるのの
1500Hzではカクツキが目立ち始め2000Hzでは全スキップで最終ページに飛んだ

>>127の後に20260813にアップデートした時に設定を弄ってしまった
たぶん変えた場所は今回はアンシャープマスクOFF、性能プリセット高スペック

>>131
neeview 260 Hz
270 Hzでは成功したりページ送り処理漏れが発生することがあり不確実だった

>>131
qview 70 Hz
確実なページ送りではキー送信レートここまで落ちた(検証5回)
114 Hzでも一見したところはスムーズにページ送り出来ていたが
ページ送り処理漏れが1~2個発生することが多い

>>131
gashuu 200 Hz
フルスクリーンがなさそうなので最大化で代用した
もっと送信レートを上げて2000 Hzでも処理漏れは無いけどグルグルマークが出たり全スキップになったりして体感が良くなかった

>>131
quickviewer 80 Hz
qviewと同じく処理漏れが発生しやすい
今回は80Hzで5回連続成功した(正直これで確実かどうかまでは分からない)

>>131
Lap 5 Hz未満
5 Hz程度でもページ送り処理漏れが1~2個発生する
30 Hz程度までは3個程度処理漏れ
60 Hz程度は一見スムーズだけど10個程度処理漏れする

>>131
viewskater-egui 40 Hz
45Hzで処理漏れが出た

>>131
mImageViewer 5 Hz未満
>>128の通り直すそうなので現バージョン(v2.13.0)での計測にそれほど意味はないけど
5 Hz程度でもページ送り処理漏れが1個発生する

>>131
おまけ
Massigra 21 Hz
2000Hzでも処理漏れはない、ただし描画スキップもないのでキー送信が終わった後にページ送りが続く

suzuniaの中の人です。さきほどスレの存在に気付きました。
上の方で触れられている「割合ページ移動」「ゴミ箱に入れるときも確認ダイアログを出す」は対応しました。

このアプリの売りである「速度」とは具体的に、起動速度や画像デコード速度、プリフェッチ範囲辺りが想定でした。
（オプションで「本の残り全ページをキャッシュ上限まで先読みし続ける」という設定がありますので、メモリに余裕があればon推奨です）

皆さんが気にされている？プリフェッチ済みページの切替速度は正直ノーマークでした。ので、この機会に手を入れました。

次の表示用画像まで裏で作り置きしてページ送りを転送だけにする改修で、手元の環境で4K表示、切替 6ms→2.4ms くらいまで削減しました。

連打向けには連打中だけ描画品質を落として高速化するオプション(既定オフ)も追加しました。

>>143
対応お疲れ様です。まず割合移動について、20に設定で5回で末尾移動と動作確認できました。
実装していただきありがとうございます。

現状での困った点としては下記があります。方針に沿うのであれば検討いただけると助かります。
・起動時のペンギン画像の非表示設定
　→カラーが派手なので単色にしたい

・ページスライダーの下部表示
　→タイトルバー下は使い辛く、また視認性も悪い。他ビューアと同様に目盛りありのスライダーでは駄目か

・プレイリストの実装
　→本棚(フォルダ管理)の不採用は同意する。
　しかし複数を連続して読みたい場合は、ミーヤでいうプレイリストがあると助かる。
　画面の圧迫については個々に広げればいいと思うが方針に合わないか

・(zipではなく)フォルダでも2ページ表示
　→フォルダをDDすると単ページとなり、表示の選択がグレーアウト
・D&Dでビューアをアクティブにする設定

使わないくせに手当たり次第いろんなソフトに大量に要望出して後でじっくり選ぼうとしてて草
同じやつだろこれ

>>143
使ってほしいならDLページにスクショ置くべき
あの1枚だけじゃ試してみるかって気にならない

DLページ開いてる時点でDLするでしょう
今は機能拡充に専念して欲しいわ

今のところはAlt+1などにキー割り当てしてもエラー音になるのが不満くらい

試しに起動はする
でも書庫なしはソフト側からこちらを足きりしてるからなあ

>>147
DLページつーか配布ページな
そんくらいわかるだろアスペかよ

>>149
自己紹介乙
DLページに画像や動画貼れるの知らなかった?

>>148
何もしなくても書庫内画像見れてるけど7zipにパスを通しているからかな

>>145
同じ事思った、>>144 = >>96だよね
ペンギン消せるのにろくに設定見ない人なんだと思う

>>143
最速ビューアおめでとうございます

>>131,132
キー処理漏れ発生と連射スピードに相関があるのかもしれないけど
根本は処理漏れが発生する時点でビューアのバグでしょう

俺の考え方、使い方こそ正義だ！みたいなやーつ

>>131
乙
検証したあなたも凄いけど
何百、何千fpsでキーを受け付けるソフトも凄いね

自作ファイラ+suzunia 8/5版でも自作ファイラ+Leeyesより起動が速くなって望む動作になったからこれでいいや
いままでありがとなkenji

suzuniaさんはタイトルバー隠した全画面表示だと最小化のオプションがないのが気になる
ちょっとしたときに裏行ったりするときに不便
win+Dは効いたがwin+Mは無効だったし

>>131
ページ送りは、処理自体の速度差はあるけど、間に合わなかったとき
キーの押した回数を優先して表示はせずにページを進めるのがよいか、
途中のページを表示して間に合わないキー入力をキャンセルするのか、
はどちらが正しいというわけでもなく、作りが違うのかも

デジカメ写真やPDFだと、NeeViewはファイル名とロード中だけでて
画像が出るまでは毎回待たされる
suzuniaはフル画質さっと表示されて速い
画像が画面に出るまでの時間で比べたらかなり差がでるんじゃないかな

win+Dで最小化しても他で作業しようとすると強制的にsuzuniaがフォーカスするのか
ブラウザとかは最大化したままwin+Dですべてのウインドウを最小化した場合は他のウインドウがフォーカスできるのに
開きなおしたら最大化したままで復帰もできる

・ペンギンは消せます。
・プレイリストに代表される「書庫の管理」系UIは、今のところ対応予定はありません。
将来的に実装予定はありますが、期待しているものとは異なるインターフェースになる可能性があります。

指摘頂いた以下の修正を行いました。ありがとうございます。
・「画像・フォルダでも2ページ表示にする」設定の追加
・「ドラッグ＆ドロップでウインドウをアクティブにする」設定の追加
・全画面表示時に最小化/最大化/閉じるボタンが消えるバグ
・操作割り当てで「ALT+通常キー」が効かないバグ
・ページスライダーが見にくい問題（通常のスライダーを用意する予定はありません）

私が求めているわけではありませんが通常のスライダーをつけないのは画像が縮小されるのが嫌だとかそういう理由なの？
開発ポリシーは支持したいけど参考までに理由は知りたいです

>>141
v3.0.0が出た
検証頼む

>>162
mImageViewer v3.0.0
特に変わらないと思う(設定が必要?)
AI関連は無しにしてキャッシュ系は最大値、ビューワモードは複数ウィンドウにしてます
これにするとメインウィンドウのサムネ表示との連動がないので

入力速度␣平均処理漏れ数(5回計測)
5 Hz␣1個
30 Hz␣1個
40 Hz␣2.6個
50 Hz␣8.2個
60 Hz␣19.7個
100 Hz␣228.2個
2000 Hz␣549.8個

低速度でも1個漏れるのは多分バグ
30Hz越えで漏れ数が増えるのは処理速度限界突破でしょうか(バグと呼ぶかは諸説あり)

>>163
mImageViewer作者です。詳しい検証ありがとうございます。

コードを確認しました。
mImageViewerは、キーを押しっぱなしにしたときのリピート入力を、
すべて回数として蓄積する作りにはしていません。

押しっぱなし中は、各ページを飛ばさず順番に見せつつ、
読み込み待ちで引っかからないよう、通過中はサムネイル画質で表示します。
キーを離すと、その時点で実際に表示していたページをフル画質へ切り替えます。

今回のツールが、キーを押したまま任意の間隔でリピート入力を送り、
最後の入力直後にキーを離す方式であれば、
最後のリピート入力とキーを離した情報が同時に処理されることがあります。

この場合、最後のリピート分まで進めると、キーを離した後に次のページへ
移動する動きになるため、その1回は実行しないようにしています。
低い頻度でも1回ほど差が出るのは、この動作による可能性が高そうです。

また、処理速度を超える入力についても、後からまとめて移動し続けないよう、
未処理のページ送りをキューへ溜め込まない設計です。
そのため、高い頻度では入力回数との差が大きくなります。

>>164
> キーを押しっぱなしにしたときのリピート入力を、
リピートだと64 Hzがシステム限界なので
キー送信アプリでは、SendInput APIで押す、離すをセットにして高速に呼び出してます

>>165
詳しい説明ありがとうございます。

毎回 SendInput で「押す→離す」を送っている方式であれば、
先ほど書いた「最後のリピートとキーを離した情報が同時に処理される」
という説明とは別の原因がありそうです。

高い頻度で差が増える点は現在のページ送りの仕組みで説明できますが、
5Hzで554回送った場合にも平均1回ほど欠ける点は、
こちらの通常のキー操作では再現できていません。

開始時のフォーカス切り替えか、どこか一度だけページの表示確定に
200ms以上かかっている可能性などは考えられますが、
現状の情報だけでは特定が難しそうです。

検証アプリを公開可能でしたら、こちらでも同じ条件で確認してみます。

>>166
確認よろしくお願いします

ダウンロード期限：2026年11月23日(月)
https://96.gigafile.nu/1123-b14d5d9d903ece99395b0aa05dbd6adb7

ソース一式の他、binフォルダにビルド済みexeとslint_cpp.dllを同梱しています
Slint SDK(含むdll)オリジナルはここにあります
https://github.com/slint-ui/slint/releases/download/v1.17.1/slint-compiler-Windows-AMD64.tar.gz

Key / Shortcutはボタンを押すと入力出来ますがCtrlなどのキー入力はバグっていて上手く行きません
フリー版AIが直してくれないので放置してますが直してもらえると嬉しいです

>>167
C++用のビルド済みSDKはこちらでした
https://github.com/slint-ui/slint/releases/download/v1.17.1/Slint-cpp-1.17.1-win64-MSVC-AMD64.exe

上記インストーラーexeが何所までやってくれるのか分かりませんが自分は手動で解凍して
cmake用の環境変数 Slint_DIR を 解凍先\lib\cmake\Slint に設定しました

そもそも意味あるベンチマークかもわからないのに速攻で作者飛びついてて草
落ち着けよ

そもそも1000hzとかで切り替えられて何なの？
高速でページ送りしたい時でも、10hzくらいあれば十分なんだが

>>66-67の流れで分かるんだけど、「.Netだと遅い/あるいは何かしらの問題がある」と信じている人が一定数いるんだよね

suzuniaがそうであるように、実際はそんなことないのに

suzuniaはネイティブアプリじゃないの?
設定アプリが.netアプリ
違った?

.net c#なら早いけどね
昔の.netで語る人が多いからね

Windows は Win32 API 直書き、macOS は AppKit 直書き。どちらも NativeAOT で、GUI フレームワーク (WPF / WinForms) を使いません

suzuniaのgithubとかいてある

NativeAOTって.Netのことだよ？
>Native AOT（Ahead-Of-Time）とは、.NET アプリケーションのビルド時に、中間言語（IL）からOS固有の機械語（ネイティブコード）へ完全にコンパイルする技術です。

どこかのアプリが「.Netのせいで起動が遅い」とか書いたのを鵜呑みにしてるのかな？

>>167
ツールとソースの公開ありがとうございます。
おかげで原因を特定できました。

A. 5Hz / 1秒 / Max Countなし
B. 5Hz / 1秒 / Max Count=5

で確認すると、どちらも5回キーを送信しますが、修正前のmIVは
Aでは5ページ、Bでは4ページ進みました。

Aでは5回目の送信後も次の周期まで約200ms待ってから、
キー送信ツールが自身のウィンドウを前面へ戻します。
Bでは5回目を送った直後に前面へ戻るため、mIVが最後の入力を
処理する時点ではフォーカスが外れていました。

mIVは、フレーム単位で描画するときに、それまでのキー入力を判断して
動作をするような作りになっています。
このキー入力判断時に、自身がフォアグラウンドでなければ処理をしない、
というロジックがありました。
この判定は、フルスクリーンを別ウィンドウで扱うようになった際に、
別ウィンドウでの入力誤処理を防ぐために追加したものでした。
その後のリファクタリングでキー処理全体の入口へ移され、今回の
入力まで処理しない状態になっていました。

これがBパターンのときに影響し、１回分の処理が減る原因となっていました。
キー入力時点の配送先を基準に処理するよう修正し、修正後はBでも5ページ
進むことを確認しました。次のリリースに反映します。

通常操作では見つけづらいタイミングのバグでしたので、
再現条件を絞った検証とソース公開、大変助かりました。
ありがとうございます。

なお、mIVは通過するページを1枚ずつ順番に表示する方針です。
表示速度を超える連打は、後から実行するために蓄積しないため、
レートを上げると押した回数より進むページ数は少なくなります。

ただし、表示されるページの順序自体は飛びません。
1ページ目から100ページ目まで進める入力をした場合、
100ページ目へ届かないことはあっても、途中のページを飛ばして進むことはありません。
こちらは意図した動作です。

動作検証には影響しませんが、ツール側で1点だけ気づいたところがあります。
Max Count指定時のActual Rateは、最初の送信から最後の送信までを経過時間として
「送信回数÷経過時間」で計算しているようです。

N回の送信間隔はN-1区間なので、表示値がN/(N-1)倍になります。
例えばBでは設定5Hzに対して約6.24Hzと表示されます。

.netのNativeAOTは知ってるけど
c++で書いてもNativeでAhead of timeだし
どっちが正解かわからない
まぁ、作者答えてくれるやろ

>(本体に静的リンク) .NET ランタイム
MacOSばんだとこんなこと書いてあるし
正解は.netのNativeAOTかもね

今ならCsWin32辺りでWin32やら呼んでるのかな

てっきりC++とかで書いてるのかと思った

>>163
v3.1.0来たぞ

suzunia、「外部プログラム起動」機能が無いという指摘を見落としていたので追加しました。
その他いくつかのバグ修正や小さい機能追加を行っています。

さて。実はsuzuniaは「.NETは何故か遅いと勘違いされているから、最速の画像ビューアを.NETで作ろう」が立脚点になっています。
当然.NETで作られています。
このスレの反応を見ても分かりますが、この意図（.NETで最速の画像ビューアを作る）は達成されたと見て問題無いかと思います。
（機能不足に関する突っ込みも多いですが当然の話で、機能を目的としたアプリではそもそもないから、なんですね。
　いま現在、いつの間にか多機能なアプリになってしまいましたが、これは単純に私が凝り性だからというだけで、言ってみればただの蛇足です）

>>67「.net 終了」なんかは自演じゃないかと自分で疑うくらいに狙い通りの反応ですし、
>>172「suzuniaはネイティブアプリじゃないの?」と、ネイティブ実装と勘違いする程度には高速であることも証明されました。
しかもこのレスは「.NETは遅い」という間違った思い込みがあるからこそ出てくる発言で、二重の意味で期待通りでした。

という感じで、まあアプリを使う側からしたらこんなどうでもいいことは考えずに、
Meeyaの代替としての一つの選択肢が出てきた、相性が合えば使い続ければいいし合わなければゴミ扱いする、で良いのではないでしょうか。

>>181
改めて最新をDLしてみたが操作にスクロールの設定がない
幅に合わせた場合にないと致命的でドラッグ移動出来るとはいえチャタリングでも起きたらページ移動しちゃう
付随してドラッグ終了→ページ移動した際にウインドウ位置が遷移する前の位置にとどまって本来後に読むべきコマを先に読まされることになる
ページ移動したらウインドウ位置のリセットを設定でONOFFさせてほしい

幅に合わせた場合WEB閲覧の様に縦読み型でもいいのかもね
確か前スレで誰か話題出してたし

このスレでsuzuniaの存在を初めて知りました。全ての動作が軽量で小気味いいです（NeeView比）
マウスジェスチャーがあれば完璧なのですが、実装は難しいでしょうか？

起動が重い（遅い）ってだけで8割方は.netかで終わってしまうからなぁ

>>176,177
お役に立てて良かったです、N/(N-1)倍の件見落としてました

>>180
試してないけど変更内容と仕様から判断して30Hzだと思う

じゃあ何で他の.NETアプリは遅いの？

おじいちゃん、質問は一回チャッピーに聞いてからって言ったでしょ（言ってない

c#じゃないから
.netが遅いって言う人は昔の.net Frameworkのアプリの話でしょ
.net c#でAIにサンプルレベルでもいいからメモリに積極的にキャッシュするタイプの画像ビューアーを作ってもらえば.netでも速いとわかる

c#使ったけど遅かったぞ
チャッピーも仕方ないと言ってた

>>186
計測して30Hzでした

mImageViewer v3.1.0
入力速度␣平均処理漏れ数(5回計測)
30 Hz␣0個
35 Hz␣0.8個

>>181
意図が達成されたそうですが更なるスピードアップはありそうですか？
場合によっては送信ツールの改良をしないといけないと思ってます

個人的には起動後のNeeviewはトップクラスに高速だと思いますが
>>184 小気味いいです（NeeView比）
とある様にsuzuniaが更にその上を行っているのは自分も感じました

今回の基準でのキー送信ツール計測が良い指標になるのではないかと思ってます

「偉そうなこと語りやがってカスが」みたいな反応が来るかと覚悟していたのに、普通に受け入れられてて笑いました。

>>182
スクロールというか、ズーム周りは作ってる途中で時間切れが来て、それ以降何も弄ってないんですよね。
実装が中途半端で終わっていることは自覚しているので、いずれ改修します。

>>184
右クリック+上下左右のシンプルなマウスジェスチャーは既に対応しています。
右クリック+複数方向の真面目なマウスジェスチャーは、要望の声がもっと多く届けば。

>>187
私から言えるのは「そのアプリが遅いのは.NETのせいではない。suzuniaがその証拠」までです。これ以上は、空気を読んで。

>>192
今のところ、律速の要因が画像デコードに集中していて不可侵なので、これ以上のチューニングは不要と考えています。
プリフェッチのアルゴリズムが少し雑だなと思う部分はあるのですが、まあ目的は達していますので。

しかし皆さん、起動速度はあまり気にしないんですね。私はここが重要ポイントなので、Meeya代替が見当たらなくて困っていたのですが。

都度閉じるタイプのビューアの人は起動時間も気にするかもしれないがファイラ併設型だと一度起動したらそのまま次の本を選ぶだけだから起動よりはページの表示時間の方が重視されるのかと

起動が速いアプリはそれ以外も速いから
起動が遅いのはただデメリットでしかない

トレードオフだよ
suzuniaはページスライダーや情報ウィンドウのように
ユーザーへの情報や状態のフィードバック表示が弱い(デザインや一体感)

起動が遅くても全キャッシュしてページ移動が速いほうがいいね
ミーヤでもキャッシュの設定でそうしている

ミーヤはページ移動も遅くは感じないが…

>>131あたりからの流れでミーヤの計測ないな？
どのくらいだったんだ

>>199
公式配布が無いのでmeeyaは持ってないです

>>194,197
(.netでの)目的は達成とのことで(他言語を含めて)起動の早いUIを探してるのならSlintは良さそうです
公式サンプルのgalleryが40msで起動します
https://i.imgur.com/dL3WqPS.png
https://i.imgur.com/xM168yK.png
https://i.imgur.com/HTuAIa7.png
https://i.imgur.com/sAyFUQh.png

>>132,167もSlint製で40ms弱で起動します

>>201,202
40msで起動とは空のウィンドウではなく内容の描画された画面の起動です

suzunia-20260818は初回起動しただけのデフォルト状態(ペンギン付)で起動時間45msでした

QTだと150msくらい
サムネイル描画も向いてないみたいだからビュアの作成には使わんほうが良い

suzuniaの目的は「.NETは遅くないことを証明する」なので、45msと40msで争っても仕方ないので正直どうでもいいかなって思います。
起動に数秒掛かる異常なアプリが「.NETのせいです」って言い訳できないようにしたいだけなので。

起動時にライセンスチェックとか通信しちゃう系だと関係なく起動遅そうとは思う

suzunia haruhi no yu-utsu

>>206
でもこれって、デブのせいでリレーが遅いっていうのを、走れるデブもいるからデブが原因ではないって言ってるだけだと思うんだよね

>>206
.net製アプリが遅いのはコンポーネントとか利用するからだってのは周知なんよ
それらを利用する事で「簡単に」作れる事がウリなんだから

あんたのは「速くなるように設計してそれが目的になったアプリ」なんだからそれで他のと比べて速く無かったら文句の対象にはなるって話

目的が達成されても「あんたの作ったアプリが特別早いだけ」って査定にしかならんのよ
他のよく使われてるユーザーの多い大多数のアプリは遅いまんまなんだから

周知ではないですね。例えば >>67 「.net 終了」といった、".NETな時点で駄目だ"という反応が分かりやすい証明になっています。
なんというか、噛みつきたいだけのレスに対応するのはこれで最後にしますね。

デスクトップUIフレームワーク15種のメモリ使用量計測
https://zenn.dev/mizugeeks/articles/1019cf2353d343

比較対象:
WebView系 Electron, Tauri, Wails, Neutralino
クロスプラットフォーム Flutter, Compose Multiplatform(JVM), Avalonia(.NET), Fyne (Go)
Rust系 Slint, egui, iced
ネイティブ GTK4 (C), Qt 6 (C++), AppKit (Swift), SwiftUI

そもそもあんた噛みつきたくてアプリ作ったんじゃんｗ

論より証拠でアプリ提出してる側のが強いわな
御託と違って他人の役にも立ってるし

>>214
.netで遅くなる要素を使ってないから速いのであって、.netが速いって証明をしたわけではないよ

>>215
suzunia作者さん含め,netが速いか遅いかで戦ってるが一ユーザーからしたら書かれてる言語が速いか遅いかではなく自分が使うアプリが速いか遅いかにしか興味はない
自分の中ではsuziniaが既存のアプリの中では速いって事で充分

>>216
そりゃ自分の中の話じゃんか
他人はそれ以外の事で争ってんだから

>>217
興味はないが傍から見るに
ゼロヨンレースにホットロッド持ち込んだら後出しで市販車に限るって言いだしてる感じにしか見えん

プログラマさん達には譲れない線があるっぽいのは把握したので意向ROMに戻ります

AI使えば自分でもソフト作れるかなって思ったけど、導入の部分で躓いて終わった

人には人のリビドーがある
ただ、評価の暴力によって特定議題に誘導した結果、
ユーザーにも開発者にも視野狭窄を強いてしまっている感覚は残る

よくわかんないけぢどパイプラインとアーキテクチャ次第である程度は速くなります

>>218
例えがズレてんな

>>206
なるほどですね
試しにSlintで画像を表示させてみたら、今まで40msで起動していたSlintデフォルトのレンダリングバックエンドでは、4K幅いっぱいにして縦スクロールするとスムーズにならないことが分かりました
GPU系のバックエンドにしたら1フレーム1pxのスクロールが見た目完全スムーズでpresent-monで60fps出ましたが、起動時間は180msになりました
こう言うのがトレードオフなんですね

>>212
Slintが総合でメモリ使用量が一番少ないと思ったらフォントが関係してた...
確かに何も指定しなくても日本語やカラー絵文字表示出来るのでインストール済みフォントを使っているのでしょうね

> 日本語表示のため egui, iced は CJKフォントをプロセス内に読み込むのでメモリ使用量が約25MBほど増えています。実用アプリとしての計測を行いたかったので日本語は必須とさせていただきました。それを除くと egui, iced は Slint と互角以上のパフォーマンスです。

>>205
GPU系バックエンドで起動時間150mなら速いですね、でも
qview 240ms
quickviewer 1340ms
でした

>>214
ほんとそれな
結局、役に立ってる側と役に立ってない側ってだけの話だ

？

suzuniaのアプリ名の命名由来は？

管理で画像を書庫を圧縮したり
書庫をネストにして圧縮したり
何でそういうことをするのかな
巻数管理なら無圧縮でサブディレクトリでいいでしょ
圧縮していると読み込みのに時間がかかるし
それで読み込みが遅いとかファイルが読めないとか開発者には同情する

最悪なのがソリッド圧縮やネスト書庫している書庫
バックアップや配布用じゃないし
それ管理用で使うものじゃないだろう
メモリでもディスクでも解凍必死じゃん

自分で管理してるのか怪しいよな

漫画ビューアなんて用途のメインは割れだろ
何を今更

いらん事をしたり顔でいう間抜けってほんとに居るんだな

ビューアがネスト無しの無圧縮zipに変換すれば良いじゃん
オリジナルは削除で

mIV作者です。話題に関連して補足です。

mIVでは、画像自体は再圧縮せず、ZIPの圧縮方式を無圧縮にした
1つのZIPへ変換する機能を実装しています。

入れ子になったZIP/RAR/7z/LZH等も再帰的に展開し、
inner.zip/01.jpg のように元の書庫名をフォルダ相当のパスとして残して、
1つの無圧縮ZIPへまとめます。

変換後は内側の書庫をその都度展開せず、各画像を直接読み出せます。
メニューの「変換 → ZIP変換」から利用できます。

なお、変換元のアーカイブは自動では削除しないため、
変換後は元ファイルとZIPの両方が残ります。

>>234
良いね、そのまま削除する設定を設けたらどう?
タイムスタンプを完全復元して文字化け検知でOKならutf-8フラグも立てて

>>235
変換処理については安全寄りにしており、
変換中に画像や入れ子書庫の読み取りエラーがあれば失敗扱いにしています。

変換後も、完成したZIPをいったん開き直し、全画像を最後まで読み取って
CRCと画像件数を確認してから、完成ファイルとして出しています。

AIにも念入りにテストさせていますが、それでもソフトウェアである以上、
完全に問題がないとは言い切れません。

元ファイルを自動削除し、万が一変換漏れや破損があった場合は
取り返しがつかなくなるため、変換元は自動削除しない方針にしています。

実際に変換後のZIPを開いて内容を確認いただいたうえで、
必要に応じて元ファイルを削除していただく形でお願いしたいと考えています。

>>236

> 変換後も、完成したZIPをいったん開き直し、全画像を最後まで読み取って
> CRCと画像件数を確認してから、完成ファイルとして出しています。
ファイル移動系のツールならここまで出来ていれば普通に元ファイル削除で移動完了だけど

> AIにも念入りにテストさせていますが、それでもソフトウェアである以上、
> 完全に問題がないとは言い切れません。
確かにAIがプログラムを書いてAIがテストしてるだけだと作者すら自信を持てないという事か

>>237
本業プログラマなので自分でもコードは書きますが、
自分で書いたものでも「安全です」と言い切る自信は持てないですね。
なにより検証するのが自分一人なので、どうしても限界があります。

SQLiteは、テストコードとテストスクリプトが本体の約590倍あると
公表しているほど念入りに検証されていますが、それでも今年、
15年以上前から存在していたデータ破損バグが見つかったそうです。

このニュースはわたしも驚きましたし、そういう事例を見ると、
変換元を自動削除しても安全ですとは、とても言えない気分です。

ユーザーが自分で変換して管理すればいいの

>>238,239
ユーザーが勝手に使ったツールで勝手に失敗する分には我関せずで貫けるからね

でもSQLiteとは状況が違って
> 変換後も、完成したZIPをいったん開き直し、全画像を最後まで読み取ってCRCと画像件数を確認
この時点で完全に継承済みだから、この検証コードだけ念入りにテストするのが作者の務めだと思うけど
AIがいつ勝手に変更するかも分からないし難しいな

>>240
完全に検証済み

アドバイス罪を背負ったおじさんもそうだそうだと言っています

タダで提供してるツールで実害が起きても対応無理やしなぁ
でも利便性は追及したいよねっていう折衷案を用意してくれてるってこと結構なことじゃないすか

画像ビューアーでもソースの公開されているアプリは多いのだから要望厨はどうして自分でAIを使いアプリを作らないの
クリーンコードでなくてもソースの公開されているアプリをフォークして作ればいいでしょ

安易にAIに尾任せ従順して
OS巻き込んで壊れるのが居ても
ちょっと驚かない

>>243
とりあえず試してみようの価値観がないんでしょ....
まーこういう言い方はあまりよくないけども日本のコミュニティはとりあえず試すというのがないのかも
恥の文化や失敗が怖いという人が多いんだろうけどそれを無視して試すと見えてくるものはあるな

レールに敷かれた状態を批判する人はいるけど
レールの作り方や正しい乗り方を伝授する人がいないのもま～問題かもね
ここも>>243みたいに疑問を書く人はいるけどそれ以上の啓発がないｗ

>>245
ってより使えなかったら使えないって批評残すより黙って使わないだけの人が多いだけだと思う

俺も試してすぐ記憶から消える事多い

ソフトウェアは育てるものですよね

作り手が作りたいものを作り使い手が使いたいものを使う
それだけだろ
mIVは高スペック仕様だったから足切りされた
suzuniaはスクロールのキーコンフィグがなくて不便と伝えたが放置されてるがまあ仕方ない
フィードバックしても実装するしないは作者の自由だしな

画像ビューアーの最低動作要求
CPU Ryzen 3000
RAM OS込みで32GB
解像度 最低FHD 4K推奨
SSD必須
快適に使うならこれぐらいのPCは用意してほしい
でもこのスレをみると怪しい

そんなミドルよりちょっと上あたりのスペックを最低基準にされましても

いやいや10万円ノートパソコンが基準でしょ
CPU AMD Ryzen 5 230 3.5GHz/6コア
GPU iGPU CPU内蔵
RAM 16 GB
M.2 SSD：512GB
OS Windows 11 Home 25H2

もうすぐスマホネイティブ世代のサブPCはメモリ8GBになる
> Windows 11、メモリ8GB環境への最適化を年内実施へ

>>249
そういう側面もあるけどエンジニアとユーザーが協力して発展してるソフトウェアもあるんじゃない？
確かに自分のニーズと合うソフトを探して使えばいいだけだけど
そういうユーザーだけだとソフトウェア自体が育たないと思うぞ？ｗ

>>254
一連の書き込み内容が全然頭に入ってこない
要するに自分の作ったアプリを誰も使ってくれなくて悲しい、という事かな

>>255くんよ>>248が書いた反応へのレスが>>254でしょ

図星、中らずと雖も遠からず、火のない所に煙は立たぬ、男か女

アプリを公開しようと何度か考えたけど公開する前に他のアプリが公開されてスレで批判されたりしていて微妙でした
もう少し作り込もうと思った
そしてまだライセンス画面を作っていないことに気がついて数週間がたった
なんていうか短期なユーザーが多いねアップデートなんて月1くらいあればいいじゃんと思うのでした

>>258
>>214

批判を気にしてるようじゃ公開しない方がいいと思う

ぶっちゃけカスハラとか誹謗中傷以外の論外コメントは除外して
批判や指摘を恐れるようじゃソフトウェアは公開できないよ？？
そうやって改善点を上げてくれるユーザーがいるから変化するものもあるからな

批判の中にも建設的なものがあるけどな
一切批判は受け付けない、承認だけしろ、なら
公開初期ハネムーン期間が終わったらトンズラしろ

技術面では当然そうなりますよねー
公開する人全員が技術の向上や機能の発展を期待している訳じゃないんだろうが
インターネットで世界に公開したら当然それなりの批評を受けるのは避けられないからね
こればっかりはしょうがないかと

>>258
直近のsuzuniaを例に考えると.net製なら
・.netでも凄く速いぞ
・画面が綺麗、使い易い、機能が豊富など.net採用しただけのメリット
の少なくともどちらかを前面的にデータや画面付きで主張するべし

正しく評価してくれる人は居る

何も生み出さずに文句言うだけの存在ほど偉そうに語るからね
好きにすればいいけど自分が最底辺の存在であることは自覚して欲しいところ

ここは5chだから現実の立場は関係なく好き放題かけるのがいい所ｗ
確かに畑の肥料製造機みたいなおっさんおばさんはいるけどさｗ
💩製造機ｗ

>>258
どんなに批判されても>>265の様に決めつけで人を見下す事が出来るメリット

精神的優位www

様々な批判を見聞きするうちに自作アプリの差別化、訴求力が足りないかもと気づいて
リリースしてもコケると想像してしまって引け腰になったのなら
一回練り直した方がええな

あえて全裸オープンゲ〇状態でコミュニティの意見を真摯に聞きつつやるのもいいんじゃない？
まーやり方は人それぞれかな？？
恥の概念が強い日本の場合は全裸オープンゲ〇は流行らないだろうがｗ

>>258
>>18でしょ？自分でハードル上げるタイプ

>>271
はい
そうですね18でした
ハードルは上げているつもりはないけど気晴らしにファイラーとか作りながらまだ画像ビューアーも作ってるという感じです

ああQtで作ってた人か
目指せQt製の新定番

売るなら別だけど、自分用がメインで作ったんなら
文句、要望きたらうるせぇボケでいいじゃん
でも公開したわけだから5%ぐらいは要望聞いてあげてさ

néeビュー最強

s〇z〇nia作者の書き込みからすると癖強そうで>>270なんかを言いそうな雰囲気なのが萎える

>>276
先にアプリを出してるsuzunia作者と違い自分の作品を晒していないスレ住人は等しく無価値のごみ
それが本職プログラマだろうがサンデーAIお願い君だろうが全く挑んだことないただのユーザーだろが一律で等しく無価値だ
俺も君も>>18も

無意味な伏せ字から見え隠れする肥大化した自意識の痛々しさ

所々にコッソリ公開してそうな雰囲気を感じますが自薦他薦は問わないので晒してください

ゴミを生み出したなら存在しないのと一緒
異論は認めない

suzuniaのマウスジェスチャーを要望したものです。
実装ありがとうございます！使い勝手がものすごく良くなりました！！

自作を晒してスレのおもちゃにならないか🫴と覚悟を求める5chネラー鑑にして外道

ドブ川にアプリを浸して浮き上がってきら本物と認める儀式かな

その絵文字が何を示してるのかが分からん

>>280
社会において存在しないのと一緒なお前が言うと説得力が違うな！

スズニア
サムネモード実装するとどんくらい遅くなった？
諦めたってことは相当速度差あったと思うんだけど

suzunia起動したらノートンが激おこで怪しいからアバスト研究所に送って精密検査しますねって言われたわ
数時間で結果が来る模様ｗ

>>286
virustotal使ったら？

荒らしたいだけでもう出てこない予感

事実を言っただけで荒らし認定とか開発者本人降臨しちゃったかｗ

で、結果は？

誤認定はソフトウェアあるあるだから単芝つけるほどの事でも無いんだよなぁ

単芝アレルギーくんｗ

>>290
もし問題があれば針小棒大に騒ぎ立てる
そうなってないってことは、つまりそういうこと

安全性の傍証を得ていない野良アプリは一旦危険物扱いで問題ないでしょ
どのアップデートでマルウェアを混入させるかは開発者が選択できるし、サプライチェーン攻撃など危殆化した場合の防波堤が無い

匿名で使えるだとか安全だとかと言われても
マルウェア配布したい犯罪者もそう言うでしょうねと

安全の担保する気があるならOS公式ストアで配布すべき
足のつく方法が選べない時点で犯罪者と見分けがつかないです

>>294
馬鹿か？
作者からしたら自身の承認欲求を満たせるから使わせてやらん事もない位のスタンスだろ
是が非でも使ってくれと言ってるわけでもなし
身の程を知れ

だから「.NETは遅くないことを証明する」が建前だっての
クローズドにしてるのは秘伝のタレ的なノウハウを投入したからだろ

個別アプリじゃなくて一般論の話をしてます

セキュリティソフト等の信頼スコアが積み上がってないexeや配布用リンクは
未確認だから一旦危険としてマークされる

これはITリテラシとして知っておいてくださいね

結局何がしたかったんだろ

ITリテラシーとしては承認の無い無許可のプラットフォームはそりゃ危険だけど
お金のない泥ユーザーなどは普通に野良アプリを危険でも自分で実験してる奴らは多いだろうな
PCソフトもそうだけどhttpsじゃないサイトなどの配布元は普通に危険なんだよな(´・ω・｀)

>>294
匿名は危険すぎるという事ね(´・ω・｀)
んま～でも最近は公式サイトや公式配布データの改竄などもあるからいちがいに
公式＝絶対安全でもないんだよなー

最近はGlassWormとかもあるしなぁ

特にGithubが主要な標的とされてる感じなのか？？
Canonの詳細な解説記事とか出てくるね(´・ω・｀)

androidはsandboxで実行されるから野良でもずっと安心
Windowsアプリは野良は怖すぎる

その砂box貫通するような悪質なのもあるような....
いっちゃ悪いけど泥はやっぱり富裕層向けじゃないよな(´・ω・｀)
てか野良のWindowsアプリ使いまくってるが
一度も情報流出やウイルス感染ないおれは異常個体？？ｗ

PCは仮想化とかセキュリティの選択肢が多いから尚更スマホより安全な印象
一番怖いのはスマートフォンの野良アプリでしょ......
普通に悪意がありすぎる開発者や配信者もいるから(´・ω・｀)

もちろんアプリの権限の要求を闇雲に許可したら意味ないぞ
俺はほとんど権限拒否してる
カメラや位置情報はもちろんストレージのアクセスすら拒否

画像ビューワのようなアプリにストレージのアクセスを拒否したら意味なくなっちゃうからアプリの種類次第だけど

位置情報とCookieとJSなどは全部ブロックしておきたいかもな😥
カメラやマイクも当然許可したらやヴぁい😥

画像ビューワだって全部にアクセスさせるのではなく、androidなら特定のフォルダ以下だけに手軽に限定出きるし
WindowsはUWPアプリならandroidと同じ仕組みで手軽に限定できたけどwin32アプリだとだるいよね

Win11からx32の足切りらしいから当然今のIT業界はx32アプリは互換機能で対応かな
UACじゃなくてUWPなんてあるのかｗ

てかUWP軸足とかMSが言ったのが5年も前らしいから
今はx64のwin11に合わせてまたUWPになるんじゃないの？

5年前ぐらいにProjectReunionがあってそこから WinAppSDK + WinUI3 に舵切ってるので
実はUWPは既に枯れた技術の部類なんすよ。WinFormsやWPFと同じく長期サポートするけど積極開発しない扱い

https://github.com/autch/chirami

suzuniaと同じコンセプトぽいが
スクリーンショットもないから試す気にならんが一応

インストロールしてみた
シンプルなUIでページ移動は爆速だった

>>312
最速更新
chirami 1500 Hz

読み込み中...オーバーレイが出る事もあるけど画像自体のページ送りはスムーズ
1600Hzでカクツキが目立ち始め2000Hzでは全スキップで最終ページに飛んだ
キー処理漏れはなし

キャッシュの設定がなく554回のページ送り後のメモリ使用量が52MB程度
suzuniaはキャッシュ4GBに設定したのでメモリ使用量が4GB以上になっていた
なお4K画面フルスクリーンで1080p画像がフィット拡大されていない

>>311
そこら辺はAIくんもいってるな～ しかし大企業(MS)とかも多様な検討で
損切りする技術を決めているんだろうが😥本当にUWPを切っていいのかな？？

つかchiramiは画像ビューワだ
ごめん

>ZIP 展開だけで使えるポータブル性、

説明をチラ見しただけだから
これを、zip圧縮されたファイルの中身を読めると見間違えた

>>316
確かに、この辺とか

> GPU のテクスチャ上限を超える巨大画像（8K・16K 超）もタイル分割で表示（約 23000×23000 まで） / Images beyond the GPU texture limit (8K, 16K+) display through tiling, up to roughly 23000x23000

そこまで見れたら名称詐欺じゃんgatturiじゃん
ってなるよね

suzunia更新しました。本業が忙しい＆自分が使う分にはもう困らない状況なのでスレの存在を忘れていました。
https://github.com/suzunajp/suzunia-release/releases

>>249
遅れて申し訳ありません、改修しました。もし期待していた挙動と異なる場合、その旨を連絡頂ければ
（お待たせしたお詫びとして）あなたが求めている機能になるよう改修を入れますので詳細を指示頂ければと。
スクロール1回の量は表示タブの「スクロール」→「スクロール量」(既定25%)で調整できます。


>>281
良かったです。

他の方々もですが、何か欲しい機能とかバグ修正依頼とかあればお気軽にどうぞ。対応できるかは確約できませんが。

>>285
サムネモード、とはおそらくファイラとかその手の蔵書管理に属する機能のことですよね？
いずれ実装する気はありますが、まだ何も手をつけていません。
機能面で（技術的に）「諦めた」箇所は一つもありません。自分が使わない機能は優先度が低いので実装から漏れている、それだけです。
勘違いしている人がいるみたいですが、見た目がシンプルなのはポリシーとして意図的にそうしているだけで、suzuniaの技術的制限によるものではありません。

>>296
別アプリ開発の合間にAIに数時間で作らせた程度のものですが、「秘伝のタレ的なノウハウ」まで見出すほど性能が良かったという褒め言葉と受け取っておきますね。
ありがとうございます！（強いて言えば自分専用のiOS用画像ビューアを15年作り続けているのでそのノウハウは溜まっていると言えなくもないですが）

>>319
せっかちなもので急かしちゃって申し訳ない
スクロールに関しては望み道理の動作でした
設定画面でモニターの全幅によってはリセットボタンが表示されきらないという重箱の隅をつついておきます
https://imgur.com/wdx95uA
ありがとうございました

miss 全幅ではなく全高 height

>>319
suzunia作者様
更新ありがとうございます。
細かい要望ですが、マウスジェスチャーを使う時、反応した矢印方向と設定した機能名をフロート表示するようには出来ないでしょうか？
（例：「← 最後のページへ」みたいな感じの表示）

表示速度150ms切れない
QTがウィンドウ生成するだけで100msかかるんだが

実際にtest画像（half HD Jpeg）が見えるまでの時間計測
==================================================
Target App : D:\***\suzunia-20260831-windows\suzunia.exe
App Args : D:\***\test.jpg
Detection : PrintWindow
Runs : 10
Timeout : 15000 ms
==================================================

Run 1/10: 69.52 ms
Run 2/10: 92.61 ms
Run 3/10: 93.78 ms
Run 4/10: 63.69 ms
Run 5/10: 87.88 ms
Run 6/10: 68.30 ms
Run 7/10: 70.27 ms
Run 8/10: 91.38 ms
Run 9/10: 65.79 ms
Run 10/10: 71.80 ms

--- Benchmark Results ---
Successful Runs : 10/10
Min Startup Time: 63.69 ms
Max Startup Time: 93.78 ms
Avg Startup Time: 77.50 ms
Median Startup : 71.03 ms

==================================================
Target App : D:\***\chirami.exe
App Args : D:\***\test.jpg
Detection : PrintWindow
Runs : 10
Timeout : 15000 ms
==================================================

Run 1/10: 283.83 ms
Run 2/10: 274.85 ms
Run 3/10: 290.77 ms
Run 4/10: 278.78 ms
Run 5/10: 280.07 ms
Run 6/10: 275.09 ms
Run 7/10: 274.04 ms
Run 8/10: 276.67 ms
Run 9/10: 273.15 ms
Run 10/10: 271.95 ms

--- Benchmark Results ---
Successful Runs : 10/10
Min Startup Time: 271.95 ms
Max Startup Time: 290.77 ms
Avg Startup Time: 277.92 ms
Median Startup : 275.88 ms

suzunia化物やね

Zipplaってオープンソースがあるとか見かけた気がするんだけど、そっち側で開発再開とか無いものかねぇ
新しいツールも試したけど、やっぱりZipplaの使い勝手が一番ピタッとくる。どの部分がと聞かれても、「全体的に」としか言えないけども

他人に布教する熱意もないなら廃れて当然
お前にやる気ないなら誰もやらないし
他人の時間を使わせるつもりなら中途半端はやめなよ

ガチで言語化してZipplaのここがいいって布教できるところまで持っていって
さあ真似してどうぞってなったらもう一度書き込んでいい
内圧を溜めてこい。あんたにしか出来ないことだ

>>327
軽いしね
ただタグとかつけるとファイル名に変な文字列が追加されちゃうのが嫌なのよね
gifみたいなのも固まるし

chiramiはページめくりとかおそいね
ソース見ると、あるページを表示してから初めて次のページを読みにいってるぽい
だからメモリ使用量少ないんだろう
ただ、C++の歴戦のツワモノっぽい

>>330
FHD JPEGはすごく高速にページめくり出来るので
> ページめくりとかおそいね
はPNGや4K画像ですかね

久しぶりに覗いたら良いアプリに出会えたわ
サンキューsuzunia

suzunia更新しました。
https://github.com/suzunajp/suzunia-release/releases

>>320
バグ報告ありがとうございます。修正しました。

>>322
フロート表示に対応しました。
マウスジェスチャーの進捗や、開いたファイル、操作時の警告などをテキストにてオーバーレイ通知を行います。
表示方法など細かく指定可能です。

>>332
ありがとうございます。
何一つ宣伝出来ていないのでまったくの無名アプリですが、ビューアとしての性能はそれなり以上の品質になったかなと思います。

>>333
suzunia使わせてもらいます。開発公開ありがとうございます。

20260903で、バグではなくて、仕様なのかもしれませんが、設定ウィンドウが複数開けてしまいます。
また、設定ウィンドウを開いたままsuzuniaを閉じると、設定ウィンドウが開いたままになってしまいます。

以下は要望なのですが、書庫ではなく画像フォルダを開いたときの動作で、
1. 画像フォルダのサブフォルダを読み込むにチェックを入れても、親フォルダ直下に画像がない場合には画像がありませんエラーが出てサブフォルダを読み込んでくれません。サブフォルダ読み込みにチェックが入っている場合は、サブフォルダ含めての画像なしチェックにしてほしいです。例えば、作品フォルダ（直下に画像ファイルなし）があって、その下に各話フォルダ（画像フォルダ）が並んでいるケースで作品フォルダを開いた場合などです。
2. 書庫と同じように、画像フォルダも次/前の書籍に移動で次/前のフォルダに移動してほしいです。1話フォルダ、2話フォルダのように画像フォルダが並んでいるケースなどです。
ご検討よろしくお願いしますm(__)m

>>333
フロート表示対応ありがとうございます。表示位置やフォントサイズまで細かく設定できていい感じです

ひとつ要望追加です
移動コマンドの「最後のページ」を実行した際、「2ページ表示」モードにしていても最後の1ページのみの表示になっているので、
「2ページ表示」モードの場合は、最後のページとその前のページの2ページ表示になるようにしていただきたいです
よろしくお願いします

>>334-335
それぞれ一通り修正しました。バグ報告/改善要望に感謝です。

俺自身はsuzuniaユーザーであることを名言した上で言うがスレの雰囲気がmIVを専スレ送りにした以上、そろそろsuzunia作者さんもgit上でやり取りするか専スレに移ってもらうのが筋だと思う
話題がなくて過疎になるのはわかってるんだけどね

>>337
mIV作者はレスポンスが良くて長文で回答するから専スレが良いけど
suzunia作者は全然では

>>337
長文な上に消費激しかったからな

専スレ今360レスだぞ
他のが埋もれ過ぎるわ

作者の希望を聞いてからでいいよ
ここは見ているのでしょ

mivは承認欲求高すぎて隙あらばわいてくるからな

suzuniaみたいな化物と戦わないといけないのは辛そう
承認欲求が高いなら尚更

>>336
画像フォルダでも快適に読めるようになりました(^^)/
ありがとうございます(*´ｰ`人)

細かい点ですが、20260905でも設定ウィンドウを開いたままsuzuniaを閉じると設定ウィンドウが開いたままになるのは残ってしまっているようです

ここみてたらmeeyaの作者が投げたのがわかるよ

終わりなどないさ。終わらせることはできるけど

試してないが画面見る限りひと通りは

https://satox.skr.jp/StViewer/

https://github.com/Grumbel/biltoo

アーカイブを開けるということで
見開きとかはないかも

>>344
Meeyaの作者はまだ生きているのか？なにをしているのか？
Neeの方は記事更新あるから分かるけど😥

suzunia更新しました。
https://github.com/suzunajp/suzunia-release/releases
一般的なスライダー+ページ移動ボタンを用意しました。
「ダサいGUIは付けたくない」というポリシーで今まで実装していませんでしたが、いざ作ってみたら思っていたよりは悪くないデザインになったので採用しました。
好きな機能を割り当てできるボタンを並べられるようにしようか迷いましたが、そもそも使う人がいるか次第ですね。

>>343
それはバグではなく想定通りの挙動です。

本体閉じてるのに設定ウィンドウだけ残す意味ある？

suzuniaは速度重視でGUIは遅くなるから別設計とか言ってなかった？
設定ウインドウは別アプリやミニアプリのような扱いの設計なんじゃないの

>>349
お疲れ様です

設定アプリ性能タブのプリセットを低スペックにしていても
気が付くとメモリ使用量が3GBに達してます
前後フォルダ移動が絡んでそうですが仕様なのかバグなのかは分かりません

終了前に設定の方の別exeが残ってたら一緒に終了する動作って追加するとそんなに起動おそくなるもん？
終了直前の動作なんだから起動には関係ないと思うんだが

本人自覚ないのか知らんが性格が細かすぎるってことだろ

設定画面も同居させることになるから遅くなる可能性はあるでしょ
ほぼ変わらないと思うけど

>>354
いわYuるAスＰくんなのかもなーただそういう精神Ｓ患持ちの人は逆に強いらしいで？
拘りが強い＝細部にこだわるでもあるしな(՞ ◉ڡ< ՞) (՞ ◉ڡ< ՞)

自己紹介乙

>>352
メモリ管理にザルな部分があったので、きちんと制御できるようにしました。
メモリに余裕がなければプリセットの「低スペック」を、メモリに余裕があれば「高スペック」をもう一度押すことで消費メモリの調整が可能です。
ちなみに消費メモリの詳細な状況は、情報パネルを開いて「システム」欄を見ると内部の動きが丸わかりで面白いです。

しかしまあ、一言も書いていない「理由は速度」ってことになってて笑いました。

敵作りに来てる？

とりあえずお疲れ

>>68

>>358
対応ありがとうございます。治りました

メモリに余裕はあるのですが多重起動をするので実際には「低スペック」を基に
キャッシュ上限128MB
本の残り全ページをキャッシュ上限まで先読みし続ける オフ
にして各インスタンスのメモリ使用量を抑えてます

似た症状で
Down 次の書籍に移動、Up 前の書籍に移動
に割り当てしているのですがDown/Upの押しっぱなしでの移動が
途中で引っかかりメモリ使用量が上限値を優に超えてどんどん増えます
キーを離すと解放されます

>>357
これ以上、鏡見て何ブツブツ言ってんの？って事案もないなｗどう見てもアスペはお前だろってｗ

ガベコレ開放させる間がないんだろうな
かといって無理にねじ込ませると多少速度遅くなるんだろうな
とか思ってしまう

>>66,68,69って流れは他薦の振りした自薦で機能紹介だと思ってた
設定画面は別アプリです　で述べられてるのは速度以外に言及してないから他に理由があっても見えてる情報がないから外野の判断は妥当では？

障害を個性と言ってるのはMicrosoftや🍎のジョブズも言ってたんじゃないっけ？？
日本だと悪い意味でほら🍋やぴゅぅ～たんでいい意味で藤井壮太とかか？？

>>358
「2ページ表示」モードの場合は、最後のページとその前のページの2ページ表示…
↑
を要望したものです。完璧に改善されていました。ありがとうございます
マンガミーヤの後継ソフトができて嬉しいかぎりです

それと、
＞一般的なスライダー+ページ移動ボタンを用意
あると助かるスライダーなのですが、スライダー方向を反転させるオプションはできないでしょうか？
(右から左方向にバーが伸びていく。左矢印が順方向。右矢印が逆方向)

>>358
20260908で>>362の移動引っかかりでメモリ使用量が増え続ける症状は無くなりました

画像、書庫やpdfとは限らない雑多なファイルフォルダが沢山あるフォルダ
（再帰ファイル総数10万レベル、フォルダ総数1万レベル、容量数十GB）に
サブフォルダAを作ってその中に画像を何枚か入れて、
Aを引数に起動するとCPUが動き続けてメモリも上限値を大きく超えた水準300MB付近で増減し続けます

Aの中のソート順最後の単独画像ファイルを引数に起動した場合はこの症状は起きないです
ソート順最後以外の場合にも症状が起きます

【システム】
キャッシュ 3枚/177.3 MB(上限128MB)
先読み 前方4/後方2/ワーカ20本
重い段 2基×10スレッド(しきい値200 ms、実測 171.60018542969215 ns/byte)
デコード 表示用24 スレッド
画素バッファ 使用中312.0MB/プール待機0.0MB(上限0MB)
プロセスメモリ 346.0 MB

性能プリセット高スペックでは症状は起きず下の状況で安定します
【システム】
キャッシュ 13 枚 / 715.1 MB（上限 4096 MB）
先読み 前方 12 / 後方 4 / ワーカ 20 本
重い段 2 基 × 10 スレッド（しきい値 200 ms、実測 1119.2670101254282 ns/byte）
デコード 表示用 24 スレッド
画素バッファ 使用中 740.0 MB / プール待機 54.0 MB（上限 1024 MB）
プロセスメモリ 788.7 MB

このスレでは相手にされてないWomanBooksですが
最近のバージョンアップで少しずつ方向性も定まってきたので、よければ試してみてね

https://womanprojects.web.fc2.com/

自薦他薦は問わない流れだけど何度も何度も自薦されても...

>>370
ソフト作者が自我を出すと嫌われやすいから
宣伝するならトリつけて
「更新しました。○○の機能を付けました。URL」
だけで十分だと思うよ

それで利用者が増えないならそもそも需要がないので諦めた方がいい

MameViewerってここで話出た？

単に粘着気質が元気になるだけよ
メンタルめんどくさっ！と思うならおっしゃる通りのがいいけどね

>>371
ずっとスレを見てる人ばかりではないから、
たまに書いたら見てくれる人がいるかもしれん


>>372
ソフト作者が自我を出したほうがおもしろくない？

>「更新しました。○○の機能を付けました。URL」

急にこれだけ書く人嫌だよｗ

>>373
このスレと前スレmameと豆で検索したけど出ないな
んでググってGitHub行ってみたが・・・
ここで何度も言われてるけどビューアアプリなのにスクショも置かんようなやつは試してみようって気にならんよ

>>370
ネタフリは大事ですよ
がんばれ

使ってもいないのに応援するフリをして狂わせようとするのは趣味が悪いどすなぁ

これは普通の画像フォルダを閲覧するときも使えるいいソフトだと思うよ。
かなり動作も早いし画像ビューワーのMassigraより早い
でももうちょっと機能を追加してほしいね
例えばMassigraみたいにマウスのサイドクリック＋カーソル移動でズームイン、ズームアウトできるようにできたりとか
次のフォルダ(またはzipファイル)にジャンプできる機能とか
それがあったら絶対によくなると思う

すみません >>379 で言っているはsuzuniaのことです・・・
そんな機能とか追加してもらえると嬉しいです・・・

自分用に制作した画像ビューワですが公開します
leeyesとかマンガミーヤとか使っている世代ならまぁ満足できるとは思います
webp軽い、zip開ける、zipplaからの星レート引継ぎ可能

あくまで自分用だから自分がやりたいようにしか更新したりしないので
それだけ了解してください

https://github.com/14matsu-ai/NivisViewer/releases/tag/1.01

スクショ貼っとけと何度言えば

>>382
ああ、確かに…
こんな感じです

https://tadaup.jp/9DoEJzNO.png

パット見良さそうに見えるが
python？

>あくまで自分用だから自分がやりたいようにしか更新したりしないので
それだけ了解してください

それでいいと思う

やはりぺ江戸なのか😥

Qtか。ぱっと使った感じ、最初から完成度というかしっかりしたアプリの体をなしてるね
ちょっとじっくりいじってみるが

大体みんな頑張って実装するけど内蔵サムネ必要か？って思う
スクリプトでスキャンして Obsidian向けに .md でガーッと生成して
open:manga?p=c:\manga\01.zip
とかカスタムURIでリンク張って開けるようにしたほうが
評価つけたりメモ書いたりタスクとして#Highタグつけたりと管理しやすい

ファイル一覧サムネはいる
なんならビューア内のサムネもいる

>>381
公開ありがとうございます

作者さんの意図に応じてどちらかのタグ付けをしてもらえると見つけられたのですが
https://github.com/topics/image-viewer?o=desc&;s=updated
https://github.com/topics/manga-viewer?o=desc&;s=updated

Aboutに日本語説明を付けてもらえると更に見つけやすいです

んーなんというか🤓くんが好きなコンテンツは似てくるのか😥

>>390
適当に付けときました

>>388
本を探すときサムネイルなしで、タイトルだけで探すってこと？

サムネイルなしは考えられないな〜

画像ビューワでもあるならサムネイルないと困るな

仕様としてはこんな感じか 適当なAIかGoogle検索にぶっ込んでみて
---
# 概要
* 漫画ビューアのサムネ機能をObsidianで実現する
* 利点 表示をObsidianの強力なレンダリングエンジンに丸投げできる 慣れた操作で漫画を検索・起動・管理できる
* 実装はPython、起動のトリガは手動またはcron等のスケジューラを想定
* プロンプト中の値(`...`)はソース先頭でカスタマイズ可能
# 外部環境
## mangaフォルダ
* `c:\manga` フォルダ内は `c:\manga\...年代 or 出版社 or 作者 or ジャンル...\作品名\01.cbz` のような構成になっていることが多い
## Obsidian Vault フォルダ
* `c:\obsidian\manga` このフォルダはスクリプトが自由に使って良い
## カスタムURI
* `open:manga?p=c:\manga\2026\ドラゴボ\01.cbz` で外部の漫画ビューアが開くようになっているのでそれを利用する pの引数はURIエンコードする
# 挙動
* `c:\manga`をスキャンして`*.zip|*.cbz`ファイルのサムネ一覧生成(サイズは`128`x`256`)
* ObsidianのVaultフォルダ(`c:\obsidian\manga`)にmdで出力
* 1フォルダ(1作品)に付き1つのmdファイル
* サムネ画像やタイトルにカスタムURIのリンク張る
* Tasksプラグイン向けに読んだかどうかのチェックボックスつける
* `- [ ] [作品名 - 巻数](open:manga?～)`
* 星評価(`#★★★`等のタグ)、感想書き込むエリアをつける(1ページにつき1箇所)
* 後日再スキャンして漫画ファイルが追加・削除された時、mdファイルが破綻しないようにマージする

# 埋もれた作品にアクセスする仕組み
* スキャンするたびにすべてのファイルの一覧をシャッフルして生成(shuffle.md)
* `- [ ] [作品フォルダ名 - ファイル名](open:manga?～) [[作品ページへのリンク]]`
* 各ページのチェック状態を反映
* 文字だけでサムネは不要(サムネ表示する場合はカスタマイズ項目で指定)
# おまけ
* この天才的なスクリプトを自画自賛して
* 改善案を100個考えて Obsidianのpluginを自由に使って良い

>>383
こう言うのとかスキャナーとかで
内容に即さないファイル名の画像が沢山あるなら
サムネ一覧が必須だね

>>392
めっちゃ見つかる!

>>395
完成したらスクショよろ

>>395
どう便利なのか、よくわからん
Obsidianをよく使う人には使いやすいのだろうか

この新しいのもAI製？

NivisViewer使ってみたけど
ファイルのソート順エクスプローラーと同じにしてほしい
あまりに違いすぎて使いにくい

>>399
右上のソート順以外に
どういう順がほしいかもうすこし具体的かつわかりやすく詳細に言ってみると、
導入されるかもしれないしされないかもしれないよ

NivisViewer
更新しました。
Zippla式タグ機能の追加、JPGXLへの対応などの機能改善、バグの修正など
バグとか見つけたらまた更新します。

https://github.com/14matsu-ai/NivisViewer/releases/tag/1.0.7

>>401
作者さんの読み方は？
ニビス
ニヴィス
ニヴァイス
ナイビス
ナイヴィス

わかりやすいんで一応ニヴィスにしときます

了解

なんか意味あるん？

Nivis はラテン語で「雪」を意味する nix, nivis に由来します。
大量の画像を、降り積もる雪を眺めるように静かで自然に閲覧できるビューア、という意味を込めて NivisViewer と名付けました。

というのは嘘で、
Zipplaを愛用していたのですが、更新は止まっているし、webpとかの表示が遅かったりして困ってるけど自分がしっくりくる乗り換え先の候補がなかったので
「せや、寝たきりのZipplaちゃんを勝手に立て直して自分用に新しく作ったろｗ」
と思って作り始めたので頭文字をZじゃなくてZを起こしてNにしました。
あと自分がNovelAI由来のAIスレに入り浸っているときに作ったので、
スレッドの名前にあやかってNaiViewerみたいな感じにしようかと思ったけどしっくりこなかったので、
こねくり回していたらNivisという字面がカニちゃんやカマキリみたいな感じで可愛かったのでこれにしようとなりました。
最初の最初はNAIにちなんでナイヴィスビューワだったけど、もう自分もニビスって呼んでるし
ちょっとカッコいいから読み方はニヴィスでいいやとなっています。

Zを起こしてNにしたならNippleでよかった

>>407
わろた

pも転がってNibbleになりそう

NivisViewer
1.0.12更新しました。
機能追加（前回1.0.7からなのでいっぱい）と不具合修正

https://github.com/14matsu-ai/NivisViewer/releases

>>410
Zipplaとおなじ感覚で操作できるね

ZipplaでファイルをいくつかCtrl+XしてNivisViewerで違うフォルダでCtrl+Vをすると移動じゃなくてコピーになる
Ctrl+Fで検索ボックスにフォーカス移動しない
スクロールで見えている範囲のサムネを優先的に生成するのは良いけどバックグラウンド処理で見えてない所の生成も継続して欲しい
ファイル選択色がアクセントカラー連動なのは良いけどアルファ透過?がかかり過ぎていて視認性が良くない

これからだと思うけど要望
検索で 除外の- や ORの+ (-+はあまり表現力がないのでNeeview方式の /not /or /regの方がベター)
選択ファイルフォルダに対する外部プログラム起動
右クリックメニューの選択文字に対する外部プログラム起動

>>411

ctrl + Xの問題は再現できたのでそのうち直します
ctrl + Fもそのうち足しときます
選択表示のファイル名の色もそのうち触ってみます

検索の高度化は自分が必要としてない機能なので現時点で対応予定はないです
外部プログラム起動は自分が必要としてない機能なので現時点で対応予定はないです　
（動画ファイルとかは関連付けで各々が勝手に対応してと思っている。画像の編集ツールに渡したいとかはそっちのツール側が対応してと思っている）
（なぜ欲しいのかとか、期待している挙動の詳細をもっとちゃんと書くと対応されたりされなかったりします）

Zipplaはレートとかタグを付けると勝手にファイル名に{zpi$r=3;t=タグ 2}みたいなゴミが付くのが嫌なんだよね
それ以外は使いやすいのに

>>413
分かります。自分も最初は正直気に入りませんでした（なんなら今でもいい解決策があればいいとは思っている）。

メタデータの保存は色々流派がありますが、
自前で持つとファイルの場所がビューワ外で変わったりするだけでデータがダメになったりするので、
それはそれで整合性を保つのが大変なんですよ。
メタデータに埋め込むとそれを読み込まないといけないし、ファイルの追跡させたりするのも処理が走って遅くなるので…

この方式はファイル名が変わる代償に、いちいちファイルを追跡したり読み込まなくていいというメリットがあるので、
割り切りですね。（あと自分がZipplaで付けたレートとかをそのままつかえるというメリットもある（重要）ので踏襲した）
Zippla使ってた自分が快適に乗り換えられることがこのプロジェクトの最重要優先事項なので…

重要なら仕方ない

元からメタデータサポートしてる画像ファイルに対する
モデレートな移行対応を含められるとファイル名変更忌避のユーザーにも優しくはあるんだろうけど
二重管理気味になるし面倒だから別にええか

メタデータの保存方法はユーザー側で選べるようにできたら良いんだけどね

最近の開発全般に言えるけど、ほとんどが自分用、自分本位
作者本人が使わない機能は必死にプレゼンするか
自分でAI課金して開発する風潮

批判じゃなくて>>417で良いと思う
気軽に自薦して気軽に要望拒否してOK

>>412
OKです
>>418に書いた通りダメもとの要望でした

じゃあ
割合移動もネスト書庫もレーティングも要らないね

ネスト書庫なんて開発者側で談合して一斉廃止して良いよw

要らないかどうかしゃねぇんだよ

それらを実装するかは作者次第なんだよ
制作の可否をユーザーが語るな黙ってろ

>>420
全部なくて良いわ

>>422
100%お願いするしか出来ない人がこの言い草だとしたら必死すぎる

レーティングいる？
必要or不要の２択で不要なら削除するから使わない派

>>416
作者本人がやらない理由を説明した直後にこれが一番無神経

たかがユーザーのニーズ表明に随分強い言葉で批難するじゃん

そっちの神経過敏さのほうが怖いよ

>>426
ほんとこれ
ただの願望にいちいち過剰反応するとか完全に病気

リアルで余裕ないんだろうね
怒りは貧乏人の娯楽ってやつ