Scriptの癖

前回掲載したスクリプト文は、AfterEffectsのスクリプトフォルダに毎度添付される「Change Render Locations」を改造して、自分たちの使いやすいスクリプトに変えているのですが、大幅に書き換えているとは言え、スクリプトの作者さん(2バイト文字への配慮がないあたり、1バイト文字圏の外人さんでしょう)の癖をいくつか残した文になっています。なんとなくながめていて、ふと、気がつきました。

 

私はインクリメント、デクリメントは、例えば変数「i」ならば、

 

i++

 

とやるのですが、原文の作者さんは、

 

++i

 

‥‥と書いております。私は不勉強なもので、演算子を前に持ってきても良いことを、今さら気がついた次第です。ちなみに、前置と後置では若干動作が異なるとのことですので、私は使い慣れた(=期待する動作をする)後置「i++」を今後も使うと思います。

 

ちなみに、私が昔から慣れ親しんで今でも現役のAppleScriptでは、このような演算子はなく、

 

set i to i+1

 

‥‥と書きます。解りやすいですけど、文字数は多い‥‥ですネ。なので、AppleScriptのスクリプト文は長くなりがちです。

 

私がJavaScriptベースのAdobe Script(正式名は不明です...)を使っていて便利だなと思うのは、null, 0, undefined以外の有効な値はtrue扱いになる仕様です。いちいち「trueかfalseか」を演算しなくても良いので、文がすっきりします。

 

もし変数「newLocation」の中身がFileやFolderのObjectでなく、nullだった場合(ユーザがファイル・フォルダ選択をキャンセルした場合など)は、

 

if (newLocation != null) {...

 

とやらずとも、

 

if (newLocation) {...

 

‥‥と書けば期待した動作になります。

 

私がその昔覚え始めて体に馴染んだいくつかの言語は、ifで取り扱う値は真偽値オンリーでしたので、JavaScriptの有効な値ならtrue、それ以外はfalseという仕様になかなか馴染めませんでした。‥‥が、慣れちゃえば楽です。考え方としても「有効な値だったら、スクリプトが進行する」ので、いちいち「真偽のまな板にのせる必要がない」ので手順がちょっとだけ省けます。その「ちょっと」が数百数千行になると、結構活きてきます。

 

でもまあ、結局はスクリプトを書いている人の癖みたいなものですね。

 

私は、本文から呼び出すファンクションやサブルーチンは、下に纏める習慣があるのですが、これも癖でしょうね。「main()」や「on run」で本文を纏めたいのも、私の癖というか、好みですし。

 

スクリプトやプログラムの文って、当人の考え方の手順、要素の整理の仕方を、如実に反映して興味深いです。他人のスクリプト文やプログラムコードを読むと、目から鱗が落ちることも多いです。

 

 


undefined

今日、以前作ったAfter Effectsのレンダーキュー周りのスクリプトを修正していたのですが、レンダーキュー項目って、selected、つまり「現在、選択状態」のプロパティがないことに気付きました。‥‥というか、何年ぶりかで思い出しました。

 

こんな感じでレンダーキュー項目を選択しておいて‥‥

 

 

「selected」属性を、alertで表示するようにスクリプト文で実行すると、

 

alert(app.project.renderQueue.item(1).selected);

 

返ってくるのは‥‥

 

 

 

あれ‥‥?

 

「あんでふぁいんど」。

 

ん? ‥‥‥trueは返ってこないのか。

 

itemクラスを継承してるんじゃないのか。RenderQueueItemは。

 

Layerとかは選択状態を取得できるんですけどね。‥‥RenderQueueItemはダメだったっけか。

 

 

そもそもなぜ、レンダーキューの選択状態を取得したいかというと‥‥

 

300〜500個のRenderQueueItemがある場合、任意の150〜250個だけレンダリング先を一気に変えたいからです。要は、大量処理です。

 

例えば、下図の選択状態のレンダーキューだけ、レンダリング先を変更したい‥‥わけです。(見やすいように、数を少なくしています)

 

 

After Effectsは謎の多い仕様で、レンダリング設定や出力モジュールは複数選択で一気に設定を変更できますが、レンダリング先だけは一気に書き換わってくれません。複数選択しようが、全選択しようが、最初にクリックした項目だけです。

 

そればかりか、何度書き出し先を指定しても、「前回指定した場所を覚えてくれない」という状態が続いています。どのバージョンからだったかな‥‥。

 

 

‥‥以前は、覚えてくれてたんだけどなあ‥‥。環境設定か何かを削除すれば良いのかな‥‥。でもそれだと、他の環境設定も消失するから嫌なんだよね‥‥。

 

まあ、図のように、5個だけなら、手作業で再指定しても良いんですが、これが100個、200個レベルになってくると、もう手作業では無理です。そんな作業にマンパワーを費やすのは、制作費の無駄遣いです。

 

一度のレンダーキューではなく、数回にプロジェクトを分ければ、レンダリング先をプロジェクト単位で一括変更もできます。After Effectsに昔から添付してあるサンプルスクリプトの「Change Render Locations」をプロジェクト毎に実行すれば良いです。‥‥ただ、サンプルプロジェクトはレンダーキュー項目ごとにalertが表示される「お試し仕様」なので、実際に使用する場合はalertの行をコメントアウトして使うのが良いです。100個あったら、100回アラートウィンドウが出てOK(=リターンキー入力)するのはアホすぎるもんね。

 

でも、そうじゃなくて、いちいちプロジェクトを分けるなんていう手間なしに、レンダーキュー項目から任意の項目のレンダリング先だけをちゃちゃっと変更したい場合は、そもそもどうやって「任意の項目」を取り出せば良いのか。

 

任意の選択状態を表す「selected」プロパティが、RenderQueueItemでは「undefined」=該当なし・存在しないので、思い描いたスクリプトが書けません。

 

頓挫。

 

でも、簡単に諦めては、様々な大量処理が待ち構えている映像制作の世界では生きていけません。くじけるべからず。

 

要は、任意のレンダーキュー項目をどうやって「スクリプトに選別させるか」を、新たに考えれば良いのです。選択状態が取り出せないのなら、他の方法で、任意の項目を取得すべし。

 

レンダーキューのウィンドウには、各項目ごとに「レンダリング」のチェックボックスがあります。これで「レンダリング先を変更する項目を指定」すればうまくいきそうです。

 

 

各項目の「レンダリング」にチェックが入って待機状態の場合、レンダーキュー項目のstatusが「QUEUED」になります。「RQItemStatus.QUEUED」です。

 

RenderQueueItemのstatusがRQItemStatus.QUEUEDならば、レンダリング先の変更を適用する‥‥というスクリプトにすれば、100個も200個も並んでいるレンダーキューの中から、特定の項目だけレンダリング先の変更が一気に可能になります。

 

チェックボックスをON/OFFするのは、項目を選択しておいてチェックボックスをクリックすれば瞬時に変更可能です。

 

 

「レンダリング」のチェックボックスで変更したい複数項目を切り替えていけば、レンダーキュー項目全てではなく、自分の処理したい項目だけを抽出できます‥‥ので、その通りに、スクリプトを書きます。

 

 

SCRIPTNAME = "レンダリング先を変更";

if (checkRenderQueueItems()) {
    ChangeRenderLocations();
}else{
    alert('アクティブな項目が0です¥nレンダリング先を変更するレンダーキュー項目をアクティブにして下さい.¥n¥n(レンダーキューウィンドウの「レンダリング」チェックボックスを確認してください.)', SCRIPTNAME);
}

function checkRenderQueueItems(){
    for (i = 1; i <= app.project.renderQueue.numItems; ++i) {
        if (app.project.renderQueue.item(i).status == RQItemStatus.QUEUED){return true;}
    }
    return false;
}
    
function ChangeRenderLocations(){
    var iCount=0;
    var newLocation = Folder.selectDialog("新しい保存先を指定してください");
        
    if (newLocation) {
        app.beginUndoGroup(SCRIPTNAME);
            
        for (i = 1; i <= app.project.renderQueue.numItems; ++i) {
            curItem = app.project.renderQueue.item(i);
                
            if (curItem.status == RQItemStatus.QUEUED) {
                for (j = 1; j <= curItem.numOutputModules; ++j) {
                    var curOM = curItem.outputModule(j);
                    var oldLocation = curOM.file;
                    curOM.file = new File(newLocation.fullName+"/" + oldLocation.name);
                    iCount++;
                }
            }
        }
            
        alert(iCount+"項目を、新しいレンダリング先に変更しました.¥n"+newLocation.fullName+"/", SCRIPTNAME);
            
        app.endUndoGroup();
    }
}

 

 

‥‥という感じのスクリプト文で「やりたいことが解決」しました。

 

もし、うっかり、レンダーキュー項目のチェックボックスが全て外れていたり、レンダリング済みの項目だけで有効な項目が無い場合は、以下のようなアラートでそっと教えてくれます。

 

 

自分で使う際にやらかしてしまいそうなミスに対し、事前に手を打っておくのも、自作するスクリプトの利点ですね。

 

実は、このスクリプト文の原型は、前述したAfter Effectsサンプルスクリプトの「Change Render Locations」なんですが、そうこうして自分らの使いやすいように改造してたら、ほとんど原型がなくなってしまいました。

 

ちなみに、オリジナルの「ChangeRenderLocations」は、toString() でパスを文字列化しておりましたが、JavaScript Tools Guide を読むと、「fullName」で「The full path name for the referenced file in URI notation. 」が取得できますので、変更しています。

 

toString() だとさ‥‥、日本語(2バイト文字)が文字化けするんよ。

 

 

別に取扱上で実害は無いんですが、文字化けは気持ち悪いので、fullName に変更すると、

 

 

‥‥のように、文字化けせずに済みます。

 

どんなに日本語を使おうが、文字化けなし。

 

 

 

もし、こうしたスクリプトを自分たちで作れない場合、何らかの手間を割いて、余計に時間を消費して、対応することになります。

 

言わば、After Effectsを使う上でスクリプトやエクスプレッションは、CQBのハンドガンやアーミーナイフのような「自分を身を守る、サバイバルツール」のようなものです。

 

身につけておいた方が格段に有利ですし、もしグループならば、誰か一人は使えた方が良いです。

 

次世代のコンピュータベースの制作現場を形成したいのなら、コンピュータを効率的に使う知識は、草の根から必須だと思います。次世代知識に聖域なし‥‥です。誰もが知り得るべき基本事項でしょう。実際に自分がコードを書かなくても、今までと違う何ができるか‥‥を知ることが重要です。

 

制作システムと同調すれば、ファイル名(=コンポ名)から識別してサーバの各所に自動でレンダリング先を割り当てるようなことも可能でしょう。システムと各個人のリソースは、有効にバインドしていくのが肝要です。‥‥もちろん、各個人のテリトリーを保護・保証した上で‥‥です。

 

After Effectsの「瑣末な事務作業」なんて、本来、アニメーター・コンポジターとしては最小限に労力を抑えるべき要素ですからね。

 

 


クリスタのiOS版。

でましたね。

 

今までのProcreate一択だった状態から、今後はProcreateとクリスタの二強時代(=わたし的にです)が訪れる予感。

 

今日インストールしたばかりなので、細かいところは判りませんが、レイテンシーなどは特に気にならず、基本性能は上々みたいです。デフォルトで選択されている鉛筆ツールの描き味は、何のストレスも感じず、画具そのものと言った感触です。

 

パームリジェクションも、何も設定してませんが良好です。私は左利きなので、いずれインターフェイスの位置は調整するとは思いますが、ツールの上においても誤反応することはなかったです。

 

Procreate同様に、人差し指を消しゴムに割り当てる機能もあり、ジェスチャーの使い勝手も今日的で良好です。人差し指1本のスワイプの時は消しゴム、長押し後はスポイト、画面のスクロールは二本指のスワイプなど、その他にも細かくジェスチャーを使い分けられそうです。iOSはこれがないと、iOSの意味がないですもんね。

 

ちょっと使っただけでも、以前に比べてかなりの創作の幅が広がる予感をひしひしと感じます。

 

ただ、インターフェイスは、昔からのクリスタユーザを意識してか、全くiOSっぽさは無いです。良くも悪くも、MacかWindowsのサブモニタみたいです。旧態依然としたインターフェイスデザインは、今やiOS慣れしたわたし的には少々違和感もあります。

 

上と横に配置されたツールウィンドウの影響で、描画面は狭めです。これは13インチのMSPを弄った時にも感じた狭さで、もうちょっとだけでもiOSの利点をインターフェイスに活かせなかったものか、少し残念にも思いますが、もしかしたら「広く使うための工夫」があるかも知れないので、今後の使い込みで印象が変わるとも思います。機能が豊富ですと、簡単には評価できないですもんね。

 

月額980円の設定は、全然OKです。仕事でお金を稼ぐ原動力となるツールですから、そのくらいは支払って然るべし‥‥です。

 

ただ、未成年の少年少女には厳しくなり始める金額かも知れません。Mac/Windows版の「月額500円」は相当、エデュケーショナル的に威力がありましたもんね。

 

 

つい先日、とうとう自宅のiMac 5Kから、板タブを外してしまいました。最近はほとんど使っていないですし、描きは全てiPad Proでやって、「共有」機能=Air DropとかiCloudで受け渡しすれば済むので、Intuosの出番は全く無くなって久しいのです。

 

そんな矢先、クリスタのiOS版のリリースも相まって、もはや液タブでも繋がない限り、Mac/Windowsでペンタブを使うことはないでしょう。

 

iPad Proオンリーでの描き作業になれちゃうと、MacやWindowsのマシンを絵を描くためにいちいち起動するのが、「大仰」過ぎるような気持ちになってきます。「パソコン」に束縛されずに絵を描く感覚は、慣れてしまうと離れられません。パソコンの存在が重くてな‥‥。

 

クリスタまでiOSで使えるようになった今、自宅のiMac 5Kの使命は、母艦としての機能と、4K60pの映像制作、コンポジターとしての作業がメインとなります。パソコンで絵を描くのは、よほどの緊急対応でもない限り、しないと思います。

 

まずは、クリスタのiOS版リリースを素直に喜ぶことにします。

 


DNxHR!

DNxHRのコーデックを色々と検証していて、特に画質面で驚くことがありました。DNxHRは、素で、トーンジャンプを抑制する「仕込み」をしているようです。‥‥本当のところはわからないので、推測ですが。

 

普通、トーンジャンプ(バンディング、バンド、マッハバンドなどとも呼ばれる)を抑制するのは、コンポジターの役割です。ディザ拡散のような状態を作り出して、単純な画素構成を回避し、トーンジャンプ=画面のシマシマを未然に防ぐわけです。

 

単純なベタ面に単純なグラデーションを加味すると、状況によっては盛大にトーンジャンプが発生しますが、画素の成り立ちを複雑にすれば、ベタ面もグラデーションも複雑化し、単純パターンのトーンジャンプを抑制できるのです。

 

単純なベタ面に単純なグラデーション。‥‥つまり、今の日本のアニメ業界製の映像が陥りやすい画素構成ですが、各社各人、色々と工夫してトーンジャンプを防いでいます。

 

しかし、DNxHRはコーデック自体が、その演算の中で画素の値を拡散し、画素構成を複雑化させて、レンダリングするようです。

 

コーデック自体が値を拡散させてレンダリングする事例は、今は消え去った「Animo」くらいなもので、他には聞いたことがありません。

 

どのくらい拡散させているかというと、8bit換算で「+1」の値です。例えば、[127,127,127]というRGBデータの場合、DNxHRでレンダリングすると、[128,127,128], [127,127,128], [128,127,127]のように、値をRGB別々に(つまり色相方向に)拡散させて出力します。

 

*DNxHRの出力した、RGB値127のSolidLayerの1600%拡大図です。圧縮前提のJPEGだと意味がないので、可逆圧縮のPNGです。値拡散の様子は、ブラウザの表示だと判りにくいかも知れません。

*ブラウザの都合で、PNG画像は表示されない場合がありますので、ご容赦ください。

 

 

この効果は大きく、16bitですらトーンジャンプが発生していた状況でも、この画素値拡散の演算によって、シマシマ模様を抑制しています。

 

下図は、わずかなグラデーションを、DNxHDで出力したものです。よく見ると、横縞=トーンジャンプが見えます。

 

*誇張すれば縞模様が見えやすくなりますが、誇張したら検証にならないので、微妙なままイジってません。

 

同じグラデーションをDNxHRで出力すると、横縞は見えません。かわりに、マダラ模様が見えますが、図は1600%拡大なので、実寸では気になりません。

 

 

代償として、データ容量はかなり大きくなります。同じ内容(=画素値拡散を施した)ProRes4444のムービーファイルの2倍の容量になったのを確認しました。ProRes4444でも「容量がデカい」と言われてましたが、その2倍ですから、ファイルサーバの容量も相当喰うようになるはずです。

 

また、計算速度も相応に時間がかかるようになると思われます。まだ様々な条件の映像を実地で計測していないので、何とも言えませんが、画素1つずつを拡散させると、結構時間を喰うようになります。

 

でもまあ、そうした負荷の甲斐あって、絵そのものはかなり綺麗です。取り急ぎ実施したテスト結果から、DNxHDの画質を大きく改善しているのが読み取れます。DNxHDはかなり心許無い画質でしたが、DNxHRなら「大丈夫かも」知れません(現在のところ、予測しかできないので、「かも」です)。

 

 

ちなみに、DNxHRの出力する画素値拡散と同等の出力は、After Effects上で再現できます。‥‥なので、DNxHRを選ばずとも、綺麗なコーデックを選択すれば(ProRes4444とかCineFormとか)、DNxHRと同等のトーンジャンプ抑制機能は付加できます。

 

‥‥判りにくいですが、数はAfter Effects上でDNxHRの画素値拡散を真似てみたものです。

 

http://img-cdn.jg.jugem.jp/fd7/2754123/20171113_5292358.png

 

 

今回の参考画像は、どれも「微妙な差」ではありますが、こうした基礎技術を現場が有していないと、特に2Dアニメーションのような手作りの映像は、簡単に品質が上下してしまいます。

 

DNxHRのような「トーンジャンプ消し」効能があるコーデックを実際に使うかはともかくとしても、コンピュータの画像を主として扱うアニメーション映像制作にとっては、画素レベルのクオリティコントロールは、この先もずっとつきまとう命題ですネ。

 

 


DNxHR、CC2018

私は特に何の縛りもない場合は、ProRes4444コーデックを標準として使用しています。なぜかと言うと、画質の劣化が極めて微小で、高い品質で映像を保存できるからです。

 

そんなこともあり、しばらくAvidのDNxHDコーデックを使っていませんでしたが、最近、必要に迫られて書き出そうとしたら、NG。

 

CC2017以降のmacOS環境では、以前のDNxHDプリセットが使えなくなっていました。

 

DNxHDは、新世代のDNxHRを含む「DNxHD/DNxHR」にまとめられ、プリセットの内容も大きく様変わりしております。

 

*数年前に作ったOutputModuleの内容が、CC2017以降では強制的に「DNxHR / DNxHD」「8bit」(数百万色)に変更されておりました。

 

*コーデック設定はグレーアウト状態で、以前のプリセットを選択することすらできません。

 

 

では、昔のバージョンのDNxHDコーデックをインストールすれば良い(要は、/Library/QuickTimeのコンポーネントですね)と思ったりもしますが、After EffectsでのDNxHRコンポーネント(正式名称やからくりは不明です)を優先するらしく、/Library/QuickTime以下に昔のコンポーネントがあっても、After Effects上からは呼び出すことができません。

 

まあ、2020年を間近に控えた今のご時世、DNxHDに固執する必要もなく、上位互換でDNxHRにすればいいじゃん‥‥と気を取り直し、DNxHRの10bitの「444」や「HQX」を選んでみましたが、After Effects上で肝心の「数兆色」を選択できません。

 

 

 

以前、ProRes4444XQを出力しようとした際も、After Effectsの旧バージョンは似たようなことがあり、新バージョンで解決したことがありました。‥‥ので、After Effectsを最新版の2018にしてみました。

 

 

AEPファイルのアイコンが変わった‥‥。わたし的には、「怪電波を発信している初期のアイコン」が好きなんですけどね‥‥。

 

まあ、それはいいとして、問題は「数兆色」です。

 

で、CC2018で再度確認してみたんですけど、「数百万色」しか選択できません。改善されておりません。‥‥がっかり。

 

 

でもまあ、それでもダメ元で「DNxHR」の10bitコーデックを選択し「数百万色」で出力して、After Effectsに読み込んでみると、

 

 

‥‥なんだ、「数兆色」でレンダリングできているじゃないか。

 

‥‥って、今までの、「数兆色を選択して出力しないと、ファイルの色深度が10bitにならない」という操作上の縛りは何だったんじゃい!‥‥と思うことしきり。

 

まあ、10bitって言えば、数百万色でも数兆色でもなく、数億色(RGBだと1024の3乗)なので、どちらに丸めるか‥‥だけの話なんでしょうかね。

 

しかし、今までのAfter Effectsの慣用とは違うので混乱します。今まで「数億色」を出力する場合は、「数兆色」を選択しないとNGだったのにね‥‥。

 

でもまあ、いいや。After Effects上から、DNxHRで10bit出力できることは判りました。

 

 

20年前にも同じようなことで混乱した記憶があります。コンピュータの世界って、いつまで経っても同じですよね。「進歩」はするけど、「調和」はしない。

 

考えても見れば、多くの会社が存在して、多くの思惑が錯綜して、きっちり足並みが揃うわけもないのです。もし、コンピュータの世界に完全な調和と整合性が実現できる日は、人間社会から争いごと=戦争がなくなる日でしょうから、そんな日は永遠に来るわけもなく‥‥。

 

まあ‥‥人間社会が滅亡するまで、コンピュータの世界では「xxの環境だと、ooは動作しない」なんて言い続けるんでしょうね。

 

つまりは、整合性が実現する日を待つのでなく、非整合な現実の中で、どのようにして自分の欲する結果物を獲得するかを考えれば良いのです。環境が揃うのを待ってたら、何も成し遂げられずに一生を終えることでしょう。

 

 

ちなみに、After EffectsのCC2018。

 

色々と小変更は加えられましたが、特筆すべき大きな機能拡大はないです。2Dアニメーションの視点からだと、ほとんど何も変わっていない‥‥と言えます。

 

 

より一層、新時代の映像フォーマットに馴染んできた印象はありますが、まだまだ今後の発展の余地は残しています。

 

パスの頂点をエクスプレッションから個別にアクセスできるようになった‥‥とか、結構、地味な機能が多いです。でもまあ、After Effectsは、「基本的に変わらないこと」が魅力でもあるので、わたし的はCCの年貢を払いつつ、徐々に4K時代に対応していくさまを見守りたいと思います。

 

私がAfter Effectsを使い始めたのは、1997年の年明けからですから、もう20年経過したことになります。その頃から基本的な操作系は変わらず、他のいくつものコンポジットソフトウェアの盛衰を横目で見つつ、今まで生き延びてきたのは、それはそれで凄いことです。

 

操作系がノード連結型だろうがレイヤー積載型だろうが、結局は、出来上がった絵・映像が全てだもんね。

 

After Effectsはいざとなれば、スクリプト文で細かく制御できるし、プリコンポーズとコラップストランスフォームを駆使すれば能率的な運用も可能だし、時流に日和ることなく、いつまでも「映像専門分野」のソフトで在れば良いと思っています。

 

 


EPAを食わせろ

私はよく「オリーブの丘」や「サイゼリヤ」に行きます。理由は、好みの料理が安いからです。

 

サイゼリヤのオリーブオイルに慣れると、国産メーカーの苦味のないオリーブオイルなど腑抜けで食った気がしないほどです。オリーブオイルは、あの苦味というか、エグさが美味しいと思うのです。

 

しかし、オリーブオイルと言っても、サイゼリヤのペペロンチーノはあまり好きではないです。アミノ酸的な旨味を後から追加したような、軟弱なペペロンチーノは私は好かんのです。ペペロンチーノは、パスタと茹で汁とオリーブオイルと唐辛子とニンニク、そして塩だけで味をまとめるのが、最高に好きです。ダシ成分など添加しないでよろしい。

 

一方、アラビアータやアマトリチャーナ、甘エビのサラダは、よく食べます。激安299円のミラノ風ドリアも美味しいですよね。

 

ただ、オリーブの丘も、サイゼリヤも、残念なのは「青い魚」系の料理が無いことです。

 

今の私に必要なEPAやDHAをほとんど摂れません。

 

イワシのカルパッチョをメニューに加えてくれたら、W(ダブル)で頼んじゃうんですけどね。(=だから、そう言う食いかた自体がNGなんだって)

 

 

日本のコンビニも、ファミレスも、基本的にEPAとDHAは摂りにくい商品ラインアップなんですよね。まあ、コンビニの場合、さば缶を買えば良い‥‥というのがありますが。

 

私は、以前、アホのように大量に「鯖缶」大人買いを敢行したことがありまして、今でもかなりの数がストックしてあります。鯖缶のEPA含有量は、1700mgも含んでいるらしいです。サプリが1日3粒で300mgとか可愛いレベルなのに比べて‥‥です。

 

鯖缶なら、少ない分量で、大量のEPAとDHAが摂取できます。

 

 

しかし。

 

鯖缶は飽きる。

 

食い続けると、正直、飽きる。

 

一時期、視界に入れたく無いほど、鯖缶にうんざりしました。‥‥なんていいますか、まさにモンティパイソンの「Spam」のように。

 

自分で大量に買い込んでて、何ですが。

 

 

鯖缶のあの油っぽい生臭さにやられるんでしょうか。まあ、私も極端過ぎたのだと思います。同僚たちに「そんな食い方したら、すぐに嫌になるよ」と言われた、その通りになりました。

 

しかし鯖缶のEPAとDHAの段違いの含有量は非常に魅力ではあります。鯖缶に比べたら、毎日サプリ3粒とか失笑ものです。‥‥ゆえに、最近、また少しずつ食べ始めました。

 

 

でもねえ、よく行くファミレスにイワシやサバやサンマの洋風メニューがあれば、最高なんですけどね。EPAを日々美味しく摂りたいと願うばかりです。

 

鯖缶もなあ‥‥、水煮とか味噌煮だけでなく、オリーブオイルと胡椒で漬け込んだ缶詰とかあればいいのにな‥‥。酢漬けとかはダメなんかな‥‥、さっぱりして美味しそうなんだけど‥‥、あ、缶的にダメなのか、酢は。

 

*ちなみに、アマゾンで鯖缶を調べたら、オリーブオイル漬けとかあったんですが、非常に高い(一缶400円前後)ので買う気にはなれませんでした。私はこと「兵站と補給」に関しては金に糸目をつけるほうですので。

 

 


3桁fps

最近までAfter Effectsのコンポジションのフレームレート欄は、「99」で打ち止め、つまり100以上のfpsは入力不可だったのですが、最新のAfter Effectsでは「120fps」がプリセットの中に含まれており、いよいよAfter Effectsもフレームレート3桁の時代に突入した‥‥みたいです。

 

いつ対応したんだろ?

 

でもまあ、ようやく対応してくれましたか。

 

ちなみに、240を入力してもちゃんと受け付けてくれますし、タイムラインも0〜239で1秒になってくれます。

 

 

 

 

「240fps」なんて使わねーよ‥‥なんて言う人は、狭い視野の人

 

最終出力だけが映像出力の全てじゃないじゃん?

 

24fps作品だからって、素材まで24fpsだけで作るのは‥‥、って、まあいいか、それは。

 

フレームレートって、色々と使い道があるんですよ。

 

 

After Effectsが3桁fpsに対応してくれたおかげで、かなり融通の利く運用が可能になります。

 

目下は60fpsがメインですが、120や240fpsも可能になったことで、運用次第でマシンの負担を軽減できます。‥‥まあその代わり、HDDの容量は一段と逼迫するでしょうが、HDDも今や3TBで8000円の時代ですから、2000年前後に比べればむしろ楽です。

 

 

ソフトウェアを含め、作業環境や世の中が徐々に4K8K時代に移行してくれて、嬉しい限りです。

 

最近、UHD BDの案件にいくつか立会いましたが、フィルム作品でも4Kの効果は絶大ですよ。

 

フィルムに記録されたセル画と背景美術のディテールが、生々しく4Kテレビで描写されます。

 

フィルム作品を本当に楽しみたいのなら、今後発売されるであろう、ちゃんと再スキャンした4Kのタイトルをお勧めします。旧作でも4K&HDRの効果は目に見えて素晴らしく、フィルムのポテンシャルを映し出すには、2K程度&SDR程度では全くの役不足だったんだ‥‥と実感した次第です。

 

HDRの効果も素晴らしく、2KとSDRの膜の向こうのぼやけて見えていたフィルムの真のエッジと発色が、4KとHDRで蘇ります。

 

 


APFSとAppleScriptその後

APFSでフォーマットされたディスク上で、AppleScriptのFinder操作でエラーがでる件、どうも再現性があやふやで困っております。

 

他の用事でiMac 5Kの電源を落として、改めて起動したら、APFSのディスク上でも正常にAppleScriptでFinderアイテム(フォルダやファイルなど)が扱えるようになりました。

 

ぎゃふん。

 

全てにおいてAPFSとAppleScriptの組み合わせがNGなわけぢゃ‥‥なさそうです。

 

APFSにおいて、AppleScript上で扱うFinder Itemに必ずしも障害が出るわけではなく、正常に動くこともままあるようです。なので、ネットを検索しても障害例が出てこなかったのかも知れません。High SierraでAppleScriptを使う人って、あまり多くはなさそうですもんね‥‥。

 

うーむ。スクリーンショットを撮っておけばよかったかな。

 

しかしまあ、再起動すれば治る時点で、どのあたりの不具合かはなんとなく見えてきました。私のiMac 5Kは、それこそ1年中電源が入りっぱなし(システムアップデートの再起動や不在時のスリープはしてます)なので、なんとなく思い当たるフシはあります。

 

でもまあ、再起動で治るって‥‥一番、嫌なパターンですね。

 

いずれまた、同じ障害が発生するかも知れませんので、その時はもう少し色々と試して検証してみたいと思います。例えば、Finderの強制終了(Finderだけを再起動)で治るのか‥‥とか。

 

今回のAppleScriptの件に限らず、新しいOSとファイルシステムを使う以上、どうしても負のリスクはつきまとうものですから、障害が立ちふさがった時は慌てず回避策や代替案で切り抜けるべし‥‥です。

 

 

 

しかし、APFS。いや‥‥、最近のディスク関連。

 

少々戸惑うことが多くて、例えば「パージ」という仕組みは、ディスクの残り容量がよくわからないことがあります。

 

最近、他のディスクに600GB分のデータを移して、元データを消去したことがありましたが、ディスク容量表示が変化しないことがありました。600GBをゴミ箱に送ってゴミ箱を空にしたのに、消去したはずの600GB分の容量が当該ディスクで増えてくれない‥‥という状況です。

 

「空にしたのに、空になっていない」ような状態ですが、それはどうも「パージ」の機能が作用しているらしいことがわかりました。ゴミ箱を空にした容量と「パージ可能」な容量が一致していたので、判明した次第です。

 

仕組みの細かい点はわかりませんが、ゴミ箱を空にしてもFinderウィンドウの表記や「情報を見る」ウィンドウの表記で容量が回復しないのは、「パージ機能」によって空にしたはずのゴミ箱の内容がプールされているから‥‥みたいです。

 

以下の「ディスクユーティリティ」のスクリーンショットでも、2TBのディスク容量にも関わらず、利用可能が「1.28TB」、使用済みが「1.37」TBで、合計がおよそ2.6TBとなっていますが、パージ可能な容量の0.6TBを差し引けば、ちゃんと2TBになるのです。

 

 

 

うーん、ややこしい。

 

ゴミ箱を空にした後は、その空にした容量分だけ、サクッと容量表記が増えて欲しいですネ。‥‥じゃないと、わかりにくいもんな。

 

 

しかし、Appleの説明もよくわからん。説明文では、クラウドが‥‥とか言ってますが、私の場合はゴミ箱に送ったファイルなので、いまいち要領を得ないです。

 

https://support.apple.com/ja-jp/HT206996

https://support.apple.com/ja-jp/HT202867

 

ただ、「https://support.apple.com/ja-jp/HT206996」の最後に‥‥

 

  • APFS フォーマットのボリュームでファイルを複製した場合、そのファイルがボリューム上の容量を追加で消費することはありません。複製したファイルを削除した場合、その複製ファイルに追加したデータが占めている分の容量だけが解放されます。ファイルを取っておく必要がなくなったら、複製ファイルとオリジナルのファイルを両方とも削除して、そのファイルが消費していた容量をすべて解放できます。

 

‥‥とあるので、このあたりの関連かな‥‥と思います。

 

APFSの「実体をともなわないコピー」が返って裏目に出て、別ディスクに複製したのちに消去したはずのファイルが「パージ可能」なファイルとして存在し続けるのか‥‥、まあ、APFSの仕組みは今後、徐々に作業しながら理解していけば良いかな‥‥と思います。

 


ガセ

iMac Proのことを調べていて、「iMac Pro」と「新しいiMac」はユーザによるメモリ増設不可だ‥‥みたいな記事があって、「え? 嘘?」と思って調べたら、半分は嘘、半分はまだ仕様が公開されていないので謎‥‥でした。ネットには、こういう不確かな情報が溢れかえっているので、最後は自分自身で確認する必要があるのは、昔と何も変わらんですね。

 

iMac Proはまだ発売前ゆえに、細かな仕様が公開されていませんが、背面からみた内部図を見ると「ちょっと面倒そう」な印象は受けます。少なくとも、iMac 5Kの現在の仕様である、スタンドの裏側の蓋を開けて交換するのではなく、大掛かりな分解でスロットにアクセスするように見受けられます。しかしメモリは基板直付けではなく、あくまで交換可能なスロットに装着されているのが、図から読み取れます。

 

*スタンドが手前にあるので、おそらく背面から見た内部図だと予測されますが、‥‥まあ、実品が発売されれば全てがわかるでしょうから、慌てないのが肝要。

 

上図メモリスロットのあたりのiMac Pro背面には蓋・カバー・ハッチらしきモールドは見えないので、これは「地獄のディスプレイ外し」の分解パターンかもしれませんが、なにぶん想像なので、Appleの実品発売開始後に確認するのが賢明ですネ。

 

一方「新しいiMac」とは、2017年6月のイベントでiMac Proと同時に発表され、現在発売中のP3ディスプレイのiMacのことだと思いますが、21.5インチモデルは以前の通りメモリ増設不可ですが、同様に、27インチモデルは以前の通りの仕様のままで、メモリ増設「可能」です。

 

Appleのヘルプにも諸元にも明記されています。

 

https://support.apple.com/ja-jp/HT201191

 

「新しいiMac」になったから、増設不可になったわけではなく、21.5と27インチ、それぞれ以前と同じメモリ増設条件です。

 

4K iMacは交換不可、5K iMacは交換可能。

 

27インチモデルの5K iMacは依然として裏蓋を外せば簡単に増設可能なようですし、アマゾンのユーザレビューでも多数の交換事例が書き込まれています。

 

‥‥なので少々、原文の英文記事および翻訳記事は誤解を生む記事ですね。‥‥つーか、原文記事はタイトルの「RAM in the new 27-inch iMac isn’t upgradeable」から察するに完全に勘違いしている感じですね。

 

まあ、ネットで調べる程度ですぐに判ることなので、チャチャっと調べて解決すれば良いだけのことですネ。勘違いなんて誰にでもありますし、その勘違いがネットを通じて全世界に伝播していく時代でもありますから、その勘違いを全く検証せずに鵜呑みにする側もマズいのです。

 

 


APFSとAppleScript

今日初めて気がついたんですが、どうも、macOSの新しいファイルシステム「APFS」だと、AppleScript上でまともに処理できないっぽい‥‥感じです。

 

ファイル・フォルダの扱いがまともにできないので、ファイルシステム上で何もできません。

 

例えば、APFSのディスク上で何かを選択しておいて、

 

tell application "Finder"

 set theSelection to selection

 set theItem to item 1 of theSelection

 name of theItem

end

 

‥‥なんてやろうものなら、「name of」がひっかかってスクリプトがエラーで停止してしまいます。(正しくは、項目が取得できないので、その項目の名前も取得できない‥‥という連鎖のエラーです)

 

なぜ「name of」がエラーになるのか、何か大ポカをやらかしているのか自分の書き方を疑いましたが、そもそもあまりにも基本的な要素なので疑いようもないのです。AppleScriptの場合、一旦変数に入れてからでないと期待した動作にならないことは昔からありましたが、今回はそういうわけでもないです。

 

試しに他のAPFSではないディスクで試したら、あっさりとエラーなく動作しました。

 

つまり、HFS+上でなら普通に動作しますが、新しいAPFSだとエラーになります。

 

エラー内容も、当該項目のcontainerのcontainer(Finderの場合、containerとは親フォルダを指します)が返ってきたり‥‥と、かなりめちゃくちゃです。

 

theItem as unicode textとか、POSIX path of theItemとかもNG。パスすら取得できんです。

 

つまりitem〜ファイルやフォルダがまともに扱えません。

 

 

どぐあ。

 

ショック。

 

 

私のiMac 5Kは、FusionドライブなのでHFS+のままでセーフ。しかし、外付けのSSDはHigh Sierraのアップデートで自動的にAPFSになるのでNG。APFSに変換したHDDもNG。HFS+のままのHDDはセーフ。

 

 

これ、何時、治るかな。それとも放置かな‥‥。

 

Appleさん。頑張ってください‥‥。

 

 



calendar

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28293031   
<< January 2018 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM