Thoughtful, detailed coverage of everything Apple for 29 years
前週号 | 日本語版ホーム | 次週号

#1469: 写真の非破壊編集を解説、101 歳の TidBITS 読者、Apple TV Home ボタンのヒント、iOS 12.3.2

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 だ。

Josh Centers  訳: Mark Nagata   

Apple、iOS 12.3.2 をリリース、iPhone 8 Plus の Portrait Mode バグを修正

Apple が iOS 12.3.2 をリリースした。iPhone 8 Plus だけでのアップデートで、「一部の iPhone 8 Plus デバイスの“カメラ”でポートレートモードの写真を撮るときに被写界深度エフェクトが適用されない場合がある問題」を解決する。このアップデートにセキュリティ修正は含まれていない。

iOS 12.3.2 リリースノート

この 94.5 MB のアップデートは iPhone 8 Plus のみで入手でき、Settings > General > Software Update から、または iTunes を通じてインストールできる。

討論に参加

Josh Centers  訳: 亀岡孝仁  

TipBITS: Apple TV の Home ボタンを元に戻す

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 に設定されている。

tvOS set to use the Home button for the Apple TV app

その Home Button 項目をクリックし、Home Screen に変更するだけである。

The Home button set to go to the Home screen

この設定がなされていれば、Home ボタンを Siri Remote 上で、iPhone の Control Center ウィジェットから、iOS Apple TV Remote アプリで、或いはその他のあなたが設定した如何なるリモコン上で押しても、Apple TV アプリに行く代わりに、Home 画面に戻る。

この設定を変えていなくとも、Menu ボタンを押し続けることで、何時でも Home 画面に戻ることが出来る。

Apple の弁護をすれば、tvOS インターフェースではこの Home ボタンの二通りある振る舞いについてはきちんと記述されているが、Apple が予告なしに変更した機能を取り戻すために Settings アプリを探ってみようなどと誰が考えるであろうか?

討論に参加

Adam Engst  訳: 亀岡孝仁  

George Jedenoff: 101 歳の TidBITS 読者

最近 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 の社長として迎えられ、その後も再度退職するまで数年間経営顧問として残った。


Adam: George, あなたの話は素晴らしい - あなたはまだ幼児だったことは理解するが、ロシア革命から逃れたと言える人で今日まで健在な人は何人いるのでしょうね? 所で、技術との出会いは何処でしたか? あなたにとってのビッグアイアン (大きな鉄の塊) は、実際の鉄ではなく、初期のメインフレームではなかったのかと想像するのですが?

George: 70 歳になった時、私は、今後年をとっていく間に、脳の老化を防ぐには何らかの頭の体操が必要だと思いました。私は常に技術には興味を持っていたので、コンピュータについて学ぶのも面白いかもと思いました。その様に考えたの私だけではありませんでした - 私の友人の何人かは同じ様に考えましたが、PC を学ぼうとした人達は、かなりの困難に直面しそして諦めてしまいました。多少の研究をし忠告を受けた後、私は Macintosh ならもっと学び易いのではと感じたので、Mac の道を進むことになりました。1987 年頃、私は最初のコンピュータを購入しました、Macintosh Plus です。

Adam: では、最初の Mac Plus を買う前に、技術的前歴があったわけではないのですね?

George: いいえ、私はそれ迄コンピュータを使った経験はありませんでした。私が 1940 年に機械工学で大学を卒業した時、パーソナルコンピュータは無く、私の主な計算機器は Monroe カルキュレータと信頼出来る計算尺 (これは今でも持っています) でした。今では、私は Apple 機器に全面的に依存しています。

Adam: 70 代になって、パーソナルコンピュータを習おうとするのはとても印象的ですね - 私の知っているその年代の人の多くは、その様な複雑な課題に挑戦しようとはしません。

George: 簡単な時ばかりではありませんでした。難しさにイライラしないかと問う人もいます。私は次の様に答えます、"ええ、でもコンピュータは私がそのために買ったことをしてくれる - それは私に考えさせてくれる。"

Adam: では、何時頃から TidBITS を読み始めましたか?

