『１０Dのバグ』のクチコミ掲示板

[ハイフェッツ]

EOS-10Dのバグを発見しましたので報告します。

EOS-10DのJPEGファイルは少しおかしいようです。
いくつかのビューアーでは色の境界部分で細かい縦縞が発生します。
私がいつも使っているPhotoShopLEではそうなりました。
添付ソフトのPhotoShopElements2.0は大丈夫で、ZoomBrowserは縦縞発生します。ソフトによりまちまちです。JPEG規格に微妙に違反しているのだと想像します。

添付ソフトの画像くらいちゃんとチェックしようよ ＞ キヤノン

書込番号：2307672

[ichibey]

どういった状態で見ているのか判りませんが、元データに対し縮小された物を
ディスプレイで見てそういった現象が起きているのならば、10D側の問題でなくて
使われているビューアーソフトの表示データを作成するプログラムのアルゴリズムに
問題が有るだけだと思います(600万画素の画像自体を想定していないからかも)

書込番号：2307711

今までこういう報告が上がって来なかった事を見ると
ハイフェッツさんの環境に問題があるか、
ソフト側の不具合だと思われます。
１０Ｄ側の問題である確率は非常に低いでしょう。

書込番号：2307770

[ハイフェッツ]

アプリの使い方の問題では無いです。
EOS-10Dのバグか、もしくはソフト側のバグです。どちらなのかは不明です。
色の縦エッジのある画像をJPEGファインで撮影して200％拡大して確認しています。注意深く見れば分かるので、同じ現象を確認したという書き込みが出るだろうと予想します。
この現象をJPEG圧縮のせいだと思う人も居るでしょう。違います。ＲＡＷで撮影したものを、後からPhotoShop等でJPEGに圧縮してみるとこのような現象がおきない事で確認できます。

デジタルカメラマガジンＥＯＳ１０Ｄ完全ガイド（オレンジの表紙のやつ）の９５ページで、この現象が起きている画像を確認できます。記事ではJPEG圧縮のせいだとなっています。（分かってないな、この記事を書いた人は）

ちなみに、EOSKissデジタルでも同様の現象が起こります。（Kissのファイルが入手できたので確認しました）
キヤノンは約半年も放置している事になりますね。気付いていないとは思えないので、もしかしたら使用している映像エンジンDIGICのバグかもしれません。

書込番号：2307788

[take525+]

同じ現象かどうかはわかりませんが、Kiss-Dレンズキットの板の［2291345］にも、似たような報告がありますね。
そちらでは、“モアレ”“ニジミ”と表現されてますから、違うのかもしれませんが。

書込番号：2307829

[ＺＺ−Ｒ]

画像をアップしてこれがそうだと指摘して頂けると分かりやすいのですが、ちょっと想像なので良く分からんのですね。

＞９５ページで、この現象が起きている画像を確認できます。
JPEGのブロックノイズのことなんじゃないでしょうかね？

＞ＲＡＷで撮影したものを、後からPhotoShop等でJPEGに圧縮してみると
＞このような現象がおきない事で確認できます。
最初からJPEGに撮影したものと後からPhotoShopでJPEG撮影したものは
違いますよ。

バグというより単にDIGICの限界のような気もします。

書込番号：2308189

[ａｕ特攻隊長]

RAWからJPEGを作る時間と、カメラでJPEGで保存される時間を考えたら、
DIGICでの処理も手を抜いていると想像できると思いますが・・・。
あとは、ソフトの描画性能の違いだと思います。

書込番号：2308281

[ハイフェッツ]

どうも想像による意見ばかりですね。
簡単な事なので、誰か確認してもらえないでしょうか？
EOS-10DもしくはEOSKissデジタルを持っていて、カラフルな被写体を撮影して、JPEGで保存し、ZoomBrowserで色境界部分を拡大表示すると分かります。PhotoShopLEでも良いです。

他の人の環境で発生するか否かという事実が知りたいです。

どのようなビューアーで見ても同一の画像ならDIGICの性能限界という事になりますが(それならなおまずいですけど)、同一ファイルをPhotoShop2.0で見ると綺麗ですので、バグだと判断しました。何のバグなのかが知りたいのです。

私の経験では、JPEGでこのような低圧縮ファイルではブロックノイズは出ません。情報量から言えば1／5程度の圧縮ですが、元ファイルとの比較をするとほとんどのピクセルが1〜2LSB程度の差となります。これは目で見ても差がわからない範囲です。適当な自然画をPhotoShop等で低圧縮JPEG保存して、元のファイルとの比較をすると分かります。（何らかの画像処理ツールを使用する必要がありますが）

書込番号：2308497

[ＺＺ−Ｒ]

＞どうも想像による意見ばかりですね。
＞簡単な事なので、誰か確認してもらえないでしょうか？
私は少なくとも自分のはそう感じませんでしたが、（鈍いのか？）
やはり同じ画像でないと評価下せないと思います。
画像もアップして頂けるとありがたいのですがどうでしょうか？

＞バグだと判断しました。何のバグなのかが知りたいのです。
あなたも結論を急がないように、問題の把握には時間が掛かります。

＞他の人の環境で発生するか否かという事実が知りたいです。
ここが重要、他の人がそれを同じ認識でみるかどうか評価違いますし、
ましてやバグと判断するかはわかりません。

このスレを立てたのは今日の朝ですし、まだまだ見てない方もいます。
丸1日立てばもう少しレスが付くと思います。
まあ時間が掛かるかもしれませんが、ゆっくり待ちましょう。

書込番号：2308544

[PPP01]

＞EOSKissデジタルを持っていて、、、、

キスデジですがZoomBrowser、ペイントショッププロ８、 IrfanViewで

＞色の縦エッジのある画像をJPEGファインで撮影して200％拡大、、

してみましたが、良く分からないないというのが私の意見です。

＞色の縦エッジのある画像をJPEGファインで撮影して200％拡大して確認して＞います、注意深く見れば分かるので

ところでハイフェッツさん200％も拡大して注意深く見れば分かるって
書いてありますが普通にみれば感じないって事ですか。
それともビューアーで等倍の画像を画面に合わせて縮小してみる時に
縦縞がでて鑑賞に耐えないという事ですか？
私の場合は自然風景の撮影ですが、電子アルバムはペイントショップ
プロ８でトリミング後リサイズしています。
縮小によるシャギーはどうしてもでますが余り細かい事は気にしないで
写真全体の雰囲気を楽しんでいます。

書込番号：2308591

[ジャド]

各自で画像を用意するより、ハイフェッツさんがバグだと感じた画像を
どこかにＵｐし、それを皆の環境で試した方が確実だと思いませんか？

ＡのソフトとＢのソフトで同時に表示した画像に差があるという問題は、
ブラウン管(CRT)と液晶(LCD)の各モニタによっても違いますし、ビデオ
カードのチップやドライバによっても変わってきます。

あるLCDならZoomBrowserとElements2.0の画像が違って見えても、あるCRT
では同じに見える・・・という事もあります。

ハイフェッツさんが実際に、ZoomBrowserをElements2.0で、同じ画像を
同時に表示させてPrintScreenで保存し、それをTIFF形式でＵｐすれば、
ハイフェッツさんのモニタ上で何が起こっているのか、皆に伝わります。

そういう再現性のあるデータ提示無しで、発言の１行目から「EOS-10Dの
バグを発見しましたので報告します」と言われても、思いこみが激しい人
なのかな？？という印象しか持てませんし、そういう意見には想像で回答
するしか無いとは思います。

書込番号：2308734

[ハイフェッツ]

実際何が悪いのか自信が無いので、ちょっと挑発的に書いてみました。すみません。でもその甲斐あって、素早いレスですね（笑）

私が指摘しているのは以下です。画像UPしました。
http://www.imagegateway.net/a?i=I1JlMaHnKr
２枚あって、１枚は問題無い画像、もう一枚が問題の画像です。
詳しく調べると、輝度データは問題がなく、色差データの周波数が高い成分が破綻しているようです。

＞ところでハイフェッツさん200％も拡大して注意深く見れば分かるって
＞書いてありますが普通にみれば感じないって事ですか。
ハイ。ほとんど分かりません。
ただ、上の雑誌でも指摘しているように、大伸ばしすると分かると思います。
実は、私が最初に疑問を抱いたのはその雑誌にあるJPEG画像の汚さでした。
私の経験では、2Mbyteを超えるJPEG画像は非常に綺麗です。これほどはっきり汚くはなりません。これはJPEGのせいでは無いのでは？というのが最初の疑問でした。使ってみるとその通りで、破綻なく開く事ができるアプリなら、十分に大伸ばしに耐える画質です。
という事で、文句を付けていますが私はJPEG記録を使っています。（RAWは使っていません。現像処理が遅すぎでとても耐えられません）

書込番号：2308782

[ＺＺ−Ｒ]

＞実際何が悪いのか自信が無いので、ちょっと挑発的に書いてみました。すみません。
＞でもその甲斐あって、素早いレスですね（笑）
あまり感心出来る姿勢では有りませんな。

で、画像ですが確かに分かりました。
しかしですが、普通に見れば問題無いと言ってますし、
画像を200％も拡大して見るのが普通なのかどうなのか疑問に思います。
粗探しのようにも感じます。
私はモニタ等倍まででそこまでしかしませんし
モニタ等倍でも評価はかなり厳しい位ですし
また普段はVIXを使って見てます。

あくまで現時点での私の個人的見解では
画像のアプリの問題なのではと思います。

まあしかしだ自分で納得の出来る使い方もされてるようだし
こんなに挑発的なのはいかがなものかと思ったり思わなかったり

書込番号：2308852

[ＺＺ−Ｒ]

補足しますと画像の拡大表示のアルゴリズムの問題と思います。

書込番号：2308887

[PPP01]

＞ＺＺ−Ｒさん
の言われるように
＞粗探しのようにも感じます。
と私も感じました。

１０Ｄ、キスデジ、ニコンのＤ１００等でも重箱の底をつつけば
何か出てくるような気がします。
おそらく１Ｄｓでも４００％拡大すれば何かでるでしょう。
現実に撮影した６００万画素の画像を等倍以上でみて細かい色ずれなどを
発見しても何も意味ないようなきがします。

