◇-早々年賀-きょうこ(10/12-21:01)No.2649 └ Re:早々年賀-宮田(10/13-00:10)No.2650 └ Re:早々年賀-きょうこ(10/13-12:27)No.2652 └ Re:早々年賀-宮田(10/13-18:54)No.2655 └ Re:早々年賀-きょうこ(10/13-22:21)No.2656 └ Re:早々年賀-宮田(10/14-01:12)No.2657 ├ Re:早々年賀-宮田(10/14-01:13)No.2658 │ └ Re:TIFF JPEG PICT-きょうこ(10/14-21:24)No.2660 │ └ Re:TIFF JPEG PICT-宮田(10/14-23:48)No.2662 └ Re:画像形式 ベクタとラスタ-きょうこ(10/14-21:14)No.2659 └ Re:画像形式 ベクタとラスタ-宮田(10/14-23:39)No.2661 └ Re:画像形式 ベクタとラスタ-きょうこ(10/15-14:50)No.2664 └ Re:画像形式 ベクタとラスタ-宮田(10/15-17:19)No.2667 └ Re:印刷サイズ-きょうこ(10/16-20:53)No.2670 └ Re:印刷サイズ-宮田(10/17-18:59)No.2673 └ Re:印刷サイズ-きょうこ(10/18-00:21)No.2676 └ Re:印刷サイズ-宮田(10/18-10:06)No.2678 └ Re:レンダリングサイズ-きょうこ(10/20-12:19)No.2684 └ Re:レンダリングサイズ-宮田(10/22-17:26)No.2690
2649 | 早々年賀 | きょうこ URL | 10/12-21:01 |
宮田さん、こんにちは! じゅんいちさんへのお返事、ありがとうございます! ところで、今年も、宮田さんの門松のアレンジ版を使わせて 戴きましたが宜しかったでしょうか? Materials のグリーティング。 vue に読み込んでみようとしたのですが、自由曲面でない 「閉じた線形状」が沢山有ると、飾り付けが下に落ちるようで、 PhotoShop で合成しました。 |
2650 | Re:早々年賀 | 宮田 URL | 10/13-00:10 |
記事番号2649へのコメント きょうこさん、こんにちは!! 》 ところで、今年も、宮田さんの門松のアレンジ版を使わせて 》 戴きましたが宜しかったでしょうか? 》 Materials のグリーティング。 あの形状はFreeDataとして作成したものですから、自由にアレンジして 使って頂いて結構です。パーツの流用もご自由にどうぞ。 しかし、もう新年の準備でしょうか。早いですねぇ(^^) 》 vue に読み込んでみようとしたのですが、自由曲面でない 》 「閉じた線形状」が沢山有ると、飾り付けが下に落ちるようで、 》 PhotoShop で合成しました。 あ〜。4点以上のポイントを持ったものだと難しいのかもしれませんね。 いちどポリゴンに変換すれば良いのかもしれませんが、Shadeのポリゴン 分割は適当な値にするのが難しいのでちょっと面倒ですね。 |
2652 | Re:早々年賀 | きょうこ URL | 10/13-12:27 |
記事番号2650へのコメント 宮田さん、こんにちは!! 》あの形状はFreeDataとして作成したものですから、自由にアレンジして 》使って頂いて結構です。パーツの流用もご自由にどうぞ。 ありがとうございます。(^^) 》しかし、もう新年の準備でしょうか。早いですねぇ(^^) どうなるか判らないんですが。。。CD-ROM 収録の話が出ていて。。。 色々印刷のを増やしてます。^^; まぁ。。。UPしてるのは、気軽に印刷出来るサイズですから、 駄目かも知れませんが。 いわゆる素材CD、私も持ってるんですが、もの凄いバイト数で んなものマシンが重くて! それで始めたマテリアルの印刷物。 でも、印刷にはCMYKとか、TIFやBMPでないと、という 話も聞きますが。。。サーバー容量の問題も有り。 |
2655 | Re:早々年賀 | 宮田 URL | 10/13-18:54 |
記事番号2652へのコメント きょうこさん、こんにちは!! >どうなるか判らないんですが。。。CD-ROM 収録の話が出ていて。。。 >色々印刷のを増やしてます。^^; をっ! そゆう話が出ているんですか。楽しみですね。 うまくいって、素材が増えていったらTakamiyaブランド素材集とか(^^)v >でも、印刷にはCMYKとか、TIFやBMPでないと、という >話も聞きますが。。。サーバー容量の問題も有り。 画像印刷ではTIFF、PICTが多く使われていたようですね。現在は PhotoShop形式でもOKという所も多いようです。 これは印刷屋さんでRGB(モニタ)とCMYK(印刷)での発色差補正の ノウハウが蓄積されていると言うことだと思います。 RGB→CMYK変換は単純な式だけだと思う発色にならないので、経験上の 知識や技術が必要なようですから。 ただ、一般家庭で使用する場合の画像形式はどれでもあまり問題ないと 思います。BMPはWinでの汎用性は高いですが、データが大きくなり すぎますのでTIFF、PICT形式が普通ではないかと‥‥ 印刷目的だと印刷物の大きさによって画像の大きさが変わりますから、 ラスタ系の画像(PhotoShopとかPainter)だと、最初創る大きさに 左右されますので面倒です。 |
2656 | Re:早々年賀 | きょうこ URL | 10/13-22:21 |
記事番号2655へのコメント 宮田さん、こんにちは!! 》をっ! そゆう話が出ているんですか。楽しみですね。 ありがとうございます。 結果兎も角、お話を戴けるだけでも嬉しいです。*^^* ウチのサイトは、法人関係の方が結構ご利用下さってるんですよ。 ものは色々で、ちらしとかカードとか包装とか。 パソコンで印刷なさる場合も有りそうです。 》印刷目的だと印刷物の大きさによって画像の大きさが変わりますから、 》ラスタ系の画像(PhotoShopとかPainter)だと、最初創る大きさに 》左右されますので面倒です。 すみません、この辺。。。理解できません。。。^^; PhotoShop は画像の大きさを自由に変更出来ますけど。。。 ただ、撮った写真の解像度が低いと、後が大変ですが。 32万画素のカメラや設定でロングショットで撮った鳥をトリミング して数倍に大きくしても。。。見られたものでなく。。。 それが、自由に変更出来る形式が有るんでしょうか。。。 それが欲しい! また、圧縮率の低いJPGとTIFの違いも。。。現実問題として どう変わるのか。。。判ってません。^^; SHADEでお猿さんが何とか出来ましたので、 マテリアルのグリーティングの年賀に、低圧縮のJPGと TIF(IBM)LZW圧縮したものをUPしてみました。 TIFだと。。。MAC用が別途要るのかしら。。。 圧縮すれば、JPGの倍、まぁ。。。少しなら可能では有ります。 PICTだと。。。3倍になりますが。。。でも、 WIN MAC 共通ですか? 16bit 32bit。。。。んと。。。 |
2657 | Re:早々年賀 | 宮田 | 10/14-01:12 |
記事番号2656へのコメント きょうこさん、こんにちは!! 長いので2つに別けます。 >>印刷目的だと印刷物の大きさによって画像の大きさが変わりますから、 >>ラスタ系の画像(PhotoShopとかPainter)だと、最初創る大きさに >>左右されますので面倒です。 >PhotoShop は画像の大きさを自由に変更出来ますけど。。。 え〜と。 印刷方法にもよりますが、印刷物はインクの霧を吹き付けて絵にします。 この時、1inch(2.54cm)幅に写っているインクの点を数え、その数を dpi (dot per inch)と言っています。これが大きければそれだけ緻密な 絵になるわけです。 印刷時は画面のピクセルをこのdotに対応させます。 300dpiで印刷すると1インチ四方には300×300ピクセルが入っていること になりますから、300×300ピクセルの画像を300dpiで印刷すると 2.54×2.54cmの絵になります。 ここで300×300ピクセルの絵を縦横倍に拡大したとします。印刷時は 5.08×5.08cmになりますが、このうちの3/4の点はオリジナルから 新たに作られた点で水増ししているんです。この水増し法はソフトに よって色々あるんですが、どうしてもオリジナルより画質は落ちます。 縮小は逆に間引いているのでやはり画質は落ちます。 これがラスタ系画像を印刷する場合の問題点のひとつなんです。 ベクタ系(IllustratorやDraw)は違った方法をとっているので拡大、 縮小しても画質はあまり変わりません。 入出力解像度について↓ http://www.ff.iij4u.or.jp/~hrmiyata/text/tes/dpi/DPI.htm |
2658 | Re:早々年賀 | 宮田 | 10/14-01:13 |
記事番号2657へのコメント >また、圧縮率の低いJPGとTIFの違いも。。。現実問題として >どう変わるのか。。。判ってません。^^; 低圧縮(可逆圧縮)のJPEGとTIFFはデータ構造の違いだけで、画質は 変わりないと思います。 TIFFの場合、このデータ中にαチャンネル(もしくはマスク)を同時に 入れられることから、その後の加工がし易い利点があります。 >TIFだと。。。MAC用が別途要るのかしら。。。 まあ、過去のしがらみからMacとWinでは同じTIFFでも読んでいく方向 が反対なんです(^^; ただ、現在のソフトは自動的にMac形式かWin形式か判断して読んでくれる と思います。 >PICTだと。。。3倍になりますが。。。でも、 WIN MAC >共通ですか? 16bit 32bit。。。。んと。。。 PICTはMac用の形式で、ほとんどのWinでも読めるはずです。巨大な画像データ でも扱える利点はありますが、その他のメリットは不明ですね(^^; Bitはカラー数です。通常RGB各8bitで24bitがフルカラーと呼ばれているものです。 人間の眼は特定の色調には鈍感なため、RGB全てを同じbitにする必要は必ずしも ないので5、6、5とかしたりすると16bitになったりします。 32bitはRGBの24bitにマスク用グレースケールの画像8bit分を入れたものです。 αチャンネルとして使えるようなデータ領域ですね。 といった所でしょうか‥‥ |
2660 | Re:TIFF JPEG PICT | きょうこ URL | 10/14-21:24 |
記事番号2658へのコメント 宮田さん、こんにちは!! 》低圧縮(可逆圧縮)のJPEGとTIFFはデータ構造の違いだけで、画質は 》変わりないと思います。 ありがとうございます! なら。。。JPEGでOKかしら。 TIFFって。。。クイックタイムが起動して、保存出来ないです?^^; 少なくとも、私の環境では。。。 前に、他所でTIFFを保存出来た経験が有るのですが。。。保存した サーバーがその設定にして下さってたのか。。。その頃の私の環境が そうだったのか、判りませんけど。 .htaccess で、TIFFは保存、と設定すれば良いのかしら。。。 》TIFFの場合、このデータ中にαチャンネル(もしくはマスク)を同時に 》入れられることから、その後の加工がし易い利点があります。 ありがとうございます。お陰様で、「切り抜きがしやすい」と上記サイト に書かれていた理由が判りました。 》ただ、現在のソフトは自動的にMac形式かWin形式か判断して読んでくれる 》と思います。 》PICTはMac用の形式で、ほとんどのWinでも読めるはずです。巨大な画像データ 》でも扱える利点はありますが、その他のメリットは不明ですね(^^; だったら、TIFFの方が良さそうですね? まぁ。。。でもサーバー容量を考えると。。。低圧縮のJPEGが無難かも? |
2662 | Re:TIFF JPEG PICT | 宮田 URL | 10/14-23:48 |
記事番号2660へのコメント きょうこさん、こんにちは!! >>低圧縮(可逆圧縮)のJPEGとTIFFはデータ構造の違いだけで、画質は >>変わりないと思います。 > なら。。。JPEGでOKかしら。 状況によってはJPEGでも良いと思います。 加工は行わず、ちょっとしたカットに使うとか言う場合ですね。 >TIFFって。。。クイックタイムが起動して、保存出来ないです?^^; >少なくとも、私の環境では。。。 ダウンロードできないということですよね? ファイルタイプのTIF関連付けがQuickTimeになっているからではないでしょうか。 これをはずせば、「不明なファイルのダウンロード」になるかもしれませんが 保存はできると思います。 初めての方だと使いにくいかもしれませんが、Zipで圧縮して置くのもひとつの 手です。XPからはZipが標準で扱えるようになったんですよね? |
2659 | Re:画像形式 ベクタとラスタ | きょうこ URL | 10/14-21:14 |
記事番号2657へのコメント 宮田さん、こんにちは!! ご丁寧なご説明を、どうもありがとうございます! 》これがラスタ系画像を印刷する場合の問題点のひとつなんです。 》ベクタ系(IllustratorやDraw)は違った方法をとっているので拡大、 》縮小しても画質はあまり変わりません。 ベクタ。。。ベクタの対語がラスタだったんですね?^^; マテリアルにUPしたお猿さん程度なら、イラストレーターでも 描けそうですが。。。でも、写真をベクタには。。。 と思って、ふと、FHASHが写真をベクタデータに変換出来たなと 思い出しました。 で、やってみたのですが、やはり遠景の鳥のUPは無理ですね。。。 まぁ、デザイン化するなら、何とかなるかもしれませんけど。 それならば、 PhotoShop でカットアウトという手も有るかも? 》入出力解像度について↓ 》http://www.ff.iij4u.or.jp/~hrmiyata/text/tes/dpi/DPI.htm これも。。。私がお尋ねしてから書いて下さったのですか?(@_@ 恐縮しつつ、その速さにびっくり! ピクセルとドットは違う、と以前にどなたかから伺ったような 気がして、***dpi とか書きつつも、ずっと不安だったのですが、 大丈夫かな!とか思いました。(^^) |
2661 | Re:画像形式 ベクタとラスタ | 宮田 URL | 10/14-23:39 |
記事番号2659へのコメント きょうこさん、こんにちは!! >ベクタ。。。ベクタの対語がラスタだったんですね?^^; ラスタ系=ペイント系(画像全体を点で表す) ベクタ系=ベクトル系(特定の点を計算によって曲線で結ぶ) ような方式です。 Shadeのプロ版とそれ以外のグレードの差がこの印刷にあります。 プロ版以外はレンダリングサイズが4000×4000の制限がありますよね。 すると、印刷に使える大きさ、精密さに制限が出てくるんです。 部分部分を最大サイズでレンダリングして張り合わせる方法もあるかも しれませんが、これは滅茶苦茶大変です。 印刷用の画像(例えば印刷用A4版の画像)を創ることを考えると プロ版以外は結構大きな制限を持っているわけです。 >これも。。。私がお尋ねしてから書いて下さったのですか?(@_@ いえ、いえ。これは以前SFTで話題として出ていた時に作成したものです。 ちょっと不備な所もあるので書き直さなければならないんですが、 今まで忘れてました(笑) |
2664 | Re:画像形式 ベクタとラスタ | きょうこ URL | 10/15-14:50 |
記事番号2661へのコメント 宮田さん、こんにちは!! 》ラスタ系=ペイント系(画像全体を点で表す) 》ベクタ系=ベクトル系(特定の点を計算によって曲線で結ぶ) 分かり易いですね!ありがとうございます。 》Shadeのプロ版とそれ以外のグレードの差がこの印刷にあります。 》プロ版以外はレンダリングサイズが4000×4000の制限がありますよね。 1024x768 以上のレンダリングってしたことないです。^^; 4000x4000 でも、もの凄く時間が掛かりそうですぅ。 コンテスト提出とかだと、A3以上とか書かれてるようでですが、 A3印刷出来るプリンタも無かったりします。 そこからでも、私程度のは弾かれるなと納得してたりして。^^; でも、いつだったかのピエロ。。。凄いピクセル数でレンダリング なさったのでしょうねぇ。。。 感激する程、良くできてました。 |
2667 | Re:画像形式 ベクタとラスタ | 宮田 URL | 10/15-17:19 |
記事番号2664へのコメント きょうこさん、こんにちは!! > コンテスト提出とかだと、A3以上とか書かれてるようでですが、 > A3印刷出来るプリンタも無かったりします。 今はA3ノビ(印刷用A3サイズ)で印刷できる機種もあるようですね。 といっても普通は使いませんけど(^^;; 単純計算でもA3ノビ程度で印刷しようとすると1万2千×8千ピクセル ぐらい必要になります。 正直な所、うちのコンプでは扱いきれません(笑) ベクタデータだったら何とかなるかもしれないですが、ラスタだとCDか DVDレベルになってしまいますね。かなりきつい‥‥ |
2670 | Re:印刷サイズ | きょうこ URL | 10/16-20:53 |
記事番号2667へのコメント 宮田さん、こんにちは!! 》今はA3ノビ(印刷用A3サイズ)で印刷できる機種もあるようですね。 ノビって。。。ちょっと長い用紙もokというタイプですよね? 印刷用A3サイズ? 》単純計算でもA3ノビ程度で印刷しようとすると1万2千×8千ピクセル 》ぐらい必要になります。 》正直な所、うちのコンプでは扱いきれません(笑) A4をスキャナー(1200dpi)で読み込むと、その位になるん ですけど。。。指先ツールなんて大変! そっか。。。レタッチしにくいサイズなんだ。。。 それにしても、そのレンダリング。。。凄い掛かりそうだし、 それ以前に、モデリングもテクスチャーも大変そう。。。^^; あらゆるボロが出そうで? |
2673 | Re:印刷サイズ | 宮田 URL | 10/17-18:59 |
記事番号2670へのコメント きょうこさん、こんにちは!! > ノビって。。。ちょっと長い用紙もokというタイプですよね? 印刷用のA3って普通のA3より一回り大きいやつです。 多分、製本などの関係から少し大きめの余白を取っているのではないかと‥。 A3:420×297mm A3ノビ:483×329mm という規格です(多分) >A4をスキャナー(1200dpi)で読み込むと、その位になるん >ですけど。。。指先ツールなんて大変! 1200dpiだと0.02mm間隔でサンプリングしますから、かなり精密にできますね。 印刷時はプリンタの性能にもよりますが、普通の画像だと300dpiぐらいでも 大丈夫ではないかと思います。 >それにしても、そのレンダリング。。。凄い掛かりそうだし、 >それ以前に、モデリングもテクスチャーも大変そう。。。^^; かかるでしょうね。>時間。 モデルは細部まで創ってあれば結構耐えられると思いますが、 テクスチャは作り直さなければならないかもしれません。 (そのぐらいに耐えられるテクスチャを使っていれば別ですけど) コンテストなどの作品は、場合によってこういった細かい部分の できも見たいので「大きく創って欲しい」といっているんだと思います。 小さい画像だとあまり細かく創っても画像に反映されないため、 ついつい手を抜いてしまうんですよね(^^;; Webベースだと特に‥‥(笑) |
2676 | Re:印刷サイズ | きょうこ URL | 10/18-00:21 |
記事番号2673へのコメント 宮田さん、こんにちは!! 》多分、製本などの関係から少し大きめの余白を取っているのではないかと‥。 ありがとうございます。解りました。(^^) 》印刷時はプリンタの性能にもよりますが、普通の画像だと300dpiぐらいでも 》大丈夫ではないかと思います。 普通に印刷する時は、そうですね。 ただ、Web用でもお仕事とかで補正が要る時、高い解像度で写真や 書類を読み込んで、最終的に縮小する方が綺麗みたいなんです。 特に、文字は劇的に違うんですよね。。。 》小さい画像だとあまり細かく創っても画像に反映されないため、 》ついつい手を抜いてしまうんですよね(^^;; 面倒だし。って。(xx\バキッ |
2678 | Re:印刷サイズ | 宮田 URL | 10/18-10:06 |
記事番号2676へのコメント きょうこさん、こんにちは!! >ただ、Web用でもお仕事とかで補正が要る時、高い解像度で写真や >書類を読み込んで、最終的に縮小する方が綺麗みたいなんです。 大きく創って小さく印刷するというのが良くされている方法みたいですね。 たしかにこの方が綺麗に印刷されます。 >>小さい画像だとあまり細かく創っても画像に反映されないため、 >>ついつい手を抜いてしまうんですよね(^^;; >面倒だし。って。(xx\バキッ 本音はそうなんですが、建前上意味がないという言い訳です(笑) |
2684 | Re:レンダリングサイズ | きょうこ URL | 10/20-12:19 |
記事番号2678へのコメント 宮田さん、こんにちは!! 》本音はそうなんですが、建前上意味がないという言い訳です(笑) これだけど。。。本当にそうなのか?って試してるんですけど。。。 細かく造って、大きくレンダリングして縮小するのと、小さく レンダリングするのと、違うんですね。 その細かさも、ぎりぎりの程度が有る訳ですけど。 チェーンを造って、ベルトに。。。。。 という所で、大本の人体がおかしくなっていて。 昨日は泣きそうになりながら、何とか誤魔化せた模様?^^; |
2690 | Re:レンダリングサイズ | 宮田 URL | 10/22-17:26 |
記事番号2684へのコメント きょうこさん、こんにちは!! >細かく造って、大きくレンダリングして縮小するのと、小さく >レンダリングするのと、違うんですね。 >その細かさも、ぎりぎりの程度が有る訳ですけど。 これは「画像スケールの対応の幅が広い」と思っていて良いと思います。 Web等では600×800以下とか動画では720×480とかで済みますが、 印刷目的とした場合、このスケールでは足りない場合があります。 レンダリング後の縮小は拡大よりも問題は少ないので、大きく創っておけば 小さいサイズにもある程度は対応可能ということですね。 ただ、レンダリング時間は増大しますので、「大きいサイズは必要ない」と 確信できる場合は、その品質よりも時間短縮を優先させる場合があります。 以前に太洋さんが書かれていた「パストレーサは品質を落とすことができる」 というのはこのことを指していると思います。 つまり、時間と品質をトレードできるので、使用の幅が広がるということですね。 |