問題タブ [libjpeg]

私のアプリケーションはlibjpegを使用してJPEG画像を読み書きします。すべてがうまくいきました

最近、jpeg_create_compress（）を呼び出すときに「間違ったJPEGライブラリバージョン：ライブラリは80、呼び出し元は62を期待します」というエラーでJPEG画像を書き込もうとすると、アプリがクラッシュし始めました（したがって、クラッシュはlibjpeg側ではなく意図的な中止のようですセグメンテーション違反）

少し調べてみると、実際に私のアプリケーションはlibjpeg-62ヘッダー（/ usr / local / includeにインストールされている）に対してコンパイルされ、libjpeg-80（/ usr / lib / i386-linux-にインストールされている）のdylibを使用していることがわかりました。 gnu /）。

libjpeg-62ヘッダーを削除し、libjpeg-80ヘッダーを使用してコンパイルすると、問題が解決しました。

ただし、一部のエンドユーザーがアプリのコンパイル対象とは異なるライブラリバージョンをインストールしている場合でも、このようなクラッシュを防ぐことができるソリューションをいただければ幸いです。

1）致命的なエラーがあっても中止しないようにlibjpegを説得できれば素晴らしいと思います。例：次のようなもの

2）または、正しいライブラリがインストールされているかどうかを非中止チェックします。

3）それが箱から出して実行できない場合は、コンパイル時のAPIバージョン（JPEG_LIB_VERSION）を実行時に検出された互換バージョンと手動でチェックすることで問題ありません。

残念ながら、APIでこれらのメソッドのいずれかを使用できるものを見つけることができませんでした。

私はただ盲目ですか、それとも完全に異なるものが必要ですか？

libexif を使用して、JPEG ファイルの exif メタデータを読み取り、変更しました。元のソース イメージ ファイルに変更内容を書き込む/保存する方法がわかりません。

何か案は？？ありがとう。

libjpegを使用してopenglバッファからスクリーンショットを保存しようとしています。

私が使っている機能はこれです

この関数は開始しますが、いくつかの反復（約100〜150）の後、関数はファイルに何も書き込まず、警告やエラーを生成せずに戻ります。

メモリエンコーディング（実際に必要なもの）を使用すると、関数は終了しますが、結果は意味がありません。さらに、バッファを解放しようとすると、エラーが発生します。これがメモリの宛先バージョンです

この関数は、次のjpeg画像を生成します。

比較すると、ビットマップファイルを保存する行は次のファイルを生成します。

私の理解では、libjpegは画像データを圧縮するために使用されるライブラリです。jpeg_start_compress()関数 を呼び出さずにマーカー メタデータを書き込むことができるはずです。

2 つの質問があります。

• なぜlibjpegはそれを許可しないのですか?
• ソース jpeg ファイル (すでに圧縮されている) がある場合、メタデータの詳細を変更するにはどうすればよいですか? 圧縮された画像を扱っており、メタデータの詳細を変更するだけでよいことをライブラリに通知するために設定できるフラグはありますか?

助けてください。

libjpeg8に依存する動的ライブラリAを他の人に提供します。ただし、他の人が私の lib を libjpeg6 に依存しているアプリケーションにリンクすると、いくつかの競合が発生してクラッシュします。

ジレンマは、彼らが libjpeg6 をより高いバージョンに置き換えないことであり、libjpeg8 で新しい関数を使用する必要があります。この問題を 1 つのプロセスで解決するにはどうすればよいですか?</p>

既存のjpegライブラリのラッパークラスを作成したい。Qtクリエーターでプロジェクトを作成しましたか？Qt Creatorでlibjpeg8をリンクする方法を教えてもらえますか？

量子化（jpeg_write_scanlines？）の後、ハフマンエントロピーコーディングの前、およびファイルをディスクに書き込む前に、DCT係数テーブルにアクセスする必要があります。libjpegでそれは可能ですか？回避策として、圧縮ファイルをディスクに書き込み、バッファイメージモード（jpeg_read_coefficients）を使用してすぐに読み取ることができることは知っていますが、その迂回は避けたいと思います。

現在、 libjpegを使用して JPEG 画像を保存しています。エラーが発生した場合、libjpeg のデフォルトの動作は を呼び出すexit()ことですが、これは私のプログラムにとって致命的なエラーではないため、回避したいと考えています。libjpegでは、独自のエラー マネージャーを使用できますerror_exit()。また、独自の関数 (exit()既定で呼び出す)を使用する場合は、制御を呼び出し元に返してはならないことが義務付けられています。libjpeg は、プログラムではなくsetjmp.hを使用してこの要件を満たすことを提案してexit()います。

ただし、私は C++ プログラムを作成しており、例外にアクセスできます。この質問の答えは、(明確に定義された動作のように) コールバックから例外をスローしても安全であると述べています。ただし、動的ライブラリについては言及されておらず、動的ライブラリの境界を越えて例外をスローしないという一般的な経験則があります。

次に例を示します。

私が知りたいのは、libjpeg が動的ライブラリとしてコンパイルされている場合でも、このコールバックから例外をスローし、それをアプリケーションでキャッチすることはできますか? libjpeg は静的ライブラリまたは動的ライブラリである可能性があり、動的ライブラリの場合は別のコンパイラでビルドされている可能性があります。ただし、例外をスローしてキャッチするコードは、確実に同じコンパイル単位にあります。上記のコードは安全ですか?

参考までに、私は OS X と Windows 向けに開発しています (そして、将来の Linux の可能性を念頭に置いています) ので、これが特定のプラットフォームではなく、一般的に明確に定義された動作であることが知られているかどうかにもっと興味があります/コンパイラ。

libjpeg8 にはこれら 2 つの関数が含まれていますが、libjpeg-turbo には次の機能があります。

...

「JPEG_LIB_VERSION 80」を使用しようとすると、次のようになります。

エラー LNK2019: 未解決の外部シンボル _jpeg_mem_src が関数で参照されています ...

可能であれば、これらの機能をどのように使用できますか？libjpeg-turbo のパッケージをコンパイルする必要がありますか?

jpeg_compressなどのビルド前の関数を使用せずにjpeglibを使用してjpegファイルを自分で書き込もうとしていますが、ヘッダーとテーブルを個別に記述しています...そしてここには多くの問題があります...

WindowsとVisualStudioを使用しているので、gnuwinサイトから.exeファイルをインストールし、コードに「include」フォルダーの4つのヘッダーファイルをインクルードしようとしましたが、write_file_header、jpeg_stdio_destなどの関数を呼び出そうとするとなど、リンクが欠落していると表示されるため、これらの関数が実装されているすべての.cファイルをインクルードする必要があります...

srcファイルも含めようとしましたが、同じ結果です...見つかったすべての例には、ヘッダーjpeglib.hのみが含まれ、他には何も含まれていませんが、この方法では必要な関数を使用できないため、質問はどうすればよいですか？それらのライブラリを適切に使用しますか？ありがとうございました

編集：エラーメッセージはエラーC3861です：識別子が見つかりません...単純に、libjpegの.cファイルにある関数を呼び出そうとすると、コンパイラはそれらの関数がどこにあるかを見つけることができません...

n.2を編集します：ここで関数の開始：