XPSに記述する座標処理系に関する覚書

ねこまたぎ

お道具箱

扉

■掲示板に戻る■ 全部 1- 最新50

1 ：kiyo ：2003/11/19(Wed) 02:35: 座標は極力処理系に依存しない抽象化された汎用的なものである事。

処理系に対するデータの最適化はアプリケーションが行う。
2 ：kiyo ：2003/11/19(Wed) 02:35: 合成処理を行う空間を仮にステージと呼ぶ。

ステージの大きさに制限は無い。
ただし、各処理系はそれぞれの目的に従ってステージの大きさを制限しても良い。
処理系の扱える範囲を超えた値の扱いは処理系に一任される。
3 ：kiyo ：2003/11/19(Wed) 02:36: 記述は、精度を特定しない実数で記述する。

座標系は、数学で用いられる座標系を用いる。
すなわち　右でXが増加　上でＹが増加する座標系
（一般的なコンピュータの座標系とYの方向が逆）

（三次元に拡張を行った場合は、奥側にＺが増加）

単位は、特に指定のない場合DTPポイント（１ポイント＝１／７２inch）
ユーザの必要にしたがってインチ・ミリ・センチ・メートル・フレーム等の
各単位を使用できるものとする。
4 ：kiyo ：2003/11/19(Wed) 02:36: 使用されるラスタデータは、可能な限りオリジナルの解像度を参照して
合成空間に置く。

解像度が特定できない場合は、７２dpiの解像度を持っているものとして扱う。
5 ：kiyo ：2003/11/19(Wed) 02:38: こうやって、書いてみると
ほとんどPSだがね、すなわちANIMOと似ている。
うーん、しょうがないかなー・・
6 ：kiyo ：2003/11/19(Wed) 11:08: 角度の単位は、指定が無ければ度数。
時計回り方向を正の値・反時計回り方向を負の値として扱う

拡大率は、指定がない場合単なる倍率で指定。（２．３＝２３０％）
負の値は座標の反転として扱う。
拡大は、座標毎に指定できるものとする。
（このためフリップは基本的に不要となる
左右鏡像は X -100% / Y 100%
上下鏡像は X 100% / Y -100%
で実現可能。）
7 ：kiyo ：2003/11/19(Wed) 19:54: ステージ上をクリッピングして出力データを得るための領域を
仮に「キャメラフレーム」と呼ぶ。（安直だけれど一応）

キャメラフレームの原点は、そのフレームの中央とする。
初期位置はステージ原点とする。
8 ： kiyo ：2003/11/22(Sat) 00:34: このスレッドの記述は、アイデアの段階なので、検討を要する。
決定仕様に非ず。

特に以下は、実現可能か実験が必要。
9 ： kiyo ：2003/11/22(Sat) 00:45: セル、および背景( BOOK含む)等の撮影素材の記述は、
トランスフォームプロパティを持つが、
撮影効果のためのキーは一切持たない。
撮影素材としての事前処理を行うために、標準的なマスク処理による単純な重ね合わせだけを行う。
すなわち、通常モードに限定したアルファチャンネル、または別ファイルによるチャンネル合成とタイムシートのタイミング情報を反映した画像の置き換えのみを行う。
10 ： kiyo ：2003/11/22(Sat) 00:48: 撮影素材の位置情報は、素材のアライメントを補正するために使用する。
アライメント情報は、それぞれのファイルの解像度、オフセットを記述して、個々の素材画像にカット内で標準的に使用できる基準点を与える。

うーん、文書が硬くて分かりにくい。
11 ： kiyo ：2003/11/22(Sat) 00:54: 要するに、「タップをサポートします」

画像スキャン時または、登録時点でタップと画像の位置関係を
記録・または規定してその情報をセル(背景)一枚ごとにもたせる
ことができる様にします。

正しい手順で登録した素材は、合成ソフトで読み込むだけで
「初期の位置合わせが終了している」状態になります。

オリジナルのアイデアではなく、実際にそうなっているソフトもあります。
12 ： kiyo ：2003/11/22(Sat) 00:57: タップ情報が不足している場合は、しょうがないので
ユーザ設定にしたがって任意のオフセットを画像に与えることになります。
・・・たぶん画像の中央が最も問題が少ない。
13 ： kiyo ：2003/11/22(Sat) 01:04: 上の構造をとると合成のためのレイヤとしての機能を果たさなくなるので、
これらの撮影素材を受け入れて(親としてネストして)合成のための
バッファを与えるトレーラーとしてのオブジェクトが必要になります。

