バグ報告 > フロント機能 > 続:モバイル用イメージの変換に関して |
フロント機能
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
kishik |
投稿日時: 2009/5/12 13:20
対応状況: −−−
|
仙人 登録日: 2009/4/3 居住地: 東京 投稿: 382 |
続:モバイル用イメージの変換に関して 表題の
「モバイル用イメージの変換に関して」 のスレッドでソースを読んだ際に いくつか気になったことがあったのですが・・・ スレ主さんの意図からは少しずれるので新しく作りました。 気になったのは2つ。 (1)おそらく複数画像を掲載するときに、 画像の大きさが何倍か違うと無駄にリサイズ (またはJPEGだと画質が無駄に落ちる)と思います。 (2)モバイル用の画像は /html/upload/mobile_image/ 以下に最終的なファイルが作られるのですが、 元のURLが同じ画像でも修正日が違うだけで このディレクトリに別の画像が作成され、 以前のものは削除されません。 不要なファイルが増える一方のはずです。 さらにハッシュを使っているため、 どれがどのファイルなのかすぐには分からないため、 手動で消すのは大変な作業になります。 ----- http://ec-cube-mall.jp/ http://ec-cube.ec-orange2.jp/ http://wiki.ec-orange2.jp/ |
seasoft |
投稿日時: 2009/5/12 13:40
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: 続:モバイル用イメージの変換に関して (1)
経験則的な話ですが、GIFなどのインデックスカラー画像を GD で縮小をする場合、JPEG で出力する方がきれいな場合も結構あったりします。 現状を把握していませんが、縮小の必要が無く、端末が元の画像フォーマットに対応している場合、オリジナル画像を読みにいって欲しい気はします。 (2) 削除を行うのは面倒な気がするので、ハッシュ名には日時情報を含めずに上書きで処理されると良いのかなと思います。 ファイルやサーバの日時を信頼することにして、オリジナルファイルとキャッシュファイルの日時を比較してはいかがでしょう? 若干強引ですが、キャッシュファイルの更新日時をオリジナルファイルのもので touch してしまうのもアリかも。
|
kishik |
投稿日時: 2009/5/12 13:46
対応状況: −−−
|
仙人 登録日: 2009/4/3 居住地: 東京 投稿: 382 |
Re: 続:モバイル用イメージの変換に関して (1)
本来縮小の必要がないはずの画像も サイズの大きく違う画像が複数ある場合は リサイズされてしまうバグがあります。 (2) 日時情報を含めずに上書きするようにするのは2箇所変えるだけな ので簡単なんですが、株式会社ロックオンさんに提案しようかな。。 ちなみにチケットに登録しました。 http://svn.ec-cube.net/open_trac/ticket/458 ----- http://ec-cube-mall.jp/ http://ec-cube.ec-orange2.jp/ http://wiki.ec-orange2.jp/ |
tao_s |
投稿日時: 2009/5/13 0:10
対応状況: −−−
|
仙人 登録日: 2008/8/20 居住地: 東京 投稿: 799 |
Re: 続:モバイル用イメージの変換に関して ちょっと乱暴ですが、ユーザーの年齢層が若い場合などは画像変換機能をoffにし、モバイルサイトの画像は全てjpgにして、ディスプレイ幅240px固定で、商品画像などリサイズ必須の画像はresizeImage.phpで変換してモバイルサイト作ったりします。
|
kick_go |
投稿日時: 2009/6/10 11:55
対応状況: −−−
|
半人前 登録日: 2009/2/17 居住地: 岡山県 投稿: 20 |
Re: 続:モバイル用イメージの変換に関して 引用:
(1) これについては、私も散々悩まされています。 SC_MobileImage.php
とあるブログでこれをコメントアウトすればリサイズされないという記事を発見し、行ったところリサイズはされませんでした。 ですが、画像が多いサイトなどでは、i-modeブラウザー1系でキャッシュサイズオーバーとなってしまいます。 携帯ブラウザで表示した場合ですが、小さい画像が画面上側にあったとして、大きい画像が画面下側にある場合、 大きい画像は見れたものではない画質になります。 これはコンバート後の比率固定が原因かと思いますが・・・ 実際のところは未だに原因特定できていないです。 image_converter.incなども怪しいかと個人的に考えていますが・・・ |
kishik |
投稿日時: 2009/6/10 19:19
対応状況: −−−
|
仙人 登録日: 2009/4/3 居住地: 東京 投稿: 382 |
Re: 続:モバイル用イメージの変換に関して これは携帯の総容量が10あったとします。
HTMLで2 画像(大)で6 画像(小)で2 を使ったとします。 ことのとき、本来ならばリサイズの必要はないのですが、 EC-CUBE内では平均許容画像サイズを計算していて ([総容量10] - [HTMLサイズ2]) / (画像数2) = 4 となっており、『どの画像も』この4に収まるように リサイズする処理が入っています。 もう少し正確に各画像のサイズを見積もるロジックを入れるか、 総容量の値を大きくするか、ですね。 確か内部に持っているテーブルでは最新機種に対応できていないので、 携帯の容量上限はもう少し上がるのではないかと思います。 (未確認です) ----- カスタマイズ承ります http://ec-cube-mall.jp/ http://ec-cube.ec-orange2.jp/ http://wiki.ec-orange2.jp/ |
AMUAMU |
投稿日時: 2009/6/16 19:41
対応状況: −−−
|
神 登録日: 2009/5/2 居住地: 東京都 投稿: 2712 |
Re: 続:モバイル用イメージの変換に関して ちょうど、そこの携帯リサイズに関連する部分を修正していたので、ご参考までに
SC_MobileImage.php
image_converter.inc
元の部分はコメントアウトしてある部分です。 imageConverterのset系を呼ぶ位置を変えて毎回初期化してます。 image_converter.incの修正は、リクエストされたphp単位で画像キャッシュファイルを別にしてます。 こうしないと、ハッシュファイル名が変わらない場合があるので修正してますが画像キャッシュファイルが増える問題は増大してます・・・ 複数画像の時の問題は(たぶん)解決してるかと思っています。 本当は、imgタグのwidthとheightも見るほうが良いんでしょうけど・・・。 |
kishik |
投稿日時: 2009/6/16 20:37
対応状況: −−−
|
仙人 登録日: 2009/4/3 居住地: 東京 投稿: 382 |
Re: 続:モバイル用イメージの変換に関して なるほど〜。
以前考えていたのは、 画像サイズは縦×横で概算して、 その比で割り当て配分計算をする・・・という感じでした。 考えてただけで、まだテスト実装してないんですが(汗) 作ったらご報告します。 ----- カスタマイズ承ります http://ec-cube-mall.jp/ http://ec-cube.ec-orange2.jp/ http://wiki.ec-orange2.jp/ |
seasoft |
投稿日時: 2009/6/17 22:18
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: 続:モバイル用イメージの変換に関して > 以前考えていたのは、
> 画像サイズは縦×横で概算して、 > その比で割り当て配分計算をする・・・という感じでした。 とても良いロジックだと思います。実現を期待しております。 各画像形式でオーバーヘッドがあるので、その分を考慮していただけるとなお良いと思います。 若干面倒そうなのは、極端に画像数が多くて、オーバーヘッドのみで対象機種の上限に到達したようなケースですかね。そんなケースは割り切って、最低画質を定めておいて上限オーバーで送出して良いのかなとも思います。ログが残っていると、運用カバーができて、幸せな人が増えるかも。
|
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |