Skip to main content
37 Posts
オブジェクトマスクをカラーモードに適用するとズレる

v27ビルド59を使用しての不具合です。Adobe Stock より次の動画をダウンロードして検証しました。当方の環境では、100%再現します。AdobeStock_305165426.movHappy african woman wear wireless headphones listening to music outdoors on an empty street, relaxing after work, funny funky mixed race girl feel stress free relief, funny dancing. Full length マシン環境Windows11 25H2Core i7-9700KGeForce GTX 1660 SUPER 当該動画をプロジェエクトに読み込んで、右クリック→最適なシーケンスを作成します。編集モードにて速度・デュレーションで速度を200%にします。オブジェクトマスクを選択し、人物を選択してマスクを作成し、クリップ全体にトラッキングします。この時点では、プログラムモニタの人物の表示とマスク範囲は一致しています。オブジェクトマスクをかけた段階プロパティパネルにて割り当てられていない当該マスクを選択し、右クリック→エフェクトマスクに変更→カラーエフェクト:色調補正1を選択し、カラーモードにマスクを掛けると、プログラムパネルの映像と、マスク範囲が次のようにズレます。カラーモードに適用後マスクをかけた瞬間に表示が変わって、映像だけがずいぶん先のフレームのものが表示されているように見えます。必要であれば、当該プロジェクトファイルのアップロードも可能です。

UXP API(premierepro)で Motion の Position(PointF型)パラメータに新しい値を書き込むと 32767 に破損する

環境Premiere Pro 25.6.2 および 26.5.0(両方で再現、Windows 11) @adobe/premierepro UXPプラグインAPI経由症状 Motionコンポーネントの「位置」(Position)パラメータに ComponentParam.createSetValueAction() で新しい値を書き込むと、書き込んだ側の座標が意図した数値ではなく 32767(符号付き16bit整数の最大値)になります。数値1つだけのパラメータ(スケール等)では同じ書き込み経路で正常に動作するため、PointF型(2値)パラメータに限定した不具合と考えられます。再現手順const ppro = require("premierepro");const project = await ppro.Project.getActiveProject();const sequence = await project.getActiveSequence();const track = await sequence.getVideoTrack(1);const items = await track.getTrackItems(ppro.Constants.TrackItemType.CLIP, false);const clip = items[items.length - 1];const chain = await clip.getComponentChain();// Motionコンポーネントを取得(不透明度以外)let motion = null;for (let i = 0; i < chain.getComponentCount(); i++) {  const c = chain.getComponentAtIndex(i);  if ((await c.getDisplayName()) !== "不透明度") motion = c;}// Positionパラメータ(displayName: "位置")を取得const posParam = /* motionのparamをdisplayNameで検索 */;project.lockedAccess(() => {  project.executeTransaction((comp

シーケンスの設定にsRGBワークスペースも選べるようにしてほしいOpen for Voting

Premiere Proにも、After Effectsのように sRGB IEC61966-2.1 を作業カラースペースとして選べるようにしてほしいです。CG・アニメーション・Web・PCモニター確認用の制作では、実際には sRGB / ガンマ2.2 基準で作業しているケースが多くあります。しかしPremiere ProはSDR作業・書き出しがRec.709中心のため、sRGB基準の素材を扱うと、色管理されたプレイヤーで確認した際に見た目がズレることがあります。検証では、Premiere Proから書き出したH.264の映像データはそのままに、カラー情報だけを NCLC 1-13-1 / Video Range に変更しました。Primaries: BT.709 / 1Transfer: sRGB / 13Matrix: BT.709 / 1Range: Video / Limited その結果、macOS QuickTime Player、Windows Media Player、VLC、RV、Premiere Proで、元のsRGB PNGにかなり近い見た目になりました。またPremiere Pro自身も、その変換後ファイルを sRGB として認識しました。つまりPremiere Proは読み込み時にはsRGB / 1-13-1を理解できます。しかし作業カラースペースや書き出し設定として、それを明示的に選べません。そのため、Premiere Proに以下を追加してほしいです。 作業カラースペース:sRGB IEC61966-2.1書き出しメタデータ:sRGB / NCLC 1-13-1 Rec.709を置き換える要望ではなく、sRGBベースのCG・アニメーション・Web向けSDRワークフローも正式に扱えるようにしてほしい、という要望です。

uhhoi
uhhoiParticipant
 バグ
【不具合報告】無音区間にSEを配置するとクリックノイズが発生し、Audition連携では別の音へ置き換わる

■使用環境Premiere Pro:26.2.2Adobe Audition:26.0OS:Windows 11CPU:Intel Core i7-11700 @ 2.50 GHzGPU:NVIDIA GeForce RTX 2070 SUPERメモリ:64 GB ■Premiere Proで発生している症状Premiere Pro 26.2.2で、シーケンス上に音声ファイルが置かれていない区間へ効果音(SE)を配置すると、一部の箇所で「プツッ」「ブツッ」というクリックノイズが発生します。 タイムライン上での再生時に発生する場合もありますが、再生時には問題がなくても、書き出した動画でのみクリックノイズが発生する場合もあります。 すべてのSEで必ず発生するわけではありませんが、複数の箇所で確認しています。 既存のシーケンスだけでなく、新規シーケンスでも発生しました。 ■再現手順 1. Premiere Pro 26.2.2で新規シーケンスを作成する。2. 音声ファイルが置かれていない空白区間を作る。3. 空白区間の音声トラックにSEを配置する。4. タイムライン上で再生する。5. H.264形式などで動画を書き出す。6. 一部の箇所で、元素材には存在しないクリックノイズが発生する。 また、音声ファイルが途切れた後に別の音声ファイルを配置した場合も、境界付近でクリックノイズが発生することがあります。 ■期待する動作音声ファイルが置かれていない区間へSEを配置しても、元素材に存在しないクリックノイズが追加されないこと。タイムライン再生と書き出し結果が一致すること。 ■暫定的に確認できた回避方法Premiere ProからAdobe Auditionへシーケンスを送信し、音声全体を1本のWAVファイルとして書き出すと、WAV単体ではクリックノイズが聞こえなくなりました。 しかし、Audition連携では別の重大な問題が発生しました。 ■Adobe Audition連携で発生している症状Premiere Proから、 編集→ Adobe Auditionで編集→ シーケンス を選び、Audition 26.0へシーケンスを送信しました。 Audition側で再生すると、Premiere Pro上ではBGMだった箇所の一部が、別の効果音に置き換わっています。 具体的には、元のB

Ckun
Community Expert
CkunCommunity Expert
 アイデア
素材のデータレベル(レンジ)の確認・変更ができる機能がほしいOpen for Voting

【要望の概要】カラーマネージメントと新しいカラーモードを活用するためには、「素材のデータレベル(レンジ)を正しく設定すること」が、今まで以上に重要になると考えます。そのため、「素材のデータレベルの設定状況(フルレンジ/リーガルレンジ)を表示する機能」と、「素材のデータレベルを手動で変更できる機能」をリクエストします。 【理由】Premiereは素材に応じてデータレベルを自動的に設定し、必要なレンジ変換を行なっているものと考えられますが、素材によっては誤った設定となる場合があります。その結果、カラーマネージメントによる色域・トーン(伝達関数)の変換も誤ったレベルで行われ、正しい色調・トーンに戻すことが困難になります(注1)。 【問題が生じる例】次の画像は、PanasonicのV-Log / V-Gamutを使用し、「AVC-Intra」と「ProRes 422 HQ」の2種類のコーデックで収録したMOVファイルを、Premiere v. 26.5.0 BETAのタイムラインに配置し、プログラムパネルに表示したものです。シーケンスのカラー設定は「ダイレクト Rec709」を使用し、「自動検出されたログと Raw メディアのカラー管理」を有効にしています。本来であれば、AVC-IntraとProRes 422の色味・トーンは完全に一致するはずです。しかしProRes 422 HQで収録した素材では、不必要な「リーガルレンジ→フルレンジへの拡張」が行われているように見受けられます。その結果、Rec.709変換後の画像はコントラストが強くなり、暗部が0%未満に沈み込んで不正確なレベルになり、「黒潰れ」が発生します。 ここには、大きく分けて二つの問題があります。一つ目は、Log素材におけるレベル管理が正しくない点です。Rec.709収録の素材には、「フルレンジ」と「リーガルレンジ(ビデオレンジ・リミテッドレンジ)」の2種類の解釈の仕方があります。そして、輝度・色差コンポーネント(YUV)で記録されるProRes 422 HQを「リーガルレンジ」として扱うことは自然な動作です。しかしLog収録素材においては、基本的に「リーガルレンジ」という考え方はありません。例えば、今回使用したPanasonicのV-Logでは、10bitコード値において「128」が0%のブラック、「433」が

Ckun
Community Expert
CkunCommunity Expert
 バグ
「ビューアガンマ」の設定が正しく機能せず、「書き出し」した映像に悪影響を及ぼすことがある問題

これは何年も前から発生している既知の問題ですが、いまだ解決に至っていません。(P: “Viewer Gamma” Settings Affect Exported Video)新しいカラーモードにおいても改善が見られませんので、投稿させていただきます。 ■問題の概要「カラースペース・ガンマの変換」が発生する状況において、「ビューアガンマ」の設定が正しく機能しません。そればかりか、本来であれば「書き出し」した映像に影響するはずのない『「ビューアガンマ」の設定』が「書き出し」した映像に悪影響を及ぼすという点で、より深刻な問題です。 具体的な例を、3つ挙げてみます。環境: Windows 11 Pro 25H2, Premiere 26.3.0 BETA StaticLib (ビルド57)※「ディスプレイのカラー」にて「カラーマネージメントの表示」を有効にしています。プリセット設定「ダイレクト Rec709」、素材のカラースペース「sRGB」 このパターンでは、「ビューアガンマ」を変更してもビューアの表示は変わらず、映像自体のトーンだけが変わります。『ビューアの表示ガンマが切り替わると同時に、それを打ち消す補正が映像にかかってしまっている』ように見えます。 なお、この問題は「自動検出されたログとRawメディアのカラー管理」の設定状況とは無関係のものです。   プリセット設定「広色域(トーンマップ済み)」、素材のカラースペース「S-Log3 / S-Gamut3.cine」 このパターンは、既知の問題として例に挙げられているものに相当します。「自動検出されたログとRawメディアのカラー管理」をONにすることで「色域変換」が発生し、この問題を引き起こしているものと推測されます。   プリセット設定「広色域(トーンマップ済み)」、素材のカラースペース「Rec.709」 このパターンは、一見問題はないようにも見えます。しかし、彩度が高い部分のレベルが少し変動しています。 (※「逆トーンマッピング」が色域圧縮を考慮していないという、別の要因が影響しているかもしれません。)   「ビューアガンマ」は「2.4」が基準とはいえ、比較的明るい作業環境で一般視聴向け・Webメディア向け編集を行う場合など、「2.2」を選びたいシーンはそれなりにあると考えられます。様々なカラースペースの