OPTPiX Labs」カテゴリーアーカイブ

将来の帯域制限を見据えると、”減色”です。

Android端末3台持ち。ソリューション営業部の浅井です。

“WindowsMobile”、どころか”WindowsCE”はおろか、”PalmOS”のころからパケット通信の恩恵に預っている私なんですが、今はデータ通信も「パケット定額」が当たり前~ってんで、定額を”前提”としたWebサービスが定番。

Webサービスの中心として成長したソーシャルコンテンツ。数年前までは自宅のPCからのアクセスが当然だった”mixi”や”Facebook”などのSNSはもちろん、動画配信系の”YouTube”や”ニコニコ動画”。更にはケータイやスマートフォンからのアクセスが大前提の”ソーシャルゲーム”も、この「パケット定額」なくしてはサービスが成り立たないのが現在のWebサービス、であります。

が! ここにきて永遠と思われたこの「パケット定額」が無くなるのでは? という話題が。

続きを読む

カテゴリー: 画像減色 | タグ: , , | 2020/06/16 更新

Flash Playerのメモリ使用量を1/3に抑えるテクニック

ウェブテクノロジ開発部の西田です。

この記事では、主にモバイル機器向けFlashコンテンツを開発されている方々に向けて、Flash Playerでのメモリ使用量とSWFファイルのファイルサイズを抑える方法についてご紹介します。
同時に、Flashコンテンツに画像を組み込む際の注意点についても紹介します。

現在、日本で普及しているほとんどのフィーチャーフォン(いわゆるガラケー)にはFlash Liteが搭載されており、Androidでも2.2以降からはFlashが搭載されています。ソーシャルゲームをはじめ、グラフィカルでリッチなFlashコンテンツが日々増えてきていますが、それにともないSWFファイルのファイルサイズやFlash Playerのメモリ使用量が問題になってくることがしばしばあるのではないでしょうか。

1. Flash Playerのメモリ使用量が1/3になる!

まずは同じくらいのファイルサイズの画像(JPEG、PNG)を組み込んだSWFファイルを作成し、SWFファイルのファイルサイズとFlash Player(エミュレーター)のメモリ使用量にどれくらいの違いが出るかを比較してみました。
※画像はクリック・タップすると拡大されます。


  • JPEG
  • PNG-8 512x512 50KB
    PNG-8(透過なし)
  • PNG-8 512x512 alpha
    PNG-8(透過あり)

表1. JPEG/PNGのメモリ使用量・SWFファイルサイズの比較

フォーマット JPEG PNG-8(透過なし) PNG-8(透過あり)
画像サイズ 512×512pixel 512×512pixel 512×512pixel
画像ファイルサイズ 50,843 byte 51,503 byte 51,771 byte
SWFファイルサイズ 50,937 byte 49,743 byte 49,933 byte
メモリ使用量 1,202KB 388 KB 388 KB
  • 計測環境:Flash Lite3.0 色深度:32bit ディスプレイサイズ:240×320
  • このページで表示している画像は実際に使った画像を縮小して表示しています。各画像のリンク先が、この実験で使用した元画像です。

図1. JPEG/PNGのメモリ使用量・SWFファイルサイズの比較グラフ

 JPEG/PNGのメモリ使用量・SWFファイルサイズの比較グラフ

同程度のファイルサイズの画像を使用しても、PNGでは劇的にメモリ使用量が抑えられていることがわかります
だったらすべての画像をPNGにすればいいの? というとそういうわけにもいきません。
では、どのような場合にPNGを使えば良いのかを考えていきましょう。

2. まずは画像フォーマットのおさらいから

Flashやインターネットなどでは主にJPEG、GIF、PNGといった画像フォーマットが使われています。
ここでは、それぞれの画像フォーマットについておさらいをしておきましょう。

表2. JPEG、GIF、PNGの特徴

JPEG

GIF

PNG-8

PNG-24

PNG-32

圧縮方式

不可逆圧縮
(画像劣化あり)

可逆圧縮

可逆圧縮

可逆圧縮
(画像劣化なし)

可逆圧縮
(画像劣化なし)

色数

1677万色
(24bit)

1677万色中
256(8bit)

1677万色中
256(8bit)

1677万色
(24bit)

1677万色
(24bit)

透過
(アルファ)

不可

可能
(透明1色のみ)

可能
(アルファチャンネル)

不可

可能
(アルファチャンネル)

アニメーション

不可

可能

不可

不可

不可

 

それぞれの画像フォーマットの長所と短所も簡単にまとめておきましょう。

 

表3. JPEG、GIF、PNGの長所と短所

JPEG 長所 – 写真画像の圧縮に向いている
– 圧縮率が可変なので、低圧縮(高画質)から高圧縮(低画質)まで、用途によって選べる
短所 – 線画、アニメ調、ロゴ、画面キャプチャのような画像の圧縮には向いていない
– 非可逆圧縮のため、圧縮率を高くすると画質が劣化する
– 透過やアニメーションはできない
– 画像をメモリに展開したとき、1ピクセルあたり3バイト使用する(メモリ使用量大)
GIF 長所 – 線画、アニメ調、ロゴ、画面キャプチャのような画像の圧縮に向いている
– アニメーションができる
– 透明色が使える
– 画像をメモリに展開したとき、1ピクセルあたり1バイト使用する(メモリ使用量小)
短所 – 256色までしか表現できない
PNG 長所 – 線画、アニメ調、ロゴ、画面キャプチャのような画像の圧縮に向いている
– PNG-24/32(フルカラー)では、圧縮しても画像が劣化しない
– PNG-8(インデックスカラー…256色、16色など)にもPNG-24/32(フルカラー)にも対応できる(インデックスカラーに減色する際の品質によって結果が大きく左右されますが、「OPTPiX imésta」を使えば高品質の減色が可能です)
– アルファチャンネルを持つことができ、半透明の表現が可能
– PNG-8(インデックスカラー)の場合、画像をメモリに展開したとき、1ピクセルあたり1バイト使用する(メモリ使用量小)
短所 – PNG-24/32(フルカラー)ではJPEGよりもファイルサイズが大きくなる
– PNG-24/32(フルカラー)の場合、画像をメモリに展開したとき、1ピクセルあたり3バイト/4バイト使用する(メモリ使用量大)
– アニメーションできない

一般的には、写真などはJPEG、画像自体でアニメーションさせたいときはGIF、ロゴやボタンなどはGIFかPNGフォーマットが適しています。

3. ではモバイル機器向けのFlashでは何を使う?

それぞれの画像フォーマットには得意・不得意があるので、画像の使用用途や目的に応じて適切な画像フォーマットを選択する必要があります。
実際にFlash内に画像を組み込み、SWFファイルのメモリ使用量とファイルサイズを見てみましょう。

 

表4. 各画像フォーマット毎のSWFファイルサイズ・メモリ使用量の比較

JPEG 512x512 70% GIF 512x512 256color
フォーマット JPEG(画質 70) フォーマット GIF
画像サイズ 512×512pixel 画像サイズ 512×512pixel
画像ファイルサイズ 23,455 byte 画像ファイルサイズ 55,901 byte
SWFファイルサイズ 23,549 byte SWFファイルサイズ 49,743 byte
メモリ使用量 1,129KB メモリ使用量 388 KB

 

PNG 512x512 fullcolor PNG 512x512 256color
フォーマット PNG-24 フォーマット PNG-8
画像サイズ 512×512pixel 画像サイズ 512×512pixel
画像ファイルサイズ 142,427 byte 画像ファイルサイズ 51,503 byte
SWFファイルサイズ 165,015 byte SWFファイルサイズ 49,743 byte
メモリ使用量 1,267KB メモリ使用量 388 KB
  • 計測環境 Flash Lite3.0 色深度:32bit ディスプレイサイズ:240×320
  • 表示している画像は実際に使った画像を縮小しています。各画像のリンク先が、この実験で使用した元画像です。

画素数が大きくフルカラーで扱いたい画像の場合は、圧縮率を調整できるJPEGを使うとSWFファイルのサイズを抑えることができます。しかしながら、アニメ調の画像では、やはり画質が劣化してしまいメモリ使用量も大きくなります。

フルカラーにこだわらなくてもよい場合は、GIFかPNG-8を使えばメモリ使用量とSWFファイルサイズを抑えることができます。ただし、この場合は減色する際の品質が重要となってきます。「OPTPiX imésta」を使えば高い品質で減色することが可能です。

また、GIFでは単色での透過しかできずFlash内でそのままGIFアニメーションを使うこともできないため、色数を256色まで制限できる場合は、メモリ使用量とSWFファイルサイズを抑え、綺麗に透過させるにはPNG-8が有効です。

 

4. 画像圧縮設定にご注意を!

画像フォーマットや画質を適切に選択していても、Adobe Flash CSにPNGやGIFなどの画像を組み込んだ際に、自動的にJPEG圧縮されてしまうことがあります。ついつい陥りやすい問題ですので注意が必要です。

画像のプロパティ

 

Adobe Flash CSの「ライブラリ」からアイテムを選択し画像のプロパティを確認してみましょう。
大きな画像の場合、圧縮の項目が「写真画質(JPEG)」に設定されることがあります。
この場合、PNGやGIFを組み込もうとしてもJPEG圧縮されてしまい、画質が劣化した画像が表示されてしまいます。
せっかくターゲットに合わせて調整した綺麗な画像が、いつの間にか劣化して表示されてしまうということは不本意です。しかも、メモリ使用量も増加してしまいます。

画像のプロパティ

圧縮の項目を「劣化なし(PNG/GIF)」とした場合、PNGやGIFはJPEG圧縮されなくなり、ターゲットに合わせて調整した画像が意図通りに表示されるようになります。また、メモリ使用量も前述した通りに抑えることができます。

 

表5. 圧縮設定によるメモリ使用量SWFファイルサイズの比較

元画像のフォーマット PNG-8 PNG-8
元画像ファイルサイズ 51,503 byte 51,503 byte
画像サイズ 512×512pixel 512×512pixel
圧縮設定 写真画質(JPEG) 劣化なし(PNG/GIF)
SWFファイルサイズ 29,899 byte 49,743 byte
メモリ使用量 1,140 KB 388 KB
  • 計測環境 Flash Lite3.0 色深度:32bit ディスプレイサイズ:240×320

 

5. Flashの今後について

Adobeがモバイルブラウザー向けFlash Playerの開発を終了する、との報道もあり今後の動向が気になるところですが、実際のところ、まだフィーチャーフォンは多く使われており、Android機でもFlash Playerを搭載している機種がほとんどです。コンテンツを提供する業界でも、フィーチャーフォンユーザー向けのコンテンツを充実させる方向で進んでいるようです。

今回ご紹介した方法を参考に、軽くて快適なFlashコンテンツ作成の一助になれば幸いです。

カテゴリー: 開発・プログラミング | タグ: , , , , | 2020/06/16 更新

オレオレ認証局の作り方~SSL証明書を無料で作る方法 on CentOS 5

ウェブテクノロジのサーバやネットワークのお守りをしている yone です。今後、社内で実際に使っているソフトウェア・設定・構成などの豆知識のご紹介をしていきたいと思っています。巷にある情報の再掲になりますが、実稼働事例の一つとしてご参考になれば幸いです。

1. お金のかかる証明書は要らない

HTTPS を使ったウェブサイトを立ち上げるとき、SSL サーバ証明書屋さんからサーバ証明書を購入するのが普通です。

ところが、会社内や特定のメンバー内だけで利用するサーバであれば、必ずしも証明書屋さんから証明書を購入する必要はないのです。

今回は、証明書屋さんから買わずに自前で証明書屋さんを作って自前で証明書を発行し、HTTPS サイトを立ち上げる方法をご紹介します。

その証明書の正式名称は、自己署名証明書ですが、本稿ではオレオレ証明書と表記することにします。(笑)
試しに、「オレオレ証明書」で検索してみてください。ジャーゴンとして、意外と広く使われているようです。

同様に、自前の証明書屋さんはオレオレ認証局と表記します。こちらも正式な名称ではありません。

2. SSL/TLS とはなんぞや

ウェブサイトの URL の先頭が、https:// となっている場合、SSL または TLS を利用しています。このときの主な特徴は下記のようになります。

  1. 暗号化
  2. サーバ認証
  3. 改竄検出

証明書屋さんへお金を払って証明書を買うのはなぜでしょうか。それは、2番目のサーバ認証のためです。このサーバは本物だぞと、証明書屋さんが太鼓判を押しているのです。

特定のメンバー内だけで使う場合、事前にオレオレ証明書を「この証明書は本物や!」と配布しておけば、証明書屋さんから購入したサーバ証明書と同様に使えちゃったりします。

不特定多数がアクセスするウェブサイトに使うのは不適切です。諦めて、証明書屋さんから購入しましょう。

3. オレオレ証明書を作ろう

certificate verify failed

サーバー証明書エラーの画面

実は CentOS 5 の場合、mod_ssl パッケージをインストールするとオレオレ証明書で稼動状態になります。が、そのままアクセスすると警告を表示してしまいます。

この難局に立ち向かう術は2つあります。

  1. サーバ証明書が正しいものだとし、PCに証明書を登録する
  2. 自前の認証局 (ルート CA) を用意し、その認証局がサーバ証明書を発行する。PC に自前の認証局を登録する

サーバの数が多くないのであれば前者でもよいのですが、いくつもいくつもある場合は認証局を作ってしまいましょう。認証局の登録を一回行えば、他の登録作業はなくなります。

4. ルート CA 構築

ここでは CentOS5 上で新規構築します。一度だけの実施です。下記は、exampleCA という名称で作成した例です。

# cd /etc/pki
# mkdir exampleCA
# cp tls/misc/CA exampleCA/
# cp tls/openssl.cnf exampleCA/
# echo 01 > exampleCA/crlnumber

/etc/pki/exampleCA/CA ファイルを修正します。

SSLEAY_CONFIG="-config /etc/pki/exampleCA/openssl.cnf"   ← 追加
DAYS="-days 365"        # 1 year
CADAYS="-days 1095"     # 3 years
REQ="openssl req $SSLEAY_CONFIG"
CA="openssl ca $SSLEAY_CONFIG"
VERIFY="openssl verify"
X509="openssl x509"

CATOP=/etc/pki/exampleCA   ← 修正
(中略)
-newca)
(中略)
    $CA -out ${CATOP}/$CACERT $CADAYS -batch \
        -extensions v3_ca \   ← 追加
        -keyfile ${CATOP}/private/$CAKEY -selfsign \
        -infiles ${CATOP}/$CAREQ

/etc/pki/exampleCA/openssl.cnf ファイルを修正します。

[ CA_default ]
dir             = /etc/pki/exampleCA    # Where everything is kept   ← 修正
(中略)
[ req_distinguished_name ]
countryName                    = Country Name (2 letter code)
countryName_default            = JP   ←修正
countryName_min                = 2
countryName_max                = 2

stateOrProvinceName            = State or Province Name (full name)
stateOrProvinceName_default    = Tokyo   ←修正

localityName                   = Locality Name (eg, city)
localityName_default           = Toshima-ku   ←修正

0.organizationName             = Organization Name (eg, company)
0.organizationName_default     = Example Corp.   ←修正
(中略)
[ usr_cert ]
basicConstraints=CA:FALSE
keyUsage = digitalSignature, keyEncipherment   ←追加
extendedKeyUsage = serverAuth   ←追加
# nsComment                    = "OpenSSL Generated Certificate"   ←コメントアウト
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
(中略)
[ v3_ca ]
keyUsage = cRLSign, keyCertSign   ←コメント削除

秘密鍵・公開鍵・自己署名証明書を生成します。