George: 私の隣人がその Web サイトを、10 年か 15 年前に教えてくれて、私は TidBITS からの情報が、有益で役に立つと思いました。

Adam: ありがとうございます - その様に言って頂いてとても嬉しいです。今お使いの Apple 機器は何ですか? Mac だけじゃなくて iPhone や iPad にも手を伸ばしていますか?

George: その通り。私は今 27-inch iMac Retina ディスプレイモデル、新型 iPad Pro, そして iPhone XS Max を持っています。

Adam: 素晴らしい組み合わせですね。それらを何に使っていますか?

George: 他の人と同様、私は何時も iPhone を身につけて持っており、それを電話通話に、テキストメッセージに、写真を撮るのに、そしてメールを読むのに使っています。残念ながら、私の視力はあまり良くないので、iPhone XS Max の画面ででも大変なので、写真や他の情報は iPad Pro で見るようにしています。もっと大変な仕事は大型の 27-inch スクリーンを持つ iMac でやります。これらの機器を、多くの友人と連絡を密にし、オンラインで買い物をし、大切な書類を書く等々のために使っています。事実、私は最近、私の家族と近しい友人のために、私の家族と私の人生の歴史を 232 ページの原稿にまとめたばかりです。私は現在、もっと公のバージョンを書いている所で、オンラインで出版したいと思っています。

Adam: 自伝を自己出版するやり方について、もし私がお手伝いできることがあるのであれば、どうか遠慮なさらずに言って頂きたいし、それを拝見するのを楽しみにしています。そして、もしその中で TidBITS のことにも触れていただけるのであれば、とても嬉しいです。

George: ありがたいお申し出と個人的にお会い出来たことに感謝申し上げます。どうか、良い仕事をお続け下さい。

Adam: ありがとうございます! この記事をお読みの皆さんのために、最後にもう一つ。George は毎日 45-60 分間の運動をしており、熱烈なスキーヤーでもある。言うまでもないが、それは彼の年齢からいえば、極めて珍しい存在であり、Ski Utah はこれ迄6年間に亘って彼のビデオを撮り続けてきた。と言うわけで、彼の最も新しいビデオへのリンクと、その終りの引用を皆さんにお届けする:

毎日を大切に過ごす、そして何か建設的なことをする。そして、より多くのことが出来れば、とりわけ他の人達のために出来れば、より幸せでもある。

以上です - 私が年を経たら、私は George の様でありたい。

討論に参加

Nik Bhatt  訳: Mark Nagata   

Mac 用と iOS 用 Photos における非破壊編集の裏と表

Photos (写真) アプリのほとんど魔法のような機能の一つは、そしてこれはその前任たる iPhoto アプリにもあったのだが、写真を編集する際にどの編集作業も 非破壊的 であることが保証され、いつでも元のバージョンに戻れるという点だ。そうは言っても、非破壊編集にはいくらかの混乱が伴うものだ。とりわけ、RAW 画像で作業する人や、Photos 機能拡張を使って編集をする人は注意する必要がある。

状況をはっきりさせるために、まずは一般に写真アプリケーションで非破壊編集がどんな風に働くかを、例として 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 がそのやり方をする。

それとは対照的に、大多数の写真編集アプリケーションは非破壊的に動作し、元の写真を決して変更しない。その種のアプリケーションは元の写真のコピーをメモリ内部で作成し、それに対して編集を施して、調整を加えられた画像のリアルタイムのプレビューを作り出す。

A basic example of non-destructive editing.

そのアプリケーションは編集指令を自動的に保存するかもしれないし、あるいはあなたが Done を押すか Save を選ぶかするまで待つかもしれない。あなたの観点からは画像が変更されたように見えているけれども、実は元のファイルは手付かずの状態でそのまま残っている。極めて有用ではあるけれども、この非破壊モデルはユーザーを混乱させることがある。なぜなら、他のアプリケーションの挙動に基づいてあなたが予期するものとは違うやり方だからだ。

Photos アプリは、編集指令を元のファイルとは別の場所に保存するとともに、編集結果を含んだフルサイズの JPEG (それに加えて小さなサムネイル画像) を生成する。(Photos はすべてのファイルタイプから、例えば RAW からも、また Apple の新しい HEIC ファイルからも、常に JPEG を作る。Mac 版の Photos の Info 枠を使ってそのファイルタイプを知ることはできない。そこには元のファイルのファイルタイプが示されるだけだからだ。) そして、編集作業が終われば、ディスク上に次のものが保存される:

What's stored in non-destructive editing.

フルサイズの JPEG はディスク上に個別のファイルとして保存される。小さなサムネイルは、複数個のサムネイルを一度に収納する「コンテナ」ファイルの中に保存される。編集指令は写真ライブラリのデータベースの中に、その画像についての他の情報と共に保存される。

もしも後日あなたがその画像に対する編集作業を続ければ、Photos は元のファイルと編集指令の双方をロードし直し、それらを組み合わせて調整後の画像を表示する。

編集モードの外では、Photos は元の写真を表示しないで隠し、その代わりにアプリケーションの中のすべての場所で、フルサイズの JPEG か、または小さなサムネイルのいずれかを表示する。それが正しいことであるのは明らかだが、元のファイルを隠すことで、元のファイルが変更されてしまったのではないかという感じが強調されてしまう。これこそ、人々が混乱する主たる原因だ。多くのユーザーたちが私に、画像を編集する前にコピーまたは複製してから作業する方法を教えて欲しいと尋ねてきた。彼らは Photos の手品に見事に誤魔化されて、画像に調整を施す前に元の画像を保存しておかなければならないと思っているのだ。(人によっては調整前と調整後のコピーを作っておいて両者を並べて見比べたいという理由で複製を作ることもあるが、そういう人たちは比較的少数派だ。)

皮肉なことに、非破壊編集が存在する理由の一つは、RAW 画像を直接書き換えて編集することができないからだ。RAW のセンサーデータに好きな編集を勝手に加えることは不可能であり、それらの編集の結果として RAW センサーデータを作成することも不可能だ。(リニア化された DNG を作成することは可能だが、リニア化 DNG は RAW 画像ではない。) Photos は元の RAW 画像に決して変更を加えない。

いったいなぜわざわざそんな手間をかけるのか? なぜなら、非破壊編集は次の三つの重要な機能を提供するからだ:

  1. 即座に元の画像を表示して A/B 比較ができるようにする
  2. 画像の編集やサムネイルをすべて削除して、元の画像に戻すことができる
  3. 画質を一切損なうことなく個々の編集を修正したり削除したりできる

Photos は常に、編集指令をライブラリのデータベースの中に保存する。他のアプリケーションは、データベースを使うこともあるし、別途に「サイドカーファイル」を (多くの場合同じファイル名に異なるファイル拡張子を付けて) 作り、その中に保存することもある。例えば IMG_0005.JPG という名前のファイルのために、そのアプリケーションは IMG_0005.xmp とか IMG_0005.dat とかいう名前のサイドカーファイルを同じディレクトリの中に作る。サンドボックス化されたアプリは、サイドカーを他の場所に保存することもある。

サイドカーは汎用目的のファイルなので、サムネイル画像を含むこともあるし、その他のメタデータ、例えばランク付けなどを含むこともある。アプリケーションによってはサイドカー情報を元のファイルの中に保存することもある。これは、大多数の画像フォーマットがピクセル情報そのものを変更することなく、また他のアプリケーションがその元のピクセルデータを読み取れる機能を損なうことなく、いろいろなデータを保存することもできるようになっているからだ。このことにより編集の情報が元のファイルと共に置かれるけれども、もしもそのアプリケーションが追加データを正しく挿入できなかった場合、ファイルが破損したりデータ喪失が起こったりする可能性がある。それに加えて、必ずしもすべてのアプリケーションが元のファイルに自分のサイドカーデータを書き込む際に他のアプリケーションから来たサードカーデータを正しく保持するとは限らない。これらの理由で、多くの写真家たちはサイドカーが元のファイルとは別に保存される方を好む。

Photos 機能拡張

