このｻｲﾄでは私の撮った水中写真を携帯の待受画像として公開しています｡その当初の理由は私が自分自身の携帯で使いたいためだったため､画像のｻｲｽﾞは 120x120 以内､ﾌｧｲﾙのｻｲｽﾞは 5KB 以内と決めていました｡
ところがある日､友達に待受画像を使わせてくれと言われて携帯を渡され､ﾀﾞｳﾝﾛｰﾄﾞしてみた私は予想外の結果に驚きました｡
小さい､､､
ﾃﾞｼﾞﾀﾙｶﾒﾗ機能の進化によって発達した携帯電話の液晶はこの時すでに QVGA(320x240) にまで達していたのです｡私の水中画像は画面の半分にも満たない大きさで表示されていました｡
これではいかん､と思った私は新しい待受画像を提供する事にしました｡今回のｺﾝｾﾌﾟﾄは､
本格的な待受画像ｻｲﾄならｻｰﾊﾞｰ側で画像の変換をﾘｱﾙﾀｲﾑに行ってあらゆるｻｲｽﾞの画像を提供するのでしょうが､ここは個人のｻｲﾄなのでそこまではできません｡というわけで画像の更新は PC 上で事前に行ってｱｯﾌﾟﾛｰﾄﾞする方法にしました｡
まずは元になる画像を準備します｡元画像用のﾃﾞｨﾚｸﾄﾘを作成し､その中に従来通り画像の種類(魚の種類)毎のｻﾌﾞﾃﾞｨﾚｸﾄﾘを作成します｡そしてそれぞれのﾃﾞｨﾚｸﾄﾘの中に元画像を以下の様な形式で置いていきます｡
実際にはﾃﾞｼﾞｶﾒの画像から正方形の部分を切り出し､それぞれのﾃﾞｨﾚｸﾄﾘに置いていくだけです｡
画像のｶﾀﾛｸﾞﾍﾟｰｼﾞは従来通り自作の Album Maker で作成します｡ここで元画像のﾃﾞｨﾚｸﾄﾘにもｱﾙﾊﾞﾑを作成し､それぞれの画像にﾀｲﾄﾙ(魚の名前)を付けておきます｡
次に JPEG 画像のｻｲｽﾞを変換する方法が必要です｡これには幾つか選択肢があります｡
とりあえずﾌﾘｰｿﾌﾄを探してみたのですが良い物が見付からなかったので自作する事にしました｡そうなると C 言語を使うか Java
を使うかを選択する必要があります｡C 言語では高速なﾌﾟﾛｸﾞﾗﾑができますが､ﾌﾟﾗｯﾄﾌｫｰﾑやﾗｲﾌﾞﾗﾘに依存した形式になります｡Java
ではｽﾋﾟｰﾄﾞは遅くなりますが､別のﾌﾟﾗｯﾄﾌｫｰﾑでも実行できます｡
今回､Album Maker にもｻﾑﾈｲﾙ画像を生成する機能を付ける事にしていたので Java を使う事にしました｡
実際のｺｰﾄﾞは Album Maker のﾊﾟｯｹｰｼﾞに含まれている Share.JPEGConverter というｸﾗｽです｡Java のｺｰﾄﾞからもｺﾏﾝﾄﾞﾗｲﾝからも実行できます｡ｺﾏﾝﾄﾞﾗｲﾝからの使い方は､
java Share.JPEGConverter <source file> <target file> <width> <height> <quality>
です｡<source file> を <target file> に変換します｡幅
<width>､高さ <height>､そして圧縮率 <quality> (0.0 より上､1.0
以下)を指定できます｡
更新の自働化は今まで通り make
を使います｡元画像のあるﾃﾞｨﾚｸﾄﾘが変更された時､画像のｻｲｽﾞごとの3つのﾃﾞｨﾚｸﾄﾘを更新します｡
実際の更新はｼｪﾙｽｸﾘﾌﾟﾄで行い､find ｺﾏﾝﾄﾞで元画像を検索して対応した縮小版の画像が存在しなかったばあいに
JPEGConverter を使って画像を生成します｡同時にﾀｲﾄﾙの入っているﾃｷｽﾄﾌｧｲﾙもｺﾋﾟｰし､最後に AlbumMaker を実行してｶﾀﾛｸﾞﾍﾟｰｼﾞを生成します｡
また携帯電話の多くにはﾀﾞｳﾝﾛｰﾄﾞできる画像のｻｲｽﾞに制限があります｡私の携帯も 5KB の制限があります｡反面 JPEG
画像は内容の複雑さによってｻｲｽﾞが大きく変化します｡最も複雑な画像に合わせて圧縮率を低くしてしまうと全体の画質が低下してしまいます｡そこでｼｪﾙ
ｽｸﾘﾌﾟﾄの中で画像のﾌｧｲﾙｻｲｽﾞが制限以下になるまで圧縮率を下げて行くようにしました｡こうすると簡単な画像は高画質のまま､複雑な画像だけ圧縮
して変換できます｡
更新された画像とｶﾀﾛｸﾞﾍﾟｰｼﾞのｱｯﾌﾟﾃﾞｰﾄは手動です｡tar ｺﾏﾝﾄﾞでまとめたものを転送してｻｰﾊﾞｰ側で解凍しています｡
存在しない画像だけを生成する事にしたので Java の速度の問題も気になる程ではありませんでした｡
実際の待受画像のﾍﾟｰｼﾞは i-mode 向けﾍﾟｰｼﾞにあります｡
これでとりあえず 360 x 360 までは対応できました｡また将来 480 x 480 が必要になってもﾀｰｹﾞｯﾄを増やすだけですぐに対応できます｡