ソフトウェア工房α・掲示板 ログ



記事リスト ( )内の数字はレス数
jpeg62.dllについて(2) | EXIFの画像方向情報で自動的に回転できませんか?(2) | SIMD 版 JPEG libraryの速度(2) | x86 SIMD extension V.2.00 (AMD64) テスト(3) | nkf ですが(1) | SIMD 版 JPEG library 使用ソフト調査(01/29)(18) | 自家掲示板 運用開始(6) | IFJPEGX.SPI で不可解なブロックノイズ発生(4) |



■記事リスト / ▼下のスレッド
■38 / 親記事)  jpeg62.dllについて
□投稿者/ kimu -(2007/03/18(Sun) 18:53:43)
jpeg6bx102_win32dll.zipに含まれる方の「cjpeg.exe」などのソースは公開されていますか?

jpegsrc-6b-x86simd-1.02.zipに含まれるcjpeg.exeのプロジェクトにjpeg62.libとjpeg62.dllを設定して再コンパイルして出来た「cjpeg.exe」がjpeg_write_scanlinesもしくはjpeg_finish_compressでアクセス違反を起こしてしまいます。

以上のことから、質問するに至りました。
jpeg62.dllで代用できるものだと考えてること自体間違っているのでしょうか?

よろしくお願いします。

▽[全レス2件(ResNo.1-2 表示)]
■39 / ResNo.1)  Re[1]: jpeg62.dllについて
□投稿者/ みやさか -(2007/03/18(Sun) 19:42:39)
No38に返信(kimuさんの記事)
> jpeg6bx102_win32dll.zipに含まれる方の「cjpeg.exe」などのソースは公開されていますか?

公開されています。jpegsrc-6b-x86simd-1.02.zip に含まれる altui/cjpeg.c そのものです。

> jpegsrc-6b-x86simd-1.02.zipに含まれるcjpeg.exeのプロジェクトにjpeg62.libと
> jpeg62.dllを設定して再コンパイルして出来た「cjpeg.exe」がjpeg_write_scanlines
> もしくはjpeg_finish_compressでアクセス違反を起こしてしまいます。

どの種類のコンパイラを使っているのでしょう?。jpeg6bx102_win32dll.zip に含まれる
コンパイル済みの jpeg62.dll は、Visual C++ 6.0 でコンパイルされたものなので、
Visual C++ .NET などの、バージョンの違う Visual C++ では利用できません。
jpeg62.dll はCランタイムライブラリとして msvcrt.dll を使っていますが、
Visual C++ .NET 2003 などでは、それとは違うCランタイムライブラリを使用するためです。

Visual C++ 6.0 を使っているなら、cjpeg.dsp のプロジェクトの設定で、使用する
ランタイムライブラリが 「マルチスレッドDLL」(msvcrt.dllを使う) になっているか
確認してください。付属の cjpeg.dsp は、「シングルスレッド」になっているはずです。

> jpeg62.dllで代用できるものだと考えてること自体間違っているのでしょうか?

間違ってはいませんが、入れ替えるだけでOKというほど単純ではありません。
簡単に説明すると、.exe ファイルと .dll ファイルとの間でファイルポインタ
(FILE *) を受け渡ししている場合は、.exe / .dll の両方ともが同じDLL版の
ランタイムライブラリを使う必要があるのです。この辺は、jpeg62.dll の場合に
限らない Visual C++ のノウハウですね。

*(2007/03/18(Sun) 20:03:20 編集(投稿者))
■40 / ResNo.2)  Re[2]: jpeg62.dllについて
□投稿者/ kimu -(2007/03/18(Sun) 20:54:01)
No39に返信(みやさかさんの記事)

> 「マルチスレッドDLL」(msvcrt.dllを使う) になっているか確認してください
マルチスレッドDLLに変更することで正しくコンパイルできました。お騒がせしました。

どの種のランタイムライブラリでコンパイルされているか知る術を知らないところが問題だったようです。申し訳ありません。精進いたします。

あと今更ですが、環境を書いておきます。
windows xp sp2
vc++ 6.0 sp6

■記事リスト / ●親記事



■記事リスト / ▼下のスレッド / ▲上のスレッド
■32 / 親記事)  EXIFの画像方向情報で自動的に回転できませんか?
□投稿者/ ikumi -(2007/02/21(Wed) 00:34:24)
はじめまして。
SIMD Enhanced JPEG Plug-inを使わせていただいています。

デジカメ写真をこのプラグインを使用して見ているのですが、
カメラを縦にして撮った写真が横向きに表示されてしまいます。
Susieやだいなファイラーには、マニュアル操作で回転させる機能がありますが、
プラグイン側でEXIFの画像方向情報を見て自動的に画像を回転させると
非常に便利だと思います。

もし可能でしたら自動回転に対応していただけないでしょうか。

# 自分も仕事上はプログラマなのですが
# Windowsでのプログラムはまるっきり素人なので…

よろしくお願いします。

▽[全レス2件(ResNo.1-2 表示)]
■33 / ResNo.1)  Re[1]: EXIFの画像方向情報で自動的に回転できませんか?
□投稿者/ みやさか -(2007/02/21(Wed) 02:46:00)
No32に返信(ikumiさんの記事)
> Susieやだいなファイラーには、マニュアル操作で回転させる機能がありますが、
> プラグイン側でEXIFの画像方向情報を見て自動的に画像を回転させると
> 非常に便利だと思います。
> もし可能でしたら自動回転に対応していただけないでしょうか。

技術的にはもちろん可能なのですが、Susie プラグインの本来の役割は、
圧縮された画像を忠実に展開してそれをそのまま出力することですから、
そういう役割を期待されているプラグインに、本来の役割ではない
このような(暗黙で機能する)画像加工機能を実装すると、場合によっては
余計な混乱が起きかねないようにも思うんです。
本来ならば、こういった機能はプラグインの方ではなく、プラグインを
利用するソフトの方に実装すべきことだと思っています。

とはいうものの、Susie プラグインには画像の方向をアプリ側に通知する
方法はありませんし、Susie そのものも開発が止まっていますからねぇ。
この辺をどう妥協するかが難しいところなのですが、
Susie32 PNG Plug-in の方には、ガンマ補正や背景色合成などの加工機能が
オプションとして実装してあるので、次回のバージョンアップ時には
画像回転機能もオプションとして実装する方向で検討してみます。
ただ、1週間や1ヶ月でできるわけではないので、催促しないでくださいね(^^;。
最近はなかなか自作ソフトをいじる時間がとれないものでして...

■34 / ResNo.2)  Re[2]: EXIFの画像方向情報で自動的に回転できませんか?
□投稿者/ ikumi -(2007/02/22(Thu) 00:46:47)
No33に返信(みやさかさんの記事)
> 技術的にはもちろん可能なのですが、Susie プラグインの本来の役割は、
> 圧縮された画像を忠実に展開してそれをそのまま出力することですから、
> そういう役割を期待されているプラグインに、本来の役割ではない
> このような(暗黙で機能する)画像加工機能を実装すると、場合によっては
> 余計な混乱が起きかねないようにも思うんです。
> 本来ならば、こういった機能はプラグインの方ではなく、プラグインを
> 利用するソフトの方に実装すべきことだと思っています。
>
> とはいうものの、Susie プラグインには画像の方向をアプリ側に通知する
> 方法はありませんし、Susie そのものも開発が止まっていますからねぇ。

そうなんですよね。
本来ならばプラグインを使用するアプリケーション側で実装する機能だとは思いますが、
Susieの(古い)プラグイン仕様では難しいと思いましたので、
プラグイン側で対応ができればと思って書かせていただきました。

Susieに続く画像プラグイン仕様が普及してない(出てきていない?)のがつらいですね…。
(業務用ソフトですらSusieプラグイン対応なんてものまでありますし…)

> この辺をどう妥協するかが難しいところなのですが、
> Susie32 PNG Plug-in の方には、ガンマ補正や背景色合成などの加工機能が
> オプションとして実装してあるので、次回のバージョンアップ時には
> 画像回転機能もオプションとして実装する方向で検討してみます。
> ただ、1週間や1ヶ月でできるわけではないので、催促しないでくださいね(^^;。
> 最近はなかなか自作ソフトをいじる時間がとれないものでして...

急がせる気はまったくありません(^^;
期待してじっくり待たせていただきます。

ご返答ありがとうございました。


■記事リスト / ●親記事



■記事リスト / ▼下のスレッド / ▲上のスレッド
■26 / 親記事)  SIMD 版 JPEG libraryの速度
□投稿者/ みずしま -(2006/05/17(Wed) 11:31:48)
はじめまして
突然の書き込み失礼いたします。
私は新参(たこ)のプログラマのみずしまです。

この度、Pentium M 1.4GHzを使用し、Linux 2.6.9(Fedora Core 3)上で
JPEG画像を取り扱うことになり、インターネットで検索をしていたところ、
貴殿のホームページに目的に合致するSIMD版JPEG libraryを見つけ、
使わせて頂こうと思い作業しています。

そこで、上司に報告相談をしたところ「其のプログラムの性能は?」と言われ、
再度ホームページを見たところ「libjpegライブラリと比較して2〜3倍程度の
速度で動作します。」と書かれてましたが、具体的な速度が見当たらず、
掲示板のNo9に「計測のプログラムも作ったので今度測ってみようと思います。」
と書かれてましたが測定値が出てませんでした。

そこでお手数ですが、SIMD版JPEG libraryの性能を教えて頂きたく思っています。
お手を煩わせ申し訳御座いませんが宜しく御願い致します。


▽[全レス2件(ResNo.1-2 表示)]
■27 / ResNo.1)  Re[1]: SIMD 版 JPEG libraryの速度
□投稿者/ みやさか -(2006/05/17(Wed) 12:54:45)
No26に返信(みずしまさんの記事)
> そこでお手数ですが、SIMD版JPEG libraryの性能を教えて頂きたく思っています。

「オリジナルのlibjpegライブラリと比較して2〜3倍」の謳い文句の根拠は、

各種 JPEG プラグイン・ベンチマークテスト結果
http://cetus.sakura.ne.jp/softlab/software/spibench/jpgbench.html

でのテスト結果に基づいています。このテストで、ifjpegv6.spi がオリジナル版の
libjpeg ライブラリを使用していて、ifjpegx.spi が SIMD 版 JPEG library を
使用しています。

一番確実なのは、貴方自身がテスト・プログラムを作って計測してみることでしょう。
このソフトを含めてフリーソフトは、あらゆる意味で「現状のままで」提供されるもの
であり、その性能などを含め、使用目的に合致するかどうかの判断は、利用する側が
テストを行なって決めるべきものだと思います。

■28 / ResNo.2)  Re[2]: SIMD 版 JPEG libraryの速度
□投稿者/ みずしま -(2006/05/18(Thu) 09:26:24)
No27に返信(みやさかさんの記事)

みやさかさん、ありがとう御座います。

