1

Google App Engine は 1M を超える画像ファイルに対して怒ります。 http://code.google.com/appengine/docs/python/images/overview.html#Quotas_and_Limits

任意のユーザー提供の画像と、それを前処理する C コードを実行する機能が与えられた場合、最大の品質で 1M に到達する賢い方法はありますか?

強引な方法は、一連の JPEG 品質設定と一連の倍率を試して、1M 未満のファイルになる圧縮レベルと解像度を探すことです。

総当たり検索以外に、最高の JPEG 品質とスケール ファクターを選択して 1M ファイル サイズを達成する賢い方法についてのアイデアはありますか?

さまざまな JPEG 品質レベルで達成される圧縮率についての仮定など、優れたヒューリスティックとは何でしょうか?

ブルート フォースには単純さという利点があり、とにかく十分に高速である可能性がありますが、好奇心旺盛です。

4

4 に答える 4

3

親愛なるGoogleAppEngineチーム：

画像ファイルの1MBの上限を削除してください。ファイルサイズを抑えるための開発者のインセンティブを維持するために、ストレージ、処理、帯域幅などに関連する割り当てと価格設定がすでにあります。

どうもありがとうございました。
心から、

開発者コミュニティ

于 2010-11-02T17:44:46.043 に答える
3

標準の二分探索はランダムなデータを想定していますが、ここではそうではありません。より効率的なアプローチは、線形補間を行うことです。この関数 Size of Compressed Image (Size of uncompressed image) は、適切な関数と同様に、十分に小さい間隔が与えられれば線形です。したがって、各反復で、線形応答を仮定します。これにより、バイナリ検索よりも劇的に速く答えが得られます。EG は 50% の品質、.75 M で圧縮されるため、(1/.75) * 50% ~ 62% を使用します。その結果が 1.5 M の画像になるとしましょう。これで 2 つのポイントが得られました。(X = 50%、Y = 0.75 M) および (X = 62%、Y = 1.5 M)。勾配は (1.5-.75)/(62-50)=.75/12 なので、2 番目の推測は .25M X (12/.75)=4%, 50%+4%=54% となります。これまでのところ推測し、結果があなたを満足させるまでプロセスを繰り返します. ニュートン法などの高次補間を使用できます。

于 2010-11-12T16:19:10.763 に答える
3

単純なアルゴリズム — 100 品質の jpeg を作成し、1M 未満の場合はそれを使用し、それ以上の場合は 50 で作成し、現在 1M 未満の場合は 75 を試し、それ以外の場合は 25 を試します…</p>

于 2010-11-01T19:05:59.307 に答える
1

ジェフ・アトウッド自身によるこの記事は、「15 の JPEG 圧縮係数で標準化する」方法があることを暗示しているようです: JPEG圧縮レベルと再圧縮の比較じっと見ていると）。

圧縮率を設定できる場合は、任意のサイズを設定できます。

ウィキペディアの記事の表は興味深いようです。Qualtiy = 50 -> Compression factor = 15:1 (ウィキペディアの経験的測定によって証明されています :-) ... 先延ばしにしています。今すぐ別のことをする必要があります...)

于 2010-11-01T19:24:13.290 に答える