# cd /etc/pki/exampleCA
# ./CA -newca
mkdir: cannot create directory `/etc/pki/exampleCA': File exists
CA certificate filename (or enter to create)
(そのままEnter)
Making CA certificate ...
Generating a 1024 bit RSA private key
...++++++
...........++++++
writing new private key to '/etc/pki/exampleCA/private/./cakey.pem'
Enter PEM pass phrase:CAパスフレーズを入力
Verifying - Enter PEM pass phrase:CAパスフレーズを入力
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Toshima-ku]:
Organization Name (eg, company) [Example Corp.]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:example CA
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/pki/exampleCA/openssl.cnf
Enter pass phrase for /etc/pki/exampleCA/private/./cakey.pem:CAパスフレーズを入力
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 0 (0x0)
        Validity
            Not Before: Aug  1 10:34:25 2007 GMT
            Not After : Jul 31 10:34:25 2010 GMT
        Subject:
            countryName               = JP
            stateOrProvinceName       = Tokyo
            organizationName          = Example Corp.
            commonName                = example CA
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
            X509v3 Authority Key Identifier:
                keyid:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
                DirName:/C=JP/ST=Tokyo/O=Example Corp./CN=Example CA
                serial:00

            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign, CRL Sign
Certificate is to be certified until Jul 31 10:34:25 2010 GMT (1095 days)

Write out database with 1 new entries
Data Base Updated
# mv careq.pem certs/00.pem
# openssl ca -config openssl.cnf -gencrl -out crl.pem

これで準備完了です。

ルート CA ファイル
説明 ファイル名
CA 証明書 cacert.pem, newcerts/00.pem
CA 秘密鍵 private/cakey.pem
CA 証明書発行要求 certs/00.pem

5. サーバ証明書を発行

ではさっそく、サーバ証明書を作ってみます。https://www.example.jp/ 用の証明書の発行例です。

# cd /etc/pki/exampleCA
# ./CA -newreq
Generating a 1024 bit RSA private key
.........++++++
...........................++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase:パスフレーズを入力
Verifying - Enter PEM pass phrase:パスフレーズを入力
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Toshima-ku]:
Organization Name (eg, company) [Example Corp.]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.example.jp
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request is in newreq.pem, private key is in newkey.pem

# ./CA -sign
Using configuration from /etc/pki/exampleCA/openssl.cnf
Enter pass phrase for /etc/pki/exampleCA/private/cakey.pem:CAパスフレーズを入力
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 3 (0x3)
(中略)
Certificate is to be certified until Sep 30 07:12:47 2005 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Certificate:
    Data:
        Version: 3 (0x2)
(中略)
Signed certificate is in newcert.pem
# ls newcerts
01.pem  02.pem  03.pem  (←一番大きな値のファイルを探す)
# mv newreq.pem certs/03.pem (←探したファイル名を入れる)
# mv newkey.pem private/03.pem (←探したファイル名を入れる)
# rm newcert.pem
# openssl x509 -in newcerts/03.pem -out www.crt
# openssl rsa -in private/03.pem -out www.key
Enter pass phrase for private/03.pem:パスフレーズを入力

これで、www.example.jp の SSL サーバ証明書ができました。

サーバ証明書ファイル
mod_ssl ディレクティブ ファイル
SSLCertificateFile www.crt
SSLCertificateKeyFile www.key

6. PC へオレオレ認証局証明書をインポート

このまま https://www.example.jp/ へアクセスしても、証明書エラーになってしまいます。
今回構築したルート CA を信頼すると、その CA が署名した www.example.jp も正しい証明書と認識するようになります。

Internet Explorer へ登録する方法を紹介します。Mozilla Firefox 等の場合は、それぞれのソフトウェア内で証明書を登録してください。

  1. コントロールパネル の インターネットオプション を開きます
    • Internet Explorer から、ツール – インターネットオプション を選択しても同じです
  2. コンテンツ タブを開きます
  3. [証明書] ボタンを押下します
  4. [インポート(I)…] ボタンを押下します。ウィザード画面になります。
  5. インポートするファイル名は、cacert.pem の拡張子を .crt へ変えたものです
    • インポートする証明書ファイルは、なるべく安全な手段でコピーしてください
  6. 証明書ストアは、信頼されたルート証明機関 へ登録
  7. セキュリティ警告が表示されたら、よぉく読んでインストールします
    • 警告にあるように大きな効力を持たせるので、十分注意
  8. インポートが成功すると、信頼されたルート証明機関タブを見ると VeriSign などに混じり、Example CA も表示されています。
信頼されたルート証明機関

信頼されたルート証明機関

これでめでたく、https://www.example.jp/ を警告なしに表示することができます。

7. さらなる証明書の力の証明

オレオレ認証局が力を発揮するのは、HTTPS だけではありません。私のところでは下記の用途で使っています。

  1. ウェブサーバ証明書 (HTTPS)
  2. メイルサーバ証明書 (SMTPS, IMAPS, POP3S)
  3. クライアント証明書
    • ウェブ
    • Subversion

SSL あるところ、ほとんどのところで活躍できます。

カテゴリー: サーバー管理 | タグ: , , , | 2020/06/16 更新

スマートフォンアプリで、綺麗な画像を軽くして組み込む方法

ウェブテクノロジ開発部の山崎です。こんにちは。

今回は、スマートフォンアプリ(アンドロイド(Android)アプリ)と、iOSアプリ(iPhoneアプリ/iPadアプリ)で綺麗な画像を軽く扱いたい開発者の方のために、解決策をご紹介いたします。

※ 本エントリーはブログ掲載時点の情報をまとめたものです。将来的に仕様が変更になる可能性もあるのであらかじめご了承ください。

ファイルサイズの制限

さて、スマートフォンアプリでは、アプリケーションのファイルサイズに制限があります。「Android Market」ではアップロード可能なアプリの上限サイズが「50MBまで」と制限されていますし、

Android Market では50MBまで

Android Market では50MBまで

「App Store」では3G回線経由にてダウンロード可能なアプリの上限サイズは「20MBまで」と制限されています。

AppStoreでは20MBまで

AppStoreでは20MBまで

ちなみに、iOSでは、WiFi経由でダウンロード可能なアプリの上限サイズは2GBとのことです。

また、それぞれの端末のメモリストレージの量も現段階では「PCのように豊富にある」「湯水のように使える」とは言えない状況です。「Android Market」や「App Store」の制限もさることながら、アプリケーションは少しでも軽いほうがユーザーに喜ばれるのは確かです。

画像をキレイなまま軽く!

努力してソースコードを短くしてもアプリケーションのサイズが劇的に小さくなることはほとんど無いと言えるでしょう。

アプリケーションの中で大きくサイズを使っているのは「画像データ」なのです。

スマートフォンの画面の解像度は、昔のPCに匹敵するほど大きく(広く)なっています。最近は、WVGA:800×480以上の端末が増えています。この大きさの画像データを複数枚持つだけでアプリの容量はどんどん増えていきます。

画像の数を減らすことなく、アプリの容量を抑えようとして画像データを必要以上に圧縮すると画像内にモスキートノイズが増えてしまい、スマートフォンのキレイで広い画面のメリットを損なう結果になってしまいます。

画像は写真なのか、図表やイラストなのかをチェック!!

写真の画像はJPEG形式が最適です。キレイに小さく圧縮できます。しかし、図表やイラストの画像はJPEG形式で圧縮(保存)するとモスキートノイズだらけのひどい結果になります。

図表の画像を使う場合はPNG形式で圧縮(保存)してください。圧縮には減色で対応するとキレイな画像のまま軽くすることができます。

雑誌やパンフレットのように写真と図表や文字が混在しているような画像はあるか?

写真と図表が混在している画像は、JPEG形式?PNG形式?どちらで保存すればキレイなまま軽くできるでしょうか。

手間を惜しまないのであれば、写真の画像と図表の画像を分離するとよいでしょう。

次の図のように、写真の部分を切り出してJPEG形式で保存し、図表や文字の部分はPNG形式で保存します。そして、表示するときに1つの画像に見えるようにくっつけるわけです。

特にモスキートノイズの入りやすい文字周りはPNG形式で保存するとJPEG形式と同じバイトサイズにまで圧縮しても表示がクッキリとキレイになります。

しかし、この作業。技術や理論が理解できても実際にやってみるととても大変です。

特に、画像の枚数が多かったり、何度も改修がかかるような画像に対してこの作業を手でやるのは・・・コスト的にも品質的にも問題があります。

この作業を確実に全自動で計算&分割&保存してしまうのが「ハイブリッドフォーマット」で画像を保存できる「OPTPiX imesta 7 for Mobile & Social」です。

詳しくは「電子書籍・雑誌やコミックをキレイに!軽く!ハイブリッド画像作成ツール – OPTPiX imesta 7 for Mobile & Social」のページをご覧ください。

サンプルソースコードの提供

「・・・で、そのハイブリッド画像をアプリで表示するには、どうしたらいいの?」

アプリとして動作実績のあるアンドロイド(Android)アプリのサンプルソースコードと、iOSアプリ(iPhoneアプリ/iPadアプリ)のサンプルソースコードともにご用意しています。

「サンプルソースコードを参考にしたい」開発者の方はお問い合わせフォームからお問い合わせください。

カテゴリー: スマートフォン開発 | タグ: , , , , , , , , , , , , | 2020/06/16 更新

複数のMacでiPhone(iOS)アプリの開発を行うときの注意点

ウェブテクノロジ開発部の遠藤です。

先日、Unityを用いたiPhone(以下、iOS)アプリの開発環境を構築する機会がありまして、その過程でちょっとしたトラブルが起こりました。

1. 証明書をきちんと入れたのに認識されない!

その問題とは、1つのライセンスを用いて複数のMacでiOSアプリの開発環境を構築する際に発生するものです。
今回の記事では、この問題の解決方法についてご紹介したいと思います。

2. Xcode のインストール~証明書のインストール

iOSアプリのビルド環境を構築し、iOS実機上で動作検証するにはMacにXcodeをインストールしたあとに、証明書のインストールや認証などいくつかのステップが必要になります。

これらのステップに関する情報は既にネット上で簡単に見つけることができますのでここでは割愛します。

さて、一通りセットアップを終えたところで、いざビルドを試みると、

Xcode could not find a valid private key /
certificate pair for this profile in your keychain.

というエラーが発生しました。

オーガナイザで見たプロビジョニングのStatusには

Valid signing identity not found

とあります。

上記のエラーについて、ネット上でよく書かれているのが、デフォルトのキーチェーンが「ログイン」になっていないため、というものです。

この点については私の環境では問題ありませんでした。

3. 既存の証明書を2台目以降のMacにダウンロードして入れると…

あれこれ悩んでいたところ、問題は私が利用した証明書が、別のMac上で既に作成済みだったものであり、それをAppleの開発サイト経由でダウンロードして取り込んでいたために秘密鍵が含まれておらず、正しく認証することができなかった、ということのようです。

つまり1つのライセンス(Certificate)を用いて複数台のMacで開発を行う場合は、最初に認証したMac上にある秘密鍵が必要になる、ということでした。

このための手順は、“iPhone 証明書 複数台 Mac” といったキーワードで検索すれば先人の方々のお知恵を拝借できるので、ここも割愛させて頂きます。

そのお知恵を借りて早速「iPhone Developer: 名 姓 (HOGEHOGE)」という秘密鍵を一台目のMacから書き出し、2台目のMacに取り込んで見ましたが…

私の環境ではそれでも足りず…

4. 「iPhone Distribution: 会社名」も必要です

結果として、

iPhone Developer: 名 姓 (HOGEHOGE)
iPhone Distribution: 会社名

という2つの証明書ファイルを書き出して、取り込む必要がありました。

※「iPhone Distribution: 会社名」については個人で開発されている方には必要がないものかもしれません。

[ 正しく動作する証明書の例 ]

証明書に関する問題については以上です。

5. Unity からパブリッシュしたプロジェクトでのエラー

iOSアプリに関連してUnityプロジェクトに関しても少々触れたいと思います。

近年話題のマルチプラットフォームのゲームエンジンであるUnity 上でアプリを作成し、iOS 向けにパブリッシュする際にも、設定が正しくないと似たようなエラーが発生します。

「Player Settings…」の「Company Name, Product Name, Bundle Identifier」あたりの内容が、iOS の開発者ページで申請したものと合致していないと、Code Sign errorの類のエラーが発生します。

初めて環境を構築される方は、このあたりもチェックされるとよいと思います。

カテゴリー: 開発・プログラミング | タグ: , , , | 2020/06/16 更新