[過去ﾛｸﾞ] Susie＆Susie Plug-in総合 Part2 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
581(1): 579 2015/10/11(日)15:12 ID:pdBTueQ80(1) AAS
>>580
感謝。
ところで画像フォーマット総合スレみたいなの無いのかな？
どこに書き込んでいいか分からなったからここに書き込んだけど。
582: 2015/10/15(木)05:54 ID:2HpKuFTS0(1) AAS
>>581
画像フォーマットと言う線引きが難しい。
○１枚絵のみ・・アニメーションＧＩＦやＭＮＧが除外。
○パラパラアニメを含む・・音声無しの動画全てが該当。
○一般的に認知されている形式・・ＦＬＩＦはマイナー。
○マイナーを含む・・拡張子が重複するものが多数有る。
583(1): 2015/11/02(月)22:37 ID:/2tDN91M0(1) AAS
今時のPCで一番高速に動作するJPG/PNGのsusieプラグインってどれだろう
584: 2015/11/02(月)23:04 ID:T2uX+VDU0(1) AAS
>>583
WIC Susie Plug-inかも
585: 2015/11/02(月)23:37 ID:o0tt4VsM0(1) AAS
spibench使って自分で検証したらいいさ
586: 2015/11/18(水)06:22 ID:Qj5rIYzd0(1) AAS
libpngにバッファーオーバーフローの脆弱性
CVE - CVE-2015-8126
外部ﾘﾝｸ[cgi]:cve.mitre.org
587: 2015/11/18(水)11:11 ID:c/J0wg9r0(1) AAS
上げ荒しウザ
588: 2015/11/18(水)15:06 ID:C1ygiBmI0(1) AAS
libpngの脆弱性はソフトウェア工房αのifpng/ifpnglを使ってなきゃ関係ない
589: 2015/11/25(水)17:32 ID:cAP4IceZ0(1) AAS
libpngとzlibをifpngの要求するバージョンにしてdifもしたけどvs2015でビルドするとifpngのとこでコケる
590: 2015/11/25(水)18:04 ID:twHAiXa50(1) AAS
ifpngとかやめてwic使ったやつにしたらいいんじゃね？
591: 2015/11/25(水)18:09 ID:+YhpaM430(1) AAS
spimngx以外の.net用ラッパーって無いんだっけ？
592(1): 2015/12/08(火)03:03 ID:0zBNXzWt0(1/2) AAS
ifzim.spi
ZIM to DIB filter ver 0.7
誰かこれください
593: 2015/12/08(火)03:25 ID:4QVpiwv60(1) AAS
>>592
これ？
外部ﾘﾝｸ[cgi]:wayback.archive.org
594: 2015/12/08(火)22:12 ID:0zBNXzWt0(2/2) AAS
それ！ありがっとおおお
webarchiveにあるとは思わなかったわー
595: 2015/12/12(土)03:53 ID:rI8rkiA00(1) AAS
なにそのwebarchiveの存在は知ってましたよ的なプライド
596: 2015/12/12(土)17:13 ID:QTb9AHNF0(1) AAS
ww
597(3): 2016/02/03(水)09:49 ID:qlUHJP/E0(1) AAS
質問です。
比較的巨大なサイズ(数百MB程度)の辞書データを使って画像をデコードするようなSusieプラグインを作りたいと考えてます。
これは現実的に可能でしょうか？
598(1): 2016/02/03(水)14:16 ID:+f2UTAcs0(1) AAS
>>597
その辞書データをプラグインに内包するなら、当然プラグインもそれ相応のサイズになって、
使用するときはそれのほぼすべてがメモリ上に読み込まれることになります。
内包まではしなくても、外部ファイルなどからメモリへ全部ロードしようとしても、
32bit DLL で使えるメモリ空間は理論上でも最大約2GB、
連続したアドレスの1つのメモリブロックとして割り当てできるのはもっと小さいです。
メモリ空間には他のDLLなども存在しますから。
全部じゃなく必要な部分だけをその都度読み込むということができるのなら可能かと
599: 597 2016/02/03(水)15:45 ID:jG6io03g0(1) AAS
>>598
ありがとうございます。
大変参考になります。
もし心当たりがあれば答えていただけると嬉しいのですが、どのくらいのサイズまでなら
メモリの連続領域を確保できるでしょうか？
あるいは、複数の領域に分散しても構わないというのでば、例えば20MB×10=200MB
ということも可能でしょうか？
ヒープ領域が使える場合にはわりとメモリには余裕があった気がしますが…
C/C++は最近触っていなく、DLLに関しても無知なので的はずれな事/質問を言ってたら申し訳ありません。
もう一つ質問として、複数の画像を解凍する際に、DLLは一回ロードされたら、そのままメモリ上に保持されるのでしょうか？
省4
600(1): 2016/02/03(水)17:23 ID:eVcLgFgt0(1) AAS
連続で確保できるメモリ量は環境依存なので保証できない
dllのメモリ空間は呼び出し側ソフトもそれが使ってるdllもすべて含めてということも忘れずに
XPなんかはIMEやテーマ用のdllがベースアドレス指定されてて変な位置にロードされるせいでwin2000よりも連続で確保できる量が少ないし、それでもだいたい600MB位は行けたと思ったけど
連続で展開中にdll開放するソフトはまずないだろうけど保証はない
プログラム的には呼び出し側がFreeLibraryしなければdllはロードされたまま
データをキャッシュする場合等には
プラグインAPIをコールされる順番もSusieと同じ順番を前提にしないように
上下前次1-新書関写板覧索設栞歴
あと 402 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.011s