・・これが、通常のソフトのレイヤになる。

仮に「キャリア」と呼びます。
TMSの「ペグ」に近い感じです。
コンバートの際には対照できるか?

キャリアは、 XPSの記述から「自動」で生成されます。
ユーザ指定も可能にするべきですが、記述を省略しても成立する要に
構成したいと考えています。
14 ： kiyo ：2003/11/22(Sat) 01:14: キャリアは、一つ以上の撮影素材を受け入れて内部で単純合成します。
合成に参照する条件は、セルの持つ透過情報および、位置情報のみです。
さらに、「キャリア自身は、キーフレームを持たない」オブジェクトです。
キーフレームは、タイムシート上に記述された撮影指定タイムライン
それぞれを独立の「撮影指定オブジェクト」であると解釈して、これらの
オブジェクトをネットワークで連結します。
少なくとも、フィルタツリーとトランスフォームツリーの二つの樹構造が
重なった物になります。
標準的なカットの処理では、たいして複雑なネストにはならない
はずです・・実際にやってみないとどんな問題が起きるかわからない
15 ： kiyo ：2003/11/22(Sat) 01:22: カットには、デフォルトのキャリアが、最初に一つある。

トランスフォームオブジェクトとフィルタオブジェクトもデフォルトの
ものがそれぞれ一つある。

ユーザによる撮影指定が特になければ、
「標準位置、フィックス、通常合成モード、セルの入れ替えのみ」
なので、初期位置のトランスフォーム情報で初期状態の(何もしない)
フィルタ条件でデフォルトのキャリアのみで終了。
16 ： kiyo ：2003/11/22(Sat) 01:27: たとえば、
背景のスライドがこれに加わると
トランスフォームオブジェクトがユーザによって指定されたため、
二つのトランスフォームオブジェクトができる。

二つのトランスフォームオブジェクトにはネストはなしなので、
その出力を受けるためにキャリアを追加する。

新しいキャリアは、指定のあった撮影素材をのせてトランスフォームオブジェクトの配下に入る。他の指定がないのでファイルターワークは、デフォルトの値を受け継ぐ。
17 ： kiyo ：2003/11/22(Sat) 01:39: さらに、 ABCセルの内 Bセルにガウスブラー・不透明度50% の指定が加わった場合。
レイヤを4層に分割する必要ができたのでデフォルトのキャリアを複製して
二つのキャリアを加える。
トランスフォームの新しい指定はないので、デフォルトのトランスフォームオブジェクトにネストする。
指定のあったガウスブラー効果のためのフィルタオブジェクトと、
Bセルの含まれるキャリアをネストして、さらに50%の不透明度の指定と
ネストする。
18 ： kiyo ：2003/11/22(Sat) 01:44: こんな感じで、撮影指定をすべて別のオブジェクトとして独立した
管理をする・・・解釈部分がキモになりそう。

さらに、このネットワーク構成処理は中間データにすぎないので
このあとこのネットワークから、実際の合成エンジンに対して
引き渡すための再構成が必要になる・・なりますねぇ。
19 ：kiyo ：2003/11/23(Sun) 11:58: 座標関連の覚書のつもりだったが、
オブジェクトのネストの話にズレてきました・・・ま、ヨシ

書式を考えてみた

が、やはり1枚のシートに書くにはムリがある。
完全に「ムリ」かというと・・プログラムとしてはそれなりだけど
時間軸とレイヤの重なりを2次元に展開してあるXPS上では、
キーの値とタイミングを列挙するのはダメそう。

座標キーデータの例
(.25cm,3.2cm,.83,.0,,12,.23)

左から
X座標、Y座標、
アーク制御点1、アーク制御点2、
タイミング制御点1、タイミング制御点2

2次元座標だとキーデータは数値6つになる。
タイムシートにこれがずらずらと並んだ姿はお世辞にも
「読める」とはいえない・・

で、常套手段としては「ラベル付けてマッピングする」わけだが・・
「あんまりファイルが増えるのも好ましくないので、マップファイルに詰め込む」・・か?
はたまた
「撮影指定ファイルを作るべき」・・か?
もしくは
「XPS内部にマッピングデータを置く」・・かな?

1カットに対してファイル3つは多いなぁ
2つでもかなり危険だと思っているのでねぇ思案中
20 ： kiyo ：2003/11/25(Tue) 17:31: あれ？何勘違いしてるかな
上の記述　間違いです。

通常の座標等の二次元値のキーデータは

X座標、Y座標、
アーク制御点1Ｘ、アーク制御点1Ｙ、
アーク制御点2Ｘ、アーク制御点2Ｙ、
タイミング制御点1V、タイミング制御点1T、
タイミング制御点2V、タイミング制御点2T

以上の10個です。　6つどころじゃない。

回転角等の一次元値　の場合

回転角、
タイミング制御点1V、タイミング制御点1T、
タイミング制御点2V、タイミング制御点2T

5つですね
21 ： kiyo ：2003/11/25(Tue) 17:39: 一般的に二次元のベジェ曲線を指定するためには、

X0,Y0,X1,Y1,X2,Y2,X3,Y3

の8個のパラメータが必要ですが、

X0,Y0　＝　始点（当該キーフレームの「値」）
X3,Y3　＝　終点（次のキーフレームの「値」）

と、置いて

制御点1および2を

　始点と終点に対する相対値
または
　始点を0，終点を1とする相対比率

で、記述することで記述量を減らすことができる。
22 ：kiyo ：2003/11/27(Thu) 01:56: ベジェ曲線を計算する場合の助変数 t は弧長と対応しないので、
弧長を高速に求める関数が必要。
23 ：kiyo ：2003/11/27(Thu) 02:03: 「りまぴん」に関しては、
アフターエフェクトのキー入力支援アプリの範囲を逸脱しない様に注意。
レイヤ構成を AE主体に構成しておかないとユーザの混乱を招く。
「セル」=「シーケンス+タイムリマップのレイヤ」である状態を基本に置いて
座標関連は、「レイヤに付属させる」か、「単独のキーデータで出力」かの
選択肢を付ける形の実装にする。

本格的な構成および解釈は別のシートコンバータを書くこと。
>アプリケーションから呼び出せる様に
>単独でデータファイルの処理が可能な様に
>マップジェネレータとエディタが必要
24 ：kiyo ：2003/11/27(Thu) 02:16: んーやっぱりエクセルか?
インターフェースのコードの分エクセルはラク
EXCELシートで保存・印刷できるのもラク

VBAの文字列処理は、当然なんだけど「BASIC」なので。なつかしいけど
機能が貧相なのでイヤ。いまさら LEN とか MID とは思わなかったし・・

といって拡張用のDLLとかVBSオブジェクトに手を出すとMacで走らなくなるので鬼門・・正規表現欲しいなぁ

やっぱりTcl/Tk か・・

ちょっと勉強してJAVA ?んーチョト思案
25 ： kiyo ：2003/12/01(Mon) 02:31: ベジェのキーは、
後区間の第一制御点と第二制御点をもたせるべきか
(パラメータの展開がラク)
はたまた、前区間の第二制御点と後区間の第一制御点をもたせるべきか
(データの所属としてはこちらが誤解が少なそう)
ひと思案必要
GUIを付加した場合は、制御点操作ハンドルの連動属性も記録する必要あり。
連動なし
方向のみ連動
方向と長さの比率連動

3パターン要
26 ：kiyo ：2004/07/20(Tue) 17:33: 座標の本体データ　３次元ベクトル（３要素配列）
　　２次元の場合Z座標を０で対応
空間（軌道）指示データ　３次元ベクトル二組（３要素配列×２）
　　表示系に従った相対値
時間（タイミング）指示データ　２次元ベクトル二組（２要素配列×２）
　　これは、考証要　現在は、０－１制限の二次元値　一次元値も一応考慮
　　制限はさらに再考が、必要。
27 ：kiyo ：2004/11/12(Fri) 22:30: マップファイルのアライメント記述参考
省略可能
省略時は、標準値を補間
括弧内は単位省略時の基準単位