> 「オリジナルのlibjpegライブラリと比較して2〜3倍」の謳い文句の根拠は、
> 各種 JPEG プラグイン・ベンチマークテスト結果
> http://cetus.sakura.ne.jp/softlab/software/spibench/jpgbench.html
> でのテスト結果に基づいています。このテストで、ifjpegv6.spi がオリジナル版の
>
この結果を参考にレポートを作成させて頂きました。

> 一番確実なのは、貴方自身がテスト・プログラムを作って計測してみることでしょう。
>
そうですよね。
私も上司に「テストプログラムを作って試してみたいのでパソコンの使用許可を
下さい」と言った所、
「まだ、調査の段階だから、無駄に成る可能性があるコストは掛けられないから、
まずインターネットや本などで調べて『此れなら行ける! 』という確証を得られてからでないと、許可は出来ない」と…
テストという"付加価値"のある無駄も、必要だと思うのですが…

取りあえず、このレポートを提出して上の判断を仰ぎます。


■記事リスト / ●親記事



■記事リスト / ▼下のスレッド / ▲上のスレッド
■19 / 親記事)  x86 SIMD extension V.2.00 (AMD64) テスト
□投稿者/ みやさか -(2006/02/18(Sat) 17:09:24)
現在開発中の AMD64 対応版(x86 SIMD extension V.2.00)が、予定よりも早く仕上がりそうなので、テスト版を公開します。ソースコードは、とりあえず AMD64 でコンパイルできるようになったという段階で、まだ整理しなければならない箇所が山ほどあるので、しばらくは非公開とさせていただきます。

http://cetus.sakura.ne.jp/softlab/jpeg-x86simd/winx64/jpeg6bx200b1_winx64.zip

現在の x86 SIMD extension V.1.02 のページにて公開している、コマンドライン版 JPEG 圧縮・展開ソフト の Win64(AMD64;x64)/SIMD 版 です。Windows XP x64 Edition で動作します。普通の Windows XP では(たとえ AMD64 対応 CPU を使っていても)動作しません。

コンパイラは Platform SDK に付属の AMD64 コンパイラを使いました。動作確認は Windows XP x64 Edition 評価版 にて行ないました。32bit 版と比べての動作速度の検証などは行なっていません。

Microsoft の AMD64 コンパイラでは、MMX/3DNow! がサポートされないので、この AMD64 版では SSE/SSE2 のみが組み込まれています。-nosse2 オプションを指定すると SIMD (SSE/SSE2) を使わずに動作しますが、正式リリース版においては AMD64 環境では常に SSE/SSE2 を使い、非SIMDのコードを除外できるようにする予定です。

▽[全レス3件(ResNo.1-3 表示)]
■44 / ResNo.1)  Re[1]: x86 SIMD extension V.2.00 (AMD64) テスト
□投稿者/ ちゃー -(2007/10/11(Thu) 23:24:54)
はじめまして。

ver2.0をお待ちしております。
なにか力になれることがありましたら、ご連絡下さい。
一応SuSE(x84_64)でソフト開発しておりますのでテストぐらいはできます。

■45 / ResNo.2)  Re[2]: x86 SIMD extension V.2.00 (AMD64) テスト
□投稿者/ みやさか -(2007/10/11(Thu) 23:54:18)
No44に返信(ちゃーさんの記事)
> ver2.0をお待ちしております。

お待たせしてすみません。現在は完全に開発が止まってしまってます。
フリーソフトを作っている人は大抵がそうなんだろうと思いますが、
何かの拍子で醒めてしまうと、なかなか開発再開には気が向かないものでして...。

でも、宣言した限りは必ずリリースはさせるつもりです。ありがとうございます。

■46 / ResNo.3)  Re[3]: x86 SIMD extension V.2.00 (AMD64) テスト
□投稿者/ ちゃー -(2007/10/12(Fri) 08:43:15)
>何かの拍子で醒めてしまうと、なかなか開発再開には気が向かないものでして...。
そうですよね。日々の仕事が忙しいとなおさらだと思います。

>でも、宣言した限りは必ずリリースはさせるつもりです。ありがとうございます。
頑張って下さい!陰ながら応援しています!!

■記事リスト / ●親記事



■記事リスト / ▼下のスレッド / ▲上のスレッド
■15 / 親記事)  nkf ですが
□投稿者/ ぽん -(2006/02/01(Wed) 21:49:20)
ここにあります。
http://www.vector.co.jp/soft/win95/util/se295331.html

▽[全レス1件(ResNo.1-1 表示)]
■16 / ResNo.1)  Re[1]: nkf ですが
□投稿者/ みやさか -(2006/02/01(Wed) 21:58:22)
No15に返信(ぽんさんの記事)
> ここにあります。
> http://www.vector.co.jp/soft/win95/util/se295331.html

どうもありがとうございます。これはまったく気がつきませんでした。
混乱を避けるために、こっちの方は引っ込めることにします。

# 焦って公開するとロクなことがないなぁ...。
# 移植物を公開する場合は気をつけないと。

■記事リスト / ●親記事



■記事リスト / ▼下のスレッド / ▲上のスレッド
■8 / 親記事)  SIMD 版 JPEG library 使用ソフト調査(01/29)
□投稿者/ みやさか -(2006/01/29(Sun) 23:47:48)
ほとんどといっていいほど反響がないので(^^;、Google の検索で、使ってくださっている方がいないか調べてみました。今のところ、以下の2件。


綾川版 Firefox - http://marilab.hp.infoseek.co.jp/buildfx/index.html

Web ブラウザ Firefox の独自ビルド版を公開している綾川さんのサイト。2006/01/28 以降にビルドされた Firefox に SIMD版 JPEG library が使われているようです。

私は Firefox は自分の html の表示確認ぐらいにしか使っていないし、画像の多いサイトにも滅多に行かないので、私的にはあまり使う意味がないのですが、JPEG の表示速度では以前の2倍程度の改善があったとのことです。


Hamana - http://miyano.s53.xrea.com/

DirectX を利用するグラフィック・ビューア。スライドショーの際に、様々なエフェクトを見せてくれます。こういうエフェクトを使うグラフィック・ビューアやスクリーンセーバーは以前からありましたが、これは DirectX を使っているので3次元のエフェクトを見せてくれるところが目新しくておもしろいと思います。

以前は SIMD Enhanced JPEG Plug-in の使用を推奨されていたのですが、V1.47 より SIMD版 JPEG library を組み込んでくださいました。


▽[全レス18件(ResNo.1-18 表示)]
■9 / ResNo.1)  Re[1]: SIMD 版 JPEG library 使用ソフト調査(01/29)
□投稿者/ 齊藤 -(2006/01/30(Mon) 06:45:52)
はじめまして。齊藤と申します。

SIMDライブラリを私のソフトで使わせていただこうと思い作業しています。
私の使用マシンは超低電圧版Pentium-M 1.2GHzですが、
体感的に随分早くなった感触です。
計測のプログラムも作ったので今度測ってみようと思います。
よいライブラリをありがとうございます。

ちなみに私はBorland C++ Builder5で作業しているのですが、
この開発環境はアライメントのデフォルトが
コンパイラ、IDE、ドキュメントで混乱しているため随分手間取りました。
(そのためこんな時間に書き込んでいます。月曜なのにやばい。。)。

書いてみますと、下記のようになっています。

                | アライメント | enumの型
----------------+--------------+-------------
bcc32のdefault  | 8バイト      | int
----------------+--------------|-------------
IDEのdefault    | 8バイト      | 可能な最小型
----------------+--------------+-------------
help記載default | 4バイト      | int
----------------+--------------+-------------

こんな困った状態なので、
ご提供いただいているライブラリ側でjpeglib.h内の
アライメントとenumの型を固めて頂けると
C++Builderユーザは時間を節約でき助かります。
よろしければご検討お願いいたします。

私が作ってるソフトです↓なかなか完成しません。
http://s-rl.net/mikatoigraph/giogaldinho/sample.html


■10 / ResNo.2)  C++Builder の変数解釈の問題
□投稿者/ みやさか -(2006/01/30(Mon) 12:12:55)
No9に返信(齊藤さんの記事)
> こんな困った状態なので、ご提供いただいているライブラリ側でjpeglib.h内の
> アライメントとenumの型を固めて頂けるとC++Builderユーザは時間を節約でき助かります。
> よろしければご検討お願いいたします。

要するに、

#ifdef __BORLANDC__
#pragma option push -b -a8
#endif

というような記述を jpeglib.h に(気を利かせて最初から)書いておいて欲しいということですよね。でも、そういう、本来ならコードの使用者が(コンパイラのコマンドラインオプションなどで)自由に決められるはずの変数の解釈を、一人の考え方や都合で勝手に「決めうち」してしまうと、場合によっては「小さな親切 大きなお世話」にもなりかねないとも思うのです。

それにこの問題は、この SIMD 版 JPEG library だけじゃなく、オリジナル版の JPEG library の場合や、それ以外のソースコードの場合でも C++Builder を使った場合はまったく同じ問題が起こってきますよね。この SIMD 版 IJG JPEG library は、オリジナル版 IJG JPEG library との互換を可能な限り確保するというのが最優先課題であるということもありまして、とりあえずは保留とさせていただきたいです。そういう要望があったということは覚えておきますので、同様の要望が多ければまた考えます。

■11 / ResNo.3)  Borland 系コンパイラの変数解釈の変更法
□投稿者/ みやさか -(2006/01/30(Mon) 12:50:06)
ついでなので、他の方のために、Borland 系コンパイラの変数解釈の変更法を掲載しておきます。以下の情報は、フリーの Borland C++ Compiler 5.5 を元にしています。

* bcc32 のコマンドラインオプションで指定する方法

-a  データアラインメントを -a4 (4 バイト)に指定する。
-a-  データアラインメントを -a1 (1 バイト)に指定する。
-an  n の値に応じて,データを 1 = バイト,2 = ワード(2 バイト),
   4 = ダブルワード(4 バイト),8 = クワッドワード(8 バイト),
   16 = パラグラフ(16 バイト)にそれぞれ配置する(デフォルトは -a4)

-b  列挙型を int とする(デフォルトは -b で,列挙型を int サイズにする)
-b-  可能ならば列挙型をバイトサイズにする


*ソースコード中で #pragma で指定する方法

#pragma option push -b -a8
    〜
#pragma option pop

というように、#pragma option push に続いて、上に挙げた bcc32 のコマンドラインオプションを書きます。#pragma option push から #pragma option pop の間のコードだけ、指定したオプションが適用されます。

■12 / ResNo.4)  Re[3]: C++Builder の変数解釈の問題
□投稿者/ 齊藤 -(2006/01/30(Mon) 23:25:52)
こんばんわ。

アライメントの件納得しました。
みやさかさんの言うとおり、
決め打ちしてしまうと問題になりかねないですね。

そもそも自分がハマったのはjerrにちゃんとエラーハンドラを設定してなくてエラーが取れてなかったためです。
今後はしっかりドキュメントを読んで使うようにします。
AMD64対応期待してます。
では。
■17 / ResNo.5)  SIMD 版 JPEG library 使用ソフト(02/13)
□投稿者/ みやさか -(2006/02/13(Mon) 14:29:47)
テテのアトリエ - http://www1.plala.or.jp/tete009/