＞破綻なく開く事ができるアプリなら、十分に大伸ばしに耐える画質です。
大伸ばしってＡ３とかＡ２とかですか。
でも大伸ばしの印刷物って距離を離してみるからそんなに気にならない
ような気がしますが。
この前プロの方の展示会に行きましたが結構距離離れてみてましたが
わざと近くで見ると（意味ないですが）粒子は粗いしボケもありました。

書込番号：2308943

[ａｕ特攻隊長]

元画像をアップしてほしいですね。
いろいろなビューワーで見てみたいし。

ちなみに、私の見解もアプリの問題が第一だと思います。
100％で見た状態がアプリの手が加えられていない素の画像と言え
ると思います。200％の状態では、アプリによってはジャギーを目
立たないよう手を加えているものもあるかもしれません。

RAWから生成したJPEG画像で同様の症状が発生しないのは、やはり
アルゴリズムの違いだと思います。DIGICって滅茶苦茶シャープな
仕上げにしていますからね。シャープにするために境界部での中間
色を切り捨てているとしたら、ジャギーが発生する傾向になってい
ると思われるし、となると前述のアプリの機能によっては弊害が起
こることになりますよね。

でも、このDIGICの圧縮アルゴリズムをバグと言うべきなのか、で
はD100や*istDのようなソフトな仕上げのほうがいいのか・・・。

何にしても、問題となっている元画像をアップしてください。

書込番号：2308967

私は画像処理を専門としております。

手持ちの画像で問題を確認させていただきました。確かにハイフェッツさんのおっしゃるような縦縞が特に原色同士の斜線境界部に発生します。

結論から申しますとこれはバグではありません。
しかしながら10Dの出力するJPEGは他のメーカーのJPEGと少し差があります。
きれいに出力できるアプリとそうでないアプリがあるのはJPEG展開アルゴリズムの差です。一般のツールではおそらく縦縞が観測されるほうが多いと思います。

かなり専門的な話になってしまいますが興味がある方は続けて読んでください。レスを分けますね。

書込番号：2309062

続きです。ちょっと長くなります。

EXIF規格のJPEGで10DはYCbCr=4:2:2という方式を採用しています。現在ほとんどのデジカメが同じ方式です。
画像は一般にRGBの要素で構成されますが、JPEG画像はRGB->YCbCr(YUV)という異なる色空間に変換されて保存します。Yは輝度、CbCrは色差を表します。

この３つの色成分がY:Cb:Cr=4:2:2の割合で格納されているのですが、つまりCbとCrはYの半分の情報しかありません。半分に間引いて記録しています。
ちなみにEXIFの規格からははずれますが、YCbCr=4:4:4という記録方式もJPEG規格としては存在します。

そしてこの間引き方ですが、横方向に1pixelおきに間引きます。この結果縦の解像度は横の解像度より高くなり、情報欠落によるノイズは縦縞が発生しやすくなります。

ここまでは10Dに限ったことではなくほとんど全てのデジカメ共通です。

次に10Dが他のデジカメのJPEGと異なる点が２点ございます。(他にもあるかもしれませんが…)
1. CbCrの圧縮率がYの圧縮率よりも高い
2. YCbCrの間引き方がCentered(中心)という方式である。一般にCosited(一致)の方が多いです。
1の結果色差の情報量が少なく原色同士の境界にはノイズが発生しやすいです。
2の結果がおそらくアプリによる表示の差につながるのではないかと思いますが、これはCbCrを間引くときに10Dでは2pixelの平均値が格納されていて、Cositedの場合は最初のpixel値を代表させます。EXIF規格では422の場合はCositedが推奨されておりますが、10DのCenteredの方式でも構いません。

私が作成したJPEG DecoderもCenteredのことは考慮していないせいか縦縞が観測されます。おもしろい題材なのでCenteredを考慮してテストプログラムを作ってみようかと思います。

現状で問題を回避したいのであれば、圧縮率を下げるしかないかな？RAWで撮影して現像で最高画質にすると圧縮率の低いJPEGができます。
ただし、JPEGで保存すること自体がこの程度の画像の劣化を許容するということだと私は考えます。

書込番号：2309130

10Dで撮影したテスト画像をJPEG展開のAlgorismを変えて展開してみました。
Link先の最後の画像がテストサンプルです。
ちょっとわかりにくいかもしれませんが、左は縦縞が発生していないのにたいして右は縦縞が境界部に見えます。(テストで一部省略したので左も若干16pixelごとに発生していますが)

左の方式でJPEGを展開しているアプリは余りないかもしれませんね。

いずれにしても10Dの出力するJPEGはFineでも結構圧縮されています。同じ画像をE-20(500万画素)で撮影したのと比較すると、10Dは1.9M、E-20は3.6Mと画素が多いのに画像Sizeは半分です。メーカーや機種ごとに色んな考え方がありますからこれがいいとも悪いとも思いませんが、E-20のJPEGは右の展開Algorismを用いても縦縞は観測されません。

書込番号：2309423

[★ ZERO ★]

ハイフェッツ　さん 、オハヨウ！（＾＾）

