約 3,458,843 件
https://w.atwiki.jp/nakamura001/pages/101.html
FinePix REAL 3D W3(FX-3D W3)で撮影して作成したMPOファイルです。MPOファイルのサンプルとして置いておきます。 ここでリンクしているMPOファイルとサンプル画像はフリーのアプリケーションやサンプルプログラムへの同梱やMPOファイルの解説ページなどでご自由にお使い下さい。商用利用は禁止です。 サンプル画像をクリックするとMPOファイルのDLします。 視差調整が上手くいっていないもの 上の画像の視差を調整したもの
https://w.atwiki.jp/nakamura001/pages/100.html
サンプルファイル
https://w.atwiki.jp/rs2lock/pages/112.html
今度は.xファイルの保存方法です。 まずは前項の事をおこなったmpoファイルを開いてください。 テクスチャーが貼ってある物はしっかりチェックして下さい。 良ければ、「名前をつけて保存」にクイック 「UVマッピング」「左右を反転する」にチェックをして、 拡大率をお好みで変更してください。 （拡大率はそんなに必要はありません。詳しくは次項以降参照。） 後は「保存」を押してください。 この時、一部のPCでは、正常にTex（テクスチャー）が 貼られていない場合があります。 その場合、8×8もしくは8の累乗（8の倍数）の正方形に 設定すると貼れるようです。 正常に保存されたら良しです。 前項でやった事をやれば変更せずにそのまま使えます。 次のページへ 前のページへ 総合図書館に戻る
https://w.atwiki.jp/rs2lock/pages/111.html
①まずは、mpoファイルに保存する事をお勧めします。 ②次にx.ファイルで保存。 ③x.ファイル形式は 直にメモ帳で開けますので とりあえず開きます。 ④Ctrl+Fキーで検索窓を開き 使った画像の形式などを入れて検索すれば 画像の構文の場所が一発でわかります。 ⑤最初はこの場所は↓のようになっています。 ("C \Documents and Settings\s0610016.M0516\デスクトップ\色々\鉄道\RailSim2(試験)\Struct\新しいフォルダ\HI350054.png") 上記の場合では、自分以外のPCでテクスチャーが表示されません。 なのでさきほどの画像のように ファイル名のみに書き直します。 これは、テクスチャーを貼っている材質全般で行ってください。 ほかの材質はすぐ下にあるので 検索窓は閉じてスクロールして繰り返し行ってください。 応用 テスクチャの量をひとつのフォルダにまとめて軽くするためのコモン。 コモン使用の際は上記の⑤と少し違います。 ①コモンフォルダを作ります。 ②画像を全てコモンにいれます。 ③このように 書き直します。 保存の方法は次項に続きます。 次のページへ 前のページへ 総合図書館に戻る お詫び ( ﾟДﾟ) 幸一番様、画面からはみ出た構文の整理や mqoをメモ帳で初心者に開かせるのは難しかったりするので かんたんに書き直しました。 ご勝手で申し訳ございませんｍ（＿ ＿）ｍ
https://w.atwiki.jp/3dimage/
3D画像まとめWIKIへようこそ ウィキはみんなで気軽にホームページ編集できるツールです。 3DSの登場でより身近になった3D画像の利用についての情報をまとめるWIKIです。 現在誰でも編集できます。みんなで有意義な情報を共有していきましょう。 3DS 3DSのカメラで撮った立体写真は、JPGとMPO、2種類のファイルでSDカードに保存されます。 このMPOファイルのほうに、画像を立体に見せるための2枚の画像が入っています。 「ステレオフォトメーカー」といフリーソフトを使えば 写真2枚を取り出し、並べて保存することが可能なんです。 （※ソフトにMPOファイルをドラッグ＆ドロップし、ファイル→ステレオ画像保存で簡単に保存できます。） 平行法の練習方法 1. 目から力を抜きぼんやり見るような感じで焦点を画像に合わせないようにする。 2. 画像が段々ぼやけてくるのでさらにそのままぼんやり見る。 3. ぼやけた像が中央へと近づいてくる。 4. 中央へと来た像が融合して立体的に見える。 交差法の練習方法 1. 画像と眼の中間付近に指を1本立てる。 2. より眼にするような感じで指先を見る。 3. 視線はそのままで指を抜く。 4. うまくいくと像が3つ並ぶように焦点が合う。 慣れると指がなくても可能である。 参考画像
https://w.atwiki.jp/funf/pages/10.html
外部資料 ISO 9660 CD-ROMファイルシステムの概要 ISO9660について 内部 ＩＳＯファイルの編集ソフトほしい（読み取り専用だから無理？） ISO9660のセクタサイズは、2048バイト ファイルの構成 次の順番に格納されている システムエリア ボリューム記述子群 パステーブル群 ディレクトリとファイル システムエリア (16セクタ) = 0x0000～0x8000 に０が入っている。予約エリア ボリューム記述子群 パステーブルの場所とか、ルートディレクトリの情報が入ってる。 ディレクトリ ＞ ファイル ディレクトリの部分にファイルの場所がかいてある。ファイルの部分には、生データがガバーっとはいっとる。 読み出しの流れ ボリューム記述子群からパステーブルの場所をゲット パステーブルにディレクトリ情報が書かれている位置が書いてあるから欲しいディレクトリのデータをゲット ディレクトリ情報の場所から欲しいファイルの場所をゲット 欲しいファイルの場所からガバッと抜き取り 読むだけなら、パステーブルからルートディレクトリとって、そこからたどれば簡単
https://w.atwiki.jp/cod4pc/pages/63.html
Demoファイルの提出方法 提出のタイミング 各ラウンド終了後、直ちに提出してください。 ファイル名 ファイル名は下記のようにしてください。 必ず各自でファイル名をきちんと修正してから提出してください。 前回はファイル名そのまま、ファイル名がおかしな人がたくさんいました。全部チェックして修正するのは非常に手間がかかります。 []内はそれぞれ変更お願いします。 HW#[第何回大会か]_Demo_R[何ラウンド目のDemoか]_[チーム名（チームごとに統一してください）]_[プレーヤー名].dm_1 例） 第2回大会の第2試合のS.F.の赤頭巾のデモファイルの場合 HW#2_Demo_R2_S.F._akazukin.dm_1 提出先 下記にお願いします。 http //www.filebank.co.jp/guest/hwakazukin/dp/hwdemo ラウンドごとに各チーム名のフォルダが作ってあります。その中にお願いします。 PassはIRCにて連絡します。
https://w.atwiki.jp/nakamura001/pages/99.html
MPOファイル
https://w.atwiki.jp/jennychan/pages/20.html
DVD-RAMのIFOファイルの情報を元に、RD-X4のIFOファイル(TS_HDDMG.IFO)を見てみると、かなり似通った構造である事が分った。 IFOファイルのブロックは、DVD-RAMのものと若干異なり、 ヘッダ プレイリスト クリップリスト 不明1 タイトルリスト ベンダ情報? 不明2 と、ベンダ情報と思われるデータブロックの後ろ、というか、IFO全体の長さの先に、不明なデータブロックが見受けられる。 ヘッダ データブロックが若干異なる事もあり、ヘッダ情報は、以下の様な構造となっている。 位置 長さ 内容 0000 0C 識別子( DVD_RTR_VMG0 ) 000C 04 このIFOファイルの終端位置(= ファイル長 - 1) 0010 04 「プレイリスト」ブロックの終端位置(ここまでが、本来のIFOブロックなのか?) 0104 04 「クリップリスト」ブロックの開始位置 0108 04 「不明1」ブロックの開始位置 0134 04 「タイトルリスト」ブロックの開始位置 0138 04 「ベンダ情報?」ブロックの開始位置 0168 04 「不明2」ブロックの開始位置(0x000cで指定された位置の後ろを指し示している) クリップリスト DVD-RAMと若干異なり、フラグ情報が0x00000102となっており、 位置 長さ 内容 0000 04 フラグ?(0x00000102) 0004 04 このブロックの長さ相対的な終端位置(= ブロック長 - 1) 0008 78 不明なデータ列 0080 02 クリップ数 0082 04 * クリップ数 クリップ情報への相対位置配列 の様な構造になっている DVD-RAMのIFOと比較したとき、 DVD-RAM RD-X4 HDD フラグ 0x00000101 0x00000102 0x08からの不明なデータ列長 0x3c(60) 0x78(120) と、フラグの下位8bitの値と、不明なデータ列長に関連性が読み取れる。 したがって、クリップリストの構造は、 位置 長さ 内容 0000 04 フラグ 0004 04 このブロックの長さ相対的な終端位置(= ブロック長 - 1) 0008 3C * フラグの下位8bitの値 不明なデータ列 0008 + 3C * フラグの下位8bitの値 02 クリップ数 000A + 3C * フラグの下位8bitの値 04 * クリップ数 クリップ情報への相対位置配列 と思われる。 とろで、「ディスクに問題がある」といわれたHDDのクリップ数は、0x3E8、つまり、1000となっていた。切がいいのか悪いのか微妙な値。 この手のRDシリーズのトラブルの原因として、ストリームデータ領域のフラグメント問題がよく話題になっているけれど、クリップ数が多すぎる事が原因なんじゃないのか??? クリップ数が900を超えたあたりで警告でも出してくれれば、このような被害は防げるんじゃないのか??? と言う事で、ここまでくれば、タイトルと、チャプタ情報を生かした状態でデータを取り出すことが可能なはず。 しかし、取り出せると言っても、パソコン上でのこと。 このデータをDVD-RAMへ書き出したり、DLNA(Digital Living Network Alliance、RD的に言えば、ネットdeダビング)で、HDDレコーダに転送できれば良いのだけれど、DVD-VRや、DLNAの資料が見当たらない…。
https://w.atwiki.jp/musukure/pages/40.html
QT += opengl // openGLを使う場合 QT += xml // xmlを使う場合 CONFIG += assistant // Qt assistantを使う場合 CONFIG += console // コンソールに出力する場合 RESOURCE += resource.qrc // リソースファイルresource.qrcを使う場合