私たちは大体において非破壊編集を Photos のネイティブな編集ツールとの関連で考えているけれども、非破壊編集が使われるのは必ずしもそこだけとは限らない。開発者たちは「Photos 機能拡張」と呼ばれるタイプのプラグインを作成してさらなる編集機能を Photos に追加することができる。Photos 機能拡張にアクセスするには、写真の編集を始めてから、ウィンドウの一番上にある Extensions (...) ボタンをクリックする。

Accessing Photos extensions

Photos 機能拡張は Photos の編集インターフェイスに追加のスライダーを挿入したりせず、その代わりに標準的な Photos のツールを丸ごと取り替える。

Photos extension replacing the default controls

Photos の通常の編集方法と同じく、Photos 機能拡張でも一度に一つの画像しか編集できない。10 枚の写真のホワイトバランスをバッチ修正しながら Photos 機能拡張を使うことはできない。Photos 機能拡張を一つ選ぶと、Photos はその機能拡張を開いて、元のファイルをそれに送る:

How Photos sends images to extensions

Photos 機能拡張のインターフェイスの中で Save Changes ボタンをクリックすると、その Photos 機能拡張はその編集指令とフルサイズの JPEG とを Photos に送り返す。次の図のような感じだ:

The extension passing the JPEG and instructions back to Photos

その結果、Photos 機能拡張は Photos がそれ自身の画像エディタで使うものと同一の非破壊編集のシステムに参加することになる。Photos はその JPEG と、機能拡張から送られた編集指令とをライブラリの中に保存する。それから、Photos はそのフルサイズ JPEG をもとにサムネイル画像を作成して、元のファイルを隠す。

もしもあなたがその画像をもう一度その同じ Photos 機能拡張で編集しようと決めたなら、Photos はその元の画像と、その機能拡張から来た編集指令とをその機能拡張に送る。ここでも、それは Photos が内臓の編集システムに対してするのと同じ作業だ。

Editing an edited image with the same extension it was edited with

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 がこれを修正してくれることを願いたい。

香油の中の一匹の蝿

このやり方は、たった一つのアプリケーションまたは Photos 機能拡張が一つの画像を編集している限り、スムーズにうまく働く。けれども二つのエディタがそこに入り込んでくるやいなや、物事が停滞し始める。その理由は、Photos アプリが一つの画像に対してたった一つのエディタのためにしか調整情報を保存できないからだ。第二のエディタから来た変更が保存されるやいなや、最初のエディタからの編集指令は捨て去られ、もはや取り戻すことができない! 画像のデータそのものは保持されているけれども、最初のエディタで変更を施せる選択肢は消え失せる。これもまた、顧客たちの混乱の大きな原因の一つだ。

この問題を説明するため、例としてあるユーザーが RAW 画像に Photos の Auto Enhance 機能を使い、その後で RAW Power 機能拡張を使ってトリミングとビネット効果を施したとしてみよう。Photos は優れた自動補正機能を備えているし、Photos 内蔵の Vignette ツールと違って RAW Power の Vignette ツールはビネット効果の中心点を選ぶことができるからだ。

ステップ 1: ユーザーは Auto Enhance ボタンをクリックして、Done をクリックする。さきほど説明した通りに、Photos はフルサイズの JPEG と、調整のパラメータとをライブラリに保存する。(元のファイルは存在しているけれども、隠されている。)

How Photos modifies an image

ステップ 2: ユーザーは Photos 機能拡張メニューから RAW Power を選ぶ。ここで、前に挙げた例と食い違う点に初めて遭遇する。つまり、Photos は (元の RAW 画像でなく) フルサイズの JPEG を Photos 機能拡張に送る。Photos が元の画像でなく JPEG を送るのは、ユーザーが Photos 機能拡張の中で自動補正を受けた後の画像が見えると期待するからだ。調整を受けていない元の画像では具合が悪い。Apple は調整用の内部的フォーマットを公開していないし、調整用にそのコードへのアクセスを提供してもいないので、Photos 機能拡張が Photos の施した自動補正を自分で施せる手段は何もない。このことは逆向きにも成立する。つまり、もしもユーザーが画像をまず Photos 機能拡張で編集してから、その後で Photos の中でさらなる編集を施せば、Photos ではレンダリング後の JPEG を対象に編集作業をすることになる。Photos には、他社の機能拡張が元のファイルに施した編集を自分で施せる手段がない。

