漫画ビューア総合スレ Part2

漫画ビューア総合スレです

前スレ
漫画ビューア総合スレ (Part1)
https://egg.5ch.io/test/read.cgi/software/1752914772/

話題多め
画像ビューアー NeeView Part7　【ﾜｯﾁｮｲあり】
https://egg.5ch.io/test/read.cgi/software/1781159107/
https://github.com/neelabo/NeeView/

漫画用画像ビューア マンガミーヤ MangaMeeya 24
https://egg.5ch.io/test/read.cgi/software/1742548602/

【画像/漫画/動画ビューア】mImageViewer 1【mIV】
https://egg.5ch.io/test/read.cgi/software/1782419551/
https://www.mikage.to/mimageviewer/

前スレリンクから
https://github.com/julyx10/lap/
https://github.com/SoraKumo001/quick-image-viewer/
https://github.com/kirinonakar/Uviewer
https://github.com/ggand0/viewskater
https://github.com/p-almighty/Piewer
https://github.com/yasuflatland-lf/gashuu
https://github.com/nalltama/RAIV
https://womanprojects.web.fc2.com/

>>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年以上前から存在していたデータ破損バグが見つかったそうです。

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