Firefox の私的ビルド版を公開している tete さんのサイト。

それにしても、Firefox に関しては皆さんいろいろな最適化手法を試していらっしゃるようで、興味深いです。

■18 / ResNo.6)  SIMD 版 JPEG library 使用ソフト(02/18)
□投稿者/ みやさか -(2006/02/18(Sat) 15:59:58)
ついに海外の Firefox 独自ビルドにも使われ始めた模様

Firefox and Thunderbird Community Edition - http://www.mahowi.com/mozilla/

IJG JPEG library をここまで SIMD 化した例は、私の知る限り世界的にもほとんど無いので、海外にも広まるのは時間の問題だとは思っていたのですが..。本当は、英文マニュアルと英語版配布ページを揃えてあげるべきなのでしょうけど、私の今の英語力ではそこまで手が回らないのが申し訳ないです。slashdot.jp では最近 No More "Sorry Japanese Only" Documents ( http://slashdot.jp/bsd/article.pl?sid=05/11/14/0529227 ) なんていう話題が挙がって、興味深く読ませていただきましたけど、私が高校生だった20年ほど前には、日本にいながらここまで英語が身近な存在になる時代が来るとは、まったく予想できませんでした(^^;。

IJG JPEG library の SIMD 版にはもう一つ jpeg-mmx というのがあるのですが、この jpeg-mmx の完成度があまりにも低かったというのが、私の x86 SIMD extension の開発動機なのです。

■20 / ResNo.7)  mmoy氏のjpeg patch
□投稿者/ 綾川 -(2006/04/19(Wed) 09:36:56)
http://www.vector64.com/WindowsBuilds.htmlにあるApril 18, 2006付けのSSE2 buildに、mmoy氏のパッチが添付されています。以前彼が言っていた「1カ所だけ彼が手を入れていない場所がある」が分かるかもしれません^^;
■21 / ResNo.8)  Re[2]: mmoy氏のjpeg patch
□投稿者/ みやさか -(2006/04/20(Thu) 22:53:20)
No20に返信(綾川さんの記事)
> 以前彼が言っていた「1カ所だけ彼が手を入れていない場所がある」
> が分かるかもしれません^^;

情報ありがとうございます。さっそく見てみました。

同梱されているパッチの中で、私がやっていないものといえば jddctmgr.patch に含まれる SIMD 化改造なんですけど、これはナンセンスに近い最適化だと思うなぁ。ここは、カラー JPEG 画像1枚を展開するたびに3回しか制御が来ない場所なので、64ワード×3回=384バイトのメモリコピーを最適化しても、ほとんど実質的な効果はないと思う。

x86 SIMD extension のコードについては、私個人的には、最適化の効果がある箇所はすべて手をつけたつもりで、ある程度枯れたコードだとは思っているんですけどね。

■22 / ResNo.9)  Re[1]: SIMD 版 JPEG library 使用ソフト調査(01/29)
□投稿者/ roytam1 -(2006/04/24(Mon) 16:28:32)
http://ictlab.tyict.vtc.edu.hk/~040386491/files/firefox/
No8に返信(みやさかさんの記事)
> ほとんどといっていいほど反響がないので(^^;、Google の検索で、使ってくださっている方がいないか調べてみました。今のところ、以下の2件。
>
>
> 綾川版 Firefox - http://marilab.hp.infoseek.co.jp/buildfx/index.html
>
> Web ブラウザ Firefox の独自ビルド版を公開している綾川さんのサイト。2006/01/28 以降にビルドされた Firefox に SIMD版 JPEG library が使われているようです。
>
> 私は Firefox は自分の html の表示確認ぐらいにしか使っていないし、画像の多いサイトにも滅多に行かないので、私的にはあまり使う意味がないのですが、JPEG の表示速度では以前の2倍程度の改善があったとのことです。
>
>
> Hamana - http://miyano.s53.xrea.com/
>
> DirectX を利用するグラフィック・ビューア。スライドショーの際に、様々なエフェクトを見せてくれます。こういうエフェクトを使うグラフィック・ビューアやスクリーンセーバーは以前からありましたが、これは DirectX を使っているので3次元のエフェクトを見せてくれるところが目新しくておもしろいと思います。
>
> 以前は SIMD Enhanced JPEG Plug-in の使用を推奨されていたのですが、V1.47 より SIMD版 JPEG library を組み込んでくださいました。
>
I got a problem with firefox-patch-x86simd-1.02.
If my $LDFLAGS has "-ltcg"(using MSVC 7.1), makecfg won't be compiled.
And, if I use Intel C++ Compiler to compile, it won't be compiled too.
■23 / ResNo.10)  about the "$LDFLAGS" problem
□投稿者/ Miyasaka -(2006/04/24(Mon) 17:51:24)
> If my $LDFLAGS has "-ltcg"(using MSVC 7.1), makecfg won't be compiled.
> And, if I use Intel C++ Compiler to compile, it won't be compiled too.

For now, you might be able to compile it by removing
"$(LDFLAGS)" from the mozilla/jpeg/Makefile.in file.

■24 / ResNo.11)  Re[3]: about the "$LDFLAGS" problem
□投稿者/ roytam1 -(2006/04/24(Mon) 18:06:49)
http://ictlab.tyict.vtc.edu.hk/~040386491/files/firefox/
No23に返信(Miyasakaさんの記事)
>>If my $LDFLAGS has "-ltcg"(using MSVC 7.1), makecfg won't be compiled.
>>And, if I use Intel C++ Compiler to compile, it won't be compiled too.
>
> For now, you might be able to compile it by removing
> "$(LDFLAGS)" from the mozilla/jpeg/Makefile.in file.
>
Thanks.