　えっと、思いきりハズしてるかもですが・・・(^^;

JPEG画像の大きさって10Dなら　3072x2048　ですよね？
分かりやすく例えば　200x100　の画像があったとします。
これは、つまり200x100個の単色の点の集まりですよね？

これを二倍拡大表示したからと言って400x200にはならないですよね？

ピクセル等倍ってのはJPEG画像のドット数とモニタのドット数が同じって事ですね。
画像の一個の点がモニタ（これも1024x768の点の集まり）の一個の点と同じなのでもしこの時点で色（単色一個の点）の境界部分で細かい縦縞が発生したらモニタの問題となりますよね？

真っ正直にJPEG画像を拡大すると・・・

□□□□□□
□■■■□□
■□■■□□
□■□■□□

って感じになり各ピクセルの色の境に縦縞なんかあるハズないですよね。
もっと拡大すると

□■

JPEG画像が単色の点の集まりぢゃないと言うならちがってくると思いますが・・


こういった事ぢゃないのかにゃ？？(^^;ゞ

書込番号：2309426

２００パーセントに拡大して「問題あり！バグだ！」と叫んだってメーカーは相手にするわけないです。ピクセル等倍を超えてるわけですから。あたりまえじゃん。

書込番号：2309741

[ハイフェッツ]

HayatePP_さん、こんばんわ。

そうです、私が欲していたのは貴方のような意見です！　私も画像処理を専門としています。ちょっと分野が異なるので、JPEG規格自体には詳しくないです。（アルゴリズム程度は知っていますが）
私の扱う範囲は線形フィルタの域を出ません。でも画像の破綻状況から、これはJPEG規格にからむ問題であるだろう事は予想していました。そして、たぶんEOS-10Dのみのせいでは無いだろうとも思っていました。（アプリによって発生したりしなかったりするので。）
JPEG規格の解釈の問題もしくは、アプリ側が未対応の特殊なオプションを使用しているなどを想像していました。

422方式のYCbCrデータについては良く理解してます。HayatePP_さんがおっしゃるCositedとCenteredの違いが今ひとつ理解できませんでした（スミマセン）
理論的に正しい間引き方はデシメーションフィルタできちんとLPFをかけてから間引くべきです。そして、YとCb/Crはサンプリング点が一致（１点おきですが）しているのが普通だと思います。ここが違うのでしょうか？　展開時はちゃんとインタポーレーションフィルタで4:4:4に直すべきです。アプリがこれを怠っている?

＞ただし、JPEGで保存すること自体がこの程度の画像の劣化を許容するということだと私は考えます。

ここは私と意見が分かれますね。JPEGは必ずしも画像が劣化すべきとは思いません。画像の冗長度を無くすのがJPEGアルゴリズム（DCT後に可逆圧縮する事）の本来の目的だと思います。量子化時点で精度を確保すれば情報量を保ったまま元にもどせる事になります。（こんなのは釈迦に説法ですね。。。計算精度および8bitという制限から無理なのは理解していますが。。）

また、10Dの圧縮率はかならずしも高く無いと思います。ベイヤー配列のカメラはもともとナイキスト周波数までの解像度は持っていないため、情報量は600万画素の1/2程度だと仮定して、2Mbyteなら圧縮率は約1/5です。自然画なら、ほとんど劣化なく圧縮できる範囲です。見た目に明らかに劣化が分かるのは問題です。HayatePP_さんの意見では、アプリ側のバグですね。でもそれもキヤノン製なのですが（笑）

P.S.
他の方には、分かりやすく表現するために4倍に拡大表示した事が誤解を生んでいるようです。

書込番号：2310058

[ａｕ特攻隊長]

端から分かっていることや推測していることを全部書いておけよ。
で、JPEGの規格には違反していないんだよね？

書込番号：2310089

[ＺＺ−Ｒ]

何か腹立ちますわな。
＞そして、たぶんEOS-10Dのみのせいでは無いだろうとも思っていました。
＞（アプリによって発生したりしなかったりするので。）
最初から自分の推測も書かずに写真出さずに小出しにしておいて何言ってんの？
200％とか言ってるし普通は拡大して鑑賞などしません
真剣に答えた私がアホでした。

書込番号：2310181

[ハイフェッツ]

HayatePP_さんへ
参考にオリジナルのファイルをUPしておきました。
何かUPした時に何か変更が加わるかとも思ったのですが、そのままでした。
JPEGでセーブして対応していないアプリで開くと問題が見れます。

書込番号：2310202

[ａｕ特攻隊長]

imagegateway、重すぎ。

書込番号：2310249

[ハイフェッツ]

ａｕ特攻隊長さん、はなからキヤノン信者さんたちの意見は期待していませんよ。
キヤノン製品に傷があるといやな人っているんですよね。そういう人と技術的に偏りがない話し合いができるとは思ってません。

私は致命的な問題を除いては、８０％の完成度で合格だと思っています。でもキヤノン製品を売りたい人はそれではダメなんでしょうね。１００％完全という事にしておかないと（人が作ったものなのに、そんな訳ないじゃん）。

最初から特定のアプリで上手く開けないという程度の指摘なのに、なぜそれほど否定したがるのか理解できません。

書込番号：2310274

文系の私としては、なんか、よく分からないけど・・・。
上段からものを言っているみたいで、感じ良くないね。

結局「バグ」じゃないんでしょ?

書込番号：2310359

[ＺＺ−Ｒ]

ハイフェッツさん
＞最初から特定のアプリで上手く開けないという程度の指摘なのに、
＞なぜそれほど否定したがるのか理解できません。
何か言ってることが矛盾してませんかね？
10Dのバグだとか言ってるじゃないですか？
スレッドのタイトルに10Dのバグとか書いて有るけど結局10Dのバグでは無いわけだ。
きちんとバグの言葉を使った件に関して回答してね。

書込番号：2310412

[ジャド]

＞ハイフェッツさん

あの〜・・・[2307672]で最初に書いてた
＞EOS-10Dのバグを発見しましたので報告します。
という文と、[2310058]で書いてる
＞たぶんEOS-10Dのみのせいでは無いだろうとも思っていました。
とでは、諭旨が全く変わってきてるんですけど。。。。(^^;

もう一度、このスレのタイトルを確認されたらいかがでしょ？

皆さんのレスを読んでも、感情的な否定意見も見受けられないし、
一番メチャクチャな事を言ってるの、あなたじゃ無いですか？

単純に、データ不足によってあなたの「EOS-10Dのバグです」という
意見が受け入れられなかっただけなんですけど。。。

書込番号：2310510

他の方に理解していただくために繰り返しますが、これはバグや問題ではありません。Canonに言わせれば仕様だというでしょう。(カメラ側の話です)
CanonはFileSizeを小さくするためにあえてこのパラメータを選択したのだと思います。

JPEG規格はひじょうにゆるい規則で、最低限のルール以外はどのように実装してもいいことになっています。
つまり、例えばTIFFやBMPなどの非圧縮または可逆圧縮FileをJPEGに変換して、それをまたBMPに戻すという例を考えた場合、
1. BMP->JPEG
2. JPEG->BMP
1の結果できるJPEG Fileはアプリによって異なりますし、同一JPEGを展開しても2の結果もアプリによって異なります。

> 理論的に正しい間引き方は…
ハイフェッツさんのおっしゃる方法でも構いませんが、理論的に正しいということはありません。目的に応じて変わってくるのです。
JPEGの歴史は15年くらいですが、その元祖にはインターレスの画像を扱ったり、モノクロ画像を扱ったりなど今の要求と異なるものがありました。
色々述べると長くなってしまうので省略しますが、Encode時はLPFはかけないのが普通かと思います。LPFをかけてしまうとDecodeした画像はLPF処理後の画像になってしまいます。

Decodeに関してはそれこそルールはあまりなくてアプリの裁量に任されているのですが、422->444の補間をNerestNeighberで行うと今回の縦縞が発生します。私のテストサンプルではBilinearで補間したものは縦縞が発生していません。
ただし、BilinearやBiqubicなどで補間する場合はどの点が記録されているかという情報、EXIFのYCbCrPsitioningというParameterが必要になってきます。JPEGにはこの情報はないのです。(先に述べたCenteredとCositedです)
この情報が不明の場合はCositedとして展開するようにEXIF企画書には書かれています。
ちなみにJPEGのEncode/Decodeを自力で行っているメーカーはほとんどないと思います。JPEG協会が公開しているSourceCodeを使用しているか、もしくはEXIF LibraryなどのLibraryを使用しているところがほとんどです。
JPEG協会のCodeはEXIFの情報は反映されませんのでそのまま使用すると縦縞が観測されるでしょう。
PhotoShopLEがだめでPhotoShopElementsが大丈夫ってのもおもしろい話ですね。

それから10DのJPEGのEncodeについてですが、JPEGの圧縮率を決定するのは量子化Tableです。このTableの値が全て1ならば、JPEGは誤差の範囲で可逆となりますがData量はむしろ増えてしまいます。10DのFineの設定では1〜5の値が設定されていて、YよりもCbCrのほうがやや大きな値のTableとなっています。このParameterだとおおむね2〜2.5MBのJPEG Fileとなりますね。
この圧縮率を高いと感じるか低いと感じるかは相対的な感覚ですのでどっちでもいいですが、JPEGは非可逆圧縮です。8bitRGBのTIFFやBMPでは約18MBから1/7以下に圧縮するわけですからそれ相当の情報の劣化は起こります。

> 情報量は600万画素の1/2程度だと仮定して
もしこのように仮定なさるのでしたらこの縦縞は1pixel単位に発生するものですからむしろ甘んじて受け入れないといけないのではないですか？
1pixel単位できちっと復元したいのであれば、私の感覚では1/3〜1/4程度までの圧縮に抑えること、結果としてはOlympusの選択しているParameterくらいが必要と考えます。

> 自然画なら、ほとんど劣化なく圧縮できる範囲です
これはおっしゃる通りです。しかしながらハイフェッツさんの用意したサンプルも私の用意したサンプルもJPEGには厳しい画像です。JPEGはグラフィック画像やアニメ画像など輪郭のはっきりした画像の圧縮には向きません。
そしてカラフルな画像も苦手です。ピントをばっちり合わせたカラフルな静物や風景写真などの場合はよく観察すればこのような問題はでてくるかもしれませんね。

最後に長くなりましたが、縦縞を発生させることなく展開できることは事実ですからアプリに改善の余地はあると思います。
しかしながらここに参加された大半の方々が余り気になさっていないように、おそらく現状は問題視されていないのでしょうね。

書込番号：2310545

[take525+]

こんばんは。

＞ハイフェッツ　さん
わたしは、キヤノン党だニコン党だなんていうのは嫌いなんですが、あなたのこのスレの書き方には賛同できません。
で、ジャドさんの意見に賛成ですね。
（色々な意味で）最初から決めつけないで書かれた方が良いとおもいますが。

書込番号：2310650

[PPP01]

＞ａｕ特攻隊長さん、はなからキヤノン信者さんたちの意見は
＞期待していませんよ

ちょっと言葉が過ぎませんか、投稿者に対して失礼だと思います。
HayatePPさん のような回答を求めるなら最初からその趣旨を
書くべきでしょう。
レポートでも書いてキヤノンへ送付してキヤノンの技術者と
活発な討論でもして下さい。

書込番号：2310666

キャノン信者でもナンでもないんだけど、一言だけ。

文中で「JPEG規格自体には詳しくないです」って言ってるけど、
最初は「JPEGファイルは少しおかしい」って言ってますね。
バグとかオカシイとか否定的な意見を述べる前に、まず規格自体を
勉強されてはいかがですか？
でなければ、「コレっておかしくないですか？」くらいの記述に
とどめるべきだと思います。
相手を否定するときは、しっかりとした根拠、論破できるくらいの
知識を持った上で行うべきだと思います。
首尾一貫しない意見は混乱を招くだけです。
よく分からないときは、もう少し語気を弱めて発言された方がよいとおもいます。
その点、HayatePP_さんの意見は、具体例も出して説得させるだけの意見がありました。

書込番号：2310691

[okkunn]

確かに○○○党の方はいますけど、それなりに節度を守っておられると思いますから（一部そうでない方もいるみたいですが…）、あからさまに否定しなくても良いかと思います。

難しいことは良くわかりませんが、要するに、10DのバグではなくJPG規格の誤差の範囲内である。ということでいいんでないの？

書込番号：2310724

スレ主さん、何の為にシャッターを切ってるのですか？
皆さんの親身なレスを当り前と思わずに感謝の心を持ちなさい。
日本語を勉強し、自己中をやめ、写真をやめなさい。
１０Ｄが泣いてます。
この板にもう来ないで欲しい。

書込番号：2310732

先に言っておくけど、私はキヤノンもニコンももってないからね。

＞EOS-10Dのバグを発見しましたので報告します。
バグ（欠陥）だと不特定多数に対して公言しておいて、
嘘だった場合下手すると訴えられますよ。

今回の場合、HayatePP_氏の言っておられることが正しいとすれば、
「仕様である」としか言いようがありません。
それを、「バグである」と世界に公言されたのですから、
売り上げに影響したキヤノンの方は相当怒っているでしょうね。

いや、私はそんな高尚な技術論は持ち合わせていないので、
HayatePP_氏の意見が正しいともなんとも判断できません。
ただ、ハイフェッツ氏は「バグである」と断言されたのですから、
それを証明する必要はあるでしょうね。


＞どうも想像による意見ばかりですね。
なるほど、そりゃあ想像ではこんなこと書けませんよね。
原因を御自分で特定されてから発言されているんでしょうね。
早く「技術論」で証明された方が良いのでは？

書込番号：2310874

「バグを発見した」とされていますし
「それをキヤノンが知っていて放置しているのでは」
とまで書かれていますので
これが事実に反していれば営業妨害になるのですか？

書込番号：2310883

みなさま　やられましたね。

本題とずれてるかも知れませんが、本来ＪＰＥＧファイルは圧縮する時の数値で（圧縮方法にもよると思いますが）、小数点何位までの計算をして小数点何位までを有効数値とするかで、基本的には圧縮時点で多少なりとも情報（データ）が捨てられてしまうと認識しています。なので１００％元には戻りませんよね。
圧縮と復元の方式が違えばなおさらだと思います。
なので、ソフトの仕様（性能）のようですね。

ＪＰＥＧとは、そう言う物だと思っていました。

HayatePP　さん の説明は大変勉強になりました。

しかし、この流れを見ていると、酔っ払っての書き込み、自分の思い込みや急な攻撃的な態度、主題と自分の書き込み内容がずれてくる所なんか、少し前にハンドルネームをよく変えていたあの人を思い出しました。

まとまりのない書き込み失礼しました。

書込番号：2311022

誤解を招くといけないので、

＞しかし、この流れを見ていると、酔っ払っての書き込み、

の「酔っ払って」は以前のあの人の事なので、今回のスレ主さんの事を言っているわけではありません。

書込番号：2311055

[ＺＺ−Ｒ]

ん〜あの人なのかな〜
パナのFZとかと比較した彼かな
IPアドレスどうでしたっけ？

書込番号：2311078

当時からＩＰアドレスも変えていたので、本人かは分かりませんね。

ただ、なんとなく思い出してしまうような流れだなと思いました。

書込番号：2311132

[ＺＺ−Ｒ]

＞当時からＩＰアドレスも変えていたので、本人かは分かりませんね。
なるほど、まあこのまま回答無しならあの人の可能性が高いかな
何時も書きたいだけ書いて煽りっぱなしだったしね。
とにかくきちんとしたレスが欲しいです。

皆さん駄レスですいません

書込番号：2311146

＞EOS-10Dのバグを発見しましたので報告します。

１０Dの問題と限定し煽る。

＞EOS-10Dのバグか、もしくはソフト側のバグです。どちらなのかは不明です。

１０Dもしくはソフトのバグと方向転換。どっちかは不明といっている
のに最初の書き込みでは断定的書き込み。

＞キヤノンは約半年も放置している事になりますね。気付いていないとは思えないので、もしかしたら使用している映像エンジンDIGICのバグかもしれません。

もしかしたらDIGICのバグとの見解。１０D側の問題と断定的表現
はしていない。

＞それならなおまずいですけど)、同一ファイルをPhotoShop2.0で見ると綺麗ですので、バグだと判断しました。何のバグなのかが知りたいのです。

何のバグか分からないのに最初の発言で断定的表現。

＞実際何が悪いのか自信が無いので、ちょっと挑発的に書いてみました。すみません。でもその甲

分からないのに断定的表現で煽って意見をたくさん貰いたかった。

＞私の扱う範囲は線形フィルタの域を出ません。でも画像の破綻状況から、これはJPEG規格にからむ問題であるだろう事は予想していました。そして、たぶんEOS-10Dのみのせいでは無いだろうとも思っていました。（アプリによって発生したりしなかったりするので。）

突然１０Dのみのせいでは無いと方向転換。
JPEG問題に変更。それもはじめからそう予想していたって・・・。

＞最初から特定のアプリで上手く開けないという程度の指摘なのに、なぜそれほど否定したがるのか理解できません。

アプリの問題と言っている？

すばらしい煽り方とコロコロと手のひら返し！

書込番号：2311452

[ａｕ特攻隊長]

私の今までの発言を全て読めば、私がキヤノン信者ではないことが
分かるだろう。
強いて言えばアンチだろうね。もっとも、アンチキヤノンではなく、
人気があるものに対するアンチだけどね。

まあ、このスレに関して得たものは、自分の間違いを巧いこと誤魔
化した手法くらいだね。

書込番号：2311500

HayatePPさんが言われる通り、JPEGの規格は圧縮時、展開時ともまったく同じデータに成ることが保証されていない（強制されていない）規格らしいので、ソフトによって見た目に差が出るのは、仕方のないことだと思います。

> PhotoShopLEがだめでPhotoShopElementsが大丈夫ってのもおもしろい話ですね。
　フォトショップは前々回のバージョンアップのとき、同じファイルを展開しても得られる画像が違っているというレポートをどこかで見かけたことがあります。
　あれ？
　フォトショップのバージョンが同じでOSのバージョンが違うと画像が違うという報告だったかな？
　どちらにせよ、展開ソフトが違うと画像に差異が出るということで、バグ（規格違反）とは断定できないと思います。

書込番号：2311703

なんだか違う方向に盛り上がってますね(笑)

JPEGは非可逆(元に戻らない)圧縮です。そして品質は圧縮時に決定します。
10DではFine/Normalの２つの設定がありますよね。

アプリによっては「品質係数」というパラメータ設定ができるものがあります。1〜99か0〜100の値を設定するのですが、デジカメの設定値はこの品質係数換算でおおむね90〜99くらいに相当します。10DのFineは95相当くらいでしょうか。JPEGの歴史的にはかなりの高品質な設定ですがデジカメとしては普通です。
PhotoShopをはじめたいていのアプリはもっと直感的な設定に簡素化しているので「品質係数」に相当するParameterはありませんが…

この「品質係数」を10くらいにするとFileSizeは1/50〜1/100程度まで小さくなりますが画像は相当荒れます。それでも画像全体の雰囲気は損ないません。
FOMAとかのTV電話の画像はこれくらい圧縮しています。(動画なんで異なる方式ですが)

画質をできるだけよく、かつデータサイズを小さくしたい…　という要求のもとにできた規格ですが、一方を尊重すれば他方は犠牲になります。

それからアプリによって展開画質が異なることについては、スレ主題の縦縞がでないアプリが優れていて、でるのが普通というのが実情のようです。
特に画像閲覧ソフトの場合は画質を落としてでも高速に表示する方に力を入れている場合があります。世界最速？の閲覧ソフト○CD○eeなんかは画質優先で展開しても高速なのにさらに画質を落として超高速にPreviewします。
PhotoShopのようなレタッチソフトの場合はできるだけ高品位に展開して欲しいところですね。

ついでにJPEGの規格内か規格外かというお話についてですが、デジカメのJPEG画像はDCF、EXIF、JPEGという３つの規格に準拠しています。(話を簡素化しているので厳密には少し違いますがあげあしはとらないでくださいね)
JPEG<EXIF<DCFの順に規格が厳密に決められています。
で、最近のデジカメでは改善されているかもしれませんが微小な規格違反は結構存在しました。私が見た範囲では10DのJPEGに規格違反はないんじゃないかな？
ついでにPhotoShopの出力するJPEGにはEXIFの情報が付加されるのですが、このJPEGはEXIFの規格外です。でもみんなが使ってるので事実上は１つの規格として認められています。世の中こんなもんです(笑)

JPEGに限らず世間には規格外の画像が結構たくさんあって、それらを全てエラー扱いすると現実的ではないためにアプリ側はいろいろ工夫して規格外の画像も展開できるようにしています。
ですから画像によっては展開できるアプリと展開できないアプリがでてきます。この場合展開できないアプリが悪いとは限らないんです。でもユーザーから見ればバグに見えますよね。
メーカーもアプリもそれなりに色んな工夫や努力はしております。お客様の苦情や要望は真摯に受け止めねばなりませんが、寛容な目でみていただければありがたいです(笑)。

書込番号：2311883

[★ ZERO ★]

ハイフェッツ　さん 、オハヨウ！（＾＾）

>>EOS-10Dのバグを発見しましたので報告します。
>>EOS-10DのJPEGファイルは少しおかしいようです。
>>いくつかのビューアーでは色の境界部分で細かい縦縞が発生します。
>>私がいつも使っているPhotoShopLEではそうなりました。
>>添付ソフトのPhotoShopElements2.0は大丈夫で、ZoomBrowserは縦縞発生します。ソフトによりまちまちです。JPEG規格に微妙に違反しているのだと想像します。

>>アプリの使い方の問題では無いです。
>>EOS-10Dのバグか、もしくはソフト側のバグです。どちらなのかは不明です。
>>色の縦エッジのある画像をJPEGファインで撮影して200％拡大して確認しています。注意深く見れば分かるので、同じ現象を確認したという書き込みが出るだろうと予想します。

えっと、ボクの「当たり前」？のレスにレスないですが・・・(^^;

ムズカシーー事はよーわからんのですが・・

（JPEG）画像を４００パーセントに拡大すると１ドットはモニタ上では
　 ■
　 ↓
　■■
　■■

とぴったし４ドットで表示されるからどのソフトでも同じに表示されると思う？

２００パーセントに拡大すると・・モニタ上ではぴったしいくつのドットにはならないと思いますが？
割り切れない分を四捨五入するか？切り捨てるか？切り上げるか？　ソフトによってモニタ表示が変わってくると思いますが？

モニタの表示に限ってはモアレが出る事も考えられますよね？

モアレは同じ１５インチでもXGAとSXGAなど解像度の違いでも出たりでなかったりしますよね？
CRTなら解像度を変えると出たりでなかったりもしますよね？


「ほとしょっぷえれめんつ」がOKで他のソフト（ビューワー）で縦縞が出るってんなら単にソフトの画像（拡大表示）方法？の問題ぢゃないっすか？

画像（拡大モニタ表示）に問題あるのは元画像のバグだって言うのはナンセンスというか支離滅裂なよーなきがしますが・・・・？？？


えっ、ち、ちがう、そんな簡単なことでなくもっとムズカシーJPEG圧縮展開あるごりずむとかの問題？

こ、こりゃシツレイしましたっ。m(_ _)m

書込番号：2312065

[ジャド]

★　ZERO　★さん、オハヨウ！（＾＾）

確かに『拡大表示時に起こる、各ソフトでの差異』については、
★　ZERO　★さんの言われる原因もあると思います。

ただ、今回は『100%での表示時でもビミョーに違う』という問題も含んで
おりまして、その理由はHayatePPさんに教示して頂いた通りでしょう。

ハイフェッツさんが最初の方に「200％拡大して〜」と書き、提示データも
拡大した画像のみだったので、二つの原因が混同されたままだったんです。

この問題は切り離して考えるべきで、拡大時もしくは縮小時に、いかに
綺麗に見せるかは、各ソフトの考え方（画質or速度）及び実力の違いだと
考えれば良いのでは無いでしょうか？

書込番号：2312744

[★ ZERO ★]

ジャド　さん 、オハヨウ!（＾＾）

>>ただ、今回は『100%での表示時でもビミョーに違う』という問題も含んで
>>おりまして、その理由はHayatePPさんに教示して頂いた通りでしょう。

ハイッ、問題は100％でもビミョーに違うかも知れないですが、それを確認するのにソフトの「拡大」機能を使ったことにあるんぢゃないですか？

銀塩写真をルーペで拡大してチェックするのとデジタル画像をモニタ上で「拡大表示」してチェックするのはまったく意味合いが違うと思いますが・・・?
それをハイフェッツさんは同じだと思ってるからアホな書き込みになっちゃったんぢゃないですか？

しかも200パーセント拡大表示でもよく注意してみないとわからないとハイフェッツさんはおっしゃってますね。
その程度ならモニタ表示されるときの誤差?（ソフトの拡大表示あるごりずむ？）と区別つかないと思いますよ。
なかにはちゃん表示される標準添付「ほとしょっぷえれめんと２」なんてのがあるとご本人みずからゆうてますからねぇ〜（＾＾；



>>ハイフェッツさんが最初の方に「200％拡大して〜」と書き、提示データも
>>拡大した画像のみだったので、二つの原因が混同されたままだったんです。

JPEG圧縮展開あるごりずむ？と「拡大表示」あるごりずむ？のまったく別の問題を最初からハイフェッツさんは混同して書き込んぢゃったのが大元のマチガイ？？
さらに原因を安直に10Dのバグに結びつけちゃうなんてただのマヌケなんぢゃないっすか？？


>>この問題は切り離して考えるべきで、拡大時もしくは縮小時に、いかに
>>綺麗に見せるかは、各ソフトの考え方（画質or速度）及び実力の違いだと
>>考えれば良いのでは無いでしょうか？

御意！
デジタル画像をモニタ上で確認チェックするならやっぱピクセル等倍（100％）でするべきでしょう。
それでもモニタで相当の差が出てきますが・・・・めでたくブラックTFT液晶のムラマサGETしたんですが、これフルカラー？がディザ表示のせいか写真は見れたものぢゃないっす。

画像を加工してwebにアップするときなどは「Fireworks」でJPEG保存します。
品質などスライダーで細かく設定できるのでサイズと見え方で決定します。
この時もしも画像の品質？確認しよーと拡大表示（機能はあります）するヤカラがいたら笑っちゃいますが・・・　　今回はその程度の問題だと思いました。

各ビューワーソフトのサムネイル画像品質はまちまちだし、サムネイル画像が汚い？のは10DのJPEG圧縮アルゴリズム？がタコだって言うのと同じぢゃないの?　ハイフェッツさん？




HayatePPさん、詳しいご説明ありがとうございます。
そのへんのところは大まかに理解していたつもりですが、大変参考になりました。

書込番号：2313110

[okkunn]

横道にそれますが
マックではこの様な（ソフトによって見え方が異なる）ことは起こるのですか？
あるいはリナックスではどうなんでしょう？

書込番号：2313224

> マックではこの様な（ソフトによって見え方が異なる）ことは起こるのですか？
Macでも同様だと思います。

拡大表示について色々述べられていますが、画像全体をマクロで評価する場合については★　ZERO　★さんのおっしゃる通り拡大して表示することの意味はないと思います。

しかしながら、私もそうですがハイフェッツさんも画像処理に携わっているようなので処理結果を確認するためにPixel単位のCheckは必要で、その場合は画像を拡大して表示します。私の場合は200%どころか1600%や3200%にする場合もあります。
この場合は画像全体を見ているのではなく、あくまでも一部の領域をミクロ的に観察します。この時の拡大AlgorismはNearestNeighberでなければなりません。Pixelそのものの色を観察するので滑らかに補間されては何の意味もなくなってしまうのです。実際にハイフェッツさんのサンプルも私のサンプルも拡大表示はNearestNeighberにて1pixelが数pixelの正方形で表示されています。

みなさんが1pixelや2pixelのノイズを誤差だと割り切って考えていただけるのであれば我々の仕事はずいぶん楽になるのですが、我々はこの1pixelも大切にしております。この積み重ねが画像全体の画質の向上につながるからです。

画像をマクロで評価する場合はモニタの色温度やガンマ特性などを基準値に一致させて比較することが必要ですよね。我々がミクロに観察する場合は見た目で判断しません。実際のpixel値を1pixelづつ確認します。
同じ画像を相手にしていても見る観点が異なると色々と扱いも違ってくるんです。

ただし画像をミクロに観察することが目的になってしまっては本末転倒ですね。あくまでも全体の画質向上のために行うのであって、ミクロなノイズなどに振り回されてしまうことは意味のないことです。

画像を楽しんでいらっしゃるみなさんの場合はあまりミクロなことにはこだわらず、★　ZERO　★さんのおっしゃるように画像全体〜pixel等倍で確認されるのがよろしいかと思います。

書込番号：2313384

ハイフェッツさんのこういう質問の投げかけがあって、有益な情報を得られるわけで、質問の仕方が・・・とか、キャノンの営業妨害だ！とか　アホらしい

そもそも仲良しクラブ的な雰囲気は腹立つ

書込番号：2313568

[ａｕ特攻隊長]

>ついでにPhotoShopの出力するJPEGにはEXIFの情報が付加されるの
>ですが、このJPEGはEXIFの規格外です。

　Photoshopでトリミングした画像をFUJICOLORネットサービスでプ
リントに出そうとしたら撥ねられました。(^^;)

書込番号：2314243

まっ、
有益な情報かもしれませんが、
不快な表現であることも否めません。
HayatePP_さんが懇切に解説をして下さっているのは
良く伝わってきますが…（これはこれで有難うございます。）

でも、ａｕ特攻隊長さんの名誉のために一言。
ず〜と、見てるけど、「隊長さん」は、
いつも、クールに、的確に、親切にレス入れられてます。
このクールってのは、「商品に中立」というニュアンスです。
キヤノンびいきなんて、全然感じてません。

大抵　素早いレスなので、それこそスレの「切り込み隊長」
という感じです。頼もしい!!!

ＺＺ−Ｒさん 、take525+さん、その他の方々も、
普通の「書き方」で、分かりやすく、熱心なぐらいに情報を
伝えてくれていますよ。

どうせなら、「書き方」も配慮しましょうよ。
横道にそれましたが。。。

書込番号：2314540

[ａｕ特攻隊長]

＞みつばパセリさん

ありがとう。
これからも冷たく行きます。(^^;)

書込番号：2314618

[ハイフェッツ]

HayatePPさん、こんばんわ。

どんな人にも真摯に対応されるのは、感心します。
私なんか、反論する気にもならないレベルの書き込みはそのまま無視してしまいます。

＞他の方に理解していただくために繰り返しますが、これはバグや問題ではありません。
＞Canonに言わせれば仕様だというでしょう。(カメラ側の話です)

私に言わせればこれはバグですね。欠陥でも不具合でも名前はなんでもいいですけど。
規格に準拠しているからとか、設計者が想定した通りに動いているからとかは、作る側の理論ですよ。
使う側にしてみれば（特に素人相手では）使って問題があればそはバグです。
規格通りだからという理論で赤いDVDを売りつづけているジブリには腹が立ちますけど、今回のは些細な事なので、こういうバグがあるよと指摘する程度です。
結局、割を食うのは購入者で、仕様なのならば今後改善される見込みも無いという事になりますね。

CenteredとCositedの違い、理解できました。問題の出ている画像データのCb/Crも確認しましたが、確かに縦２ピクセルおきに変化していました。これが原因なんですね。
良くわからないのは、Centeredの時になぜ０次補間してしまうのかですね。サンプリング位相が違うだけなのだから普通に補間すれば問題が出ないでしょうに。輝度と色が０．５ピクセルずれる事になりますが、さすがにこれは気付かないと思います。

＞このTableの値が全て1ならば、JPEGは誤差の範囲で可逆となりますがData量はむしろ増えてしまいます。

これは初めて知りました。冗長度が減る分、データサイズは減る物だと思っていました。JPEGで使用している可逆圧縮部分の性能があまり良くないと言う事ですかね。


＞＞ 情報量は600万画素の1/2程度だと仮定して
＞もしこのように仮定なさるのでしたらこの縦縞は1pixel単位に発生するものですからむしろ甘んじて受け入れないといけないのではないですか？

これはさすがに乱暴な意見なのでは？
1pixel以内なら、どんな変更を加えても良いというものではないでしょう。情報が無い部分はできるだけ自然に補間する必要があります。

＞1pixel単位できちっと復元したいのであれば、私の感覚では1/3〜1/4程度までの圧縮に抑えること、結果としてはOlympusの選択しているParameterくらいが必要と考えます。

オリンパスサイトのE-1のサンプル画像で、TIFFとJPEGでどの程度差があるのか確認してみましたが、ピクセルの約半分が同一値、約４割が１LSBの差、約９９％が２LSB以内の差となっていました（RGBトータルでの統計）。圧縮率は1/6程度です。このくらいなら十分でしょう。これ以上を求めても、見た目には差を確認できません。オリンパスのJPEG(SHQ)3.8MB はちょっとやりすぎのように思います。

最後に、
＞CanonはFileSizeを小さくするためにあえてこのパラメータを選択したのだと思います。
私は、今回の事実を知っていてなおキヤノンがこのパラメータを選択したのだとは思えません。問題の処理はDIGIC内部に実装されていると想像しますが、これを作成したチームはHayatePPさんほどJPEGに精通していなかったのだと思います。あらかじめいくつかのアプリで問題になる事を知っていれば、Centeredは使わないでしょう。
422へのデシメーション時にLPFをかけずにサンプルを間引くのは随分乱暴なやり方です。エイリアッシングが思いっきり出ますので、これを嫌ったのではないかと思います。キヤノンはモアレをかなり気にしているようなのでこれは正常な判断ですが、世間に出回っているアプリがどういう状況なのかまでは把握できていなかったのでは？

書込番号：2315026

[ジャド]

みなさん・・・これ以上荒れないようにしましょうね。(^^;

書込番号：2315173

[ＺＺ−Ｒ]

言動が頃々変わり自分の都合の悪い部分すべて無視してるようですし
どうぞ、勝手にやって下さい。

HayatePPさんも大変ですね。

書込番号：2315523

> 私に言わせればこれはバグですね。欠陥でも不具合でも名前はなんでもいいですけど。
改善すべき項目であることはいうまでもありませんね。
ただこの程度のことに目くじらをたてるのはどんなものかと思います。ハイフェッツさんのような専門家は気づきましたが他の人は問題の存在にすら気づいていないわけです。

Centered/Cositedの意味がわかるとはお手元にEXIFの規格書をお持ちなのですね。
２つの方式が用意されている理由は非常に長くなるので省略しますが、意味があってのことです。
CanonはCRWからの現像処理の方式にも共通して解像度よりも画像の滑らかさや偽色抑制を重視しているようです。その観点から考えるとCenteredの選択は間違っているとは思いません。
しかし世の中のJPEG DecoderがほとんどCenteredに対応できていないことにはCanonも気づいていないでしょうね。

ちなみにこの現象は程度の差はありますがCositedにしても発生します。422->444の補間方式によるのでDecoderしだいです。

DIGICがどうなっているかは知る由もありませんが、JPEG DecoderがCanonの設計とは思えないんでどっかから買ってきたんじゃないかな。ASICの世界もだいぶ高級言語化が進んでいますので移植は簡単です。
で、もし改善するつもりがあるならばF/Wにて調整が可能な可能性が高いです。私が設計したASICならばParameter調整できるようにしますから。

1pixelの誤差の話についてですが、正直いってこれはCMOSがベイヤー配列であることからも重視していないのだと思います。ベイヤー配列ってのは悪く言えば1pixelは滑らかにごまかす方式ですから。

OlympusのParameterは私もやりすぎだと思います。
ハイフェッツさんの画像の評価方法は１つの大事な方式ですが、JPEGの可逆性のCheck方式としてはダメです。仮に99%のpixelが完全に一致していたとしても、残りの1%が重要だからです。JPEGのノイズは画像輪郭部に集中します。人間が視覚的に注視する領域に集中してしまうのです。人は輪郭部以外は実際は詳細に見ていませんので、おそらく平均的には画像の5%以下であろう輪郭部で画像の劣化を評価する必要があります。
ハイフェッツさんご専門の線形フィルタとは少し違った目で見る必要があります。

今回のハイフェッツさんのレスは厳しい意見としてはその通りだと思います。
ただ１点だけ考えていただきたいのはこの問題によって被害を被るユーザーがどれだけいるのか？ということです。
ほとんどの方は問題にすら気づいていないことと、仮に気づいて気にされる場合にRAWで撮影してTIFF現像するという高品質画像を得る手法が用意されていることでいいのではないでしょうか？

JPEGはあくまでも非可逆圧縮です。1pixelどころか最大16x8pixel単位で画像は劣化します。とくに画像輪郭部はJPEGの苦手なところです。
なので私はJPEG画像にpixel単位の精度は求めません。そして状況の許す限りはRAWで撮影しております。
ハイフェッツさんもRAWで撮影されたらいかがですか？

余談ですが、これは私の持論ですが、画像工学の特殊性は最後は人が目で見てどう感じるかで評価されるということです。
例えばアンシャープマスクなどははっきりいって画像を壊すフィルタです。でも一般受けする画像の作成にはかかせません。なぜだか考えたことがありますか？ちらっと見ただけで注視したのと同様の効果があるからです。視細胞の応答レベルで考えれば理屈づけできます。
さらには理屈づけできない視覚効果もいっぱいあります。
JPEGは優れた画像圧縮技術だとは思いますが、人間の目にはここちよくない画像の壊れ方をします。これでもかなり人の感覚を意識してProgressive方式などは設計されているんですがね。
こんな話を続けると大学の講義みたいになってしまいますね(笑)

書込番号：2315527

ハイフェッツさんの問題提起は私にとっては色んな問題を再認識させられて面白かったです。

> 仕様なのならば今後改善される見込みも無いという事になりますね。
そんなこともないんじゃないかな。少なくとも添付S/Wは改善されるかもしれないですね。
10DのJPEGをCheckしましたが、D30には見られた些細な問題も改善されていました。ちょっとしたことでも気づけば対応しているということです。

> 冗長度が減る分、データサイズは減る物だと思っていました。JPEGで使用している可逆圧縮部分の性能があまり良くないと言う事ですかね。
これはちと違います。JPEGのHaffman符号化はJPEGの量子化を前提にTuneされていることと、EXIFの規格でHaffmanTableが固定されていることに起因します。
EXIF規格を無視してHaffmanTableを最適にするだけでもDataSizeは何割か(結構でかい)減るんですがね。H/Wで処理すること前提につくった規格なんでしかたないかな。
ということでアプリでFile保存する場合はEXIFより非EXIFのJPEGの方がFileSizeは小さくなります。JFIF422というのを選択すれば画質はEXIFと変わりません。(そんなの選択できるアプリがあるかは不明です(笑))

書込番号：2315581

久々の返答を見ると、大多数の人があきれ返っていることに全く気づいてないようですね。
しまった、煽りに乗ってしまった・・・

書込番号：2315992

ａｕ特攻隊長さん。

決して、「冷」と言う意味じゃないですよ。
かっこいいクールです。
（お分かりになってるとは思いますが…）
　　私の方が、いつも情報ありがとうデス。(^O^)

書込番号：2316612

[★ ZERO ★]

okkunn　さん 、HayatePP_　さん、オハヨウ！（＾＾）

>>> マックではこの様な（ソフトによって見え方が異なる）ことは起こるのですか？
>>Macでも同様だと思います。

モニタガンマ値の違いで、キャリブレーションとってない場合Ｍａｃの方が目立たないと思いますよ?

そもそもＪＰＥＧって大まかな規格だと思ってます。
ミノルタディマージュXtのJPEG画像はよく使っているMacのソフトでは表示されませんでしたがJPEGだからこんなこともあるよなと思っただけです。
初期のリコーのデジカメは日本独自のJPEG規格？ってんで拡張子「J61」（たしか？）でしたね。
細かいことは覚えてないですが、ワープロ等に貼りこんだ時に反映される解像度情報が付いてて便利だったよーな？


ボクは１０ＤのJPEGは好きで気に入ってます。
サンプルとか見てホントーかよとお店にＣＦ持ち込んで試し撮りしたのが運のツキでした。(^^ゞ


HayatePP_　さんのおっしゃるように１０ＤのＪＰＥＧが気に入らなければRAWで撮影すれば良いだけ。

ぢつはココだけの話ですが、最近１０ＤのDIGIC@ＪＰＥＧの限界が見えてきまして・・・
丁寧にRAW現像された画像ってホントキレイだし良い感じに色も出てるんですよね。
まぁRAWだからキレイってわけでもないですが、ＪＰＥＧだったらちとムリだよなって画像を良く見かけるよーになったものですから。


１０Ｄの場合JPEGもRAWファイル内に格納されちゃうからちと躊躇してます。

ボクは場合によっては半日で軽く２Ｇ位撮影しちゃいますので。(^^ゞ
RAWなら当然撮影枚数は減りますが、それでもいちいちJPEG取り出すのがメンドーに思えちゃうんですよね。

別フォルダー保存ならJPEG即チェックできるし、RAW現像したいファイル以外捨てちゃえばいいだけですからね。

おそらく、現像したいと思う写真はあまりないと思うから余計に迷っちゃうんです。

書込番号：2317072

[★ ZERO ★]

みつばパセリ　さん 、オハヨウ！（＾＾）

>>どうせなら、「書き方」も配慮しましょうよ。

すんましぇ〜ん、つい地が出てしまいましたっ。m(_ _)m

書込番号：2317373

RAW撮影はお勧めしますよ。容量が足りるならばメリットはいっぱいあります。
めんどうな点はありますが、より高品位を求めるのであればそれは我慢してください。

WBの設定から解放される点が最大のメリットだと思いますが、露出も±1EV程度までなら調整可能です。失敗写真は減りますし、WBの調整で作品の印象も変わります。
10DのAWBは優秀ですが、白熱灯など屋内は結構狂いますから。

増感が効くのを利用してSSを上げることもできますし、外部ストロボ使用中にFullCharge前に撮影しちゃってもなんとかなります。一瞬のタイミングは待ってくれないですから。

RAWだからといって撮影が雑になってしまっては本末転倒ですが、現像処理まで自分で行うことはフィルムではできなかった新しい世界が開けます。

私の考えでは高いレンズをそろえる前にRAWで撮影したら？って思います。手間さえかければただで画質向上はできる分野があるんですから。

書込番号：2317468

★　ZERO　★さんへ、　こんばんわ。　（^_^）

そんな、謝られるような書き方されてませんよ。
楽しく読ませて頂いてます。
ご心配なく。。。

ところで、
HayatePP_さんによって、RAW撮影のメリットが
一層魅力的に感じられたのは、このスレ一番の収穫。
RAW、もっと活用しようっと。

書込番号：2317519

[ａｕ特攻隊長]

＞みつばパセリさん

>決して、「冷」と言う意味じゃないですよ。

分かっとります。
これからも頑張ります。

書込番号：2318096

[ジャド]

ＲＡＷで撮るなら、ぜひ現像ソフトもいろいろお試し下さい。　＞　皆様

過去スレにも多く話題が出ていますが、現像ソフトによって、価格はともかく
ニッコールとプラナー程度の差は出て来ます。(^^;

私は、ポートレート以外は「源蔵」というフリーソフトを使ってます。

キヤノンの付属ソフト「File Viewer Utility（FVU）」との比較画像をＵｐ
してますので、参考程度にご覧下さい。
http://prime.lib.net/camera/photo/hikaku.jpg

ちなみに、源蔵の標準シャープネスは「７」ですが、ちょっとカリカリな
気がするので、やや弱い「５」にしています。

上記画像は、一部分のピクセル等倍です。全体画像の縮小版は↓こちら。
http://prime.lib.net/camera/photo/db_g.jpg

書込番号：2319009

[ハイフェッツ]

HayatePPさん、こんばんわ。

＞ただこの程度のことに目くじらをたてるのはどんなものかと思います。

目くじらをたてたのは私でしょうか？
他の人が、私が『EOS-10Dのバグ』と書いた事に対して目くじらを立てたのではないでしょうか。
とにかくこういう書き込みをされるのが嫌な人が多いようですね。

＞ハイフェッツさんのような専門家は気づきましたが他の人は問題の存在にすら気づいていないわけです。

私も、これには驚きました。既出かな？と思ったのですが、18000件もの書き込みを読む気には到底ならず、とりあえず書いてみたのですが本当に私が最初なのでしょうかね？
確かに問題の発生するアプリは限られていますので、購入者でこの現象に遭遇した人はそれほど多くないとは思います。でも何人かは居るのではないでしょうか。なぜ誰も報告しないのでしょうね。みんなキヤノンに対して好意的だから？
他の書き込みをいくつか読んでみると、傷があって交換したとか、気泡があって交換したとか『それをここに書いて誰の参考になるの？』と思うような事まで書いてあるのにです。
工業製品には有る一定の割合で不良品が有るのですよ。カメラだけでなく全部の工業製品にね。
（べつにHayatePPさんに言っているのでは無いですよ。）

掲示板を読むと、私以上に細かい事が気になる人が多いようですね。でもなんかこだわっている場所が違いますね。EOS-10Dの箱を開けたとき、和紙？のようなものでつつんであって『なんで？』と思いました。レンズには立派な袋も付いていて、『おまえはシャネルのバックか!』と思わずつっこんでしまいました。この掲示版を読んで、その理由がやっと分かりましたよ。キヤノンも気を使うわねこれじゃ。こういう部分に手間がかかるから、今回のようなのが見過ごされるのかもしれません。

＞ハイフェッツさんの画像の評価方法は１つの大事な方式ですが、JPEGの可逆性のCheck方式としてはダメです。仮に99%のpixelが完全に一致していたとしても、残りの1%が重要だからです。

反論できません。おっしゃる通りです。ちょっと理由としては甘いかなとも思ったのですが、見逃してくれませんね（笑）。厳しいご指摘ありがとうございます。

＞ハイフェッツさんもRAWで撮影されたらいかがですか？
HayatePPさんの言われるように、細かい画質が気になる人はRAWモードを使うべきですね。私もそう思います。私にはちょっとした理由があって、あえてJPGEを使用しています。
私のPCが少し前のもの（P3-600MHz)なので、現像処理が遅くていやなのです。それとある程度の枚数を処理する必要があり、RAWデータでは時間がかかりすぎて困ります。HayatePPさんも毎日数十枚を自分の納得のいく画像になるように仕上げて見れば分かると思います。PCを買い換えようかなとも思います。
またJPEGでも撮影時にきっちりと露出と色温度を合わせてやればRAWと仕上がりはほとんど変わらないと思います。後から直そうとするより、撮影時にちょっと手間をかけた方がトータルで時間の節約になるのですよ。

＞余談ですが、これは私の持論ですが、画像工学の特殊性は最後は人が目で見てどう感じるかで評価されるということです。
まったく賛同します。目のモデルを作って画質を数値化できないだろうか？などと本気で思った事もあります。そしてそれを逆に解いて、与えられた条件で最も良い画質となる画像を作るとかなど。思っただけでとても実現は無理そうですけど。

＞例えばアンシャープマスクなどははっきりいって画像を壊すフィルタです。でも一般受けする画像の作成にはかかせません。なぜだか考えたことがありますか？
なぜだかを本気で考えた事はないですね。とりあえず、人間が物を認識するのにはエッジが重要だから程度に思っていました。画像を拡大するとエッジがなくなって、とても『嫌な』画像になりますよね。適当に処理をしてエッジを保存してやると見た目にすっきりします。人はエッジをたよりに物を認識しているのだなと感じていました。

書込番号：2319026

> HayatePPさん

キヤノンのデジカメを古いものまでさかのぼって調べましたところ、
コンパクトデジカメも含めてかなり初期の段階からcenteredを採用し
ているようです。ですから、Digic云々は関係ないでしょう。キヤノン
の流儀のようなもので、なぜこの方式を採用したかは想像するしかあ
りませんが。

> ただ１点だけ考えていただきたいのはこの問題によって被害を被る
> ユーザーがどれだけいるのか？ということです。
>
数年前からcenteredが採用されているので、この問題自体は数年間放
置されていたということになりますね。その間誰も問題視することな
く改善されていないわけですから、結局その程度の問題ということな
んでしょう。ユーザーレベルでは問題ですらなかったとも言えます。

とはいえ、一方でPhotoshopなどの一部のソフトでは対応が進んでいる
のも事実です。LEがダメだというのはすでに出ていましたがElements
のVer 1.0も対応していませんでした。Ver 2.0から対応していてEXIF
タグの情報をちゃんと使ってますね。簡易版でないPhotoshopでは7.0,
CSですでに対応しています。いつから対応しているのかは不明ですが、
Elements 1.0と同時期だと思います。

この問題が顕在化するような利用者は当然Photoshopなどのソフトを使っ
て印刷とか行っているでしょうから、実はこの件はすでに解決していて
現時点及び今後は何の問題も生じないように思われます。

さて、ここからは質問なのですが、画像ビューアソフトなどでEXIFから
co-sited/centeredの情報を読み取り、伸張を正しく行うように設計した
場合、速度的にどの程度のデメリットが生じるのでしょうか？ もし速度
が大きく低下するようであればこの程度のミクロな画質の向上よりも動作
速度の方を取りたいのですが、速度的に何の問題も無ければ今後は他の
画像ソフトもきちんと対応してもらいたいと心情的には思います。(それ
以前に画質を落として速度向上しているのがあればあまり意味が無いで
しょうが。)

それと、これは本題から大きく外れるですが、EXIFの規格書に目を通
していますと、YCC=422の場合はco-sitingが推奨されていてYCC=420の
場合はcenteringが推奨されていますがこれはなぜなんでしょうか？
前者はTV system、後者はPCのアプリ用とか書かれているのもピンと
きません。簡単に説明できるのであれば教えてください。話せばとて
も長くなるのであれば無視してください。

書込番号：2319200

> co-sited/centeredの情報を読み取り、伸張を正しく行うように設計した場合、速度的にどの程度のデメリットが生じるのでしょうか？
境界条件を厳密に処理する場合は上下左右のMCU Blockを参照する必要がでてくるためにAlgorismの変更を強いられる可能性がありますが、速度的にはほとんど変わらないで処理できるはずです。

> YCC=422の場合はco-sitingが推奨されていてYCC=420の場合はcenteringが推奨されていますがこれはなぜなんでしょうか？
私も正確な理由がわかるわけではありませんが、そもそも２つの方式の特徴は、
Cosited: Sampling位置が一致していることと、平均化処理を行わないためによりシャープな画像が残せる半面情報が非均一に間引かれるために画像の滑らかさが損なわれます。
Centerd: 画像は滑らかになりますがぼけた感じになります。

で、画像をモニタに表示する場合はシャープを大事にすることから一般にCositedが推奨されているようです。
いま１つはインターレース画像を扱う場合にYCbCr420でCositedを使用すると偶Lineと奇Lineが同等に扱われなくなると困るので、420の場合はCenteredにしろってことのようです。
ちなみに422の場合に横方向に間引く理由はインターレース画像を意識してのことです。

私はデジカメ画像の保存にはCenteredの方がいいと思いますが、いずれにしてもこれらを考慮して展開しないならばどっちもどっちです（笑）

ちなみに現在のデジカメはより高画質に画像を保存するために422で保存していますが、EXIF規格ができた当時、つまり初期のデジカメは420で保存していました。画質よりも保存枚数を重視してのことだと思います。つまりEXIF規格もデジカメ画像の場合はCenteredを推奨していると読み替えてもいいと私は思います。

書込番号：2319703

スレ主題からはずれてきましたが、ハイフェッツさんのような方にこそRAWを使用していただきたいです。
他の方も容量さえ足りるのであればRAW撮影を一度は試していただきたいです。

> JPEGでも撮影時にきっちりと露出と色温度を合わせてやればRAWと仕上がりはほとんど変わらないと思います。
おっしゃる通りですが、RAW撮影ならばその露出と色温度に気を使う分他に集中できます。また露出を±0.5EV替えて3枚撮影なども不要になります。さらに撮影時には意図できなかったWB調整を撮影後に行うことも可能です。

> 後から直そうとするより、撮影時にちょっと手間をかけた方がトータルで時間の節約になるのですよ。
これもその通りなんです。後から直すことを前提としてRAWを使用するのは本末転倒だと思います。後から直すことも可能という可能性を残すことが大事だと思います。

10DはCRWで撮影してもJPEG画像を内包できます。設定を変更すればLarge/Fineものこせます。Data量はさらに増えますが、だいたい8MB/枚です。
私はCRWで撮影して、まずは一括してJPEG分離します。これはそんなに時間はかかりません。むしろCFからPCにCopyするほうがよっぽど時間がかかります。
分離したJPEGで満足できればそれを使用します。修正が必要な場合にはじめてCRWから再現像します。
トータルでの時間の損失は私には感じられません。むしろ再撮影が減るので時間も節約できくらいに感じております。
実際はレタッチの可能性が増える分時間はかけているかもしれませんが、それはその分画質も向上させているので納得しております。

FVUはさすがに重過ぎるのであまりお勧めはしにくいですね。Canonに改善してもらいたいところです。
でもFVUでも基本的に分離したJPEGの使用が前提なら耐えられますよ。

私は自社製品のプロトタイプを使用しているのですが、完成したらみなさんに使っていただきたいです。10Dの現像は私が趣味と実益を兼ねてTuneしているのでいい出来ですよ。ここで宣伝すると怒られるので内容はあいまいなまま終了します（笑）
でも正直いってここでお近づきになれた皆さんにモニタになっていただきたいです。

書込番号：2319906

[okkunn]

HayatePP_さん、★　ZERO　★さん
回答ありがとうございました。

JPEG規格に拠るのですね

書込番号：2320379

[★ ZERO ★]

HayatePP_　さん オハヨウ！（＾＾）

>>増感が効くのを利用してSSを上げることもできますし、外部ストロボ使用中にFullCharge前に撮影しちゃってもなんとかなります。一瞬のタイミングは待ってくれないですから。

増感ですけど、ノイズが気になりますよね。
RAWだとノイズ発生面でも有利なんでしょうか？
ISO800で撮影してISO100で現像するとか?(^^ゞ



>>私はCRWで撮影して、まずは一括してJPEG分離します。これはそんなに時間はかかりません。むしろCFからPCにCopyするほうがよっぽど時間がかかります。

JPEG分離作業はFVUでしかできないんですよね。
1Gマイクロドライブ満タン転送時間は約5分ちょいですが（Firewireリーダー）、分離作業はそれ以下なのかな？



ジャド　さん 、オハヨウ！（＾＾）

>>私は、ポートレート以外は「源蔵」というフリーソフトを使ってます。

源蔵はダウンロードだけしてありますが(^^;、　ポートレートはやっぱFVUをお使いなのでしょうか?

それぞれの現像ソフトで特徴があると思いますが、使い分けができるのはやっぱウィンドウズならでわですよね。(^^;









みつばパセリ　さん、オハヨウ！（＾＾）

>>そんな、謝られるような書き方されてませんよ。
>>楽しく読ませて頂いてます。

うふっ、そですか？
ぢゃ、も一発かましますね。（＾＾）
↓



okkunn　さん 、オハヨウ！（＾＾）

>>JPEG規格に拠るのですね

だと思います。

展開して見ることもできないと言う取るに足らないホンの些細な問題が起こることもあれば、200％拡大し更に良く見ないと分からない縦縞が出るというきわめて深刻で重要、緊急度最大な問題が起こることもあるということですよね。　>ハイフェッツさん(^_-)

書込番号：2321409

そろそろこのスレも終焉でしょうか（笑）

> 増感ですけど、ノイズが気になりますよね。
> RAWだとノイズ発生面でも有利なんでしょうか？
ISO400までなら+1EV程度までいけると思います。それ以上はノイズが目立ってきますね。

> ISO800で撮影してISO100で現像するとか?(^^ゞ
-3EVで現像するってことですよね？これはダメです。
そもそも明るく撮影しておいて露出をマイナス補正するというやり方はダイナミックレンジの狭いCCD/CMOSではできないです。
CMOSがOverflowしないぎりぎりで使用できればS/Nはいいのは事実ですがそんな制御は難しいでしょう。

> JPEG分離作業はFVUでしかできないんですよね。
そうかもしれませんね。FVUでも同一Folder内の画像は一括処理できますから１画像づつ行う必要はないです。
Canonは100画像毎にFolderを切り替えてしまうんで、HDDにCopyする時に1つのFolderにまとめてそれから一括分離すればいいと思います。

> 1Gマイクロドライブ満タン転送時間は約5分ちょいですが（Firewireリーダー）、分離作業はそれ以下なのかな？
それ以下の時間でできます。
間違ってもCFから直接行ってはいけませんが。必ずHDDにCopyしてから行いましょう。

> HayatePP_　さん オハヨウ！（＾＾）
ところで★　ZERO　★さんの起床時間はいったい何時なんでしょう？（笑）

書込番号：2321591

ひとつ質問！

Small/Normalの画質ってこんなもんじゃないの？
どんなソフトで開けたって・・・

なんで、Large/Fineで撮らないかが不思議（笑）
イメージゲートウエイのはオリジナルでしょ？

書込番号：2323775

祝？　白熱ランキング第１位　　
確かにとてもいいカメラだけど、そこまで気にして使うぐらいのカメラなの？
初心者には全くついてけませ〜ん（初心者が使うなって？）

書込番号：2325695

[★ ZERO ★]

HayatePP　さん 、オハヨウ！（＾＾）

>>> 増感ですけど、ノイズが気になりますよね。
>>> RAWだとノイズ発生面でも有利なんでしょうか？
>>ISO400までなら+1EV程度までいけると思います。それ以上はノイズが目立ってきますね。
>>
>>> ISO800で撮影してISO100で現像するとか?(^^ゞ
>>-3EVで現像するってことですよね？これはダメです。
>>そもそも明るく撮影しておいて露出をマイナス補正するというやり方はダイナミックレンジの狭いCCD/CMOSではできないです。
>>CMOSがOverflowしないぎりぎりで使用できればS/Nはいいのは事実ですがそんな制御は難しいでしょう。

えっと、ちょっと理解しにくいのですが・・(^^ゞ
+1EV　or　-3EV　ってのは露出補正？ですよね？

現像時に露出補正かけるということでしょうか？
現像時の露出補正具合でノイズの出方が変わる?ということ・・・でしょうか？？？


ISO400のノイズ？はボクにとって許容範囲？です。
ISO800でも被写体によってはほとんどノイズ気にならない場合もあるのですが、場合によって盛大に出たりしますね。(^^ゞ
これがある程度緩和？されれば良いなぁ〜と思ったものですから



>>> 1Gマイクロドライブ満タン転送時間は約5分ちょいですが（Firewireリーダー）、分離作業はそれ以下なのかな？
>>それ以下の時間でできます。
>>間違ってもCFから直接行ってはいけませんが。必ずHDDにCopyしてから行いましょう。

なるほど・・JPEG抽出時間は気にならないですね。
FVU現像処理はやったことないですが、ビューワーとしての処理速度は悪くないですからね。（使い勝手は悪いけど(^^;）

書類を開く場合必ずCFからHDDにコピーして行うのは「お約束」ですね。(^^ゞ






>>> HayatePP_　さん オハヨウ！（＾＾）
>>ところで★　ZERO　★さんの起床時間はいったい何時なんでしょう？（笑）

ボクは24時間稼動であります。
電源確保できない場合大容量リチウムイオンで駆動しておりますです、ハイッ！（＾＾）
ま、ギョーカイでのフツーのご挨拶ということで・・(^_-)

書込番号：2328121

> えっと、ちょっと理解しにくいのですが・・(^^ゞ
> +1EV　or　-3EV　ってのは露出補正？ですよね？
そうなんですが、デジカメでは現像処理時のデジタルのGain調整も可能なために同様の表現をしております(FVUもそうです)。で＝増感とも称しています。
フィルムとは処理形態が異なるのでややこしいのですが、デジカメは撮影部、フィルム相当部(CMOS)、現像処理を全てこなしますので対効果で言葉の適用範囲を拡大しております。+1EVは2倍明るくするってことです。

2倍明るくすればノイズも2倍目立つので、ISO400では+1EVが限度かなってことです。

高感度でのノイズはデジタルの場合はフィルムの粒子荒れとは違って非常に低周波のカラフルなノイズのために私には不快です。高周波ノイズと違って除去は難しくかつ処理時間もかかります。ただいまこの辺に挑戦中です。

そもそも「現像処理」って言葉もいいのか？って思ったこともありましたが、CMOSの観測値から像を作成するという意味で銀塩とは異なる意味の現像でいいのかなって思っております。
できるだけ従来の言葉に当てはめるのはわかり易い反面誤解も招くので注意は必要ですね。

書込番号：2329048

[★ ZERO ★]

HayatePP　さん 、オハヨウ！（＾＾）

>>> +1EV　or　-3EV　ってのは露出補正？ですよね？
>>そうなんですが、デジカメでは現像処理時のデジタルのGain調整も可能なために同様の表現をしております(FVUもそうです)。で＝増感とも称しています。

ふ〜む、なるほど・・・・とワカッタフリしときます。(^^;ゞ
まぁ、実際にRAW撮影して色々といぢってみれば分かる事ですね。



>>フィルムとは処理形態が異なるのでややこしいのですが、デジカメは撮影部、フィルム相当部(CMOS)、現像処理を全てこなしますので対効果で言葉の適用範囲を拡大しております。+1EVは2倍明るくするってことです。
>>2倍明るくすればノイズも2倍目立つので、ISO400では+1EVが限度かなってことです。

先日、新年会の時10Dでぱしぱししたのですが、最初はISO400+550EX+ディフィーザー使ってたんですが、ストロボ焚かないほーが雰囲気出るんで途中からISO800ノーストロボでも撮影しました。
店内はかなり暗かったですがレンズF2.8のおかげか失敗？は数枚ですみました。

この時はISO800で発生するノイズはほとんど気にならなかったですよ。
むしろ雰囲気が出てるよーな感じがします。
初めて（キタムラ100枚無料プリント券使って）富士フイルム@フロンティアで銀塩プリントしてみましたが、無補正でもかなぁ〜り良い感じっす。（＾＾）

900x600リサイズしてオンラインアルバムにあげてありますのでご覧になるならメール下さい。




>>高感度でのノイズはデジタルの場合はフィルムの粒子荒れとは違って非常に低周波のカラフルなノイズのために私には不快です。高周波ノイズと違って除去は難しくかつ処理時間もかかります。ただいまこの辺に挑戦中です。

これってケースバイケース（被写体による）だと思ふのですが、10DのISO800は意外と実用になるなって感じがします。




>>そもそも「現像処理」って言葉もいいのか？って思ったこともありましたが、CMOSの観測値から像を作成するという意味で銀塩とは異なる意味の現像でいいのかなって思っております。
>>できるだけ従来の言葉に当てはめるのはわかり易い反面誤解も招くので注意は必要ですね。

デジタルって理解しにくいですからね。
分かってるヒトは分かってるんですが・・わからないと使い方も誤り？ますよね。

>>私も、これには驚きました。既出かな？と思ったのですが、18000件もの書き込みを読む気には到底ならず、とりあえず書いてみたのですが本当に私が最初なのでしょうかね？

デジタルなら検索かけるのがフツーだと思ふのわボクだけでせうか？(^^;


なんか、かなり奥深く？埋もれはじめてますが・・まだみてます？(^^;ゞ

書込番号：2341377

[ＺＺ−Ｒ]

＞なんか、かなり奥深く？埋もれはじめてますが・・まだみてます？(^^;ゞ
自分の返信をブックマークしてるので返信が有れば分かりますが・・・
もうこのスレは終わってるよ〜、今更蒸し返してもね〜
結論なんて出ないんじゃいかと（笑）

書込番号：2341398

このスレッド、EOS-digital掲示板で知り
今日初めてですが、楽しく拝見させていただきました
相当！元スレとのずれは承知ですが
HayatePPさん開発中のraw展開ソフトに「強く」興味があります
こちらでの公表・公開が無理ならば、お手数かとは思いますが
そのソフトの現状・今後に付いて知りうる情報（URLとか）を
私のメールアドレスにメールいただけませんでしょうか?
ちなみに、現在BBとC1DSLRで
１Dと１Dsをつかい撮影のすべてをRAWで撮影・処理しています
C1では
（パラメータ変更時の）プレビュースピードとバッチ処理
高感度撮影の画質、トーンカーブの使い易さ
BBは、ブラウザー（画像用エクスプローラぐらいに使っています）としての
使い勝手の良さとHTML自動生成がそれぞれ魅力です

書込番号：2346641

[★ ZERO ★]

ＺＺ−Ｒ　さん 、オハヨウ！（＾＾）

>>もうこのスレは終わってるよ〜、

キャイン　キャイン　ですぅ〜(^^;ゞ

　めざせ白熱ランキング　→　「地上の星」？？　って意味不明？

書込番号：2360561