ステップ 3: ユーザーは RAW Power の中で Crop と Vignette を適用し、それから Save Changes をクリックする。すると、Photos library には次のものが保存される:

Losing edit data in Photos

Photos が自らが施した調整データを捨ててしまったことに注目しよう! すべてが問題ないように見えるかもしれないが、Photos で編集した情報は実際失われてしまっており、ユーザーがそのことを知らされる機会はない。ユーザーは Photos 機能拡張へ戻ってトリミングやビネット効果を (あるいはその機能拡張でできる他のどんなことでも) 調整できるけれども、前のステップへ戻って Photos の中でスライダーを微調整することはできない。その上、ユーザーは Photos 機能拡張を呼び出したより以前に施したことをやり直しすることもできない。唯一残された選択肢は Revert to Original で元の写真に戻ることしかない。それ以外に Apple による調整で戻せるものは残っていないからだ。

もう一つ注意したいのは、この時点でライブラリの中に 2 個の JPEG が保存されていることだ。片方は Photos が作ったもの、もう片方は Photos 機能拡張が作ったものだ。これは、非破壊編集の外見だけでもせめて残しておくために必要なことだ。最初の JPEG は Photos が Auto Enhance のステップの結果として作成し Photos 機能拡張へ手渡したものだ。思い出して頂きたいが、ユーザーが同じエディタを使って画像を再編集するためには、そのエディタが「出発点の画像」と共に編集指令を受け取る必要がある。今の例の場合、その「出発点の画像」は Auto Enhance が適用された後に作成された JPEG だ。そこには 2 個の JPEG が存在しているけれども、ユーザーインターフェイスの中で見えるのは最後の JPEG だけだ。自動補正の後の JPEG は隠されていて、Photos 機能拡張を使って再編集される場合に備えてライブラリの中に保存されている。

「でも、」とあなたはおっしゃるだろう。「Photos で編集してから、Photos 機能拡張を使い、それから Photos に戻って編集を続けることもできていますよ」と。それはその通りだが、あなたは Photos 機能拡張から送り返された JPEG に調整を加えているのであって、最初に Photos で RAW ファイルに施した調整は既に失われている。極端な例として編集ごの画像を白黒写真に変換したところを想像してみれば、保存されるものはこうなる:

Losing edit data with a Photos extension

言い換えれば、これは RAW Power による調整の上に Photos による調整を積み重ねた例だ。(その過程で、RAW Power による調整のデータは失われる。)

また、このような調整データの喪失は先に Photos 機能拡張で編集してからその後で Photos で編集しても起こるし、Photos での編集をせずに 2 つの Photos 機能拡張で編集をしても起こることに注意しよう。順序は関係ない。同じ画像に 2 つ以上のエディタを使えばそうなるということだ。

これは 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 でも動作するからだ。

私としては、画質の劣化や調整データの喪失が起ころうとする度に Photos がユーザーに対して警告するようになることを望みたい。Photo 機能拡張がユーザーに対してこの問題の警告を出すのは、Photos 機能拡張が Photos とコミュニケーションするやり方を考えれば不可能だ。Photos 機能拡張からは、RAW 形式の元の画像があるか否かさえも知ることができない。これは、Photos にしか提供できない種類の警告だ。もしもこの問題があなたに起こったならば (もしも手遅れでないうちにそうと気付けば)、あなたは次のようにすべきだ:

  1. Photos 機能拡張での編集をキャンセルし、
  2. Photos で Revert to Original コマンドを使い、
  3. 機能拡張に入り直す。

私が何から TIFF を書き出したって?

編集を受けた RAW を後世に残すために保存しようとする際、写真家たちは 16-bit の TIFF を好む。その理由は、編集を受けた RAW の豊かさのすべてを普遍的な画像フォーマットの中に保存できるからだ。最良の結果を得るためには、書き出す行き先のファイルフォーマットと等しいかまたはそれ以上の画質の画像フォーマットから書き出しをするべきだ。RAW は TIFF より優れており、TIFF は JPEG より優れている。従って、RAW を Photos で編集してその後で TIFF に書き出せば、非常に良い結果が得られる。なぜなら、Photos は RAW をロードし直し、その RAW に編集指令を適用して、それから TIFF を生成するからだ。

けれども Photos 機能拡張ではそれと同じことが言えない。さきほども説明したように、機能拡張が Photos へ送り返すのは JPEG にならざるを得ないのであって、TIFF ではない。機能拡張を使って編集した画像を Photos を使って書き出せば、Photos はそのソースに JPEG を使う。繰り返して言おう。あなたが手にする 16-bit TIFF は、8-bit にレンダリングされた JPEG をもとに作られるのであって、元の画像に調整を加えたものではない。(Photos が自らのツールを使って調整を加えた場合には元の画像が使われるのだが。) つまり、Photos は行き先よりも画質の劣るソースを使って書き出しをするのであって、あなたが書き出した画像は基本的に JPEG の圧縮を解いて TIFF に直したものに過ぎない。

このことには (満足はいかないけれども) もっともな理由がある。Photos が機能拡張に対してレンダリングされたフルサイズの TIFF を請求することができないのは、その機能拡張がその時点で既にアンインストールされてしまっているかもしれないし、あるいはその画像がその機能拡張の存在しないデバイス上に同期されたものかもしれないからだ。これもまた、Photos がユーザーに警告すべき状況の一つだ。自分の 16-bit TIFF が 8-bit JPEG から作られていることの理由を何も説明せずともユーザーが理解してくれると想定するのは理不尽というものだろう。

賢者への一言を: 機能拡張を使って画像を編集したならば、Photos から TIFF を書き出すことにもはや意味はない。私は RAW Power の中に「TIFF を書き出す」ボタンを追加せざるを得なかったけれども、ある意味それは正気とは言えないが必要悪であった。

複数個のエディタへの対応も、TIFF への書き出しも、もしも機能拡張が TIFF を Photos へ返すことができるようになれば、そして Photos が TIFF を機能拡張へ送ることができるようになれば、大幅に改善されるに違いない。そういう機能は、最高の画質を望むユーザーたちのために機能拡張に搭載できるオプトインの機能として実装されるべきものかもしれない。

"Edit With" (外部編集) で編集してはいけない

Photos には、サードパーティのエディタとやり取りするためのもう一つ別の方法があり、不幸なことにそれは Image メニューの目立つところに置かれているにもかかわらず、ほとんどの場合品質の劣る結果しかもたらさない。

The Edit With menu.

この機能は、ユーザーが 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 を見つけるという手段も可能ではあろうけれど、そんなやり方はあまりにも怪しげでどうにもお勧めできない。(いずれにせよサンドボックス化されたアプリにそんなことはできない。)

結論: 非破壊編集は、たいていの場合、素晴らしい

非破壊編集は、瞬時の復帰、A/B 比較、編集処理へのきめ細かいコントロールなど、さまざまの価値ある機能をユーザーに提供する。しかしながら、非破壊編集はその目的のために非常に違ったインターフェイスの枠組みを作り上げており、アプリケーションはまだ十分にそれをユーザーに伝えられていない。非破壊の錯覚は多くの写真家たちに対して、元の写真が単に隠されているだけにもかかわらず変更されていると思ってしまう結果に陥らせている。するとその写真家たちは、元の画像を守ろうとして不必要に画像を複製するようになる。賢くコピーすればディスクにかかる費用を最小限に抑えることはできるけれども、その種の複製作業は複雑化を引き起こし、グリッドに余計な画像が並ぶことで視覚的雑音を生む。少しばかりの教育によって、大切な写真を編集する際の顧客の緊張を和らげることができるのではないだろうか。

独自の編集ツールに加えて、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 の開発をしている。

討論に参加

TidBITS 監視リスト: Mac アプリのアップデート

訳: Mark Nagata   

iMovie 10.1.12

iMovie 10.1.12

Apple が iMovie 10.1.12 をリリースして、iMovie Theater でのビデオ共有への対応を削除した。iMovie Theater を Apple TV や iOS デバイスで視聴するには、今後はムービーや予告編を iCloud Photos に保存する必要がある。(詳しくは Apple サポートページを参照。) iMovie Theater にビデオがある場合、Window > Go to Theater から Theater ウィンドウにアクセスできるようになる。今回のリリースではまた、非常に低い解像度で互換性のないメディアファイルを変換する際の品質を改善し、iOS 用 iMovie プロジェクトを読み込む際の互換性を改善している。(Mac App Store から無料、2.2 GB, macOS 10.13.6+)

iMovie 10.1.12 の使用体験を話し合おう

DEVONthink 3.0 Public Beta 3

DEVONthink 3.0 Public Beta 3

DEVONtechnologies が DEVONthink 3 の三番目の公開ベータ版をリリースして、今回もまた驚くほど多くの改善やバグ修正を施した。(詳細は PDF 版と EPUB 版の 説明書にのみ書かれている。ブログ記事に要点が紹介されている。) このリリースでは注釈のワークフローを改善し、コンテクストメニューにコマンドを追加し、読み終えた書類をリーディングリストから直接ゴミ箱へ移動できるようにし、メインウィンドウを開き直した際に View/Edit 枠が復元されなかったバグを修正し、ウェブサーバの信頼性を高め、新規タグの名前を "New Tag" に変更している。

DEVONthink 3.0 の公開ベータ版は無料で利用できるが、公開ベータテスト期間が終わった後は有効なライセンス鍵がなければ使えなくなる。また電子メールのアーカイブへのアクセスや、試用上限を超えるテキスト認識機能は、ライセンス鍵がなければ使えない。(DEVONthink 新規購入 $99、DEVONthink Pro 新規購入 $199、DEVONthink Server 新規購入 $499、TidBITS 会員にはそれぞれ 15 パーセント割引、アップグレード価格あり、89.2 MB、macOS 10.11+)

DEVONthink 3.0 Public Beta 3 の使用体験を話し合おう

Logic Pro X 10.4.5

Logic Pro X 10.4.5

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+)

Logic Pro X 10.4.5 の使用体験を話し合おう

ExtraBITS

訳: Mark Nagata   

How Catalyst and SwiftUI will Change App Development

Catalyst と SwiftUI はアプリ開発をどう変えるか

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’s 2019 Apple Design Award Winners

Apple の 2019 Apple Design Award 受賞者

WWDC の中で、Apple は毎年恒例の Apple Design Award を 9 つのアプリに与えた。がっかりしたことに、Mac 専用のアプリは一つも受賞しなかった。受賞アプリのうち Mac 互換なものはただ一つ、The Voxel Agents によるマルチ・プラットフォームのゲーム The Gardens Between であった。この冷遇はどうやら意図的なものとみえて、Apple のプレスリリースには「Apple は昨日、Apple Design Awards の授与式を行い、iOS 開発者 9 社の卓越した技巧、技術的な業績、ユーザーインターフェイス、アプリケーションデザインを讃えました」と書かれている。選ばれたアプリのうち 5 つはゲームで、残りの 4 つはそれぞれ実用的な機能を提供するものであった。Moleskin の Flow はノート取りのアプリ、Pixelmator Photo は iPad 用の写真編集アプリ、Butterfly iQ は超音波検査用アプリ、HomeCourt は拡張現実を使ったバスケットボール練習用アプリだ。

元記事を読む | 討論に参加

A Plethora of WWDC Podcasts for Your Listening Pleasure

聴いて楽しい WWDC 関係のポッドキャストがたくさん

Apple は、WWDC の最中に Apple メディアのコミュニティーに対して次第に敏感に反応するようになってきている。そして今年、Apple はかつてなくそれを押し進めたとみえて、Apple 従業員たちが Apple に集中した 6 つのポッドキャストに出演して語った

  • 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 にインタビューした。.

MacStories の記事に、さらに詳しい内容と、聴取方法の選択肢が載っている。

元記事を読む | 討論に参加