And finally I find a better solution:
jsimdcfg.inc: makecfg.c jinclude.h jconfig.h jpeglib.h jmorecfg.h jpegint.h jerror.h Makefile Makefile.in
$(CC) $(COMPILE_CFLAGS) $(_VPATH_SRCS)
$(LD) $(LDFLAGS) makecfg.$(OBJ_SUFFIX)
./makecfg > jsimdcfg.inc
$(RM) makecfg$(BIN_SUFFIX) makecfg.$(OBJ_SUFFIX)

■25 / ResNo.12)  Re[4]: about the "$LDFLAGS" problem
□投稿者/ Miyasaka -(2006/04/24(Mon) 21:37:15)
> And finally I find a better solution:

Thank you very much. I'll fix my firefox-patch on the web, too.

■31 / ResNo.13)  SIMD 版 JPEG library 使用ソフト調査(08/13)
□投稿者/ みやさか -(2006/08/13(Sun) 22:51:57)
久々に FireFox 以外の採用例を見つけました。

Picture Viewer PV32 - http://www.yox-project.com/products/pv32/index.htm

■35 / ResNo.14)  ライブラリ使用報告
□投稿者/ ルーチェ -(2007/02/27(Tue) 22:37:21)
http://www.ruche-home.net/
みやさかさん、はじめまして。
ルーチェと名乗っている者です。

自身のサイトのBBSにて本サイトのSIMD版JPEGライブラリのことを教えられ、IJGオリジナルのものをそのまま置き換えられるということで、早速自作の画像処理DLLに組み込んでみました。
http://www.ruche-home.net/download/?pack=imgctl
自作ツールのDLLを既存のものと置き換えてJPEG変換を試してみたところ、具体的な計測をしたわけではありませんが、体感できるほどの速度向上を確認しました。

当DLLでは、libpngを用いたPNGの読み込み処理においてもみやさかさん作のifpng.spiのソースコードを参考にした経緯があります。
ifpng.spiのソースコードがなければ、当時の自分にlibpngを理解することは到底無理だったでしょう。

数々の有用なソースコード、ライブラリの提供には大変感謝しております。
ありがとうございました。
■36 / ResNo.15)  Re[2]: ライブラリ使用報告
□投稿者/ みやさか -(2007/03/06(Tue) 07:33:20)
こんにちは。みやさかです。返信遅れてすみません。
SIMD版JPEGライブラリを試してくださいましてありがとうございます。

imgctl.dll って、確か、秀丸エディタの拡張機能である Hidemarnet Explorer の
添付コンポーネントにも採用されていますよね。imgctl.txt に私への謝辞が
書いてあるのを見て嬉しかったのを覚えています。ありがとうございます。

■41 / ResNo.16)  Delphiでの使用
□投稿者/ ゐ -(2007/05/08(Tue) 22:24:01)
ちょっと無理矢理ですが、Delphiで使わせて頂いています。
http://janekako.hp.infoseek.co.jp/cgi-bin/up2/src/jane_s0318.zip
jpeg_simd_mask等で確認した範囲では、ちゃんとSSEでも動作しているようです。
因みに午後のこ〜だのソースにはfixu32というのが入っていますが、
私はDelphiなので試していません

海外のDelphiのMLでも話題になっているようです
http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.language.basm/
■42 / ResNo.17)  Re[2]: Delphiでの使用
□投稿者/ みやさか -(2007/05/08(Tue) 23:09:32)
No41に返信(ゐさんの記事)
> ちょっと無理矢理ですが、Delphiで使わせて頂いています。
> http://janekako.hp.infoseek.co.jp/cgi-bin/up2/src/jane_s0318.zip
> jpeg_simd_mask等で確認した範囲では、ちゃんとSSEでも動作しているようです。

報告、ありがとうございます。Delphiは全く使ったことがないので、
私の方からは、何のアドバイスもできなくてすみませんです。

jidctred.asm などの非SIMDバージョンのコードは、'99年頃、MMXの使えない
Plain Pentium を使っていた頃に実験的に書いたコードを流用しています。
現在では、MMX の使えない CPU を実用しているケースは希でしょうから、
このような「過去の遺物」に近いコードは、無理してまで組み込む意味は
少ないと思いますよ(^^;。

最近では、あちこちで実用してくださっている人がいるようで、嬉しい
限りです。64bit対応版も、一年以上開発が止まってますが、何とか
完成させねばなりませんなぁ。

■43 / ResNo.18)  SIMD 版 JPEG library 調査(07/06/01)
□投稿者/ みやさか -(2007/06/02(Sat) 00:20:29)
Direct Picture Viewer "Linar" - http://www2s.biglobe.ne.jp/~smas/

画像ビューア・整理ツール。V.1.7 ベータ版に SIMD版 JPEG library が使われているようです。

SSP - http://ssp.shillest.net/

いわゆる、萌え系デスクトップアクセサリ。V.2.00.00 以降で SIMD版 JPEG library が使われているようです。


■記事リスト / ●親記事



■記事リスト / ▼下のスレッド / ▲上のスレッド
■6 / 親記事)  自家掲示板 運用開始
□投稿者/ みやさか -(2006/01/12(Thu) 10:22:34)
1999年以来使ってきた vector のホームページスペースが手狭になったため、ソフトウェア工房α は、さくらインターネット のサーバーに順次コンテンツを移転します。その手始めとして、掲示板をこちらのサーバーに移転させました。

2005/12/23 〜 2006/01/12 の間に、Net4u のレンタル BBS に書き込まれた書き込みは、今後の便宜を考え、ここの掲示板に手作業にて転載いたしました(No1-5)。これらの転載されたメッセージは、(投稿主が入力した)削除キーを使っての削除/編集ができませんので、これらの転載されたメッセージを削除/編集をしたい場合は管理者(私)までお申し出ください。


▽[全レス6件(ResNo.1-6 表示)]
■7 / ResNo.1)  サイト移転完了
□投稿者/ みやさか -(2006/01/20(Fri) 14:58:09)
サイト本体の移転を完了しました。ついでに、ページの構成や文章も一部見直しました。

以前のサイトのページを書いた当時('99年)は、スタイルシートを使いたくても Netscape 4 で表示するとレイアウトが崩れてしまうし.. という状況だったのですが、状況はすっかり変わりました。一部のページを除いて HTML 4.01 Strict + CSS 1 で書き直してすっきりしました。

■13 / ResNo.2)  更新情報のRSS配信開始
□投稿者/ みやさか -(2006/01/31(Tue) 12:41:20)
サイト本体の更新情報のRSS配信(RSS V1.0)を開始しました。このRSSファイルは、Headline-Editor Lite版 http://www.infomaker.jp/editorlite/ を使って手動で作成しています。
■14 / ResNo.3)  小ネタ−「夢カウンタ」改造版
□投稿者/ みやさか -(2006/01/31(Tue) 17:07:54)
ここのサイトのカウンタは、Kent-Web http://www.kent-web.com/ の
「夢カウンタ」を一部改造して使用しています。
改造箇所は、数字画像をランダムに選択して表示するようにするもので、
以下のように変更しています。

***************
*** 85,91 ****
  }
  
  # 画像ディレクトリを定義
! if ($in{'gif'}) {
        $in{'gif'} =~ s/\D//g;
        $gifdir =~ s/(.*)\d+\/$/$1$in{'gif'}\//g;
  }
--- 85,96 ----
  }
  
  # 画像ディレクトリを定義
! if ($in{'gif'} =~ /(\d+)-(\d+)/) {
!       srand;
!       if ($2 >= $1) { $rand = int(rand($2-$1+1)) + $1; }
!       else          { $rand = int(rand($1-$2+1)) + $2; }
!       $gifdir =~ s/(.*)\d+\/$/$1$rand\//g;
! } elsif ($in{'gif'}) {
        $in{'gif'} =~ s/\D//g;
        $gifdir =~ s/(.*)\d+\/$/$1$in{'gif'}\//g;
  }

この改造版 夢カウンタ の使用法は、

<img src="/count/dream.cgi?gif=1-8&amp;fig=6" width="90" height="20">

のように、gif= オプションの数字画像番号を範囲で指定します。
すると、その範囲内で数字画像をランダムに選択します。

■29 / ResNo.4)  掲示板仕様変更(スパム対策)
□投稿者/ みやさか -(2006/07/19(Wed) 01:30:06)
最近、あまりにもスパム投稿が多いので、スパム対策として掲示板の仕様を一部変更しました。

変更箇所は、投稿フォームに2時間の有効期限を設定した点です。正規の投稿フォームを使わない投稿、2時間以上前に表示(出力)された投稿フォームを使っての投稿をブロックします。

通常の方法で投稿する限り、この仕様変更が問題になることはないと思いますが、もし投稿できないなどの不都合がある場合はメールにてご連絡ください。

■30 / ResNo.5)  掲示板仕様変更(スパム対策/その2)
□投稿者/ みやさか -(2006/07/20(Thu) 23:28:24)
さらに仕様変更。投稿フォームの有効期限を1時間に短縮しました。また、フォームが表示されてから15秒以内に送信された投稿もブロックするようにしました。これは、スパム自動投稿ソフトへの対策です。

通常の方法で投稿する限り問題になることはないと思いますが、もし投稿できないなどの不都合がある場合はメールにてご連絡ください。

■37 / ResNo.6)  掲示板仕様変更(スパム対策/その3)
□投稿者/ みやさか -(2007/03/13(Tue) 04:13:40)
スパム自動投稿ソフトへの対策をさらに強化しました。
また、「関連するレスをメールで受信する」の機能を廃止しました。これは、現状ではスパム投稿を完全に防ぐことができないので、スパム投稿についてもメールが送信されてしまうのを防ぐためです。


■記事リスト / ●親記事



■記事リスト / ▲上のスレッド
■1 / 親記事)  IFJPEGX.SPI で不可解なブロックノイズ発生
□投稿者/ 和哉 -(2006/01/06(Fri) 14:54:22)
「SIMD Enhanced JPEG Plug-in Ver.0.20」を使用させていただいております

今でもメインの画像閲覧方法が Susie Plug-in を利用した画像ヴュア中心なので、非常に高速で快適です。この様なソフトウェアを公開していただき、有難う御座います。


ただ、不思議なことに、一部の Photoshop で書出したJPEG 画像で、不可解なブロックノイズが発生するようです。
GV, IrfanView, ViX でも表示させてみましたが、その様なノイズは発生しませんでした。

具体的には、30girl.com で過去に配布されていた一部の期間限定壁紙画像(転載禁止) で発生します (現在、それらの画像はダウンロード出来なくなっています)。

8x8 pix. 単位で、エッジが極端に強い部分でのみ、明度がおかしくなっているので、YCrCb の Y をデコードする時に何らかの問題が起きているように感じました。

サンプル画像をお渡しできればよいのですが……。


▽[全レス4件(ResNo.1-4 表示)]
■2 / ResNo.1)  Re[1]: IFJPEGX.SPI で不可解なブロックノイズ発生
□投稿者/ みやさか -(2006/01/06(Fri) 15:42:09)
No1に返信(和哉さんの記事)
>8x8 pix. 単位で、エッジが極端に強い部分でのみ、明度がおかしくなっているので、
>YCrCb の Y をデコードする時に何らかの問題が起きているように感じました。

もしかして、JPEG プラグインの設定で DCT演算の方法が「高速整数演算」になっていませんか?。マニュアル(SETUP.TXT)にも書いてありますが、元々「高速整数演算」は高画質のJPEGファイルほど計算精度が低下して、画像によってはブロックノイズが目立ちやすくなる傾向があります。

他のソフトの場合は、DCT演算の方法が「高精度整数演算」に固定されているものがほとんどですから、問題が出ないのでしょう。GV を持っていらっしゃるのなら、フォーマット別設定の JPEG のところで、DCT Method を speed にして試してみてください。同じ現象が現れませんか?。

以上の方法でも問題が解決しないのなら、問題の画像をメールに添付してお送りくださいませ。

■3 / ResNo.2)  Re[2]: IFJPEGX.SPI で不可解なブロックノイズ発生
□投稿者/ 和哉 -(2006/01/06(Fri) 19:53:07)
No2に返信(みやさかさんの記事)

ご回答有難う御座います。

>もしかして、JPEG プラグインの設定で DCT演算の方法が「高速整数演算」になっていませんか?。

なっていません。画質重視で使用しているので、一番演算が重たい“浮動小数点演算(SSE)”に設定しています。
# 3D Now! , FPU も含め表示結果は全て同じでした (Athlon XP-M 使用)
# (演算は SSE の方が僅かに速い事を確認済)


>GV を持っていらっしゃるのなら、フォーマット別設定の JPEG のところで、DCT Method を speed にして試してみてください。同じ現象が現れませんか?。

同様の現象が、Speed に設定したときのみ発生する事を確認致しました (普段は Correct に設定しています)。


暫くいじっていて気付いたのですが、原因は、呼出しアプリケーション側の設定で、IFJPEGX.SPI の責任ではないようです。
こちらの検証不足が原因でした。申訳御座いません。
# 内蔵 JPEG デコーダを Off にしたつもりが、On のままになっていました
# と言うことは、この内蔵デコーダに問題が有るのですね…

設定を変更すると、無事に IFJPEGX.SPI の設定が有効になって、正常に表示されるようになりました。

■4 / ResNo.3)  Re[3]: IFJPEGX.SPI で不可解なブロックノイズ発生
□投稿者/ みやさか -(2006/01/06(Fri) 22:17:38)
No3に返信(和哉さんの記事)
>暫くいじっていて気付いたのですが、原因は、呼出しアプリケーション側の設定で、
>IFJPEGX.SPI の責任ではないようです。
>こちらの検証不足が原因でした。申訳御座いません。
># 内蔵 JPEG デコーダを Off にしたつもりが、On のままになっていました
># と言うことは、この内蔵デコーダに問題が有るのですね…

もしかして、そのソフトは Hamana じゃありません?
Hamana の内蔵デコーダで試してみると、確かに同じ現象が現れますね。
たぶん、少しでも速度を上げるために「高速整数演算」を利用しているのでしょうけど、作者の方は「高速整数演算」の弱点をご存じないのでしょうね。

■5 / ResNo.4)  Re[4]: IFJPEGX.SPI で不可解なブロックノイズ発生
□投稿者/ 和哉 -(2006/01/06(Fri) 23:53:21)
No4に返信(みやさかさんの記事)

ご返信有難う御座います。

>もしかして、そのソフトは Hamana じゃありません?

いえ。WinFM32, WinFM2000 に添付されている FView32, FView2000 と言うマルチヴュアです。


>たぶん、少しでも速度を上げるために「高速整数演算」を利用しているのでしょうけど、作者の方は「高速整数演算」の弱点をご存じないのでしょうね。

今回の事で分ったのですが、このヴュア (FView 32/2000) の場合、バグにより、意図しない劣化現象が発生しているようです。
FView 32/2000 の設定では、標準が「整数演算 - 精度優先」になっていて、「整数演算 - 速度優先」・「浮動小数点演算」が選択できます。
ところが、どれを選んでも実際には、「整数演算 - 速度優先」で動作してしまっているようで、全てのモードで劣化現象 (ブロックノイズ) が発生してしまいます。コード自体は、全てのモードが用意されているようなので、どうやら振分けミスのようです。

幸い、内蔵デコーダを停止する事が出来ますので、宮坂さんの IFJPEGX.SPI を有効にすると、不具合が回避でき、副作用で、画質が上がるだけでなく、内蔵デコーダよりも展開が速くなるのも体感できます。IFJPEGX.SPI がどれだけ高速なのかが良く分る実例にもなりました (ADCSee 5 や 6 と同等レベルの速さですね)。

※ ADCSee は閲覧中に次の画像の先読みを行う事で速度を稼いでいるので、連続閲覧時の体感速度では負けますが、1枚目の展開速度の体感速度は、ほぼ同等です


速度と引替えに画質を優先したいと思っても、浮動小数点演算を選択でき、扱易いデコーダが意外と少ないので、ほんの僅か速度が落ちるだけで浮動小数点演算が利用できる IFJPEGX.SPI の性能は非常に有難いです。


■記事リスト / ●親記事