[幅(pt),高さ(pt)[
,解像度X(dpi)[,解像度比(比率)または解像度Y(dpi単位省略不可)[
,原点オフセットX(pt),原点オフセットY(pt)][
,ローテーション(degrees/radians)]]]]
28 ：kiyo ：2004/11/12(Fri) 22:34: 長さ系列の指定可能な単位は、
pt ポイント
px ピクセル
cm センチメートル
mm ミリメートル
in インチ
単位省略時は、ptであると見なす。

指定可能な解像度単位は
dpi(ppi) 毎インチ
dpc(ppc) 毎センチメートル
単位省略時は、dpiであると見なす。

指定可能な角度単位は
degrees 360度法
radians 弧度法
単位省略時は、360度法であると見なす。
29 ：kiyo ：2004/11/12(Fri) 22:43: 幅、高さの省略値は、メディアから読み取った値を使用
解像度が設定されていない場合は72dpi(1ピクセル1ポイント)として処理
原点オフセットはユーザ指定。指定がない場合は画像中央(幅×0.5,高さ×0.5)
回転はユーザ指定。指定がない場合は0度(回転なし)
適用順はオフセット>回転
30 ：kiyo ：2004/11/12(Fri) 23:03: メディア(ファイル)が存在しない場合の省略値はプログラムで設定

高さ、幅はテンプレートから選択
例えば
NTSC(VGA) 640,480,72,1,320,240,0
D1(NTSC) 720,486,72,0.9,360,243,0
DV(NTSC) 720,480,72,0.9,360,240,0
D1(PAL) 720,576,72,1.07,360,288,0
225mm144dpi 637.80,478.35,144,1,318.9,239.18,1

当座は、こんなもんで開始するかな
31 ：kiyo ：2005/02/06(Sun) 10:10: アライメント情報まとめ

[幅(pt),高さ(pt)[
,[解像度X(dpi)][,[解像度比(比率)または解像度Y(dpi単位省略不可)][
,[原点オフセットX(pt)],[原点オフセットY(pt)]][
,ローテーション(degrees/radians)]]]]

うーん、これで良いのかなぁ?
例
225mm,168.75mm,144dpi,1,112.5mm,84.375mm,0deg
225mm,168.75mm,144dpi,,,,-0.215deg

サイズと実際のピクセル数があれば解像度と解像度比は要らないはずだが、どうよ?
ただし、実ファイルに先行してシートを書く際には何らかの情報が必要?

実用上、あとからファイルの入れ替えがあった時にどの情報を優先するか一考。

ALI(animo)がどうなっていたか思い出せないので資料を掘る。
ここほれワンワン
32 ：kiyo ：2005/02/06(Sun) 10:14: みた。
サイズは記述してなかった。

内容は、
----------------- 以下アライメントファイル
.br
DPI= 52.000000
.br
PAR= 1.000000
.br
Origin= -186.346154, -149.423077
.br
[EOF]----------------- 以上
こんな感じ
オリジネーションは、ワールド座標系内での画像の位置

やっぱり、情報の重複を避けるためか、サイズは書いてない。
ローテーションが入っていたような記憶が…間違いだったようだ。
PAR はピクセル・アスペクト・レシオの略(と思う)。
ライン高に対するピクセル幅の割合で記述。
うちもそうしたい鴨ネギ…一般的だから。
33 ：kiyo ：06/03/04 00:53:06 ID:???: 帰り道で考えがまとまった様な気がするのでメモ

数値情報を、カンマ区切りで列挙するのにすごく抵抗があったけれど、
考えてみれば、1レコード/1行にこだわる必要がない。

A A-1 "/usr/data/Work/myFolder/myCut/A/A_0001.tiff",225mm,168.75mm,144dpi,1,112.5mm,84.375mm,0deg

とかでなく

A A-1 "/usr/data/Work/myFolder/myCut/A/A_0001.tiff"
225mm ,168.75mm ,144dpi ,1 //size
112.5mm ,84.375mm ,0deg //offset

こんな記述で良いのだ…要はデータをパースする側だけの問題
可読性優先でGOGO!
34 ：1 ：25/03/05 21:05:57 ID:???: 555

13KB

新着レスの表示

掲示板に戻る全部前100 次100 最新50