iPhone 8 Plus をお持ちの方は、Apple が iOS 12.3.2 をリリースして Portrait モードのバグを修正したことに注意しよう。また、Apple TV をお持ちの方には次のことに注意して頂きたい。Home ボタンを押すと Apple TV アプリが開くようになったことが気に入らなければ、簡単な手順でその設定をリセットして、従来通りの働き、つまり Home 画面が開くようにできる。今週は2つの特別記事がある。まず、Adam Engst が TidBITS 読者 George Jedenoff にインタビューする。彼はもうじき 102 歳になろうというのに、ますます元気に活躍している。それから、以前 Apple で Aperture と iPhoto のチームでリーダーとして働いていた Nik Bhatt が、Photos アプリでの非破壊編集の仕組みについて詳しく語る記事を寄稿してくれた。今週注目すべき Mac アプリのリリースは、iMovie 10.1.12、DEVONthink 3.0 Public Beta 3、それに Logic Pro X 10.4.5 だ。
Apple が iOS 12.3.2 をリリースした。iPhone 8 Plus だけでのアップデートで、「一部の iPhone 8 Plus デバイスの“カメラ”でポートレートモードの写真を撮るときに被写界深度エフェクトが適用されない場合がある問題」を解決する。このアップデートにセキュリティ修正は含まれていない。
この 94.5 MB のアップデートは iPhone 8 Plus のみで入手でき、Settings > General > Software Update から、または iTunes を通じてインストールできる。
Apple が最初に第四世代 Apple TV に tvOS 9 を搭載して発表した時、Siri Remote 上にある Home ボタン (TV アイコンのあるもの) を押すと、それは iOS 機器上にあるかの様に働いた - 何処からでも Home 画面に戻してくれた。多くの人がこの振る舞いに慣れたので、Apple が Apple TV アプリを tvOS 10.1 に付け加え、Home ボタンをそれを開くよう再マップした時、それはイライラを募らせるものであった。殆ど Netflix、未だ Apple TV アプリでサポートされていない、しか見ない人達や、ただ単に Apple TV アプリを好きになれない人達にとって、この変更は二重に腹立たしいものであった。
この数年の間に、これについて私に苦情を言ってきた人は数多くいたが、Adam Engst が最近これを腹立たしいと言った時、私は何かを言わなければならないと思った。もし Adam この振る舞いの変更に対しては手早い回避策があることを知らないとしたら、同じ様に知らない人はおそらく他にも沢山いるであろう。回避策は次の様なものである。
Settings > Remotes and Devices に行き、Home Button の項目をハイライトする。デフォルトで、それは Apple TV App に設定されている。
その Home Button 項目をクリックし、Home Screen に変更するだけである。
この設定がなされていれば、Home ボタンを Siri Remote 上で、iPhone の Control Center ウィジェットから、iOS Apple TV Remote アプリで、或いはその他のあなたが設定した如何なるリモコン上で押しても、Apple TV アプリに行く代わりに、Home 画面に戻る。
この設定を変えていなくとも、Menu ボタンを押し続けることで、何時でも Home 画面に戻ることが出来る。
Apple の弁護をすれば、tvOS インターフェースではこの Home ボタンの二通りある振る舞いについてはきちんと記述されているが、Apple が予告なしに変更した機能を取り戻すために Settings アプリを探ってみようなどと誰が考えるであろうか?
最近 TidBITS 会員の一人のログイン問題を手助けしている時、Lauri Reinhardt は興味深いことを知った。その読者は、George Jedenoff という名前の気立ての良い紳士で、102 歳に届こうとしているというのである。米国には 100 歳以上の人は 72,000 人程度いると推定されているが、そうではあっても、101 歳はすごい! この人が乗り越えてきた歴史を想像出来ますか? Lauri がこの事実を伝えてきた時、私は是が非でも George と話をして、彼を、彼の人生をもっと知りらなければと思った。そして彼は快諾してくれた。
George Jedenoff は July 1917 に Petrozavodsk, Russia で、ロシア革命の最中に生まれた。彼の両親はロシア貴族階級の一員で、国中に拡がりつつあった流血の惨事を逃れるため、彼らは、最初は Urals に、次に Siberia に、そして更に Manchuria に移ったが、最終的には米国に移住することとなり、1923 年に Seattle にたどり着いた。1935 年に高校を卒業生代表として終えた後、George は Stanford に入り、1940 年に極めて優秀な成績で卒業、そして 1942 に MBA を Stanford から取得した。
World War II の間、彼は US Navy Reserve の将校として、主に Guam で士官した。戦争から帰還した後、彼は U.S. Steel の子会社である Columbia Steel で、生産技術者として職を得た。George は、会社の中でキャリアの階段を登り、VP of Operations を経た後、最終的には U.S. Steel の子会社である USS Engineers and Consultants の社長に迄昇りつめた。1972 年に、早期退職を選んだ後、Kaiser Steel の社長として迎えられ、その後も再度退職するまで数年間経営顧問として残った。
George: 70 歳になった時、私は、今後年をとっていく間に、脳の老化を防ぐには何らかの頭の体操が必要だと思いました。私は常に技術には興味を持っていたので、コンピュータについて学ぶのも面白いかもと思いました。その様に考えたの私だけではありませんでした - 私の友人の何人かは同じ様に考えましたが、PC を学ぼうとした人達は、かなりの困難に直面しそして諦めてしまいました。多少の研究をし忠告を受けた後、私は Macintosh ならもっと学び易いのではと感じたので、Mac の道を進むことになりました。1987 年頃、私は最初のコンピュータを購入しました、Macintosh Plus です。
Adam: では、最初の Mac Plus を買う前に、技術的前歴があったわけではないのですね?
George: いいえ、私はそれ迄コンピュータを使った経験はありませんでした。私が 1940 年に機械工学で大学を卒業した時、パーソナルコンピュータは無く、私の主な計算機器は Monroe カルキュレータと信頼出来る計算尺 (これは今でも持っています) でした。今では、私は Apple 機器に全面的に依存しています。
状況をはっきりさせるために、まずは一般に写真アプリケーションで非破壊編集がどんな風に働くかを、例として Photos アプリを使って説明しておこう。その後で、Photos アプリの非破壊編集が RAW 画像ファイル、Photos 機能拡張、その他でどのように働くかを詳しく見て行こう。トラブルを起こしやすい点についてもはっきりさせておきたい。
いくつか背景を書いておこう。私は Aperture の主任開発者であったが、その後 Mac 版の Photos の編集エンジンを開発するチームの責任者になった。現在私は独立の開発者として、RAW Power という名前の Photos 機能拡張を開発している。この機能拡張は Photos や Aperture の基盤となっているものと同じ RAW エンジンを使っている。この記事では実例として RAW Power を何度も使うが、他の Photos 機能拡張も同様に動作する。RAW に馴染みがない方のために言い添えれば、私が書いた別の記事が RAW の利点について議論しているし、Apple の新しい HEIF 画像フォーマットについても触れている。
非破壊編集の基礎
たいていのアプリケーションはあなたの書類を直接に変更する。例えば、Microsoft Word で Save を選べば、あなたが施した変更が直接にその書類のファイルに保存され、その過程でそのファイルのそれまであったバージョンは置き換えられてなくなってしまう。画像編集アプリケーションの中にも画像ファイルを直接に変更するものがある。例えば Adobe Photoshop や、Apple の Preview がそのやり方をする。
そのアプリケーションは編集指令を自動的に保存するかもしれないし、あるいはあなたが Done を押すか Save を選ぶかするまで待つかもしれない。あなたの観点からは画像が変更されたように見えているけれども、実は元のファイルは手付かずの状態でそのまま残っている。極めて有用ではあるけれども、この非破壊モデルはユーザーを混乱させることがある。なぜなら、他のアプリケーションの挙動に基づいてあなたが予期するものとは違うやり方だからだ。
Photos アプリは、編集指令を元のファイルとは別の場所に保存するとともに、編集結果を含んだフルサイズの JPEG (それに加えて小さなサムネイル画像) を生成する。(Photos はすべてのファイルタイプから、例えば RAW からも、また Apple の新しい HEIC ファイルからも、常に JPEG を作る。Mac 版の Photos の Info 枠を使ってそのファイルタイプを知ることはできない。そこには元のファイルのファイルタイプが示されるだけだからだ。) そして、編集作業が終われば、ディスク上に次のものが保存される:
皮肉なことに、非破壊編集が存在する理由の一つは、RAW 画像を直接書き換えて編集することができないからだ。RAW のセンサーデータに好きな編集を勝手に加えることは不可能であり、それらの編集の結果として RAW センサーデータを作成することも不可能だ。(リニア化された DNG を作成することは可能だが、リニア化 DNG は RAW 画像ではない。) Photos は元の RAW 画像に決して変更を加えない。
Photos 機能拡張は元の画像を表示でき、以前に施されたすべての編集を削除したり調整したりをその Photos 機能拡張の中でできる。さらに素晴らしいことに、Photos 機能拡張が調整したデータは iCloud Photos を通じて同期されるので、別のデバイス上でその Photos 機能拡張を使って編集作業を続けることもできる。つまり、Mac の上で RAW Power 機能拡張を使って編集してから、RAW Power 機能拡張のある別の Mac 上で、あるいは RAW Power アプリを備えた iOS デバイス上で、非破壊的に編集を続けることができる。
iOS 上でもこのシステムは同様に働くけれども、一つだけ重要な制約がある。iOS 12 の下で Photos 機能拡張に RAW 画像が渡されることはない。画像はすべて、JPEG にレンダリングされてから渡される。だから、iOS 12 では Photos 機能拡張を使って RAW 画像を編集しようとしても無駄だ。わたしは以前にこのバグを正式に報告しておいた。iOS 13 で Apple がこれを修正してくれることを願いたい。
この問題を説明するため、例としてあるユーザーが RAW 画像に Photos の Auto Enhance 機能を使い、その後で RAW Power 機能拡張を使ってトリミングとビネット効果を施したとしてみよう。Photos は優れた自動補正機能を備えているし、Photos 内蔵の Vignette ツールと違って RAW Power の Vignette ツールはビネット効果の中心点を選ぶことができるからだ。
ステップ 1: ユーザーは Auto Enhance ボタンをクリックして、Done をクリックする。さきほど説明した通りに、Photos はフルサイズの JPEG と、調整のパラメータとをライブラリに保存する。(元のファイルは存在しているけれども、隠されている。)
これは RAW に限った注意だが、RAW を最初に Photos で編集してからその後で画像を RAW Power へ、あるいは別の RAW 対応の Photos 機能拡張、例えば DxO OpticsPro などへ送れば、その Photos 機能拡張の中であなたは 12-bit や 14-bit の RAW でなくたった 8-bit の JPEG に作業を施すことになる。その上に、せっかく RAW Power や DxO が提供している RAW 処理の諸機能にもアクセスできなくなる。これほどに重大な画質の劣化は、Photos の中でどんな編集を施しても、それが単なる回転や反転のみだったとしても起こる。
この深刻な問題点は、2 つの RAW 互換な Photos 機能拡張を使いたい場合にもやはり起こる。その場合、どちらの Photos 機能拡張を先に使うべきだろうか? RAW Power には Photos が使っているのと同じエンジンに基づいた強力な RAW 編集コントロールがある。DxO には高品質のレンズ補正機能がある。私の意見では、先に RAW Power を使ってその RAW 専用の編集スライダーを使い、その後で DxO OpticsPro を使うのが良いと思う。DxO のレンズ補正機能は RAW でも JPEG でも動作するからだ。
この機能は、ユーザーが Photoshop や Preview などファイルを直接変更するアプリケーションであって機能拡張を持たないもので編集できるようにという意図で設けられている。しかしながら、ここには画像を編集可能なアプリケーションのすべてが現われるので、意図された使用には意味を成さないようなものまで含まれてしまう。さらに混乱に輪を掛けて、Photos 機能拡張を提供するアプリも、それが (RAW Power と同じように) Photos 外部の画像を編集できるものならばここにリストされる。目立つところに置かれているので、顧客が RAW Power 機能拡張を使う代わりに、Edit With メニューから RAW Power を選んでしまうことがあまりにも容易に起こり得る。けれども、皆さんにはお分かりの通り、機能拡張として使った方がはるかにうまく Photos と統合できる。(単純な修正策として、Photos は Edit With リストから Photos 機能拡張をフィルター分けして除外することができるのではなかろうか。)
Apple は Edit With を破壊的編集をするエディタのためと意図して作ったので、Photos は元の画像を保護する。つまり、元のファイルを送る代わりに、Photos はライブラリの中でそのコピーを作って、そのコピーを外部エディタへ送る。するとそのエディタはそのコピーの方を変更するので、非破壊的挙動が確保されると考えられる。まあ、ある意味ではそうとも言える。外部エディタは破壊的編集をするので、Photos に確保できるのは Revert to Original 機能が使えることだけだ。編集情報は一つとして Photos ライブラリに保存されていない。(なぜならそんなものはどこにもないからだ。) それに、Photos にもその外部エディタにも、ユーザーが後になって編集し直せるものはない。(多少なりとも非破壊的性質を備えたワークフローを作るのは技術的には可能だが、それをするためには編集を別途どこかに保存して自分でそれを管理しなければならない。非常に手間が掛かる上に、非常に間違いを起こしやすい。)
たった今私は Photos がまず元のファイルのコピーを作ると述べたが、厳密に言えばそれは正しくない。もしも元のファイルが RAW ならば、Photos はその代わりに TIFF を送る。なぜか? それは、行き先のエディタが変更可能なファイルを送る必要があるからだ。でも、さきほども述べたように、RAW は編集したり書き直したりできない。それに加えて、すべてのエディタが RAW に対応している訳ではない。
結果として、Edit With は RAW 編集のためには特に悪い選択肢だ。私は顧客たちから、なぜ RAW Power で RAW を編集できないのかという質問を数多く受け取ってきた。その理由はたいていの場合、その顧客が RAW Power 機能拡張を使わずに Edit With から RAW Power を選んでいたからだった。外部のアプリが Photos ライブラリの中を探し回って RAW を見つけるという手段も可能ではあろうけれど、そんなやり方はあまりにも怪しげでどうにもお勧めできない。(いずれにせよサンドボックス化されたアプリにそんなことはできない。)
独自の編集ツールに加えて、Photos はクリーンな機能拡張インターフェイスを提供して、非破壊的な編集と、iCloud を通じた同期を提供している。そこにはいくらかの欠点もあり、複数エディタ、書き出し、Edit With 機能などもその欠点に含まれる。けれども、少し修正を加えることによって、Apple は Photos の中の非破壊的なワークフローを、画質の面でも分かりやすさの面でも、大幅に改善することができるだろう。その目標に向けて、私は自分の提案を添えてバグ報告を Apple に送っておいた。macOS と iOS 双方の Photos アプリの将来のリリースで、何らかの改善が実現されることを心から願いたい。
Nik Bhatt はかつて Apple で Senior Director of Engineering を務め、数年間にわたって Aperture と iPhoto のエンジニアリングチームを率いていた。その後、彼は Apple の写真アプリケーションのための画像化チーム、具体的には Core Image と Apple の RAW Camera ライブラリを担当するチームを率いた。そして現在の彼は、Mac と iOS の双方で高度な写真編集をするアプリ、 RAW Power の開発をしている。
Apple が Logic Pro X 10.4.5 をリリースして、最大 56 個のスレッドに対応することにより来たるべき Mac Pro 用にパフォーマンスの最適化を施した。(2019 年 6 月 3 日の記事“新型 Mac Pro と Pro Display XDR、強力なパワーを高い価格で提供”参照。) このプロフェッショナル向けオーディオアプリはまた、トラックとチャンネルの最大数を引き上げ (ステレオ・オーディオ・チャンネル・ストリップ、ソフトウェア音源チャンネル・ストリップ、オグジュアリー・チャンネル・ストリップ、外部 MIDI トラックがそれぞれ 1000 個まで、チャンネルストリップあたりのセンドが 12 個まで)、DeEsser 2 プラグインを更新してオーディオトラックの歯擦音を低減するためのオプションをより多く提供し、Loop Browser でループタイプによるフィルタを適用できるようにすると共に複数のループをまとめてプロジェクト内にドラッグ&ドロップできるようにし、いくつかのクラッシュを解消し、大規模なセッションでの作業時に Mixer と Event List の応答性を向上させている。(Mac App Store から新規購入 $199.99、無料アップデート、1.5 GB、リリースノート、macOS 10.13.6+)
WWDC が終わった今、皆さんは Catalyst や SwiftUI といった新しい業界用語に当惑した気持ちでいるかもしれない。Macworld の記事で Jason Snell が、これらのテクノロジーが何をするものであり、それらが何を意味するかを説明する。要約すれば、Catalyst は Apple のフレームワークで、開発者が既存の iOS アプリを手軽に Mac に持ち込めるようにするものだ。結果として、利用できる Mac アプリの数が急増することだろう。(ここでの大きな問題はそれらが本当にネイティブな Mac アプリの見栄えと感触を備えるかどうかだが、それは開発者次第だ。) Catalyst は何年も前からコードネーム "Marzipan" として噂されてきたが、Apple アプリの真の未来は SwiftUI にある。こちらはまったく新しい、Swift に基づくテクノロジーであって、開発者たちがアプリをデザインする方法を根底から変えるものとなり、一つのアプリで Apple のすべてのプラットフォームで動作するものを簡単に作成できるようにする。過去に Apple が越えてきた移行、例えば PowerPC から Intel へ、Classic Mac OS から Mac OS X への移行と同様に、最初のうちは Catalyst に多くの努力が注がれるだろうが、新規のアプリや、完全に書き換えで作られようとするアプリでは、次第に SwiftUI を使うようになって行くだろう。
Apple のソフトウェア・エンジニアリング担当上級副社長 Craig Federighi が、AppStories に出演して Federico Viticci と対談し、iPadOS、Shortcuts、Catalyst、SwiftUI について議論した。
Apple の Mac Pro 製品マネージャ Doug Brooks が Mac Power Users で、Stephen Hackett と David Sparks と共に語り合った。
John Gruber がホストを務める The Talk Show のライブ番組に、Craig Federighi と、製品マーケティング担当副社長 Greg Joswiak が出演した。
Vector の Rene Ritchie が、Apple の Director of Global Accessibility Policy & Initiatives である Sarah Herrlinger にインタビューし、また Apple のソフトウェア担当副社長 Bud Tribble にもインタビューした。
Sarah Herrlinger と、Apple Accessibility エヴァンジェリストの Dean Hudson が、AppleVis に出演した。
私たちの友人 Steven Aquino が、Accessible で Sarah Herrlinger にインタビューした。.