iOS Apps
拙作のiOSデバイス向けアプリケーションの紹介ページです。
Pictplus
Pictplus
PictplusはiPhone/iPad向けの画像の簡易編集を行うことができるアプリです。
このページでは、iTunes Storeやアプリ内のヘルプで紹介し切れていない使い方を中心に解説します。
(2014/9/30 初版)
Pictplusの特徴
Pictplusはデジタルカメラで撮影したような高画素の画像のプレビュー、および簡単な編集を実現するためのアプリケーションです。
扱う画像にデジタルカメラで撮影した画像を想定に含んでいるため、デジタルカメラの画像をiOSデバイスで直接読み出す手段としてFlashAir™に対応しています。
※FlashAir™は株式会社東芝の商標です。
対応iOSデバイスと扱える画素数
本アプリケーションはiOS5.1.1以降のiOSデバイスで動作することを想定して作成していますが、古いiOSデバイスではハードウェアの制約で動作が重い、正常に動作しないといったことが予想されます。
扱える画像の画素数についても同様で、ハードウェアの制約(メモリおよびGPU)により以下のような目安があります。
iPhone4, iPod touch 4th(A4プロセッサ) およそ1000万画素(ただし長辺4088ピクセルまで)
iPad2, iPad mini, iPod touch 5th(A5プロセッサ、メモリ512Mバイト) およそ2700万画素(ただし長辺8184ピクセルまで)
iPhone4s, iPhone5, iPhone5c, iPad 3rd, iPad 4(A5,A5X,A6,A6Xプロセッサ、メモリ1Gバイト) およそ4500万画素(ただし長辺8184ピクセルまで)
iPhone5s, iPhone6, iPhone6plus, iPad Air, iPad mini retina(A7,A8プロセッサ、メモリ1Gバイト) およそ6000万画素(ただし長辺12276ピクセル、短辺8184ピクセルまで)※なお実際に確認出来ている最大ピクセルサイズは8256×6192(およそ5100万画素)です。
アプリケーションのサイドメニュー＞描画設定＞メモリ不足チェックをONにすることで、上記の画素数を目安にピクセル数を減らして表示します。(一辺のピクセル上限については強制的に適用されます)
この設定をOFFにすると、GPUの許す限り高画素でデコードしようと試みますが、メモリが不足した場合、アプリケーションを強制終了するため、メモリ搭載量が512Mバイト以下のデバイスではONにしたまま使用することをお勧めします。
また、高画素の画像を読み出すと多くの場合メモリを空けるためにバックグラウンドのアプリを終了させます。複数のアプリでの並行作業には向かないため、ご使用の際は他のアプリでの作業を一区切りさせてから本アプリを使用することをお勧めします。
なお、パノラマ画像の場合は、一辺が上記の長辺を超えるピクセル数を表示できる場合があります。
使い方補足
画像選択画面
画像選択画面は使い勝手の向上のため以下のような操作ができるようになっています。
– アルバム選択画面でアルバムをロングタップすると手前に拡大され、この状態で移動させることでアルバムの並び順を入れ替えることが出来ます。
– 画像選択画面でピンチイン/ピンチアウトすることでサムネイルのサイズを変更することが出来ます。このとき、アルバムの画像数が多い場合は操作が重くなるため、画像枚数が少ないアルバムで変更することをお勧めします。
iOS8になってから、カメラロールがなくなりました。そのままではiOSデバイスに格納されているにも関わらず、アプリケーションから選択できない画像が出てきてしまう状況になりました。そのためPictplusでは「全ての画像」という選択肢をアルバム選択画面に設け、選択できない画像がないようにしています。必ずしもベストの方法とは言えないのですが、現時点でよりよい方法が見いだせていないため(カメラロールが復活するのではとわずかばかり期待しているというのもありますが)、現状の動作にてご容赦ください。(このような形に出来ないかというようなリクエストがありましたら、ご連絡いただけるとありがたいです)
色調補正
アプリ内のヘルプにも記述していますが、アイコンをタップすることでスケーラで設定した値がリセットされます。
トーンカーブのピンは最大10まで設定できます。当初バージョン1.3.0であった両端のピンの配置制約は、表現の自由度を上げるため1.4.0で大幅に緩和しています。
トーンカーブ編集画面の下部にある「オート」と「リセット」はヒストグラムの上限、下限設定のためのもので、トーンカーブ用ではありません(トーンカーブのリセットはサイドメニューから行います)。
プリセットエフェクト
ユーザ設定したエフェクトはWindows/Mac用のソフトウェアiTunesから、ファイルとして参照することが出来ます。
接続したiOSデバイスのAPPタブを選択し、ファイル共有からPictplusを選択すると、「custompreset.ini」というファイルが見えると思います。このファイルが設定ファイルになりますので、ここからPCに保存し、別のデバイスに追加することでプリセットの共有が可能です。
URLスキーム
PictPlusはURLスキームに対応しています。クエリを設定することにより、アプリ起動時の動作を指定できます。詳細は以下のリンク先を参考にしてください。
Pictplus対応URLスキーム
URL scheme for Pictplus(English)
ちょっとだけ技術的なこと
このアプリではどんなことをやっているんだろう？と興味をお持ち頂いた方へ
色調補正について
このアプリケーションは、各設定のリセットはあってもアンドゥのような機能がありません。指定したパラメータは設定を行った順番とは関係なく、決まった順序で計算して画像を加工します。
あまりメリットはなさそうですが、数少ないメリットのひとつとして画質劣化を最小限に抑えることが出来ることがあげられます。
逐次的に画像処理を行うものの多くは、処理のたびに256階調の整数に変換していると考えられます。通常、画像処理自体は浮動小数点で行いその時点では比較的精度の高い計算が行われますが、256階調化することでその精度が落ちてしまいます。そのような処理を繰り返し行うとだんだんと画質が落ちていく恐れがあります(こうした画像劣化を抑えるような作りになっているアプリもあるとは思いますが…)。
Pictplusは色調補正を毎回読み出したオリジナルの画像から行うため画像処理のための計算をシャープネスを除き最後まで浮動小数点のままで演算を行います。その結果、加工後の画像の劣化は最小限に抑えられていると考えています。
そこで肝心な順番ですが、以下のような順番で行っています。
1: RGB->YUV変換
2: RG,BG補正
3: 彩度補正
4: YUV->RGB変換
5: コントラスト、ブライトネス、ガンマ補正
6: トーンカーブ
7: モノクローム化
8: ヒストグラム制限
9: シャープネス
シャープネスは一旦画像を確定しないといけないため、その直前で全てのピクセルを一回256階調の整数にしています。
なお、メモリが不足している場合は表示画像はRGBを16ビットで表現するため、256階調ではなくRGBそれぞれ32，64，32階調になります。ただし、これは表示のときのみで画像を保存するときは256階調で行います。
扱えるピクセルサイズについて
扱えるピクセル数は主にメインメモリのサイズ(総画素数)とGPUのスペック(長辺、短辺)によるものです。
本アプリケーションは、画像の表示、加工にOpenGL ES2.0(使える場合は3.0)を使用しています。
OpenGL ES2.0のテクスチャとして画像データを読み込み、シェーダプログラムで画像を加工し画面に出力、またはファイルへの書き出しを行います。
この際、オリジナルの画像に4枚、加工済み画像用に4枚割り当てており、これが1辺の制約になります。
テクスチャ1枚あたりの最大ピクセルサイズはA4プロセッサで2048×2048、A5プロセッサ以降は4096×4096なので、単純にはA4プロセッサで4096×4096、A5プロセッサ以降では8192×8192になるのですが、シャープネスを実現するため隣接する側に4ピクセルのマージンを設けているため、実際のテクスチャサイズから来る制約はそれぞれ4088×4088、8184×8184になります。
なおこれはテクスチャを2×2で並べたケースですが、パノラマ画像のように横に長い画像はテクスチャを4×1に並べるためそれぞれ8168×2048、16360×4096が上限となり、上限を超えるピクセル数の画像を読み込む場合はよりピクセルの再現が出来る方法を選択して読み出します。
また、上記の制約はOpenGL ES2.0のもので、これは最大で扱えるテクスチャ数が8となっていることに由来するものですが、OpenGL ES3.0では最大で扱えるテクスチャ数が16までと拡大されているため、本アプリケーションではOpenGL ES3.0が使用可能と判断できた場合(A7プロセッサ以降)、オリジナル画像、加工済み画像にそれぞれ最大6枚のテクスチャを割り当てるようにしています。
これにより、GPUの制約としてはピクセルサイズ12272×8184まで拡大しています。なお、パノラマは5×1、ピクセルサイズとしては20448×4096を上限にしています。
これによりA7プロセッサ以降では、おそらく現在市場に出ているデジタルカメラが出力する大半の画像をリサイズせずに読み込むことが出来ると考えています。
FlashAir対応
FlashAirから読み出した画像は、デコードが完了したらオリジナルのファイルはアプリケーションとしては保持しておかないため、たとえ無加工のままカメラロールに保存しようとしても、再度エンコードを行った上で保存します。そのため、iOSデバイス本体への単純な転送を目的として使用することには向いていません。あくまで加工する画像の元画像を読み出す一手段としてのFlashAir対応とお考えください。
逆に、数枚の画像をSNSへ上げることを想定する場合には、本アプリのエクスポート機能を使用することでiOSデバイスのストレージを圧迫することなく加工した画像をシームレスにSNSに画像をアップロードすることが出来ます。
PictplusではFlashAir内の画像はDCIMフォルダの下第2階層(一般的にデジタルカメラが画像を保存する階層)までにある画像へのアクセスが可能です。画像選択画面では階層化を解消して日付ソートされた一覧として表示します(通常のアルバムと同じ操作感覚になります)。
なお、ちょっと特殊なサムネイルの読み出しをしているため、画像選択画面ではJpeg以外の一部のRAWファイルのサムネイルも表示できます。また、画像のピクセルサイズも表示します。なお、一部のRAWファイルはサムネイルだけでなく本画像の表示も可能ですがiOSの機能を使用しているだけですので、個別の機種の対応の可否については不明です。
FlashAirは実際のところiOSデバイスとの親和性はあまり良くないように感じます。iOS7になってアプリを中断させることなくWi-FiのON/OFFが切り替えられるようになったことで、アクセスポイントがFlashAirのみの環境では公衆回線との切り替えは容易になったのですが、それでもFlashAirより優先されるアクセスポイントが別にあったりすると設定画面で切り替える必要があるため若干煩わしさが残る感じです。
一つの解決方法として、FlashAirをステーションモードで動作させることが考えられます。このモードは別のアクセスポイントにFlashAirが接続するモードで、FlashAirの接続先をインターネット共有したiOSデバイスやiOSデバイスを接続しているブロードバンドルータに設定しておけば、iOSデバイスのWi-Fi設定を切り替えることなくFlashAirへの接続が可能になります。
ただこのモード、繋がる環境が出来ると煩わしさがなくなり快適なのですが、接続性があまり良くない(FlashAirを搭載しているデバイスとの相性問題が通常のアクセスポイントモードよりも大きいように感じる)うえに、FlashAir自身が能動的に接続処理を行う必要があるモードのため、ひとたび接続できない状況にしてしまうと、カードリーダーとパソコンがないと設定を変更できずWi-Fiが使えなくなる危険をはらんでいます。なかなか難しいこととは思いますが、メーカー様にはステーションモードでも安定した接続が出来るような改善をして頂きたいと思います。
ステーションモードの詳しい話は、FlashAirの開発者向けサイト「FlashAir™ Developers」の上段にあるメニューの
ドキュメント＞チュートリアル＞上級者向けチュートリアル＞ステーションモードの利用設定
に詳細が書かれています。(もしリンクに問題があるようでしたらお手数おかけしますがご指摘ください)
余談ですが、こちらのFlashAir™ Developersのアプリショーケースにて大変ありがたいことに本アプリの紹介をさせて頂いております。拙作以外にもFlashAir対応のアプリが紹介されていますので、FlashAirをご活用されている方は参考にされると良いと思います。
FlashAirに関しては接続に難儀する方が多いように見受けられます。製品の性質上動作状況が目視できないというのもこの製品を使うことを難しくしているようにも思えます。無線機器になれていない方は特にこの製品を扱うのが難しいのではないでしょうか。もしお困りの方がいましたら気軽にご相談ください(といっても解決はお約束できませんが…出来るだけ協力いたします)。
ヒストグラム
Pictplusではヒストグラムは最初の画像の読み出したときに作成します。色調補正のパラメータが変化した際には、画像に対して行う演算とは別にヒストグラムに対しても同じ演算を行うことで動的な変化を実現しています。
このときのヒストグラムデータの持ち方なのですが、通常であればRGBそれぞれの256階調に対応する値を持てば良いのですが、それだけでは前述の「色調補正について」の2，3に該当する、RG,BG変換と彩度補正の変更に対応できません。そのため、本アプリではRGBそれぞれについてRGB自身の256階調だけでなくYUVにおけるY成分256階調も判別できるよう、256×256の二次元配列でヒストグラムのデータを管理しています。単純なRGBだけであれば256x3x(shortで管理することを想定して2バイト)で1.5kバイトで済むところ、本アプリでのヒストグラム用データは256x256x3x2=384Kバイト用意しています。
何とも贅沢なメモリの使い方だと思いますが、ヒストグラムから得られる情報は白飛びや黒飛びを始め正確であればそれなりに色調補正を行う上で有用なデータと考えたため、敢えてメモリサイズを多く取りより正確性の高い状態で色調補正の動的変化に追従できる手段を取りました。
これによりYUVベースでの色調補正にも対応(といってもY成分だけですが)できたわけですが、実は前述の7:モノクローム化以降で破綻が起きています。その前工程である6:トーンカーブを行うことで、Y成分の値が信頼できないものとなってしまうため、それ以降の工程に対応した正確な演算が出来なくなっています。現状ではあまり見苦しくならない範囲でそれらしい計算を行っていますが、トーンカーブにより変更前から大きく色調が変化してしまう場合、ヒストグラムの信頼性は著しく落ちてしまいます。
ヒストグラムの正確性を維持する方法としてもっとも単純な方法としては、色調を変えるたびに画像データから集計し直すという方法がありますが、OpenGL ESのテクスチャデータの読み出しにはオーバーヘッドが大きく、また高画素の画像を読み出している際はそれだけ集計に時間がかかる上に、メモリが少ないiOSデバイスでは表示上の演算では16ビットRGBにスケールダウンして演算しているという致命的な問題を含んでいるため現実的ではありません。
7:モノクローム化のプロセスを前に持ってくることも可能なのですが(1.4.0以前はそうだった)、これを行うと実際に色調補正を行ったときのイメージと期待したイメージの乖離が大きいと判断したため現状のような計算順序になっています。
今後の機能拡張で出来そうなことと出来なさそうなこと(ほとんど出来ないことの言い訳ですが…)
実際にこのアプリを使った方の多くが色調補正を行えるアプリケーションとしては、機能が物足りないと感じているのではないかという自覚は持っています。
とはいえ、実際問題として出来そうなことと出来なさそうなことについては厳然として存在するので、現在の見通しについて記述したいと思います。
・スタンプや文字、フレームといった別レイヤの重ね合わせ
これは現状困難と考えています。方法としては本画像を書き出したテクスチャとスタンプや文字を書き込んだテクスチャを合成するということで実現出来そうですが、前述の通り、テクスチャはGPUの制約上限まで本画像用に割り当ててしまっているため実現は困難と考えています。
・HSV色空間での色調補正、特定の色域のみへの加工
まずこれらの実現の前提として、ヒストグラムの信頼性はRGBとY成分の関係が維持できないと著しく落ちてしまうという問題があります。加工自体はそれほど難しくない算術演算になると思いますので実現困難ということはないですが、ヒストグラムをどこまで諦められるかといったところでしょうか。(まあ、トーンカーブに対応したことである程度あきらめがついていますが…)
・指定した箇所のみへの加工
例えば、指でなぞったところだけに効果を与えるような処理についてですが、これも新たなレイヤを用意できない問題で実現は困難と考えています。
周辺光量の低下を算術的に再現させるような加工であればレイヤは不要で計算だけで可能なため実現は出来るかもしれません。