『ＪＰＥＧデータからＲＡＷ相当の現像について』 の クチコミ掲示板

[ねぼけ早起き鳥]

ＲＡＷ保存データからの現像に関心はあるのですが、
一般にコンパクトデジカメさんでＲＡＷ保存は時間がかかるので視て見ぬフリをしていますが。。。

SILKYPIX 3.0↓はＪＰＥＧでしか残っていないデータから変換によりＲＡＷ相当の現像（補正？編集？）が出来るそうです（私の早とちり、カン違いかも知れません）が、
コンパクトデジカメさんで試した方がおられましたら、使用感や仕上がり感などご感想をお聞かせいただけたらと思います。

http://dc.watch.impress.co.jp/cda/other/2006/08/18/4428.html

書込番号：5981036

[G4 800MHz]

試用版がダウンロードできます。自分で使ってみるのが一番。

http://www.isl.co.jp/jpegphoto/download/

書込番号：5981081

[ねぼけ早起き鳥]

G4 800MHzさん
教えていただきありがとうございました。
予想はしておりましたが、いきなりでしたね（＞＜）
ＯＳ推奨機種ではない息子のお古を使用しているので、もし具合がよければ買い替えを検討しているのですが。。。

書込番号：5981163

[LUCARIO]

RAW現像相当の画質が得られるとは思わない方が吉です。

メリットはむしろ、RAW現像と同じ使い勝手でJPEG修正が
出来ることですね。

1. 元の画像データを破壊しない。
2. 調整の順序を気にしなくて良い。
3. 何度でもやり直せる。

あと、グレー点指定によるホワイトバランス調整ができるのは便利ですね。

書込番号：5981204

[LUCARIO]

RAWを使わないのであれば、こっちの方が安くていいかも。

http://www.isl.co.jp/jpegphoto/

あまり使い込んでませんが、体験版をダウンロードしてみた
感じでは本家のSILKYPIXと操作感はほとんど変わらない印象です。

書込番号：5981243

[kuma_san_A1]

JPEG画像をレタッチソフトで色被りなどをとるよくある作業(レベル補正で黒点と白点決めて中間調グレーを指定するやり方)は一旦ガンマ変換されたRGBデータに対して行うのでグレー軸がゆがんだりします。
JPEGデータからリニア変換してWBを採るという作業の方がよりナチュラルに仕上がります。

もちろんRAWデータから扱ったほうが良いことは言うまでもありません。

書込番号：5981387

[京都のおっさん]

>一旦ガンマ変換されたRGBデータに対して行うのでグレー軸がゆがんだりします

なるほど。
よくはわかりませんが、自分の経験上ではレタッチソフトで WB補正するのは至難の技です。仕上がりが気に入らないことが多いです。
SILKYPIX を使うと WB補正が簡単にできます。仕上がりも自分的には満足できることが多いです。

書込番号：5982233

[ねぼけ早起き鳥]

おはようございます。
LUCARIOさん
kuma_san_A1さん
京都のおっさんさん
ありがとうございました。とても参考になりました。

理解不足の質問になりますが、LUCARIOさんの、
【グレー点指定によるホワイトバランス調整ができるのは便利ですね。】
は、kuma_san_A1さんの、
【JPEGデータからリニア変換してWBを採るという作業の方がよりナチュラルに仕上がります。】
というのと同じことなのですね？

書込番号：5982584

[kuma_san_A1]

別のことを言ってますけど？

書込番号：5982997

[ねぼけ早起き鳥]

ええっ！
じゃあ〜、
【JPEG画像をレタッチソフトで色被りなどをとるよくある作業(レベル補正で黒点と白点決めて中間調グレーを指定するやり方)は一旦ガンマ変換されたRGBデータに対して行うのでグレー軸がゆがんだりします。】
のこととおなじ？？

書込番号：5983014

[kuma_san_A1]

[5983014] はもっとNG！
(そもそも「何と」が抜けてます)

なんで「おなじ」にこだわるの？

WB(ホワイトバランス)を採る(というか調整できる)ということに触れている点は同じです。
けど内容は別でしょ？
片方は「具体的な操作の一例」でもう片方はリニアに戻してWBが取れる場合の「ロジカルな利点」なわけだから。

書込番号：5983066

[ねぼけ早起き鳥]

【(そもそも「何と」が抜けてます)】
「何と」は前の流れから、
LUCARIOさんの、
【グレー点指定によるホワイトバランス調整ができるのは便利ですね。】
ですね。

【なんで「おなじ」にこだわるの？】
こだわってはいません。お訊きしているだけです。

【片方は「具体的な操作の一例」でもう片方はリニアに戻してWBが取れる場合の「ロジカルな利点」なわけだから。】
あっちゃあ〜早とちり、カン違いのようでしたね、失礼いたしました。
お二方とも『結果が期待するレベルに達しておられる』という推測（思い込み）でお訊きしたのですが。。。

書込番号：5983299

[はるきちゃん]

当方、JPEGデータをよくいじっています。

画質の劣化は多少はあるのでしょうが、RAW現像と
同じ使い勝手で調整できるのは非常に便利です。
レンズ収差補正も重宝します。

書込番号：5983391

[ねぼけ早起き鳥]

はるきちゃんさん
ありがとうございました。
Ｅ−３００は一眼でしたね。
やはりＪＰＥＧで撮られることが多いのでしょうか？

まあ、【「具体的な操作の一例」】だろうが【「ロジカルな利点」】だろうが、
『結果が期待するレベルに達しておられる』という推測（思い込み）でよいんでしょうねえ。。。

書込番号：5985073

[京都のおっさん]

ホワイトバランス以外にも利点はあると感じましたが、
http://bbs.kakaku.com/bbs/-/SortID=5854530/
よろしかったらどうぞ。アルバムの画像は削除されてますけど。

あと使っていて感じるのはノイズをうまいこと舐めてノイズ感を減少させるなというところです。
同じ SILKYPIX で RAW から現像した画像を RAW Bridge を通すと、元画像よりもノイズ感が減少されるように感じることがあります。どちらが良いかと聞かれると微妙ですけど。

書込番号：5985558

[ねぼけ早起き鳥]

おはようございます。
京都のおっさんさん、いろいろご紹介ありがとうございました。
LUCARIOさんのコメント共に、たいへん勉強になりました。

私なりに要約いたしますと、メリットとして、
１．元の画像データを破壊しない。
２．調整の順序を気にしなくて良い。
３．何度でもやり直せる。
４．WB補正が容易。
５．「諧調補間」が可能。
６．トーンジャンプが目立たない。
７．ノイズ感が減少する。

注意点といたしましては、
１．画像全体に対する操作となる。
２．パラメーターを何もいじらず、そのまま現像保存すると色が緑っぽくなる。
３．版による微妙な差。
でしょうか。
注意点の１．は逆に私にとってはうれしいかなあ〜

そろそろ絶滅種の９８さんともお別れの頃合い。。。

書込番号：5986666

[京都のおっさん]

ねぼけ早起き鳥さん が非常に詳細にレスを読まれているようなので補足します。

>３．版による微妙な差。

あったことは確かなのですが、ヒストグラム表示させて差があったということで肉眼では差が認められませんでした。気にする必要は無いと思います。

>２．パラメーターを何もいじらず、そのまま現像保存すると色が緑っぽくなる。

元画像が Tiff の時には起こらず、jpeg の時のみ発生する現象です。jpeg画像を RGB に展開する時に誤差が生じるものと推測します。
気にならない人は気にする必要が無いと言ってよいと思います。
自分は気になりますが、知ってて使っているので特に問題とはなりません。

SILKYPIX に慣れた自分にとって、RAW Bridge は有意義な機能です。

書込番号：5990183

[ねぼけ早起き鳥]

おはようございます。
京都のおっさんさん、補足ありがとうございました。

【３．版による微妙な差。】
上位（最新版）改善方向とお伺いしていますので、おっしゃるとおり気にする必要は無いと思います。

【２．パラメーターを何もいじらず、そのまま現像保存すると色が緑っぽくなる。】
標題どおりJPEGデータからの質問ですので、知ってて使うってことが注意点ですね。

書込番号：5991105

[LUCARIO]

３連休はスキーに行ってました。
今日は手足も頭脳も筋肉痛です(笑)

スキー場に一眼レフは持ち込みたく無かったので、コンデジ３台で（ぉぃ）
すべてJPEG撮りしてきました。
これをSILKYPIXの自動露出補正とグレー点WBで修正すると、
ばっちり狙い通りの結果が出せています。

JPEGを再度WB調整をする場合、撮影時にAWBを使わずプリセットを使うのがコツですね。
マニュアルWBは不要。晴天なら晴天に、曇天なら曇天に固定するだけでOK。
できるだけ現場の光源に合わせておくのが画質的にベターですが、
迷ったら晴天固定(6500K相当)でも可です。

そのようにして撮ると、まるでRAW現像と同じように、同じ光源下で撮ったコマは
現像パラメータのコピーだけでWB調整が完了します。とても楽ちんです♪

いろいろ使いこなし方はあるにせよ、画像レタッチの手間を厭わず
むしろ楽しみに感じられる方には、SILKYPIXのJPEG現像機能はオススメできますよ。

一括サイズ変更のついでにちょちょっと自動補正を掛けるだけでも
仕上がりは雲泥の差になります。

書込番号：5996853

[kuma_san_A1]

JPEG現像をデフォルトパラメータで行って「ずれ」が生じるのは一旦リニア変換や広帯域変換を行ってから再現像している証でもありますよね？
逆に「ずれ」が生じない方が不気味です。
もちろん「ずれ」はわずかである方がよい(各カメラのJPEGデータの解析に苦労した結果でしょう)のですが。

書込番号：5996911

[ねぼけ早起き鳥]

LUCARIOさん
３連休スキー、うらやましいですね。
【コンデジ３台で（ぉぃ）】の使い分けをお聞きしたいですね。

kuma_san_A1さん
たびたびスミマセンが教えてください。
【「ずれ」】
とは、何を基準にしたどういう「ずれ」なのでしょうか？

書込番号：5997427

[kuma_san_A1]

？
緑っぽくなるっていう報告がありますよね？
全く同じになるほうが不思議だという意味ですけど？

書込番号：5997453

[ねぼけ早起き鳥]

kuma_san_A1さん、ありがとうございました。

【緑っぽくなるっていう報告がありますよね？】
？
京都のおっさんさんのご説明で納得出来ていましたので、
RAWまたはTiffとの比較なら判らなくもありませんが。。。
一般的に、
デジカメさんのJPEGは(劣化)圧縮で、しかも、各メーカーさんの「画像エンジン」とやらによって、それぞれ違った味付けがなされている。。から、「ずれ」ているものは他にいろいろあってもおかしくはないと思っていましたので。

不気味でも不思議でも、で、なくてもよいですから、
kuma_san_A1さん自身も
『結果が期待するレベルに達しておられる』という私の推測（思い込み）でよいんでしょうねえ。。。

書込番号：5998185

[kuma_san_A1]

「期待するレベル」自体がわかりませんので答えられません。

ただし、JPEG(またはTIFF)ファイルしか手元にない場合は非常に有効でしょう。

書込番号：5998245

[ねぼけ早起き鳥]

kuma_san_A1さん
簡単にご説明いたします。

LUCARIOさんと京都のおっさんさんは、お二方のアルバムを拝見した私の印象とお二方のコメントを照合して、お二方ともそれぞれに、
『結果が期待するレベルに達しておられる』という推測（思い込み）にスンナリ達したわけです。

で、kuma_san_A1さんの場合は、その手前で私は逡巡しているわけです。
たぶん、kuma_san_A1さんご自身の、
【「期待するレベル」自体】が見えて来ないからだと思いますけど。。。

書込番号：5998383

[kuma_san_A1]

え？わたしの責任なのですか？
それは関係ないと思いますよ。
早くご自身で試されてください。

書込番号：5998570

[ねぼけ早起き鳥]

kuma_san_A1さん
【え？わたしの責任なのですか？】
もちろん、そうですよ。
で、なければ、このスレを立てたりはしないでしょう？

この世に麻酔と消毒があってよかった。。。おやすみなさいzzz

書込番号：5998671

[kuma_san_A1]

酒のつまみになるつもりはありませんので「絡まないで」くださいね。
わたしの場合は「結果が『予想できる範囲』に収まっている」ということです。

書込番号：5998779

[京都のおっさん]

[5996911] kuma_san_A1さん

その論調ですと Tiff現像においても同様に緑っぽくならなければならないはずですよね。しかし実際は Tiff現像ではそうなりません。

Tiff現像 … 元画像を Tiff、現像結果も Tiff に保存。
jpeg現像 … 元画像を jpeg、現像結果も jpeg に保存。
の意味で言葉を使っています。
この他にも二通り、全部で四通りの「元画像のファイル形式、現像結果の保存画像のファイル形式」がありますが、自分は上の二通りしか試していませんが。

・Tiff現像は、ヒストグラムはわずかに変化するが、緑っぽくはならない。
・jpeg現像は緑っぽくなる。
です。

一方、PhotoshopElements3.0 で Tiff保存(Tiff の元画像を開き、Tiff で保存)した結果は、全くヒストグラムが変化しません。
同様に jpeg保存(jpeg の元画像を開き、jpeg の低圧縮(最高画質)で保存)した結果はブロックノイズが増えるため、もちろんヒストグラムは変化します。しかし肉眼で見る限り、カラーバランスに変化は無いように感じます。

なお、[5874568] の私の検証には誤りがありますので、そこの部分は気にしないでください。

書込番号：5999296

[kuma_san_A1]

TIFFはRGB絶対値で記録されているけどJPEGはYCbCrでしたっけ？
そっちの誤差なのかな？

TIFFではずれないということから[5996911]のわたしの書き込みは間違っていますね。
恥を晒しました。

書込番号：5999385

[京都のおっさん]

http://www.rysys.co.jp/dpex/help_rgbwarn.html

ここを見ると jpeg って YCC記録みたいなんですが、
YCC ⇔ RGB
の変換式をどこかで見たことがあります。単なる線形演算だったかな？ だとすればそんなに誤差が生じるものかなとも思いますが。
ただ上のリンクを見ると「クリッピング」云々とあります。両者とも「色空間を決めれば値が決まる」性質のもので(デバイスディペンド)あろうし、YCC の色空間が広ければ誤差も出るのかなとも思いますが。
何にも知らないので全て想像です。ただ、何となく SILKYPIX の画像表示の問題(緑っぽくなる)と同じように思うのです。

書込番号：5999529

[ねぼけ早起き鳥]

おはようございます。
[5998779] kuma_san_A1さん、ありがとうございました。

【酒のつまみになるつもりはありませんので「絡まないで」くださいね。】
あははは。。。時すでに遅し、おつまみにするかどうかは私の自由ですよね。
もちろん、感謝こそすれ、絡んでなんかいませんよ。
kuma_san_A1さんの【「期待するレベル」】を推測したいがためです。

【わたしの場合は「結果が『予想できる範囲』に収まっている」ということです。】
びびび。。。と来ない理由がよく分かりました。
撮り方のスタイルが私と違うこともよく分かりましたね。
私の撮ったものはたいがい、
「結果が『予想できる範囲』を(±)超えている」

京都のおっさんさん、たびたびコメントありがとうございました。
ここからは、モニターで見るか印刷して見るかという話にも及びそうなので、この辺で。。。
みなさん、いろいろ教えていただきありがとうございました。

書込番号：6000111

[アユモン]

[5999529] 京都のおっさんさん、
釈迦に説法です。
デファクトスタンダードのJFIF形式のjpegでは、YCbCr表色系を用いるんですよね。
http://ja.wikipedia.org/wiki/JPEG

http://www.mis.med.akita-u.ac.jp/~kata/image/rgbtoyuv.html
Y = 0.299 x R + 0.587 x G + 0.114 x B
U = -0.169 x R - 0.3316 x G + 0.500 x B
V = 0.500 x R - 0.4186 x G - 0.0813 x B
http://siisise.net/jpeg.html
輝度明るさ
Y = 0.29900 * R + 0.58700 * G + 0.11400 * B
色差
Cb = -0.16874 * R - 0.33126 * G + 0.50000 * B + 0x80
色差
Cr = 0.50000 * R - 0.41869 * G + 0.08131 * B + 0x80
http://www.nahitech.com/nahitafu/mame/mame6/color.html
Y = 0.299R+0.587G+0.144B
Cb=-0.172R-0.339G+0.511B
Cr= 0.511R-0.428G-0.083B

式は簡単ですが、コンデジのような1CCDのBAYERフォーマットの場合、R、G、B各信号の取り方が・・・・
■カラーフィルター方式CCD素子
http://www.mis.med.akita-u.ac.jp/~kata/image/rgbtoyuv.html
P green = (G7 + G10)/2　　・・・（Rec -2）
P red = (9・R11 + 3・R3 + 3・R9 + R1）/16　　・・・（Rec -3）
P blue = (9・B6 + 3・B8 + 3・B14 + B16）/16　　・・・（Rec -4）

式が行にうまく収まりません。ご容赦を。

書込番号：6000737

[アユモン]

自己res。補足

YUVに変換後、U/Vは間引かれて記録される[ことが多い]
。（というかこれをする為にRGB-YUV変換をする）
http://www.wdic.org/w/WDIC/YUV

書込番号：6001091

[京都のおっさん]

ありゃ、急に難しくなってしまいました。
今知りたいのは YCC → RGB なので、行列の逆演算しなきゃならないな、と思っていたらありました。
http://image-d.isp.jp/commentary/color_cformula/YCbCr.html
RGB はガンマ変換後だそう。
YCbCr の範囲が 0-255 より狭いのは、これより広い範囲がターゲット色空間を飛び出る(クリップする)の意なんでしょうかね(じゃないと色々説明が付かない気がします)。
あとこの場合のターゲット色空間が何なのかはよくわかりません。ターゲットによって式は変わるのか変わらないのか。DPEx というソフトで YCC表示させると、色空間の指定で uvプロットが変わるので、おそらくデバイスディペンドだろうというのは想像できますが。

いずれにせよ有効数字四桁あります。求めるものが 8bit でも、変換するにはもう少し精度が必要そう。
試しにリンク先の式で (Y,Cb,Cr) = (235,128,128) を代入すると初項だけが残り、値は 254.916 になります。1.164 を 1.16 にして計算すると、値は 254.04 になります。誤差は 1 に近いですね。
R'、B' と比べ、G' の右辺だけ形が違います(初項を除き)。どうもこの辺に鍵がありそうな気が。
YCbCrデータが生で埋め込まれてるので無ければ、データ抽出の際の誤差かもしれませんが。

書込番号：6002222

[京都のおっさん]

http://ja.wikipedia.org/wiki/%E8%89%B2%E7%A9%BA%E9%96%93
これはガンマ変換後ではないみたいで、しかも Yuv みたいですが(よく知らない)。
これも式の形は似ていますね。G だけ違う。

書込番号：6002253

[アユモン]

[6002253] 京都のおっさんさん、英語が不自由なんですが・・・
http://www.intersil.com/data/an/an9717.pdf
p2左下
ついでに
ITU-R BT.601 について　わかりやすいと思うWeb
http://www.marumo.ne.jp/bt601/

書込番号：6003392

[ねぼけ早起き鳥]

おっはようございます。
おっ、まだ続いている。。。

ところで、アユモンさんは、
『結果が期待するレベルに達しておられる』でしょうか？
（レベルはご自身のご判断で。）

[5999296]＆[5999529] 京都のおっさんさん
のコメントから私の期待です。

【緑っぽくなる】のが、常にある程度一定方向で、ある程度の範囲の量であるならば、
そして、ある程度何らかの要素データとの相関があるのであるならば、
来たるべき最新バージョンでの改善は期待できるのではないでしょうか。。。

書込番号：6004303

[アユモン]

ねぼけ早起き鳥さん、勝手にスレをお借りしてすいません。
私の書き込みは、
[5999529] 京都のおっさんさんの「YCC ⇔ RGB
の変換式をどこかで見たことがあります」へのResです。
ご迷惑なら退去します。
ここで上げられたソフトのヘルプの記述http://www.rysys.co.jp/dpex/help_rgbwarn.html
に関しては、よくわからないのですが、ここでのRGBとは、RGBといってもモニタRGBのことのようですね。
http://www005.upp.so-net.ne.jp/fumoto/linkp25.htm

書込番号：6004699

[アユモン]

自己レス
追伸

モニタRGB、sRGBの話なのでガンマ補正後の話ということでしょうか？
http://www005.upp.so-net.ne.jp/fumoto/linkp25.htm

書込番号：6004724

[ねぼけ早起き鳥]

アユモンさん
【モニターで見るか印刷して見るかという話にも及びそうなの】は、
予測しておりましたので、いいんですよ。
歓迎します。

で、アユモンさんは、
SILKYPIXのJPEG現像は未経験ということで？

書込番号：6004840

[アユモン]

SILKYPIXは名前ぐらいしか知りません。

　従って、このスレの後半のテーマ「緑」問題にコメントできるものを持ち合わせていません。RGB-YCCに反応しただけです。
　しかし、あえて、無知を承知で書きこまさせていただきますが、「緑」問題は、その本質がjpeg（規格）にあるのではなく、[6000737] でも述べましたが、BAYER配列のカラーフィルターの特性によるものではないかと妄想します。

　天体撮影のWebですが、こんな記述がありました。
「一般にベイヤー配列の画像では R,B 画素に比べて G 画素のカウント値がかなり明るい場合が多くなっています。これは主にデジタルカメラの撮像素子に乗っている色フィルタの分光感度特性によるものです。」
http://www.astroarts.co.jp/products/stlimg5/support/greenstar-j.shtml

　重ねてのスレ汚し、ごめんなさい。　

書込番号：6005853

[ねぼけ早起き鳥]

[6005853] アユモンさんのコメントについては、
京都のおっさんさんのご意見もお聴きしたいですね。

私の場合は、何か[5998185] の繰り返しような気がしますので。。。
【京都のおっさんさんのご説明で納得出来ていましたので、
RAWまたはTiffとの比較なら判らなくもありませんが。。。】

【汚し】というより、【緑っぽく】してほしかった。。。

書込番号：6006401

[京都のおっさん]

え？ 自分のコメントはこのスレとリンク先のスレに書いてあるとおりで、これ以上の新しい発見は何もありませんけど。
本気になって「要素データとの相関」を調べるなら、1677万色全て調べないと駄目でしょうね。そこまでするつもりはもちろんありません。

収集付きそうもないので、アルバムにアップしました。
http://album.nikon-image.com/nk/NK_ImageAlbum.asp?id=11106842&key=711615&un=115360
ここからの連続4枚(そのうち削除します)。
精根尽き果てたので Tiff現像はやってません。以前やった時は [5999296] に書いたとおり、ヒストグラムに差が出ました(肉眼でも元画像との差はわかります)が、緑っぽくはなりませんでした。

あとはこれをネタにメーカーに問い合わせるなり何なりしてみてください。
自分は一度問い合わせましたが、メーカーにやる気が感じられないので、そのままにしています。実際モジュール変更するにしても大変だと思いますし(今は拡販の時期でしょうしね)。

全然関係ありませんが
http://www2.isl.co.jp/SILKYPIX/japanese/community/bbs/?mode=all&namber=164&space=0&type=0&no=0
こんなのやってたんだ。知りませんでした。
行きたかったなあ。

書込番号：6007616

[kuma_san_A1]

あら！来てくれれば良かったのに。
行ってきましたよ。
ちなみに…PIEもどこかで見られるかもです。

書込番号：6007717

[京都のおっさん]

PIE ってカメラショーか何か？
SILKYPIX掲示板はほんとたまにしか覗かないんで見逃しました。
でも kuma_san_A1さん に会ったら恐縮して隅の方でちょこんとしちゃうかも。

こちらもスレ汚し、ごめんなさい。

書込番号：6008020

[ねぼけ早起き鳥]

おはようございます。
京都のおっさんさん、コメント＋アルバム作例ありがとうございました。
【緑っぽくなる】のが実感できました。
感謝です。

kuma_san_A1さん
【…PIEもどこかで見られるかもです。】
【PIE】って【EP版】のこと？
絡んでません。。。（＾＾；

書込番号：6008033

[LUCARIO]

ねぼけ早起き鳥さん、
「PHOTO IMAGING EXPO 2007」で検索してみて下さい。

京都のおっさんさん、
緑化現象、私はこれまで特に意識したことなかったんですが、
こうして見てみると確かに気持ち悪いですね。一度の現像でも確実に
変色しているわけでしょうし、、、。
メーカーに問い合わせても素直にバグと認定しなかったということは、
かなり根が深い問題なのでしょうかねー？

＃だからというわけでもないのですが、JPEG後処理をPhotoshopメインに
＃移行しようかどうか、今逡巡しているところです。

書込番号：6008829

[ねぼけ早起き鳥]

LUCARIOさん、ありがとうございました。
あれやこれやで、
MEAT PIEやAPPLE PIEまでも連想していました。。＾＾；
西国住いなので、うらやましいですね。

【、メーカーにやる気が感じられないので、】
[6007616] 京都のおっさんさん 、
私の期待ですが、この問題が解決すればさらに販売が伸びると思いますので、ソフトやさんは次期バージョンで改善すべく鋭意努力されておられるのではないでしょうか。。。

書込番号：6009147

[京都のおっさん]

ねぼけ早起き鳥さん リンク先の SILKYPIX掲示板は読まれました？
基本的にはあの調子です。やる気が無いと言えばその通りだし、取り合ってくれない感じですね。思うに「何寝ぼけたこと言ってるんだ？」といったところでしょう。
でも自分に分析能力が無かったのでしょうがないです。連続かまして大きくアピールする技も覚えたのはカラマネスレの頃、ついこの間のことですので。
バグと言ってしまえばそうなんでしょうけど、SILKYPIXver1 の頃からの仕様なんだと思いますよ。「jpeg展開時の誤差」が原因だと思います。

試しに「カラマネ無しの jpeg画像表示」のスクリーンキャプチャをやってみました。6連続で挫折しましたが、それぞれに対応する jpeg現像の連続回数画像と比較してみました。SDS32876dev01, SDS32876dev01, … それぞれとです。時計の「ある白い部分」のエリアだけでのヒストグラム表示で比較です。
jpeg現像は jpeg圧縮によるブロックノイズもあります。また、キャプチャ画像なのでエリア座標も完全一致とは行きません。それらを考慮すれば「キャプチャ画像と jpeg現像画像はほぼ一致した」と言ってよいと思います。

RAW現像時のキャプチャ画面と SDS32876.jpg そのものの画像のヒストグラムも比較しました。こちらは思ったとおり「ヒストグラム一致」です(ただし時計エリアだけの比較)。思った通りというのは「jpeg展開画像では無いので緑っぽくならない」ということです。
SILKYPIX を RAW現像ソフトとしてみた場合には、今までこれで問題無かったのでしょうね。ただし、それならばビューアソフトの機能を削るべき(jpeg画像を読み込んで表示する機能を付けるべきでない)と思います。

まあでも自分はあるがままを使うタイプなのでこのまま使っていきます。こういう仕様の製品なのですから。

画像は削除しました。
「見るべき人が見ればいいや」的な掲示板の使い方は良くないと思いますが、その気になれば基本的に誰でも試せる内容なので。

書込番号：6011144

[京都のおっさん]

誤)：SDS32876dev01, SDS32876dev01, … それぞれとです。
正)：SDS32876dev01, SDS32876dev02, … それぞれとです。

スクリーンキャプチャにも連続技をかけたということです。
SDS32876dev01.jpg と SDS32876cpt01.jpg とのヒストグラム比較
SDS32876dev02.jpg と SDS32876cpt02.jpg とのヒストグラム比較
　　　　　　・・・・・・・・・・・・
　　　　　　・・・・・・・・・・・・
SDS32876dev06.jpg と SDS32876cpt06.jpg とのヒストグラム比較
をした結果、少なくとも時計の部分に関してはヒストグラムがそれぞれ一致したよという意味。

書込番号：6011168

[ねぼけ早起き鳥]

おはようございます。
京都のおっさんさん、経緯ご説明ありがとうございました。
私は窓口のセンスと受け取ってますが。。。いずれ判るのでしょうけど。。。
おっしゃるとおりたしかに、どうして、
「よくぞご指摘くださいました。」
と、言えないんでしょうねえ〜

【「見るべき人が見ればいいや」】
これまた、たしかに、
「見てはいけない人が見る」ことの方が、
圧倒的に多いですねえ〜

麻酔と消毒が欠かせないゆえんです。。。

書込番号：6011667

[京都のおっさん]

>おっしゃるとおりたしかに、どうして、
>「よくぞご指摘くださいました。」
>と、言えないんでしょうねえ〜

違います。「問題がある」ということを認識していません。それゆえ

>思うに「何寝ぼけたこと言ってるんだ？」といったところでしょう。

と書きました。
自分達は完全無欠で間違いなんか有ろうはずが無いという驕りが感じられます。「自分達は映像のプロだぞ」という感じで、細かいバグの報告はともかく、色や画像の仕上がりといった根本事項に付いては素人が口出しすべきでないとでも思っているような感じです。

私はこの会社の製品を信用していませんよ。
SILKYPIX はユニークな特徴とオリジナリティ溢れるアイデアの具現、それと掲示板などを通して面白い話が聞けるから利用しています。今の自分に SILKYPIX が無くなったら困る、それ程の製品です。
ですが Photoshop と比べると詰めの甘さを感じさせるような疑問点が多々あります。地に足が着いていない感じなんですよね。それぞれの疑問一つ一つは小さいことです。ですが今回のような問題に発展しなければいいのですけどね。
今回は表示で色が違う点を指摘したのに放って置いた(RAW現像に問題は無い) → jpegも大々的に扱うようになる大幅なヴァージョンアップでボロボロに、という流れです。

書込番号：6011836

[LUCARIO]

私見と言うか個人的好みですけど、

「貴重なご意見ありがとうございます。
　お客様のご意見は担当部署に伝え、
　次期製品リリースの際の参考にさせて頂きます。」

みたいな口当たりの良い定型文を返して来るだけで、
その後何にも反映されてない…みたいな、
大手企業にありがちなサポート対応に比べると、
市川ソフトの正直で頑固な姿勢は共感が持てます。

時々ムカッと来るのは事実ですが(笑)、
技術者同士のやり取りをして、きっちり論拠と希望を示せば、
きっちり対応してくれましたからね。
βテスト時に出した希望がリリースごとに着実に反映されて
くるのを見ると、やはり嬉しく感じます。

こちらの希望が通らなかった項目は、必要性を認めれもらえる
だけの提言が出来なかったか、あるいは現状では出来ない理由が
あるのかと割り切れますので。

書込番号：6011986

[kuma_san_A1]

＞自分達は完全無欠で間違いなんか有ろうはずが無いという驕りが感じられます。「自分達は映像のプロだぞ」という感じで、細かいバグの報告はともかく、色や画像の仕上がりといった根本事項に付いては素人が口出しすべきでないとでも思っているような感じです。


それ(驕りも思っても)は『無い』から安心しましょう。
最近は「サポートフォーム」から報告や要望を受け付けるように変わってしまいましたので定型文返信もあるかもしれませんが「便り(返信)が無いのは元気(対応に追われている)な証」と構えています。

で、JPEGデコード時にグレーバランスは変化しないからYCbCrからカラースペースにする際のズレというか誤差がある(つまり色差情報の部分)という結論でいいのですよね？

対応されるといいですね。

書込番号：6012308

[ねぼけ早起き鳥]

こんばんは。

【「何寝ぼけたこと言ってるんだ？」】
京都のおっさんさん、すみません、ねぼけは芋エキスが残っていました。
幼稚園のみどりぐみさんでも判ることが、
どうして。。？どうして。。。？？ってことは、世の中に常に浮きつ沈みつ、のようですね。
kuma_san_A1さんのおっしゃるとおり、
対応されるといいですね。

書込番号：6014008

[京都のおっさん]

結論は知りませんがわずかな試行によるとグレーは変化しないようです。

サポートがユーザーフレンドリーな点や、ある程度の情報開示がなされる点は評価しています。しかしこれはただのバグではありませんので。他ソフトでも経験無い酷さです。
「色を正しく表示する」という画像ソフトの基本を疎かにするようでは「他にも何か落とし穴が？」と疑心暗鬼になるのは当然のこと。それでもすぐに問題確認されるのであれば次の問題発生にもまだ安心できますが、実際には「すぐに徹底調査します」とはならなかった。そしておそらく今も。これが驕りでなければ見識の低さか怠慢か。いずれにせよ良い言葉は見付かりません。個人的に一番ガッカリ度が高かったのはこの点です。

http://www2.isl.co.jp/SILKYPIX/japanese/beta/sakura/bbs/?mode=all&namber=1332&space=0&type=0&no=0
このスレで自分は二点、ここは異常な空間だと感じました。

一点目は検証をユーザーに委ねること。
あれは SILKYPIX3.0 の開発バージョン用の掲示板。「問題の発見、報告はユーザーの権利・問題の検証はメーカーの責務」が私の常識でしたが、あの掲示板では違っていたようです。
今スレほどの検証が要請されるのなら(掲示板の生命線である)問題提言は激減するでしょう。実際はもっと簡単に他のビューアと普通の写真を見比べれば済む話なのに、それすらやった気配が無い。

二点目はサポートの登場に二度目が無かったこと。要するにガッカリポイントですが、スレである程度結論が出ているのに「そんなんでいいの？」って思いました。スレを読んでもいませんね、おそらく。他人事みたい。自分の興味ある分野には積極的に顔を出し、その他の話題は無視って、ユーザー同士の掲示板じゃないのに。

サポートには連絡しました。このスレを見ろって。
三度目はどうなるでしょうね。


ねぼけ早起き鳥さん すいません、勝手にこの場で憤っちゃって。
SILKYPIX を使って気付いた点は他にもあるのですが、
一つは「画像表示時にトーンジャンプ(その実態はノイズ？)が他のソフトより緩和される」というのがあります。これは RAW Bridge でのノイズ低減との関連性はわかりませんが、確かにそうなんです。不思議ですね。
もう一つは個人的な感覚ですが、SILKYPIX の jpeg圧縮は下手だということです。Tiff に落として Photoshop で圧縮した方が高画質に感じます(自分はそこまでやりませんが)。
スレ題に関連する話題を出したということで許してください。

書込番号：6015342

[kuma_san_A1]

どう思うかの違いですが、元々あそこの掲示板は「必ずベンダー側からの返事があるとは限らない」旨の断り書きはしてあったと思います。
起きる条件と現象をわかりやすく報告された場合には検証もしやすいですよね？

JPEG表示は絶対的じゃない(特にカラーマネージメントでモニタプロファイル見て補正している場合)とわたしは考えているので、あそこのコメントも一度くらいでしたっけ？
JPEGのエンコードもデコードも違いはあるんものだと思っているので話に参加できないなって思ってました。

書き込みを読んでそれを理解出来なかったらコメントも難しいでしょう？

自分がWINマシンを使っていて「Windows 画像と FAX ビューア」との見え方の違い(というかスクリーンキャプチャのサンプリング値の違い)を気にするなら「表示」設定の「カラーマネージメントをしない」にすると思います。
カラーマネージメントをすることを選んだ時点で絶対的な値は期待できないと思っていますから。
「WB微調整」でグレー軸がずれていく方がいやだから自分なら彩度を少し落とすと思います(カラー設定でもいいしふぁいんからーコントローラでもいい)。

もちろん、JPEG現像が備わっている現在において報告の問題が解決されるのは望ましい方向だと思いますよ。

書込番号：6015562

[京都のおっさん]

半分サポート向けのコメントです。
カラーマネージメントとかモニタプロファイルとか、当時は何もわかっていなかったので最初は Windows で指定しない状態で発見したのですよ。肉眼で見て「あれ？マゼンタかぶりが無くなったな」って。何と比較したわけでもなく素の状態で気付きました。
最初に発見したときは「嫌なことに気付いてしまったな」と思ったものです。自分で検証できないのもわかっていたし、色の問題ってこじれること多いですから。
直感的におかしいとは思った(だから報告した)。でもモニタプロファイル云々言われて(自分は何も知らないので)困惑したことを覚えています。識者により問題の本質が歪められる例ですね(kuma_san_A1さん に対して言っているわけではないです)。
「色が違う」と言われて「何？もしそんなことがあったら大問題だ！」とピピピッってこない感性に疑問を感じます。ハードならいざ知らず、ソフトウェアで色が違う(それも肉眼でわかるほどに)って、どんな美辞麗句を並べても私には欠陥にしか思えません。
この先は…って、いかにもどこぞの業界の話になぞらえられそうな話題ですが…。ここが隠蔽体質でないことは何となくわかりますし、それはせめてもの救いです(しかもどこぞの業界に例える程大騒ぎする問題でもない)。でも気付いて欲しかった。

書込番号：6016089

[京都のおっさん]

>ピピピッってこない感性に疑問を感じます

疑問を感じると言うよりむしろユーザーとして悲しいことなんです。

書込番号：6016123

[kuma_san_A1]

いや、RGBで扱っていて絶対的な色って無いから。
こう考える理由はもう何度も書いています。

書込番号：6016526

[京都のおっさん]

kuma_san_A1さん もうちょっとちゃんと書いていただかないと理解できません。

書込番号：6016862

[LUCARIO]

京都のおっさんさん、

出来る限り、話を発散させずにポイントを絞って進めた方が
近道だと思います。

1. 問題としている現象は何か？

　JPEG画像を読み込んで、パラメータを何も操作せず
　そのままJPEG現像出力すると、色が緑側に変わってしまう。

　微妙な差なので1度では分かりづらいかも知れないが、
　これを何度も繰り返すと明確な違いが現れる。

　入力画像、出力画像のカラープロファイルはいずれもsRGB。
　同じ条件でTIFF画像を読み込んで、TIFFで出力した場合は
　この現象は起こらない。

　また参考情報として、Photoshop Elements等の他社ツールでは、
　JPEGであってもこのような現象は起こらない。

2. 問題がもたらす悪影響はなにか？

　JPEG画像に対し、色合い調整等を行わず、ノイズ除去、
　シャープネス調整、リサイズのみを行いたい場合、
　元の画像と色合いが変わってしまうのは不都合である。


…こんな所でしょうか？
私自身では検証していないので、これまでの話の流れから
想像を交えて書いていますが、多分、筋は通っていると思います。

あとはその現象を分かりやすく示す証拠ですね。
アルバムの実例画像は削除してしまったようですが、
ああいうのは示してあげた方が話が早いと思いますよ。

もし、ご自宅の部屋が写っていた事に抵抗があるのでしたら、
素材に私のMyColorChecker.JPGを使ってもらっても構いません。
http://album.nikon-image.com/nk/NK_ImageAlbum.asp?id=11024039&key=832162&un=116951

そういえば、京都のおっさんさんもマクベスチャート
購入されたんですよね。適切な光源を当ててご自身用の
チャート画像を作っておくのも一案カモ。

＃私の方はあれ以降、さっぱり活用できてませんが(^^;;;

書込番号：6017262

[京都のおっさん]

LUCARIOさん 話をまとめるのは必要と思ってたところです。
時間経緯と共にわかってきたこともあるし、もちろんバリバリ推測込みです。検証にしても漏れも当然あるので 100% とは限りません(当たり前)。


・現象
(1):SILKYPIX をビューアとしてみたとき、jpeg画像をカラマネ無しで開くと、他のビューアと表示される色が違う。R、B に対して、G のレベルが相対的に 1 〜 2 ほど高くなる。
(2):SILKYPIX の RAW Bridge 機能は、jpeg画像をデフォルト現像すると、R、B に対して、G のレベルが相対的に 1 〜 2 ほど高くなる。

この二つが確認されている現象(症状)です。sRGB 前提は暗黙というか、それ以外は試していない。
また、(レタッチソフトで作成した色の中で)完全グレーの色に関しては変化しない。ごく普通のデジカメで撮影したごく普通の画像であれば(1)、(2) とも簡単に確認できる内容。

(1)、(2) ともに「相対比較で色が変化する」現象です。(1) は「他のビューアソフト」と比べて、(2) は「jpeg現像前のオリジナル画像」と比べて。
そこで「YCC → RGB 展開時の誤差では？」との説が有力となっています。


・問題がもたらす悪影響
これは人それぞれ。そして(かっての2000年問題のように)予測不能です。私個人の印象では「見た目で気付くことはそうは無いが、たまには気付く」程度なんで、要するに大したことない問題です。
ただし上の (1)、(2) は関連があると思ってますし、時間的な流れもありますから、既に「(1) を放っておいたから (2) という悪影響が出た」と考えています。


「個人の気になるか気にならないか」は問題でなく「それは正しいのか正しくないのか」といった立脚点に立つのは当然のことだと考えます。例え(有効数字の取り方でいくらでも値が変わる)誤差だとしても(結果の表示に表れる)ヒストグラムで 1 以上違えば、それは正しくないとの判断です。
「相対比で SILKYPIX が緑色」なのであって、Windowsビューアに誤差が無いなんて言ってません。でもYCC → RGB 変換の誤差とした場合の話、「どっちが正解に近いの？」についての答えはあるかもしれないし、あるいは暗部トーンではこっちが正しくハイライトでは他方が正しい、みたいな感じの決着の付かない問題かもしれないし。それは私にはお手上げです。

で去年の七月からずーっと腹が立っていたのでね。おまけに今年の一月中旬かな？ RAW Bridge についても報告したんですが同じ調子。色が違うで動かないのだから話にならない。
Maker と User の違いなんでしょうかね。RAW bridge も出たての九月中旬かな？パラメーター弄って User の私はすぐ気付きました、ホワイトバランス変えた三枚の写真で「どっち？」ってやった時に。表示との関連性を考えたのはそれより後ですけど。
すいません、また飛散しましたね。

別に写真は気にしてませんよ。それ用の写真です。どうしても見たいのならまたアップします。
サポートには別のアルバムをパスワード付きで紹介してますので。内容は同じで dev01 〜 dev10 まで全部、cpt01 〜 cpt10 までも全部追加しているだけです。MyColorChecker でやるのは良いアイデアですけど、作業が面倒なんですよね。

書込番号：6017616

[kuma_san_A1]

せっかくまとめてもらったのですが話がどんどん変わっているように思えてわかりません。
1ないし2Gのレベルが変わるとおっしゃるのですが、ニュートラルグレイでは問題ないということも書かれていますよね？

(1)で表示でズレた
(2)でデフォルト現像するとずれるという結論は何で比較して(Photoshopで前後を比較したのかな？)
(1)でずれたまま表示と同じズレがJPEG現像画像に生じるということでいいのですよね？
TIFFの読み込み時は問題がない

単純にJPEGデコード時にずれているということが疑われるのかな？
でもあちらの掲示板のスレッドでは「Developer Studio生成JPEGファイルでは現象(表示時の)が確認できない」ようにも書かれています。
でも多重にJPEG現像するとズレが目立つと報告されている。
じゃ、どこに問題が潜んでいるのか？
わからなくなってしまいます。
また、キャプチャ画像で調べるなら表示ソフト全部カラーマネージメントを無効にしモニタ指定もWINDOWSのデフォルト(sRGBなんとか)にするとプロファイル変換をしないはずだから問題が切り分けられるように思えます。

ちなみにMac環境ですがJPEG現像でデフォルトパラメータ現像した際に結果として色が変わる現象はあるようです。
ただ自分の考え方としてJPEG現像を選択した時点で「精度の低いRAWファイルとして扱う」という考えなので結果を受け入れているということです。
ましてや他人に画像を見てもらうにしろプリントを見てもらうにしろ環境で色は変わるわけですから。

TIFFは問題なくてある種のJPEGだと問題(当初はこのような表現だったと思います)というところに「当然解決すべき問題でしょ」ということですよね？

出来たらもう一度どこかで整理された報告(読んでるとどんどん迷路に入っていくみたい)を希望します。

書込番号：6019531

[京都のおっさん]

その前に kuma_san_A1さん の [6016526] の発言の真意が図りかねます。それとご自分で検証なされたのなら、迷路にはまらない報告をしてみてください。

書込番号：6019681

[kuma_san_A1]

RGBデータじゃなくてPhotpshop使ってLab空間座標で評価するといいかなというのが一つ。
じゃなければ先に書いたプロファイル変換の起きそうな部分を排除して評価するのが妥当じゃないかと思うのがもう一つ。
JPEGデコーダも色々あるだろうから絶対的に同じRGB値になるかどうか疑問なのがさらに一つ(MacだとQuickTimeのデコーダとアプリそれぞれ独自のデコーダがあるし)。
JPEG記録自体YCbCr記録で圧縮もあることなので。

自分自身
・JPEGビューワーとして使わない
・JPEG現像するときは元ファイル自体を精度の低いRAWファイルだと思うようにする
・何らかの理由で多重にDeveloper Studioを使う場合はTIFFを経由する

というフローからそもそも問題意識自体がわたしにありません。
京都のおっさんさんが問題にされるのは理解したいです。
それにMacOSだと画面キャプチャにもモニタプロファイルが埋め込まれたりするので、1ないし2の値の違いを評価するのに適当なフローが思いつきません(たぶんPhotoshop使うことになると思います)。

書込番号：6019792

[京都のおっさん]

>(2)でデフォルト現像するとずれるという結論は何で比較して(Photoshopで前後を比較したのかな？)

そうです。画像が出来上がるので「画像全体でのヒストグラム変化」の評価です。
PhotoshopElements ではヒストグラムダイアログボックスに「平均」のレベル表示があります。RGBそれぞれのチャンネルに対して表示できます。
例えば現像前 (R, G, B) = (127.5, 128.5, 127.5)
現像後 (R, G, B) = (126.5, 129.5, 126.5)
のように変化した場合「相対比で 2 ずれた」という評価にしています。

>(1)でずれたまま表示と同じズレがJPEG現像画像に生じるということでいいのですよね？

Tiff現像でも Photoshop でのヒストグラムはわずかに変化します。それは「きちんと現像している証」と考えています。
きちんと現像している「ズレ」の差分を考慮すれば、おそらく (1) と (2) は同じであろうと。ただしここの検証はあるエリアでの比較(画像全体でのヒストグラム変化の比較でなない)ですので充分な検証ではないです。

>でもあちらの掲示板のスレッドでは「Developer Studio生成JPEGファイルでは現象(表示時の)が確認できない」ようにも書かれています

この発言も含め、ほとんどの発言は覚えているつもりでいます。それは訂正すべき内容です。原因は「(たしか急いで書き込もうとしたため)わかりにくい絵柄での目視確認で評価したため」です。
なるべく正確な情報を伝えたいとは思っていますが、能力の無さ故ある程度はご容認ください。

>キャプチャ画像で調べるなら表示ソフト全部カラーマネージメントを無効にしモニタ指定もWINDOWSのデフォルト(sRGBなんとか)にすると

これは [6011144] で書いてあるとおり、カラーマネージメントは無効にしてあります。OS(WindowsXP)でも指定していません。
この設定で sRGB のプロファイルが付いた画像を開けば、SILKYPIX、Windowsビューア、ともに RGB変換を行わないであろうとの認識でいます。
ただし AdobeRGBプロファイル付き画像を Windowsビューアにて開いたときに、強制的に sRGB のモニタプロファイルが適用され、RGB変換が行われているのであろう現象は確認していますので、上記「RGB変換は行わない」も確かではありませんが。

書込番号：6019805

[kuma_san_A1]

ヒストグラムでの平均値での評価だったというのは今初めて知りました。
それって適当な評価法なのですか？
高彩度部分での処理の違いが影響しそうですし…。
低輝度部分の処理の違いも影響しそうです。
もちろんエリアを選択しての評価なのですよね？

書込番号：6019838

[京都のおっさん]

>ヒストグラムでの平均値での評価だったというのは今初めて知りました。
>それって適当な評価法なのですか？

それは私にはわかりません。

>もちろんエリアを選択しての評価なのですよね？

そうです。エリアもときに「大体のエリア」になりますけど。
「適正な評価でなければ正しい結論に到達できない」はわかりますが、平均での評価で 1 〜 2 違うということです。

あと Lab については自分がわからないので。その前に jpegデータがどういうものかわからないので。
そもそもデジカメ(一般的なコンデジでいいです。現象はほぼ一緒と思われますので)が画像データ生成の際に Lab を経由するのかも知りません。ということで Lab を使う価値がわかりませんので。あと Elements では Lab は扱えません。

>というフローからそもそも問題意識自体がわたしにありません。

それはわかっています。
ただ、たとえ Mac であっても、ごちゃごちゃ試行しているうちに何かわかる部分はあるかと思いますよ。理にかなっていない試行はお好きではないでしょうが。

書込番号：6019919

[kuma_san_A1]

実際問題として今のMacOS X(10.4.8)でColorSyncに対応していない画像ビューワーって自分で使っている中ではwebブラウザのFirefoxだけなんですよ。
OS標準の「プレビュー」や「Mail」に「Safari」もColorSyncに対応していて「外せない」のです。
自分の画像ビューワーはレガシーな時代からのアプリでColorSyncのONとOFFが出来ますが普通にONです。
もちろんSILKYPIX Developer Studioも「カラーマッチングする」です。

この状況でFirefoxで画像表示したときだけ「色が若干薄いかな？」「暗部の落ち込みがきついかな？」程度の感覚を持って普段作業しているわけです。
基本的に埋め込みICCがsRGBだったらプロファイル変換されてモニタに表示している状態(別にユーザーが気にしなくていいように)なんだろうと思います。
画面キャプチャファイルや「webページ作成」というアプレットで変更した場合はその時点で設定されているモニタプロファイルが埋め込まれます(この場合はその生成ファイルを作るときにプロファイル変換もされているだろう)。

するとわたしの環境でキャプチャ画像をPhotoshopで開くと必ずプロファイル変換されるわけで「同じ値を期待する」ことはできない(同じような色は期待できるけど)ですよね。

つまり、(1)の評価だけはわたしには無理です。
それ以外は注意深く作業すれば可能かもしれませんが宿題とさせてください。

書込番号：6020064

[京都のおっさん]

緑っぽさの検証の不備(？)を指摘されましたが、スクリーンキャプチャ画像の場合はそれ以前に「異種ソフト間でどうやって画面表示の位置を合わせるか」の問題がありますので。自分の場合はどのみち厳密な検証は無理と思っています(あくまでも自分の場合)。
なるべく対等な条件を作りたいとは思ってますけど、そこまでやる意味は無いと感じています。なぜなら知識が無さすぎるから。jpegデータはどういう風に作られるのか、どういう風に展開されるのかを知っていなければそういった検証はできませんから。

で、[5999296] で

>なお、[5874568] の私の検証には誤りがありますので

こういう発言をして、その後

>「要素データとの相関」を調べるなら、1677万色全て調べないと駄目

と書いてますが、最後の発言は大げさに書いてます。
自分の Elements では jpeg画像で 1677万色作り出せません。
例えば (R, G, B) = (128, 127, 128) の単色画像を新規作成で作って jpeg で保存、それを閉じて再読み込みでヒストグラムを確認すると
(R, G, B) = (127, 127, 127)
となるからです(故に「私の検証には誤りがあります」の記述)。

グレーで無い適当な RGB比率の jpeg画像を作ります(もちろん再読み込みで jpeg としての RGB を確認)。こういう場合はヒストグラムの「標準偏差」が 0 で、「平均」と「中間値」が一致します。写真とは違い、ノイズの無い画像ということですね。
こういう単色画像でも「だいたい G相対レベルが 1 〜 2 上昇」は確認できます。
よく覚えていませんが、SILKYPIX掲示板スレの結論もこれに近い感じだったはず。モニタプロファイルについては自分は知らなかったので、なぜそれを適用するかはおまかせだったのですが。

書込番号：6020072

[京都のおっさん]

SILKYPIX の「カラーマネージメントを有効にする」のチェックボックスを外した状態では「モニタプロファイルを適用していない状態」を作り出せないのですか？
もしその状態を作り出せるのであれば

>グレーで無い適当な RGB比率の jpeg画像を作ります

これで作った画像を SILKYPIX のカラマネOFF で表示 → スクリーンキャプチャ

この方法を (3) とでも何でも呼んでいいですが、この方法で確かめられます。
2, 3種類の適当な(グレーでない)カラー単色画像を作りスクリーンキャプチャした結果。
・SILKYPIX　　　　　・・・ G相対レベル上昇
・Windowsビューア　・・・ RGB値まったく変化せず

WindowsXP ではこういう結果です。
「RGB値」とは、作った単色 jpeg画像を一旦閉じ、Elements に再読み込みして(なぜなら RGB値が jpeg保存で変わるから)、Elements のヒストグラムで得た RGB値のことです。

Photoshop が認識している RGB値 ＝ Windowsビューアが出力している RGB値

ということが(数少ない試行では)確認されています。


上記はキャプチャの試行。
じゃあ単色画像の RAW Bridge を用いて jpeg現像した結果は？
については、まだ試してません。

書込番号：6020131

[kuma_san_A1]

スクリーンキャプチャは「等倍表示」で行っているのですよね？
縮小表示による誤差は回避していると…。
疑わしい要素は「排除しているよ」と明確に記述されると読む人は安心して考察できます。

で、Developer Studioを「カラーマネージメントをしない」に設定することは可能です。
でも画面キャプチャするとモニタプロファイルがICCとして埋め込まれるのは説明したとおり。
Firefoxで表示して画面キャプチャすれば同じ条件といえば同じだが比較としてどうかと…(Firefoxが信頼に値するかどうかということ)。

書込番号：6020176

[京都のおっさん]

>じゃあ単色画像の RAW Bridge を用いて jpeg現像した結果は？
>については、まだ試してません。

この方法は (4) ですか？
一つだけ試しました。

SILKYPIX はマウスポイント点の RGB値を画面右下に表示します。
スクリーンキャプチャの場合、Elements で表示しているキャプチャ画像の RGB値は、SILKYPIX マウスポイント点の RGB値と一致しました。

しかし jpeg現像して、出来上がった画像を Elements で開き RGB値を得ると、それはキャプチャRGB値とわずかに異なりました。
この原因が「RAW Bridge」によるものか「jpeg圧縮保存」時に変化するものかはわかりません。
ただし「わずかに異なった」…値 1 の差なので、どちらが原因でもよいと思います。

この方法でも、
jpeg現像で G相対レベルが 1 〜 2 上昇する
ことが確認されました。
ただしある一つの色についてだけの試行です。


いちおう操作方法は、誰もがわかる、をモットーに書いているつもりですが、わかりにくかったら質問ください。
SILKYPIX も Photoshop も体験版があるので、高速回線があれば誰でも試せる内容です。

書込番号：6020199

[京都のおっさん]

>スクリーンキャプチャは「等倍表示」で行っているのですよね？

そうです。

>で、Developer Studioを「カラーマネージメントをしない」に設定することは可能です。
>でも画面キャプチャするとモニタプロファイルがICCとして埋め込まれるのは説明したとおり。

ではキャプチャの方法は無理ですね。
単色画像を使ってマウスポイント点の RGB値を読み取る「擬似スクリーンキャプチャ」くらいなものですか。
もっとも「擬似スクリーンキャプチャ」とスクリーンキャプチャが同じことを証明する必要はあるのかもしれませんが、「カラーマネージメントを有効にする」チェックボックスを外せば(Windows版はこういう表現をします)同じはず、と思うのですが。
つまりマウスポイント点は SILKYPIX が認識している RGB値であり、SILKYPIX のカラーマネージメントを OFF にすればその RGB値がそのまま出力されている、と考えます。

書込番号：6020221

[kuma_san_A1]

(4)の場合の「スクリーンキャプチャの場合」が意味不明となっています。

＞スクリーンキャプチャの場合、Elements で表示しているキャプチャ画像の RGB値は、SILKYPIX マウスポイント点の RGB値と一致しました。

ごめんなさい。
やっぱり「遠い」宿題にさせて下さい。

書込番号：6020229

[アユモン]

門外漢の頓珍漢質問でお邪魔します。
RAW Bridge というのは、
http://www.isl.co.jp/jpegphoto/news/rawbridge.htmlのことですよね。
京都のおっさんさんが検証されているのは、
SILKYPIX Developer Studio 3.0 Windows版Ver3.0.5.4ですか？
リリース履歴
[2007/02/13 Ver3.0.5.4]
製品版としてリリース
[2007/02/09 Ver3.0.5.4] *** Early Preview ***
● RAW Bridgeの問題の修正

書込番号：6020241

[京都のおっさん]

画像(A):「通常写真」
画像(B):「Photoshop などで新規作成した RGB値のわかっている単色画像(非グレー)」

(1): (A) を SILKYPIX で等倍表示させたスクリーンキャプチャ画像が、元画像(A) とどれだけ色ずれしているかを調べる検証方法

(2): (A) を SILKYPIX で jpeg現像した画像が、元画像(A) とどれだけ色ずれしているかを調べる検証方法

(3): (B) を SILKYPIX で等倍表示させたスクリーンキャプチャ画像が、元画像(B) とどれだけ色ずれしているかを調べる検証方法

(4): (B) を SILKYPIX で jpeg現像した画像が、元画像(B) とどれだけ色ずれしているかを調べる検証方法

検証方法そのものはソフトウェアの選択に始まり、RGB値のズレを調べるのか、あるいは Lab で調べるのかなど、色々な方法が考えられます。
私は Elements でのヒストグラムでの RGB値を採用しています。(A) を用いた場合は「平均」での評価、スクリーンキャプチャの方法では「(同一点と思われる)矩形エリア」を選択しての評価です。
スクリーンキャプチャについてはモニタ画面解像度より小さい画像を用いれば画像全体に対する評価が出来ると思いますが。

>＞スクリーンキャプチャの場合、Elements で表示しているキャプチャ画像の RGB値は、SILKYPIX マウスポイント点の RGB値と一致しました。

今のところ (3) でのキャプチャ画像の RGB値(Elementsによる取得値)は、キャプチャ画面(SILKYPIX の画面のことです)でマウスポイントすると右下に表示される RGB値(SILKYPIXによる表示値)と同じようである。ということです。単色画像なので画像上にポイントすれば (A)画像のように RGB値(SILKYPIXによる表示値)が変化することはありません(当たり前)。
そして同じ単色画像を用いて (4) の方法を試します。この時もマウスポイント点の RGB値(SILKYPIXによる表示値)は (3) で得た RGB値と同じです。
ここまでの RGB値は全て同一であることに注意。

ところが jpeg現像結果の RGB値(Elementsによる取得値)は上で得た RGB値とは異なるということです。
これが次の文章

>しかし jpeg現像して、出来上がった画像を Elements で開き RGB値を得ると、それはキャプチャRGB値とわずかに異なりました。

の意味です。


[6020241] アユモンさん それは知っています。リリースノートにもそのように書いてあるようです。
何が改善されたのかは不明です。今回の問題に関する挙動は変わっていないようです。
また、JPEG Photography は「SILKYPIX の RAW Bridge 機能をそのまま移植した」と考えて構わないと思います。以前試したときはすくなくとも同等に感じられました。

書込番号：6020397

[京都のおっさん]

で、結局のところ自分の場合は

>本気になって「要素データとの相関」を調べるなら、1677万色全て調べないと駄目でしょうね。そこまでするつもりはもちろんありません。

こういう話になるということです。
(B)画像で調べると、中には「緑っぽく」ならない色ももちろんあります。
しかし (A) の通常写真を用いる限り、ごくふつうの風景(街並み、部屋など)の写真の場合は緑っぽくなることが圧倒的に多い、というのが私の経験です。

で YCC → R'G'B' の変換式を眺めると、G' だけ右辺の形が違うなと。今回自分が新たに得た知識はこの部分です(もちろん YCC が何かまでは理解していません)。

書込番号：6020430

[京都のおっさん]

「jpeg」について自分が今考えていることを書いてみます。言葉の使い方は変ですが。
なるべくシンプルなモデルが良いのでカラーマネージメント(カラマネ)はオフです。カラマネとは「モニタプロファイル」のことです(実際は入力プロファイルもあるが無視)。モニタプロファイルとは個々のモニタ特性に合わせて、画面表示時に元のRGB値を別のRGB値に変換するためのものです。よってここではカラマネはオフ。
また、画像は (B) の単色画像を想定します。(A) だと空間周波数(画像を点ではなく二次元で捉えること)の圧縮問題も考えねばならないので複雑化するからです。

・jpegエンコード … 生のRGB値のデータを、jpeg形式のデータ(コード)に変換すること。jpeg圧縮、jpeg保存。
jpeg形式のコードが何者かは知りませんが、RGB → YCC 変換したデータの圧縮と考えればよいでしょうか。

jpegエンコードで変換ロスがあることを自分は知っています。[6020072] の例では (128, 127, 128) → (127, 127, 127) になったと言ってかまわないでしょう(「かまわないでしょう」の言い回しはこれ以降の記述参照。実際には Elements の jpegデコードに依存するから)。

・変換ロス … RGBデータをコード化する際、元のRGB値が別のRGB値に化けてしまうこと。

jpegエンコードの際の「色の変化」は自分は問題とはしていません。「そんなもんじゃない？」って思っているからです。特に根拠はありませんが。

・jpegデコード … jpegエンコードの逆で、jpeg形式のコードから生のRGB値を抽出(復元)すること。

しかし jpegデコードの際に、Windowsビューアと PhotoshopElements は変換ロスしないように思います。その根拠は両者の出す値が一緒だからです(本当に一緒かはこれ以降で説明)。
「両者の出す値が一緒では変換ロスが無いことの証明にはならない」と言われればそれまでですが、別にそれでもいいです。「両者の出す値が一緒」ということで、SILKYPIX の特殊性が浮き彫りにされればそれで良いと考えます(これ以降で説明)。どっちが正しいのかは(もし返答があるなら)サポートの意見を聞いた後に判断します。


・プリントスクリーン … Windows の提供する「画面 RGB データ保存機能」のこと。生の RGB値データ。
・キャプチャ画像 … プリントスクリーンしたデータを Photoshop などのソフトで取り込んだ(未保存)画像のこと。

キャプチャ画像の RGB値(Photoshop のヒストグラム表示、情報画面などで得られる値)はプリントスクリーンの RGB値と同一です(単なるデータのコピーだから当たり前)。間に jpegエンコードなどによる変換ロスがありません。


ここで元画像(B)を用意します。(B) の RGB値は
(137, 118, 138)
とします(実際に試した値)。

ところで (137, 118, 138) とは何かと言いますと、PhotoshopElements が情報提供している値です。
つまり (137, 118, 138) とは、
PhotoshopElements が元画像(B)を「jpegデコードした値」のことです。つまりこの値が正しいかどうかなどわかりはしません。

元画像(B)を次は Windowsビューアで表示させプリントスクリーン、Elements でスクリーンキャプチャします。このときの Elements が情報提供してくれた RGB値は
(137, 118, 138)
でした。
プリントスクリーンとスクリーンキャプチャで変換ロスが生じないことを考慮すると
「Elements の jpegデコードの仕様と、Windowsビューアの jpegデコードの仕様は同じである」
と言い切ってしまっても構わないと思います(きちんとした検証には 1677万色全部を試す必要があります)。

では元画像(B)を SILKYPIX で表示させプリントスクリーン、Elements でスクリーンキャプチャした RGB値はどうか？
(138, 120, 138)
がその答えです。
「SILKYPIX の jpegデコードの仕様は、Elements や Windowsビューアとは別物である」
ということが確定します。


この話の中におかしな部分が無ければ、検証はこれで充分ではないでしょうか？


さらに「jpeg現像」まで検証に加えると話は複雑化します。それは
「SILKYPIX の元画像(B)の jpegデコード」
の他に
「SILKYPIX の RAW Bridge アルゴリズム」
「SILKYPIX の jpegエンコード仕様」
「Elements の jpegデコード仕様」
の三つの要素を加えねばならないからです(Elements で RGB値を評価する場合)。

結果を一応書けば
(139, 120, 139)
です。


以上、話の前後が飛びとびになりわかりにくいですが、自分の考えはこんな感じです。

書込番号：6020571

[ねぼけ早起き鳥]

おはようございます。
京都のおっさんさん、検証内容ご説明ありがとうございます。
みなさん、議論白熱歓迎です。
私も理解が及ばないながら、たいへん勉強になります。

みなさんの検証の中味に立ち入るための道具と知識が今はありません（スレ主でありながら申し訳ありません）ので、周辺を散策です。
一般にそれが社会通念的に不当なものでない限り、顧客の不満や疑問点を解決するために、説明や検証に努力する責任はメーカーさんにあると思います。
しかし、メーカーさんがそのように対応しない場合があるのは、次のことが考えられます。

１．法律、規則、規制、規程、基準、定義などと呼ばれるものに従っている、または、ガードされている（という思い込みがある）場合。
２．経済的あるいは、経営戦略・戦術的な事情がある（と考えている）場合。
３．顧客情報の管理能力・体制が（著しく）欠如している（または機能していない）場合。

前の方で隠蔽体質の話がありましたが、今回の場合を推測するに、私は３．はないと思います。
２．はあり得るかもしれません。
問題は、１．ですね。
もしも、設計者や関係者が１．であった場合は、顧客の不満や疑問が正当なものであっても、門前払いされることはじゅうぶん考えられますね。
そういえば、私の妻が車の検定で「ダイダイ」と答えて、危うく門前払いになりかけことがありましたっけ。
もちろん、あってよいということではありませんよ。。。

書込番号：6020896

[LUCARIO]

> 車の検定で「ダイダイ」と答えて、危うく門前払い

ぶわははは。「信号の色」ですか？

ちなみに私、小学生の頃、父に言われたことを真に受けて
「40と書かれた標識は、50キロまでは捕まらない」と
学校の道徳の時間に答えて怒られたことがあります(爆)

また、私の息子が最近、私の普段の言動を見てか
「信号が赤になったタイミングで、停止線を越えていれば大丈夫」
などと学校で言ったらしく、後のフォローが大変でした(爆2)。

＃てスミマセン。真面目な話に途中でしたね(^^;;;
＃私も時間と気力が取れたら検証方法の模索を含めて色々試してみます。
＃ちょっと、今は他の案件でアタマが一杯なもので…m(_o_)m

書込番号：6020954

[ねぼけ早起き鳥]

【ぶわははは。「信号の色」ですか？】
LUCARIOさん、その通り。
検定員曰く、「表へ行って信号見て来いっ！」
妻も然る者、「見て来たけどやっぱり【ダイダイ】。。。」
以来、色に関しては妻を信頼しています＾＾；

【、後のフォローが大変でした(爆2)。】
ぐはあはあはあ。。LUCARIOさん、間違いなく運転適正のＤＮＡ鑑定は息子さんですね(爆3)。

書込番号：6021123

[ねぼけ早起き鳥]

LUCARIOさん
運転適正→運転適性
訂正です。

【ダイダイ】続編。
検定員気色ばんで、「ホントに間違いないか。。？」
妻、「そういえば、ちょっと暗くて汚れてましたけど。。。」(爆4)。

書込番号：6021192

[京都のおっさん]

[6020571] で使用した「元画像(B)」をアップしておきました。
http://album.nikon-image.com/nk/NK_ImageAlbum.asp?id=11133545&key=711615&un=115360
(R, G, B) = (138, 118, 138) の画像を
Elements で jpegエンコード → Elements で jpegデコード
した結果、
(R, G, B) = (137, 118, 138)
との RGB値を得た、ということです。

この画像には「sRGB IEC61966-2.1」というプロファイルを付けています。それが「モニタプロファイルを適用した(カラーマネージメントを有効にさせた)」検証では意味を持ってきます。
これ以降ではカラーマネージメントを有効にさせた検証ですので話が複雑になります。また、その理解には「色空間」という概念が必要となりますので、興味のある方のみお読みください。特に重要な検証というわけでもないので。

準備として WindowsXP の「画面のプロパティ」を開き、設定 → 詳細設定 → 色の管理、と進み「sRGB Color Space Profile.icm」を追加、規定のモニタプロファイルに設定します。このプロファイルは OS付属のファイルと思います。
この設定は PhotoshopElements3.0 の為に必要です。設定後に Elements を起動すると、Elements はこのモニタプロファイルを画像表示時に適用します(カラー設定で「カラーマネージメントなし」以外を設定した時)。

Windowsビューアの元画像(B)の表示結果は (137, 118, 138) で変化ありません。
Windowsビューアは OS設定にかかわらず「モニタプロファイルを適用しない」からです(例外は AdobeRGB のファイルを開いた時)。

Elements の元画像(B)の表示結果も (137, 118, 138) で変化ありません(カラー設定で「カラーマネージメントなし」以外を設定。「カラーマネージメントなし」に設定するとモニタプロファイルを適用しないので、検証の意味が無い)。
これはなぜかと言うと、元画像(B)のプロファイルが「sRGB IEC61966-2.1」、モニタプロファイルも同じなので、「適用はしているが変化はしない」からなのです。

ちなみに DPEx というカラーマネージメント対応ソフトでモニタプロファイルを適用しない(カラマネなし)設定だと (137, 118, 138) で、この結果は [6020571] の Windowsビューア、Elements と変わりません(jpegデコード結果は同じ)。
モニタプロファイルに「sRGB Color Space Profile.icm」を指定してモニタプロファイルを適用させると
(137, 119, 138)
となります。G の値が 1 大きいですね。
でも私にはこれくらいなら誤差と認められるかな、という気がします。あるいは画像の埋め込みプロファイルとモニタプロファイルが若干違う可能性もあるし(画像のプロファイルは Elements が設定しています)。むしろ「ちゃんとモニタプロファイルが適用されている」証拠と言えます。

SILKYPIX の「カラーマネージメントを有効にする」は二つ選択ができます。
一つは「ウィンドウズのデフォルト設定に従う」の「sRGB IEC61966-2.1」です。このモニタプロファイルが先の「sRGB Color Space Profile.icm」と同一かどうかは不明です。
二つ目は「ファイルから選択する」で、当然「sRGB Color Space Profile.icm」を選びます。
結果は両方とも
(138, 120, 138)
でした。[6020571] の「カラマネなし」の結果と同じです。


考え方の上では「画像プロファイルとモニタプロファイルが同一であれば、画面表示結果はプロファイル変換しないのと一緒で、RGB値に変化は無い(jpegデコード結果と同じ RGB値を得る)はずである」で良いのではないでしょうか？
DPEx では変化がありました。しかしこれは容認できる誤差ではないでしょうか。
Mac環境においても、モニタプロファイルに「sRGB IEC61966-2.1」を指定すれば、この検証と同じ結果が出るのでは？ と予想します。


なお私は、Elements に付属している「sRGB Color Space Profile adbe.icm」というプロファイルファイルも持っています。Windows のプロパティで「プロファイル情報」が表示されます。
sRGB Color Space Profile.icm」のプロファイル情報は
「カラープロファイルの生成者：Copyright (c) 1998 Hewlett-Packard Company」
sRGB Color Space Profile adbe.icm」のプロファイル情報は
「カラープロファイルの生成者：Copyright (c) 1998 Hewlett-Packard Company Modified using Adobe Gamma」
と、それぞれあります。両者とも「カラープロファイルの説明」は「sRGB IEC61966-2.1」です。
実際に元画像(B)で試したところ、これは「sRGB Color Space Profile.icm」とは別物ですね。
「sRGB Color Space Profile adbe.icm」ではさすがに「SILKYPIX の jpegデコードの特殊性」を調査することは不能と感じました。


余談としては、SILKYPIX3.0 のマウスポイントによる RGB値表示は「jpegデコード結果」に感じます。カラーマネージメントを有効にしても RGB値表示に変化はありません(SILKYPIX1.0 ではカラマネ有効にすると表示が消えた)。
で、JPEG Photography には無い機能ですが、SILKYPIX3.0 には「JPEG/TIFFを現像対象とする」チェックボックスがあります。これをオン・オフしても今回の検証結果に差はありません。
Tiff現像で色が変化しないことを考え合わせると、RAW Bridge は jpegデコード後にやっている、と考えるのが当然なのですが、
「じゃあ SILKYPIX の RAW Bridge の画面表示(プレビュー表示)って何？」
って疑問が湧いてきます。
単に「jpegデコード結果の表示」なのか、でもそれだと「What You See Is What You Get」じゃなくなるし。Tiff現像でもわずかにヒストグラムは変化しますので。
って考えると SILKYPIX の画面表示に関する疑問は次々湧いてきます。
[6015342] でちょっと書いた
>「画像表示時にトーンジャンプ(その実態はノイズ？)が他のソフトより緩和される」
もその一つです。

書込番号：6024709

[ねぼけ早起き鳥]

京都のおっさんさん
おつかれさまです。
ちょっと長かったので、１／３くらいまで読んでから、あれっ？おなじっ？？でした。。＾＾；

このほど、スペインのカンタブリア州で開催された「ミス・カンタブリア」騒動は、いかに定義や基準の前提と運用の根拠がいい加減かを物語ってますね。
スグれた設計管理者はそこに気づくべきです。
ねぼけの囀りでした。。。

書込番号：6026817

[kuma_san_A1]

宿題は放置のままなのですが…

＞余談としては、SILKYPIX3.0 のマウスポイントによる RGB値表示は「jpegデコード結果」に感じられます。カラーマネージメントを有効にしても RGB値表示に変化はありません(SILKYPIX1.0 ではカラマネ有効にすると表示が消えた)。

ちょっと誤解だと思いました。
JPEG現像モードでは出力色空間の指定で変化します。
それが作業色空間ということになるからです。

書込番号：6026925

[京都のおっさん]

すいません。「パラメーターが不正です」が出たので重複書き込みしました。削除以来出して起きます。

サポートからは再調査する旨、連絡がありました。

>JPEG現像モードでは出力色空間の指定で変化します。
>それが作業色空間ということになるからです。

たしかにそうですね。では RAW Bridge後のデータかな？
JPEG/TIFFを現像対象とするを外せば jpegデコード後RGB ですかね。よくわかりませんが、あの画像データでは変わりませんでした。
ただし Windows版の出力色空間指定はバグがあるっぽいです。RGB値が変化しません。

>Tiff現像で色が変化しないことを考え合わせると、RAW Bridge は jpegデコード後にやっている、と考えるのが当然なのですが、

ちょっと今読んだら意味不明ですね。何か言いたいことがあったから書いたと思うのですが。
普通に考えたら RGB展開 → RAW Bridge で当然と思いますが。
その話とちょっと関連するかと思いますが、

>RGBデータじゃなくてPhotpshop使ってLab空間座標で評価するといいかなというのが一つ。

これって RGB の色域外データのことですか？
YCC色空間は RGB色空間より広いらしいですが(そこのデータを出力する PrintImageMatching という技術があるらしいですが)、このあたりは私はわかりません。
以前アップした部屋の画像も DPEx で見ると sRGB を超える YCCデータがあるそう。で、RAW Bridge後のデータにも、キャプチャ保存画像のデータにも sRGB超えはあります。とするとプリントスクリーンって RGB値の授受ではない？
一旦 YCC → RGB に変換した時点で、sRGB超えデータはクリップして再生不可能と考えていましたので、よくわかりません。
http://image-d.isp.jp/commentary/color_cformula/YCbCr.html
これの YCC それぞれの範囲を超えたところが RGB超えの部分だと考えていたのですが。結局これ以上は私にはわかりません。


あと [6020571] の
>ところで (137, 118, 138) とは何かと言いますと、>PhotoshopElements が情報提供している値です。
>つまり (137, 118, 138) とは、
>PhotoshopElements が元画像(B)を「jpegデコードした値」のことです。つまりこの値が正しいかどうかなどわかりはしません。

このへんの記述についてですけど、やはりこの値は「jpeg画像の RGB値」だと思います。つまり YCC → RGB は一意に定まる前提ですが。
(138, 118, 138) を jpegエンコードして (137, 118, 138) になった。
との考えです。
でないと、元画像(B)を「表示→キャプチャ→保存」の繰り返しで (137, 118, 138) が Elements では保たれることの説明がつきません(三連続試しました)。Windowsビューアでもこれはそうです。デコード誤差があったらどんどんずれていくと思うのです。
SILKYPIX はキャプチャ連続を繰り返すと緑っぽくなります。やはり SILKYPIX の jpegエンコードだけが変だなと。ここで三ソフトでの検証での要素の変化は jpegエンコード部分だけですから。
(137, 118, 138) の Tiffファイルを使ってキャプチャ連続の検証をすると、SILKYPIX でも当然のように値は変化しません。
色域外YCCデータは別にして、jpegデコード結果は一意に定まって当然と思いますけどね。べつに規格にあるかは知りませんが。一意に定まらないとなると、今度は誤差範囲を規定しなければいけないと思います。誤差を規定しないと、今回の場合のように 2 程度の誤差ならみんながたがた言わないみたいですが、これが 10 の誤差だったらどうか、って話になっちゃいますから。
元画像(B)を DPEx で YCC表示させても、色域外データは無いとのことでした。

書込番号：6028050

[京都のおっさん]

>やはり SILKYPIX の jpegエンコードだけが変だなと。ここで三ソフトでの検証での要素の変化は jpegエンコード部分だけですから。

デコードの間違いです。

書込番号：6028080

[kuma_san_A1]

出力色空間というのはモニタプロファイルとは別のことを書いてます。
現像時の色空間指定という意味です。

色差情報を扱うときに小数点以下の扱いが違うということじゃないのかな？
デコードの場合だと
Cr(赤の色差)
Cb(青の色差)
どちらも128が中心
小数点以下を切り捨てると相対的にG成分が強くなりそう
エンコードの場合だと切り上げると…なんて考えたりもしますが。
デコードもエンコードも昔から使い回していた部分だろうからチェックの外だったりして。
これだとグレーバランスは変化しないのも(きっちり色差がそれぞれ128だったら関係ないから)説明できたりして。

変換式から明示的に少数部分が変化するところを狙ったターゲット作って試すのも手かも。
どこの部分かは開発の人に「疑わしい部分」伝えてチェックしてもらった方が速いでしょう。

書込番号：6028118

[京都のおっさん]

>現像時の色空間指定という意味です。

わかってます。
それでバグがあって、って、実際に出力される RGB値(モニタプロファイル適用前)も変わらないんじゃないかな、Windows版のバグは。使わない機能だし検証面倒なんで。

前にも書きましたけど、G' だけ右辺の形が違いますからね。Cr と Cb の両方を項に持ち、しかもその係数はマイナス。R' と B' は係数はプラス。
ただこれだけ見ると「緑っぽくなる」のはよくわかりません。マゼンタっぽくなる例がたくさんあってもおかしくないのに。とりあえずまだマゼンタっぽい例を(単色画像でも)発見できていません。

自分個人に関しては今のままで別段困らないのですけどね。たまたま手持ちにマゼンタかぶりが気になる画像がたくさんあって、デフォルト現像でほどよく直って・・・
って、これって思いっきり技術者を馬鹿にしてるんで。もし不正なら早く気付いた方がいいかなと。
ってことを妄想してたらグレー点指定ってありましたね。jpeg現像であれ使ったらどうなんだろ？
そこはグレーになるのか、あるいは +2 になるのか。
自分は使わない機能なので興味のある方は試してみてください。

書込番号：6028194

[ねぼけ早起き鳥]

こんにちは。

京都のおっさんさんの、
【前にも書きましたけど、G' だけ右辺の形が違いますからね。Cr と Cb の両方を項に持ち、しかもその係数はマイナス。R' と B' は係数はプラス。】
で、単純にR' G' B'の変換式を見ているだけの疑問ですが。。。

変換式の項の（Cr-128）、(Cb-128)は、Cr と Cbの値によって、係数がらみのプラス・マイナスは変わりますよね？
たしかにおっしゃるように、【マゼンタっぽくなる】こともあれば【緑っぽくなる】こともありそうですね。
常に一方向に【緑っぽくなる】のでしたら、変換式の項や係数のみには依存しないのかも。。と、思っちゃいましたが。。。

書込番号：6029156

[kuma_san_A1]

係数を無視した一般的な話ね。

Cb->128より大きければ青方向で小さければ黄色方向
Cr->128より大きければ赤方向で小さければシアン方向

CbCrがともに128->グレイ(無色)
CbCrがともに128より大きければマゼンタ方向で小さければグリーン方向

ということを変換式は表している…ってお二人とも理解できているんですよね？

書込番号：6029624

[ねぼけ早起き鳥]

kuma_san_A1さん
【係数を無視した一般的な話ね。】
係数の符号は無視していませんが、値（のまるめ方？）は無視して眺めていた、ということです。

【CbCrがともに128->グレイ(無色)】
このときは、輝度Yの項だけになるんですよね。

【CbCrがともに128より大きければマゼンタ方向で小さければグリーン方向】
【ということを変換式は表している…ってお二人とも理解できているんですよね？】
少なくとも、私はじゅうぶん理解できておりません。
変換式を眺めていて、
”常に一方向で、CbCrがともに128より小さい”とは思えない、
と思っちゃったわけです。。。

書込番号：6029807

[京都のおっさん]

いちおう「騒動」ということにして、騒動のここまでの経過のまとめ。

発端はこのスレ。
http://www2.isl.co.jp/SILKYPIX/japanese/beta/sakura/bbs/?mode=all&namber=1332&space=0&type=0&no=0

次は 9月2日に SILKYPIX3.0ベータ版の RAW Bridge をコンデジ画像に適用して「色の違い」に本人が気付く(その時の画像の作成日時で確認しました)。ただし「緑っぽい」とは気付いていない。

機能を利用しない時期が続き、頭の中で潜伏期間を経て
http://bbs.kakaku.com/bbs/-/SortID=5765750/
これの [5808203] (価格コムで話題に上ると本人は使ってみようかなという気になるようです。以後は常用機能)。

次は
http://bbs.kakaku.com/bbs/-/SortID=5854530/
の [5867879] 以降のレス。

これでやる気になりサポートの質問フォームで連絡
---------------------------------------
+++++++++++++++++++++++++++++++++++++++
RAW Bridge 機能について質問です。
jpeg現像を、パラメーターをいじらず(つまりテイストがデフォルトのままで)実行すると、オリジナル画像に比べ、わずかに緑っぽくなります。
なお、R=G=B のグレー画像のカラーバランスは崩れません。グレー以外の色がわずかに緑っぽくなります。
受付日：2007/01/13(Sat) 00:26:23
++++++++++++++++++++++++++++++++++++++++----------------------------------------(かなり省略してあります。最初の「色が違う？」スレとの関係性の可能性についても言及しています。また、上のリンク内 [5874568] で「jpeg現像を繰り返すたびに緑が強くなっていきます」とありますが、サポートにはそこまで強くアピールしていません)
サポートは Tiff のみ試し、緑っぽくならないことを確認した模様。

そして今スレ [6015342] にて再度質問フォームに連絡
----------------------------------------++++++++++++++++++++++++++++++++++++++++画面表示、jpeg現像が緑色になる件を再調査していただきたく、再度書き込みさせていただきます。
受付日：2007/02/18(Sun) 00:17:57
++++++++++++++++++++++++++++++++++++++++----------------------------------------(こちらのスレで概ね意見の一致を得ていると思われる、jpegデコード時の YCC → RGB 展開時に誤差が出ているのだろうとの推論も付記しました)


本日、サポートより連絡がありました。
今回のサポートの文章は読解がやや難しいのですが、いちおう
SILKYPIX Developer Studio 3.0 Windows 版
において問題現象が確認されたそうです。
重要と思われる部分を抜粋します。

＞結論から申し上げますと、緑がかる問題は、
＞JPEGデコードに際して演算誤差により、
＞有彩色部分で G の値が大きくなることが判明しました。

「判明しました」は「原因です」と言い換えた方がたぶん良いのだと思います。
また、その後の文章で YCbCr から RGB 値に変換するには演算が必要ともあります。
対応までには今しばらく時間を頂きたいとのことです。

書込番号：6030992

[kuma_san_A1]

おつかれさまでした。
推論も遠からずということでしたね。

書込番号：6031030

[アユモン]

京都のおっさんさん、
やりましたね。市川ラボは、京都のおっさんさんをテスターに任命し、ソフトを無料提供すべし。
（今回の一件だけでも菓子折りの２つや３つ貰ってもおかしくないねぇ・・・）

書込番号：6031369

[kuma_san_A1]

アユモンさん、それはズレてますよ。
とにかく開発テスト版時からの課題が一つあちらに届いたということです。

書込番号：6031387

[アユモン]

kuma_san_A1さん、
見つけられなかったバグはつぶせんのだから、
ソフト開発で一番のキモは、バグの発見だと思うけど違うかな？
そこにコストがかかるんじゃないかと思っているのだけど・・・
（人海戦術の人件費）

書込番号：6031492

[kuma_san_A1]

依頼されていないのだから謝礼は発生しないものだと思われます。
普通の考え方のことね。

書込番号：6031517

[アユモン]

kuma_san_A1さん、
菓子折りを、謝礼（或いはお詫び）と位置づけて、「この場合はいずれにも該当しないから・・・」なんてこと言ってる企業は伸びんと思うよ。
（菓子折りというのは一例でユーザーとのコミュニケーションツールは、色々あるよね。β版ソフトの提供なんかコストかからないし）

書込番号：6031729

[kuma_san_A1]

いえ、ユーザーを対等に扱わない企業のほうが嫌いです。

書込番号：6031756

[アユモン]

kuma_san_A1さんは、
「お客様の貴重なご意見は、しかるべき担当者に・・・
今後の商品開発の参考にさせていただきます。今後とも弊社の商品をご愛顧いただきますよう・・・」
というのがお好きかな？

書込番号：6031862

[kuma_san_A1]

いえ、やることさえちゃんとやってくれたらノーリアクションでもかまいません。

書込番号：6031878

[アユモン]

なーるほど・・・
「やることやらないでもユーザーみんなに平等ということに変わりなし」とならないように企業には頑張ってもらいましょう。

書込番号：6031926

[LUCARIO]

風邪を引いてしまい、顔色が青くなったり赤くなったり大変です。
今の所、緑にはならないようです。え？お前は寝てろって？(笑)

京都のおっさんさん、
長らくの検証お疲れ様でした。メーカーの方で現象が特定された
というのは朗報ですね。今後のリリースで対処版が出ることを
期待しましょう。

市川ソフトのいい所は、この「途中経過」を顧客にはっきり
伝えることだと思います。普通の企業だと、仮に現象が掴め、
原因が分かったとしてもそれは内部情報として外には秘匿し、
対応が完全に済んだ時点で「結果報告」として外に出します
からね。

途中経過だけ先に公開するというのは、ある意味リスキーなやり方です。
下手するとごく一部の客を「逆ギレ」させることにもなるし。
…βテストの時も色々あったなぁ。

でも、SILKYPIXの場合はこれを繰り返すことで確実にソフトの
クオリティを向上させていますからね。そしてその「恩返し」は、
全ユーザに対して等しく振りまかれているわけです。

「オレが育ててやってんだぞこのソフトは」と思っておけば、
菓子折りなんぞよりも嬉しいもんですよ(^o^)

＃惜しいのは「エンディング」ないので、「スタッフロール」に
＃「Special Thanks to...」が出せないことですね（笑）

書込番号：6032775

[ねぼけ早起き鳥]

こんばんは。
京都のおっさんさんよかったですね。
一歩前進です。
このスレも多少はこの前進に関与できたような気分でうれしいです。

さて、アユモンさん
私は菓子折り大歓迎です、芋なら"いちころ"です＾＾；

kuma_san_A1さん
【依頼されていないのだから謝礼は発生しないものだと思われます。
普通の考え方のことね。】
何とか談合の土壌も当事者は【普通の考え方】って言ってましたから、歴史の証言にはならないでしょうね。

【やることさえちゃんとやってくれたら】
おっしゃるとおりですね。
でも、そのように行動させるエンジンは何でしょうか？
こころざしとモチベーションを高く持つことの大切さ、そして持ち続けることのむずかしさは、常に顧客との接点において再確認されるものではないでしょうか。。。

LUCARIOさん、今夜は玉子酒をどうぞ。
早く風邪が治るとよいですね。
【ごく一部の客】にならないように、気をつけます。

書込番号：6034075

[京都のおっさん]

菓子折りはアユモンさん一流のジョークと受け止めさせていただきます (^^;

> (こちらのスレで概ね意見の一致を得ていると思われる、jpegデコード時の YCC → RGB 展開時に誤差が出ているのだろうとの推論も付記しました)

これなんですけど。
再調査する旨の一通目の返答を読んで「今回の再調査も空振りに終わりそう」と予感した(私見です)ので、しかたなく「敢えてこちらの推論を申し上げさせていただくのなら…」という内容の返信メールを差し上げたのです。
通常自分はこんなことはしません。プロフェッショナルに対して失礼にあたると考えるからです(そもそもこれに限らず、メーカーサポートに連絡って滅多にしませんが)。
でも結果的にこれが功を奏した感じはします(これも私見です)。

今回メーカーが問題を確認されたことで騒動はひとまず決着なわけですが、自分には特に感慨のようなものはありません。初出の時点で決着していた問題だからです。
無論メーカーが演算誤差を認めたことは大きいでしょう。自分の興味は「メーカーがこれを教訓にするのか」という点です。

書込番号：6035839

[kuma_san_A1]

わたしは推論を伝えちゃいますけどね。
違って恥かくのは自分なだけなので。

書込番号：6035888

[京都のおっさん]

>わたしは推論を伝えちゃいますけどね。

あ、やっと解読できました。
「わたしは推論をいつもサポートに伝えてはいますけどね」じゃなく、
「わたしは推論をついサポートに伝えてしまいますけどね」
の意味ですね。

職人気質の中には「素人が何抜かすか」って人、わりと多いですからね。
その意味では SILKYPIX は新しい風なのかもしれませんね。


で、リコースレ特有の(？)だらだらを (^_^;)
自分個人の考えに沿った式なのでくだらないですが、いつもやってた「Gレベルが 1 〜 2 違う」ってのはこんな感じです。
[6020571] での値を用います。
(r0, g0, b0) = (137, 118, 138)
(r1, g1, b1) = (138, 120, 138)
ここで「添え字 0 」は「正しい RGB値」、「添え字 1 」は「計算誤差が生じた正しくない RGB値」とします。
例えば(キャプチャ画像ではありませんが) オリジナルjpeg画像と jpeg現像後の画像を比べると、ヒストグラムの緑チャンネルが右へわずかに(大体 1 くらい)シフトし、赤と青チャンネルが揃って左へわずかにシフトすることが経験上多いです。

「Gレベルが 1 〜 2 違う」は(G と R のみに着目すると)
(G の誤差の差) - (R の誤差の差)
あるいは(同じですが)
(誤差のある G と R の差) - (正規の G と R の差)
です。
式で表すと前者は
(g1 - g0) - (r1 - r0)
後者は
(g1 - r1) - (g0 - r0)
です。ここからは後者を採用。G と B にも着目して計算するとと
(g1 - r1) - (g0 - r0) = 1
(g1 - b1) - (g0 - b0) = 2
です。R に着目すると G の相対誤差は 1 増え、B に着目すると G の相対誤差は 2 増えた、みたいに表現していました。
R に着目した場合と B に着目した場合で(ヒストグラムの平均を用いて)そんなに差が無いので、これで大体いつも同じように「G レベルが 1 〜 2 違う」と表現できていたわけです。


ここで
http://image-d.isp.jp/commentary/color_cformula/YCbCr.html
の YCbCr → R'G'B' の式を流用します。めんどくさいので
x = Cr - 128
y = Cb - 128
z = Y - 16
と変数を設定します。それぞれの変数の値のとりうる範囲は
-112 <= x <= 112
-112 <= y <= 112
0 <= z <= 219
です。
ここで「添え字 0 」「添え字 1 」の規則を復活して、リンク先の式を書き直します。「添え字 1 」の誤差のあるほうの式は、こちらで勝手に「小数点以下三桁目を切り捨て」た式とさせていただきます。

r0 = 1.164z + 1.596x
g0 = 1.164z - 0.813x - 0.392y
b0 = 1.164z + 2.017y

r1 = 1.16z + 1.59x
g1 = 1.16z - 0.81x - 0.39y
b1 = 1.16z + 2.01y

ここから「G と R の差」と「G と B の差」を導きます。

g0 - r0 = -(2.409x + 0.392y)
g0 - b0 = -(0.813x + 2.409y)

g1 - r1 = -(2.40x + 0.39y)
g1 - b1 = -(0.81x + 2.40y)

正規の方は「2.409」が、誤差のある方は「2.40」が、R の式も B の式も「係数に表れ」ますね。この辺は元々が差信号を用いていたからでしょうか、よくわかりませんが。
これで「誤差の差」の式(G の相対誤差がいくつ上昇したかを導く式)を導くと次のようになります。

(g1 - r1) - (g0 - r0) = 0.009x + 0.002y
(g1 - b1) - (g0 - b0) = 0.003x + 0.009y

ここで再掲しますが
-112 <= x <= 112
-112 <= y <= 112
です。つまり G の相対誤差はプラスにもなればマイナスにもなります。
こういう感じで自分は

>ただこれだけ見ると「緑っぽくなる」のはよくわかりません。マゼンタっぽくなる例がたくさんあってもおかしくないのに。

と書きました。G' の右辺の係数がマイナスは特に関係ありませんが。
これだけ見ると、彩度が低いと全然誤差が生まれないので、「小数点以下三桁目を切り捨て」では無さそう。
リンク先には YCC の拡張表現では式が変わるみたいなことが書いてあります。この式だけでは何とも言えないのでしょうね。

書込番号：6036187

[kuma_san_A1]

どうもそこの式はビデオ用(0と255を同期信号に使えるためだったりする)だと思います。
こっちを使いましょう。

Y = 0.29900 * R + 0.58700 * G + 0.11400 * B
Cb = -0.16874 * R - 0.33126 * G + 0.50000 * B + 128
Cr = 0.50000 * R - 0.41869 * G - 0.08131 * B + 128

R = Y + 1.40200 * (Cr - 128)
G = Y - 0.34414 * (Cb - 128) - 0.71414 * (Cr - 128)
B = Y + 1.77200 * (Cb - 128)

こちらだと輝度情報が0-255使えますので、デジタルカメラはこっちでしょう。

で話がまたよく見えなくなっていると思うのですがDeveloper Studioのプレビュー画面でのRGB値のサンプリングはelementsと一致したという文章からデコード時の問題ではなくエンコード時の問題だと思うわけです(ここに誤解があったらなんですが)。

で、症状が出る疑わしい部分はCbCrへのエンコード部分です。
演算最後に小数点以下の値を四捨五入でなく切り捨てで扱っているとします。
この場合切り捨て前に「0.5」足しておけば結果は同じになるからです。
そして状況を再現するには

・Y情報は0.5足して小数点以下を切り捨てた
・CbCrは0.5足し忘れて小数点以下を切り捨てた

こうしてエンコードされたものをRGBにデコード(ここは間違いがないとする)すると

R0:137
G0:118
B0:138
が
Y:126
Cb:134
Cr:135
となり、
R1:136
G1:119
B1:137
に化けます。
必ず一定方向の誤差になります。

ちなみに、そういうミスを犯さないと

Y:126
Cb:135
Cr:136
となり、
R1:137
G1:118
B1:138
となり化けません。

エンコード時にこの一定方向への誤差は出せないと思うのですけど(それともあり得るのかな)？

と、検証はしないで考察のみです。

書込番号：6036454

[kuma_san_A1]

えっと一応変換式はwebで探したものですがたくさん種類があって本当はどうやっているかはわたしは知りません。
念のためです。
でも当初から「YCbCrだから」って言っていたのは覚えていただけてますよね？

書込番号：6036469

[ねぼけ早起き鳥]

おはようございます。
みなさん、おつかれさまです。

【念のためです。】
輝度情報が0-255でも16-235でも、それにCrCbの範囲も対応していれば(すなわち変換式の景色が変わっても)、
[6036454] kuma_san_A1さんの考察の結論は変わりませんよね？

【でも当初から「YCbCrだから」って言っていたのは覚えていただけてますよね？】
もちろん、当初からJPEGデータからの話ですから、圧縮のプロセスを前提にしていたつもりです。
そこで、くだんの件が、輝度や色差成分の範囲に依存しないとすると、エンコード時の係数のまるめ方に関わるバグではないか？
というのが、当面の考察の結論でしょうか？

書込番号：6036770

[kuma_san_A1]

「当面の考察の結論」？

お二人とも「マゼンタ側にも…」という書き込みがあるので一定方向に影響を与える誤差について書いただけです。

書込番号：6036882

[ねぼけ早起き鳥]

kuma_san_A1さん、ありがとうございました。

[6029807] で私が、
【係数の符号は無視していませんが、値（のまるめ方？）は無視して眺めていた、ということです。】
とkuma_san_A1さんに返信いたしましたから、
そのあとで、
kuma_san_A1さんが[6036454]で考察をコメントされたので、確認させていただいたまでです。

【お二人とも「マゼンタ側にも…」という書き込みがあるので一定方向に影響を与える誤差について書いただけです。】
もちろん、検証なし考察のみが前提で、
ここでの【一定方向に影響を与える誤差】とは、
私には、“エンコード時の係数のまるめ方に関わるバグではないか？”に受け取れるのですが、違いますでしょうか？

書込番号：6037443

[kuma_san_A1]

係数のまるめ方？
例として書いたのは演算結果のまるめ方による誤差ですけど。
あと「バグ」っていう単語はこちら側(ユーザー)が使う言葉ではないと思っている人間なのでご配慮下さい。

書込番号：6037523

[ねぼけ早起き鳥]

kuma_san_A1さん
教えていただきありがとうございました。
“エンコード時の【演算結果のまるめ方】に関わるバグではないか？”
に訂正いたします。

「誤差」はそもそも不確かな真値を前提にしていますので、どこまで行っても誤差は誤差です。
「誤差」そのものに罪はない（喜ぶ人もガッカリする人も居ない）。

「バグ」は、「ミス・欠陥」あるいは「瑕疵」の概念ですから、その先の罪（くだんの場合グリーンっぽくなること）の前提になっていますよね。

もちろん、【こちら側(ユーザー)が使う言葉ではない】というお考えは否定いたしません。
他に適当な言葉が見つかりませんでしたので、使っていることにご配慮ください。

書込番号：6037655

[LUCARIO]

ソフトウェアエンジニアリングの世界では

バグとは即ち、仕様と動作の差異である。

と定義するのが通例です。
ユーザが口にしてはいけない言葉というわけでは決して無いのですが
（バグのないコーディングを望む、とか、このソフトはバグが多くてダメだ、とか普通に使いますね）、
ある現象を語る際に、「これはバグだ」と断定するには、
仕様書との照合が不可欠なんです。

たいていの場合、ユーザは仕様書見れませんよね。

市川ソフトの場合はフランクに仕様の中身を公開してくれたりもするので
こちらも一歩踏み込んで

「それならこれはバグですね」

と断定できる場合も多々あるのですが、一般論としてユーザが決める内容でないのは間違いないと思います。

これって、結構、ソフトメーカーにクレーム出すときの裏ポイントだったりもするんです。
ここを取り違えて臨むと、

「これは明らかにバグでしょう！」
「いえ弊社ではこれは仕様と捉えてますのでご理解云々」

などとゆー、ふもーーな問答に陥ることもありますので。

何かのご参考になれば幸いです。全然関係ないですが先程F31fd買っちゃいました。
＃ああ、赤口の買い物だ、、、まお昼近くだったしいいか(^^;

書込番号：6037772

[ねぼけ早起き鳥]

LUCARIOさん
さすが回復がお早いですね。
ご説明の意図は理解出来ました。否定はいたしません。

【バグとは即ち、仕様と動作の差異である。】
お話の流れからすると、
「バグ」を「誤差」と置き換えは出来ない、
ってことを、私は言いたかっただけです。
続いて、
【ある現象を語る際に、「これはバグだ」と断定するには、
仕様書との照合が不可欠なんです。】
お話の流れからして、
「これはバグだ」を「これは誤差だ」と置き換えは出来ない、
ってことも、私は言いたかっただけです。

【たいていの場合、ユーザは仕様書見れませんよね。】
これは、ハードエンジニアリングの世界でも同じでしょう。

【「これは明らかにバグでしょう！」】
【「いえ弊社ではこれは仕様と捉えてますのでご理解云々」】
【などとゆー、ふもーーな問答に陥ることもありますので。】
[6020896] で、私はそれを１．の場合として述べたつもりです。

赤口とは「口を飾らない正直に言うこと」の意で、必ずしも悪いことでないが率直に過ぎてぶちこわしになる恐れがあるから…云々↓。。なにはともあれ、F31fdご購入おめでとうございます。
http://www2s.biglobe.ne.jp/~hi-fumi/zatugaku7.htm

書込番号：6038025

[LUCARIO]

うぎゃあ。赤口にそんな意味があったとは(^^;
今日はもうオトナシクしてます。ごきげんよう。ごほごほ。

＃いやぁ、某パナ機スレで本音ぶっちゃけトークしなくてよかったっす。ホントに(^^;

書込番号：6038050

[ねぼけ早起き鳥]

LUCARIOさん
うひょっ、私のことに当てはめたつもりでしたが。。。
今夜は私も、口は芋エキス専用といたします。m(_ _)m

書込番号：6038104

[京都のおっさん]

[6036454] kuma_san_A1さん わざわざありがとうございます。
アユモンさん のリンクもざっと見てみました(参考になります)。ガンマは画像生成時に考慮する問題でしたかね。
kuma_san_A1さん の考察を読んで、なるほどと言うかさすがと言うか、自分には思いつかない方法です。
でも、デコード → エンコード → デコードという流れはわかりません。どこの過程で行われる処理を意味しているのでしょう？


>でも当初から「YCbCrだから」って言っていたのは覚えていただけてますよね？

#1340 の
>jpegのフルカラーってそもそもRGB値を記録しているわけじゃないし。

のあたりの記述でしょうか。正直良く覚えていません。
tiffの提言を無視したことは気にはなっていましたが、こういうのってスキルそのものなんで。実際に試せるようになったのは今年になってからだと思います。


今回の騒動に関してその後も少しは冷静になって考えたんですけど。
スレ途中のあたりで感情的な批判を自分は少しだけしました。何故批判をしたくなるのか自問自答しましたが、よくわかりません。単に不正(色が違うこと)に対する怒りだったのかもしれませんし、このソフトを使い続けたいという気持ちからだったのかもしれませんし。このソフトに限りませんが、製品に対する愛情って自分は無いのですね。でも茶番で「いいよいいよ」なんて使い続けるつもりもありませんので。
批判ってユーザーのエネルギーそのもの。自分の場合今回の騒動に関して言い足りないことはたくさんあります。それはメーカーにはプラスになることだと思うのですけど…そこの部分はよくわかりません。
今はね、冷静になったと言えば聞こえはいいですけど、めんどくさくなってきて冷めてきてます。

書込番号：6040576

[kuma_san_A1]

[6036454] の最後の一文を書き間違えてました！

＞エンコード時にこの一定方向への誤差は出せないと思うのですけど(それともあり得るのかな)？

(jpeg)デコード時にこの一定方向への誤差は出せないと思うのですけど(それともあり得るのかな)？

と訂正してお読みください。

・(jpeg)エンコード->jpeg保存時->だからRGB to YCbCr

・(jpeg)デコード->jpeg読み込み時->だからYCbCr to RGB

です。
お互いちゃんと読むたちなので、それぞれの書き込みのミスが迷路に誘います(反省)。

書込番号：6041051

[kuma_san_A1]

メーカーにもプラスになることだと思いますよ。
ただわたしがサポートを利用する際の動機は「自分が幸せになりたい」のと(ついでに)
「利用している他のユーザーに少しは役に立つかも」というのがメインです。

だから、そういうお気持ちも京都のおっさんさんにあったのではないでしょうか。

「幸せになりたい」ていうのは
・疑問が解消してすっきり
・報告が確認されて対応リストに載った
など色々とあります。

書込番号：6041106

[ねぼけ早起き鳥]

さすが“先勝”の午前でしたね、よい雰囲気になって来ました。

そこで、[6037655]での、
“エンコード時の【演算結果のまるめ方】に関わるバグではないか？”
というのは、それでよかったのでしょうか？
“バグ”は“誤差の取り扱いの一例“でも構いませんが。。。

書込番号：6041352

[kuma_san_A1]

＞“エンコード時の【演算結果のまるめ方】に関わるバグではないか？”
というのは、それでよかったのでしょうか？
“バグ”は“誤差の取り扱いの一例“でも構いませんが。。。


現象が起きる可能性について考察しただけです。
それ以上でも以下でもありません。
わたしが結論することではありません。
わたしはユーザーですよ？

書込番号：6041456

[ねぼけ早起き鳥]

もちろんですよ、kuma_san_A1さん
【現象が起きる可能性について考察した】結論を確認させていただいているだけです。
考察した「結論」という表現がお嫌でしたら、考察した「まとめ」でもよいですよ。
それが正しいかどうか、的を射ているかどうかをお訊きしているのではありません。

書込番号：6041568

[kuma_san_A1]

結論はないです(なぜ考察のまとめとか結論をわたしに求められるのかが理解できません)。
現象が起きうる一つの可能性について示しただけですから。
この考察の動機も「ちゃんと切り分け予測を付けて疑わしい部分がどこで起きる可能性があるか…にたどり着く助けになれば」というものです。
今となっては結果論ですが…
当初(発端となった開発テスト版の中のスレッド)から「TIFFではどうか」「JPEGのみなら(圧縮もあるだろうしそもそも記録がRGBじゃなく)YCbCr」と書いてましたし、その予想を起点にすればTIFFとJPEGの比較で現象の解析が楽に出来たのではないかということです。

ようするにまとめというか結論は検証なさっている方に譲るということです。

書込番号：6041999

[ねぼけ早起き鳥]

なかなか、かみ合わないようですので、視点を変えてみます。
[6036454] kuma_san_A1さんが検証なしの考察の後半で、

【ちなみに、そういうミスを犯さないと

Y:126
Cb:135
Cr:136
となり、
R1:137
G1:118
B1:138
となり化けません。

エンコード時にこの一定方向への誤差は出せないと思うのですけど(それともあり得るのかな)？】

と、申されました。
その後、
[6041051] kuma_san_A1さんが、

【[6036454] の最後の一文を書き間違えてました！

＞エンコード時にこの一定方向への誤差は出せないと思うのですけど(それともあり得るのかな)？

(jpeg)デコード時にこの一定方向への誤差は出せないと思うのですけど(それともあり得るのかな)？

と訂正してお読みください。】

と、訂正されました。
じつは何度も読み返してみて、私は訂正の必要性を感じませんでした？？？
私がとんでもない勘違いをしているのでしょうか？
そこで、私がお訊きいたしました、
[6037655] の、
“エンコード時の【演算結果のまるめ方】に関わるバグではないか？”
は、訂正の必要はありませんか？と言うことなのです。

【バグではないか？】の表現が、まずかったようですので、
言い換えさせていただきますと、
“エンコード時の演算結果のまるめ方に関わる誤差の取り扱い方が、現象が起きうる一つの可能性ではないか？“
ではどうでしょうか？

【ようするにまとめというか結論は検証なさっている方に譲るということです。】
それはおっしゃる通り、よく分かりました。

書込番号：6042210

[京都のおっさん]

メーカーが対応してくれてるので推論遊びですが。

>[6036454] の最後の一文を書き間違えてました！

いやそこではなく。
たぶん [6020199] でマウスポイントの RGB値のあたりから噛み合って無いと思うので。

Windows版にはバグがあると書きましたが、どうもよくわからず。こんな感じかもしれません。ちょっとだけ検証しましたが、「色空間」の話題が入ってくるので話は複雑に(自分にとっては難しく)なります。

・RAW現像の場合は出力カラースペースの設定により変化せず sRGB色空間での現像結果の(あるいは現像結果を sRGB にマップした) RGB値の表示。

・「JPEG/TIFFを現像対象とする」を外したとき(ビューアとして使ったとき)は、YCbCr → RGB の変換結果(デコード結果)の RGB値をマウスポイントは表示。画面表示色には画像埋め込みプロファイルの色空間を無視して sRGB になる(AdobeRGB のビューアとして機能しない)。

・RAW Bridge機能を使ったときは、RAW Bridge による「現像」は「RGB変換前」か「RGB変換後」かは知らぬが、おそらく前者であれば情報量が多くなる可能性がある？ そしてマウスポイントの RGB値は SILKYPIX カラースペースの「入力」「出力」の組み合わせで変化する。

RAW Bridge の場合は処理内容(処理順序)が不明なので複雑です。
色空間の設定にかかわらず YCbCr → RGB はやはり「(誤差を無視すれば)一意に定まる」ものでは？ YCbCr の色空間が RGB色空間より単純に広いのであれば、変換時(デコード時)にクリップされる色が出てくる。それらを全て知覚的にマッピングするのであれば一意には定まらず、RGB値全体をマップしなおす必要があるのでしょうが。
そしてYCbCr → RGB の計算式がある以上、YCbCr というのは「デバイスディペンドな値(絶対的な色を指し示しているのではない)」のでしょう。
これと「RAW Bridge のデフォルト現像は原則的には変化してはならない」を考え合わせれば、「入力」「出力」の組み合わせが同じであれば、マウスポイントの RGB値は「同一(jpegデコードに誤差があれば、誤差をそのまま表示)」と考えられ、検証結果もそれに準ずるようです。
「入力」「出力」の色空間が違えば、その組み合わせに応じた色変換(RGB変換)が行われます。

ああ、また長くなっちゃった。
結局あそこの表示は「RAW現像時」のみバグがあるみたいです。
「SILKYPIX はビューアとしては機能が足りない(埋め込みプロファイルを無視して sRGB として扱う)」は検証が足りませんが、(137, 118, 138) のファイル(sRGB と AdobeRGB のプロファイルを付けた二つのファイル)で検証した限りではそうでした。

で、[6036454] kuma_san_A1さん の書き方を見ると
「デコード → エンコード → デコード」
という動作を SILKYPIX がやっていると読めるのです。
「JPEG/TIFFを現像対象とする」を外したときもそういう動作なのですか？ ということ(おそらく ねぼけ早起き鳥さん の疑問もここ)。

書込番号：6044936

[ねぼけ早起き鳥]

こんばんは。
kuma_san_A1さん、ご覧になっておられますでしょうか？
京都のおっさんさんや私の質問（疑問）にはお応えいただけないご様子？なので、
いったんこの辺で、お開きにいたしたいと思いますが、如何でしょうか？
もちろんご意見、コメントのある方は引き続き歓迎です(^^)。

書込番号：6050654

[kuma_san_A1]

検証はしないので材料だけ提供です。

http://homepage.mac.com/kuma_san/color_shift/

Photoshopで見比べてみては如何でしょうか？

ちなみにPhotoshopでRGBモードからLABモードに切り替えると8bitの場合だとディザリングが入りました。
16bitモードで行うとディザリングは入っていない(というか表示画面では差が出ない)です。
演算による変換なので「誤差」はつきものみたいです。
あと、提供した材料だとGだけが相対的に高いとは言い切れない部分もありますね。

書込番号：6050751

[ねぼけ早起き鳥]

kuma_san_A1さん
さっそくご対応いただきありがとうございました。
私の場合は、道具を揃えた段階で試してみます。

念のため確認ですが、質問は受け付けてもらえるのでしょうか？

書込番号：6050839

[kuma_san_A1]

疑問点？がお二人のを読んで理解できていないだけです。
一応読んでいますので、私にわかることであればコメントできるかもしれません。

書込番号：6052329

[ねぼけ早起き鳥]

kuma_san_A1さん
ありがとうございました。
コメントがないということは、質問が【理解できていない】と理解してよろしいのですね？
で、理解できていたとしても、コメントがいただけると限らない。。。？？？

私の疑問点は以下の通り、
書き込みいただいた「考察」や「推論」を、読み手側で整理・要約して（これを私は考察や推論の「結論」次いで「まとめ」と表現いたしましたが）、再確認させていただくことは、（このような掲示板であっても）じゅうぶんフツーの行為と思っていたのですが。。。
絡んではいませんよ＾＾；
どこがご理解できないのか、知りたいだけです。

書込番号：6052596

[京都のおっさん]

いや、「エンコードによって一方向にずれるモデル」を提案したと理解します。Photoshop がエンコードでミスってるとか、SILKYPIX が JPEG現像時のエンコード過程でミスってるとかの具体的な話でなく。

kuma_san_A1さん 四通り試していてくださったのですね。HP も作られていて恐れ入ります。
自分のところでは Lab モードは試せないのですが。ちょっとずつ検証させていただきます。検証と言うか単なる数値の採取になりそうな。
やはりこの辺は CS2 が無いと駄目ですね。

書込番号：6052968

[kuma_san_A1]

＞いや、「エンコードによって一方向にずれるモデル」を提案したと理解します。Photoshop がエンコードでミスってるとか、SILKYPIX が JPEG現像時のエンコード過程でミスってるとかの具体的な話でなく。

その通り！

なぜならYCbCrの値を直接読める環境はユーザーにないので本当のところはわからないのです。

書込番号：6053025

[ねぼけ早起き鳥]

おはようございます。
京都のおっさんさんはご理解できましたようで、よかったですね。
私だけ取り残されて（＞＜）しまいました。。。

そこで、ご理解された（と思われます）京都のおっさんさんにお訊きいたします。
[6052968]
【いや、「エンコードによって一方向にずれるモデル」を提案したと理解します。Photoshop がエンコードでミスってるとか、SILKYPIX が JPEG現像時のエンコード過程でミスってるとかの具体的な話でなく。】

上記と [6042210] で、私のkuma_san_A1さんへの質問である、
“エンコード時の演算結果のまるめ方に関わる誤差の取り扱い方が、現象が起きうる一つの可能性ではないか？“
とは、どこが、どうちがうのでしょうか？

kuma_san_A1さんからのコメントはいただけるかどうか不安なので、失礼ながら、お訊きしていますm(_ _)m

書込番号：6053350

[京都のおっさん]

[6050751] kuma_san_A1さん
勝手に補足させていただくと、あれは gretagmacbeth 社の ColorChecker というカラーチャートの色です。
左上から右へ向かって順に 1, 2, …, 6、折り返して2行1列目から右へ 7, 8, …, 12、この順で「色」を 1 〜 24 まで番号付けします。全ての色の RGB値は公表されています(@ sRGB color space)。18 のシアンは sRGB の色域外と聞いたことがありますが、よくわかりません。
kuma_san_A1さん の gmcc_00.png を PhotoshopElements3.0 でチェックしたところ、gretagmacbeth 社の公表値と一致しました。
png は知らないのですが、gmcc_00.png を gmcc_00.tif に変換したところヒストグラムは一致したので、png は(Tiff と同様)信用してよいフォーマットということにします。
周囲の (118, 118, 118) の縁取りは、Windows環境における「18%グレー」だそうです(18% の輝度に対し逆ガンマ関数を通すと得られる)。

kuma_san_A1さん の WIN版はバーチャルマシーンでしょうか(どこかで聞いた気が)。
早速私の Windowsマシンでも四通りの SILKYPIX デフォルト現像を試してみました。
結果は驚くことに、X_2jpg (現像結果を jpeg に保存)の場合に kuma_san_A1さん 提供の画像とヒストグラムが一致しませんでした。
http://album.nikon-image.com/nk/NK_ImageAlbum.asp?id=11178954&key=711615&un=115360
ここからの三枚です。
バーチャルマシンの WIN版と、ピュアな Windows環境での SILKYPIX の jpegエンコードが違うということなのでしょうか？
YCC444、品質係数100 でやられてますか？ そこの違いかも。
その他は完全一致しました。

それはともかく、Mac版とWIN版を比べてみると、WIN版の方に「色相ズレ」を感じますね。緑っぽくなるやつを。あれだけ見ると、Mac版には緑っぽくなる感じは受けません。
プラットフォームが違うと演算アルゴリズムを変えるというのは理解できます(サポートからのメールでも感じた)。ですので「結果が違う」ことについては「ああそうなんだ」という思いです。

この問題はですね、多少屁理屈でサポートのメールを読んでみると「誤差はあるが、問題にしてるのはあなた(書いている私)だけ。クレームを付けるユーザーがいるので、今回は対策をします」と読めなくもないのです。
けどその後に「Windows版において通常より大きい誤差が・・・」とも書いてありまして、この問題については、やはりメーカーは全面的に非を認めているようなところは感じられます。
認識可能なすべての色に対して検証を行っているようなので、期待は持てます。

今回はいかにもホワイトバランスが変化したかのごとく、ヒストグラムの形はほぼそのままに Gチャンネルは右へ、RBチャンネルは左へとシフトするような現象だったので、問題を見つけられたのだと思います。
これが特定色で彩度が変化するとかの症状だと、おそらく自分は見つけられなかった(見つけてもおかしいとは感じなかった)と思います。
今回を教訓として、色々な誤差についてメーカーが再度見直すきっかけになることを期待します。

書込番号：6056982

[京都のおっさん]

で、ねぼけ早起き鳥さん。
kuma_san_A1さん は「エンコードでミスると、緑方向にずれるモデルが考案できるよ」とおっしゃっているのですが。

元のjpeg画像 → デコード1 → エンコード(ここでミス) → デコード2
とすると、デコード1 は「誤差の無い値」です(デコードではミスの無いモデルなので当たり前)。デコード2 は誤差のある値です。

元のjpeg画像を
Y:126
Cb:135
Cr:136
と設定して、[6036454] kuma_san_A1さん の式、そして「誤差の出る間違った考え方」を順次適用して、デコード2 まで計算してみてはいかがですか？

書込番号：6056999

[kuma_san_A1]

gretagmacbeth 社の ColorCheckerの公表値で作り、18%グレイ時のsRGB規定値である118の値でまわりを覆ったので当然です(だからgmccね)。

YCC422の品質係数97です。
あの…EXIFの規定というか普通のJPEGはYCC422です。
PhotoshopのJPEG保存もそうだと思ってたけど？

あと、カラーマネージメントで指定しているモニタプロファイルがsRGBのなんたらっていうWINのインストール直後の規定値ですが、これは関係ないでしょう。

書込番号：6057053

[京都のおっさん]

>YCC422の品質係数97です。

あとでそれでやってみます。同じでやれば合うと思います。
品質係数を97と100で変えたやつは微妙に違いました。

書込番号：6057057

[kuma_san_A1]

はい、バーチャルマシンです。
WIN版の動作のチェック(Mac版との違いを含む)のためだけにライセンスを購入している変人です。
いや、いつかWINマシンを購入するかもしれませんが…。

あと、[6056999] でのフォローありがとうございます。

書込番号：6057063

[ねぼけ早起き鳥]

うははは。。。かくもみごとにかみ合わないのは、私のねぼけのせい？
京都のおっさんさん、ありがとうございます。
お手数をおかけして申し訳ありませんでした。

念のため、もう一度確認させていただきます。
[6056999]
【「エンコードでミスると、緑方向にずれるモデルが考案できるよ」】
と、
[6042210] で、私のkuma_san_A1さんへの質問である、
“エンコード時の演算結果のまるめ方に関わる誤差の取り扱い方が、現象が起きうる一つの可能性ではないか？“
とは、おなじことなのですね？
そうでなければ、どこが、どうちがうのでしょうか？

[6042210] での私の質問（疑問）に、kuma_san_A1さんからお答えいただいていない、と私は思ってますので、たびたびの失礼を承知でお訊きしています。

なお、[6056999] 四行目以降は理解できたつもりです。

書込番号：6057274

[kuma_san_A1]

示した例を一緒に考えて計算もしてみれば「確認できました」っていう報告をわたしが見られるはずなのです。
そもそも「誤差は(緑方向に限らず)両方に出るのでは」…みたいな話をしていたので示した一例なのです。
「それをわたしに確認してどうするの？」というのが「わたしに理解できない」と書いている気持ちです。

書込番号：6057508

[ねぼけ早起き鳥]

kuma_san_A1さん、（私へのご返事ということで）ありがとうございました。

【「それをわたしに確認してどうするの？」というのが「わたしに理解できない」と書いている気持ちです。】
ええ、そのことはよく分かりました。
ですから私は失礼とご迷惑を承知で、京都のおっさんさんにお訊きしているのです。
ご不快な思いをお掛けいたしましたことをお詫びいたします。

書込番号：6058488

[京都のおっさん]

言葉にこだわっておられるのなら、「丸め誤差」の定義を自分は知らないので判断できません。

>なお、[6056999] 四行目以降は理解できたつもりです。

とのことですので、それで良いのではないのでしょうか。
推論遊びは何かの役に立つかもしれないし、立たないかもしれない。遊びですからそういうものと思ってます。

それより gmcc の画像はダウンロードされましたか？
あれはなかなかに貴重な資料だと思います。
たとえ頭の中にイメージがあったとしても、実際に作るのは大変なものです。

書込番号：6061046

[ねぼけ早起き鳥]

おはようございます。
今朝はさわやかに晴れましたので、梅の花やオオイヌノフグリや花韮の花を撮りに行って来たいと思います。
京都のおっさんさん、ありがとうございました。
ご迷惑とお手数をお掛けし、すみませんでした。

【言葉にこだわっておられるのなら、「丸め誤差」の定義を自分は知らないので判断できません。】
私も詳しいわけではありませんので、ご参考まで↓。
丸め誤差
http://www.shunzei.com/lecture/words/rounding_error.html
コンピュータは引き算が苦手？丸め誤差の発生
http://www.kentei.ne.jp/quali/column/knowhow/030415.html

【推論遊びは何かの役に立つかもしれないし、立たないかもしれない。遊びですからそういうものと思ってます。】
おっしゃるとおりですね。
この掲示板で仕事をされておられるのは、価格.comさんだけ？でしょうから、書き込みは所詮遊びの範疇でしょう。参考にされても生活とプライドをかけておられる方は少ないと思います。

【それより gmcc の画像はダウンロードされましたか？】
【あれはなかなかに貴重な資料だと思います。】
【たとえ頭の中にイメージがあったとしても、実際に作るのは大変なものです。】
[6050839]
「私の場合は、道具を揃えた段階で試してみます。」
労作であろうことは私なりに理解できました。
即ダウンロード、プリントアウトさせていただきました。
あらためまして、kuma_san_A1さんにお礼申し上げます。

オーナーのわがままとしてひとこと。
「標題」のスレを立てましたが、道具もソフトも揃わず、知識も備わっていませんので、考察であれ、推論であれ、遊びであれ、みなさんの追体験（もちろん追い着いていませんが。。。）に終始いたしましたことをお詫びいたします。
このような時にいつも感ずることなのですが、道具と情報を持っている方は、当然ですが圧倒的にお強いです。
でも、お子さんや小さい子供たちから、「これなあに？」、「あれはどうして？」などと訊かれて、
「それを訊いてどうするの？」とは、返されないのではないでしょうか？

では、撮影に行ってまいります。。♪

書込番号：6061341

[kuma_san_A1]

聞かれたら答えますよ(可能な範囲で)。
でも、今回のはある問題について考えているところに「こういう考え方をするとこういう結果が出る例があるよ」と示しているわけです。
子供の好奇心や知識欲に関しては「一緒に考えながら」がスタンスです。
何でも知っているわけではないので。

＞“エンコード時の演算結果のまるめ方に関わる誤差の取り扱い方が、現象が起きうる一つの可能性ではないか？“

まるめ方の扱いを例のようにすると現象が起きえます…ということです。
当該アプリケーションがどのように扱っているのかわからないので、その質問の仕方だと「NO」と答えればご期待にそえるのでしょうか？

書込番号：6061766

[ねぼけ早起き鳥]

こんばんは。
kuma_san_A1さん
お呼びだてしたようで恐縮です。
でも、うれしいですね、ありがとうございました。
ご回答いただき感謝です。
お答えの主旨は理解できたつもりです。

【聞かれたら答えますよ(可能な範囲で)。】
異論はございません。

【「…」と示しているわけです。】
おっしゃるとおり、よく分かりました。

【何でも知っているわけではないので。】
相手のレベルや程度を的確に判断して自在に返答できるのは、【何でも知っている】以上にすごいことです。。。
kuma_san_A1さんがお書きになられたことを、追認の意味でお訊きしたつもりでしたので、じゅうぶんにお答えできると、私が勝手に思い込んでいたようです。

【まるめ方の扱いを例のようにすると現象が起きえます…ということです。】
よく分かりました。

【当該アプリケーションがどのように扱っているのかわからないので、その質問の仕方だと「NO」…】
kuma_san_A1さんがお書きになられたことを前提に質問したつもりでしたので、そのようにおっしゃっていただけたら、「ＹＥＳ」でも「ＮＯ」でも、私の勝手な思惑にはそれなりに沿うものです。

お礼に、
まだ整理の途中ですが、今日撮って来たばかりの草花のいくつかを、アルバムに追加してみました。
おつまみにはならないかも知れませんが↓。
http://collection.photosquare.jp/open.php?ad=76493&page=0

書込番号：6063188

[kuma_san_A1]

とりあえずEP版ですが3.0.6.xでJPEG展開時の品質を改善したようです。
後(いつだ？)で同じような変換してみます。

おつまみにならないかもしれませんが記録をお願いされたものを…

http://homepage.mac.com/kuma_san/20070227_geinosalon/

書込番号：6063444

[ねぼけ早起き鳥]

EP版3.0.6.x
情報ありがとうございました。
それにしてもはやい？おそい？

なんでもおつまみのねぼけです、ありがとうございました。

書込番号：6063613

[京都のおっさん]

対応早いですね。根拠はありませんけど一ヶ月くらいはかかるだろうと思っていたので。
試してみたい、けど自分も変態のようで。感慨は無いと言っておきながら今の版を取っておくために追加ライセンスを購入しようかなと。3.0.5 の起動と 3.0.6 の起動を選択なんてできませんからね。
でも予備の PC は全部 Windows98 で (＞＜)
誰か変態じゃない人試してみて。

>YCC422の品質係数97です。

そういうことで、これの決着を。自分の SILKYPIX でも kuma_san_A1さん の画像と完全一致しました。

>あと、提供した材料だとGだけが相対的に高いとは言い切れない部分もありますね。

これはそうですね。
あの画像全体でヒストグラムを取ると、jpeg to jpeg では緑っぽくなるようですが。

gmcc_00.png と gmcc_jpg.jpg で RGB 各チャンネルのレベルの差を調べました。2 以上ずれていたのは 17 の magenta の Bチャンネル(149 → 151)だけでした。2 以上ずれると、単なる誤差ではなくマッピングしているのかなとも考えてしまいますが。
なお自分のところの PhotoshopElements で jpegエンコードすると結果は微妙に違います。

もう一つ気付いたことは、SILKYPIX で X to jpeg で、ターゲットを jpeg にして現像すると、色境界で滲みが発生します(Tiff だと出ない)。こだわるのならば SILKYPIX では jpeg出力せず、Photoshop で jpegエンコードするのが良いのかなと思いました。

あと ねぼけ早起き鳥さん、お詫びする必要は無いと思いますよ。少なくとも自分に対しては。恐縮しちゃいます。

書込番号：6064230

[ねぼけ早起き鳥]

おはようございます。
京都のおっさんさん、ありがとうございます。
ねぼけのわがままとご理解願います。

【対応早いですね。】
京都のおっさんさんのおかげですよ、きっと。
[6061341] は一部訂正いたします。
ここの掲示板を覗きながら参考にしていただくと、仕事が早くなることもあるようですね。。。
で、あって欲しいですね（＾＾）

書込番号：6064707

[京都のおっさん]

kuma_san_A1さん 読んでいらっしゃいますでしょうか？
EP版3.0.6.1 の評価用に kuma_san_A1さん製作の gmcc_00.png と gmcc_jpg.jpg を使用したいのですが。アルバムにアップして一般の目に留まる可能性もあります。
許可・不許可にかかわらずお返事いただけると幸いです。

EP版3.0.6.1 は自分的には問題は改善されたと考えております。

書込番号：6092140

[kuma_san_A1]

どうぞです。
わかりやすい評価のために役立つなら良いのではないでしょうか。
3.0.6.Xで明らかに改善されていると思います。

後残っているのはJPEG/TIFF現像時のRGBのサンプル値とヒストグラムが出力色空間を切り替えても変わらないというのが目立ってますね。
上で書かれてますよね。
どう考えても仕様外の動作(RAWの様に扱うならちゃんとサンプル値もヒストグラムも変化しないといけない)ですよね。
今度報告しておこうかな？

書込番号：6092149

[京都のおっさん]

ああ、素早い返信ありがとうございます。

>JPEG/TIFF現像時のRGBのサンプル値とヒストグラムが出力色空間を切り替えても変わらない

バーチャルマシンでもそうなのですか。
例のカラマネスレで、途中自分が混乱してた時期があったのですが、これも原因の一つなのです。
あとは Tiff でプロファイルが付かないことかな。
自分はあんまり細かいバグは気にしないので、この二つは本当に気になっていないのですが。

ただしエンコードデコードに関しては突っ込んでしまいます。ユーザーが得る画像に直接関係するので。

も一つ関係無いけど、ニコンオンラインアルバムって Tiff を受け付けてくれなくなりました。以前は確かにできたはずなのに。png変換って時間かかるなあ。

書込番号：6092164

[kuma_san_A1]

TIFFでもプロファイル付いていたと思いますよ。
Developer Studioが埋め込みICCじゃなくEXIFタグ内を見ているみたいな部分もあります(二つが食い違った場合に変な動作する可能性あり)が、Photoshop CSで開く限り問題ないです。

このへん自分に関係ないと報告しないのですが迷路に入っちゃった例を見てしまったのでタイミングを見て報告しておこうと思います。

書込番号：6092173

[京都のおっさん]

Tiff にプロファイルが付かない、の根拠は薄いのですが、

http://www.rysys.co.jp/exifreader/jp/
このソフトで Tiff にのみ ICC Profile という項目が出ないこと(Pthotoshop でプロファイルを付けて Tiff保存すると出るが、SILKYPIX では出ない)。

Windowsビューアは、Photoshop でプロファイル付き AdobeRGB画像を作り Windowsビューアで表示させた場合、sRGB のモニタプロファイルを適用して出力する動作をする(としか思えない動作をする)のに対し、SILKYPIX でプロファイルを付けた(つもりの) AdobeRGB画像を Windowsビューアで表示させると、彩度が低いままで、いかにもモニタプロファイルを適用していない色になる。

この二点だけです。

書込番号：6092183

[京都のおっさん]

でもその画像を、SILKYPIX や Photoshop で表示させるときちんとモニタプロファイルを適用して、画像の色空間を AdobeRGB と解釈して表示されますね。
う〜ん。

書込番号：6092187

[ねぼけ早起き鳥]

京都のおっさんさん、kuma_san_A1さん、こんにちは。
ＥＰ版評価の途中かもしれませんが、
もし、よろしければ、
SILKYPIXとPthotoshopの使い方（使い分け）の要領みたいなものがあるようなので、
分かりやすく、整理して教えていただけるとありがたいですm(_ _)m

書込番号：6093036

[京都のおっさん]

私の場合 Photoshop は今回のような検証用途です。レタッチソフトによるレタッチは難しいので自分は出来ません。

一例を挙げます。

RAW撮り出来るカメラで次の二つの画像を考えます。
・適正露出で撮影し、そのままソフトで現像。
・一段アンダー露出で撮影し、露出補正機能のあるソフト(大抵あります)でプラス一段の増感現像。
この二つの画像を等しくすることは理論的には可能なはずです(ノイズ、暗部諧調を除く)。

では jpeg撮りしかできないカメラで撮影し、レタッチで二枚の画像を等しくする方法は？ と聞かれても、自分には皆目見当が付きません。
RAW Bridge ならそれが出来る可能性があります。少なくともそういう動作を目指していると思います。
現実にはメーカー製デジカメの画像は、暗部と明部で WB が違ったりするので、そううまくはいきませんが。例えば明部でマゼンタ気味で、暗部で緑っぽいというのはありがちなパターンのように感じています。

書込番号：6095876

[ねぼけ早起き鳥]

京都のおっさんさん
早速のご回答ありがとうございました。
Photoshop は検証用途とのこと、理解いたしました。

ところで、
ＲＡＷ未経験なもので的外れな質問かも知れませんが、
お話の中で、
【この二つの画像を等しくすることは理論的には可能なはずです】
とありますが、
もし現実にも可能だとしたら、逆にも戻せることを前提とするならば、
ＡＥＢ（露出補正を変えて撮ること）は不要になるということなのでしょうか？
その辺のところが、いまいちよく分かりませんので、
教えていただけたらと思います。

書込番号：6098160

[京都のおっさん]

不要になると言うか、同じようなことは出来ます。白飛びさせてしまった部分は現像時に露出補正マイナスにしても戻ってきませんが。

書込番号：6098460

[ねぼけ早起き鳥]

京都のおっさんさん
ありがとうございました。
了解です。
不要かどうかは、使う人の判断でもありますよね。

で、[6093036] ですが、
kuma_san_A1さんは如何でしょうか？

書込番号：6098503

[kuma_san_A1]

質問の前提がわかりませんので答えようがないです。

まずはご自分で体験することです。
PC環境も含めてご決断ください。

RAWについては

http://www.isl.co.jp/SILKYPIX/japanese/tour/

ここにあるコンテンツを一通り見てみることをお勧めします。

Photoshopに関してはこれは画像編集ソフトとしてはあらゆる手段が用意されており私自身使いこなせていません。

書込番号：6100031

[ねぼけ早起き鳥]

おはようございます。
kuma_san_A1さん、ありがとうございました。

【質問の前提がわかりませんので答えようがないです。】
無理にお答えいただいたようで恐縮です。
でも、お応えいただいて感謝です。
いろんな意味で、
脳味噌を刺激されて、ぼけ防止に効果がありそうでうれしいです。
このスレにご参加いただいたことでもありますので、ねぼけのわがままをお許しください。

コンテンツは一通り、見れる範囲で見させていただきました。

【まずはご自分で体験することです。
PC環境も含めてご決断ください。】
【Photoshopに関してはこれは画像編集ソフトとしてはあらゆる手段が用意されており私自身使いこなせていません。】
おっしゃるとおり、万事に共通することですが、万事に実践はムツカシイですね。

書込番号：6100692

[kuma_san_A1]

JPEG保存時の色のにじみの件ですが…問い合わせてみました。
Photoshopは品質係数を変化させるのに連動してYCC420->422->444と自動的に切り替えていることがわかったそうです(ずるいというかスマートというか…)。
Developer Studioでの生成は今後は画質重視の場合はYCC444指定にします。
Photoshopの高画質保存の画像が再生できなかった環境は今のところ見たことないのでYCC444で大丈夫だろうという判断ということで。
一応、話題の続きということでご容赦下さい。

書込番号：6124683

[LUCARIO]

し、知らなかった…。そうなんですか（驚）

JPEGデータフォーマットの方言て、私は突っ込んだ所までは
良く知らないのですが、互換性とか大丈夫なんでしょうかね。

> Photoshopの高画質保存の画像が再生できなかった環境は今のところ見たことないのでYCC444で大丈夫だろう

確かに…。言われてみればその通りなのですが…。

SILKYPIXの現像結果保存設定を見ると、

◎Exif JPEG (YCC422)
○Exif JPEG (YCC420)
○JPEG (YCC444)

と、最後だけ表記が別扱いになってるのも妙に気になります。

（多分その下にある「□Exif-IFDを含める」にチェックを
入れておけば大丈夫なんでしょうけど…。）

あとは画質的な優劣関係もかなり気になる所ですね。
例えば、YCC422の品質係数95と、YCC444の品質係数85を
比べるとどうなんだろう…とか。

時間が取れたら私も色々試してみます。貴重な情報ありがとうございました。

書込番号：6124736

[LUCARIO]

うーん。カラーチェッカの画像を使って少し試してみたんですが
（品質係数50, 80, 90, 95, 100でそれぞれYCC３種のJPEG合計15枚作ってみた）、
同じ品質同士で比べると、出来た画像の違いがサッパリわかんないですね(^^;

ファイルサイズだけは確実に違います。
ざっくりと見ると、YCC420に対して422, 444がそれぞれ1割増し、2.5割増し
という感じですね（単純平均なのでホントにざっくりですけど）。

＃サイズだけ見るとYCC420は結構オトクかも？(^^;

色差情報が間引かれることによって、画像としては
端的にどういうあたりに影響が出て来やすいものなんでしょうか。

上では色滲みについて言及されていたので、色境界バリバリの
カラーチャートで、ピュアディテールシャープの誇張設定で
試してみれば分かりやすいかな？と思ってやってみたのですが、
少なくとも私が見る限りでは境界部に目を凝らしても違いは
さっぱり分かりませんでした（節穴確率は多分に高いですが）。

↓一応ご参考として、品質係数95の３枚のみアップしてみました。
http://www.imagegateway.net/a?i=wksjYbRDqr

書込番号：6124940

[kuma_san_A1]

exif規格ではYCC422ということ。
だからそれを外してるけどexifTAGなどを埋め込んだ形式にしているということでは？＞exif-FIDを含める

あ、仕事の時間なので深夜にでも。

書込番号：6125489

[kuma_san_A1]

FIDじゃなくてIFDの間違いね(すみません)。

オンラインマニュアル

http://www.isl.co.jp/SILKYPIX/japanese/product/ds2/Manual/man0011.html

に記述があります。

輝度情報に対して色情報の解像度が落ちると理解すればよいでしょう。

[6050751] に上げたリンク

http://homepage.mac.com/kuma_san/color_shift/

でのPhotoshopCSでのJPEGとDeveloper StudioでのJPEG(このときはYCC422)を見るとライトブルーの周りが特に滲んで見えますよね？

YCC444にすると問題ありません(gmcc_00.pngからTIFF変換してやってみるとわかります)。

実際のカメラの画像でも高彩度の色の境界で差がわかります。

書込番号：6125598

[LUCARIO]

なるほど！

高彩度の色同士が隣接している所がミソだったのですね。
（カラーチェッカは彩度極小のグレーの枠がありますから）

書込番号：6125647

[LUCARIO]

テスト画像を追加しました。

http://www.imagegateway.net/a?i=wksjYbRDqr

まぁ、確かに、色の境目で違いは出るんですが、
このテスト画像では、ほんのわずかな違いに留まるようです。

一応、赤い服と空の境界の部分で縁取りが薄くなる効果は
あるようですが、一方で袖の所や、画像左下のピンクの花の
エッジ部ではむしろ不自然な縁取りが見えたりして…。

YCC444は、ファイルサイズの増大分ほどの効果はないなぁ、
というのが正直な感想ですね。

＃まぁでも、知っておけば今後何かの時に役に立ちそうですが。

書込番号：6126937

[京都のおっさん]

>ライトブルーの周りが特に滲んで見えますよね？

一番滲んでいる境界では 2pixel といった感じですね。jpeg なので境界がはっきりとはしてないのですが。

Photoshop の仕様はへー度が高いですが、モニタプロファイルの適用もそうでしたし、表に明記してないことは陰で何やってるかわかったものではない、といった部分がありますね、このソフトは。

SILKYPIX は何となく良さそうという理由で YCC444 を使用してきました。でも jpegエンコードは下手だと思います。自分の言うことなのであてにならないですが。
品質係数のデフォルトが 80 だった時代には樹木の葉っぱなどの解像感が目に見えて劣化してましたので、それ以来ちょっと注目してたんですけどね。

でも YCC444 とか、あとモニタプロファイルもそうですけど、やってることを隠さない姿勢は好きです。あとで意味がわかるようになりますから。
ビューアとして表示した場合に入力画像の色空間を表示することは必要と思いますけどね。

書込番号：6126970

[kuma_san_A1]

いや、縮小リサンプルして最初から等倍で鑑賞してもらうつもりの時には違いは大きいのです。
大きなサイズをユーザー側で縮小表示で鑑賞してもらう時には縮小アルゴリズムの違いによるエイリアスノイズ(偽解像やモアレなど)などの影響大きいので。

書込番号：6126996

[京都のおっさん]

あ、間に割り込んだみたいでしたね。

書込番号：6127007

[LUCARIO]

＞kuma_san_A1さん
なるほど、縮小現像した場合ですか。
横幅800にしたもの(USM100の半径0.6)を追加しました。
確かに、赤い服のエッジで多少違いを感じやすくなってますね。

＞京都のおっさんさん
今晩は。緑変色の件ではお疲れ様でした。
対応版の恩恵、私も早速享受させて頂いてます。
（3.0.6.3を今使ってるんですが。何やらバグがあったみたいで。
　このテストが終わったら3.0.6.4Aに更新しないといけませんね。）

＞ねぼけ早起き鳥さん
スレッドお借りしてますが、どうですか？
SILKYPIXって、こうやって「ユーザが育てている」感覚が
結構あるんですよ。だからコアなファンが付くんですね。

スレッド本題のJPEGデータからの現像についても、
3.0から追加された新機能ですが着実にレベルが上がっていますよ。
そして今回のように「微妙だけどやっぱり不具合」みたいな
現象が見つかれば、きちんと対応してさらにレベルアップ
されますし…、お勧めです。是非お一つどうぞ（笑）

書込番号：6127196

[ねぼけ早起き鳥]

おはようございます。
みなさん、貴重な関連情報ありがとうございます。

LUCARIOさん、みなさん、
ぼけ防止に効果テキメンですので歓迎です。。（＾＾）

私は間違いなくユーザーであり、
近い将来、SILKYPIXのユーザーにもなっていることでしょう。
みなさんのお陰です、感謝申し上げます。

さて、
「品質係数」とか、「縮小リサンプル」とか、「縮小アルゴリズム」とか、「エイリアスノイズ」とか。。ふんだんに目新しい言葉を使われるみなさんが、
どうして「バグ」の使い手に拘るのかが理解できずにおります。

ええっ？拘っているのはお前だけだろうって？
その通りですね。。絡んでませんよ＾＾；

書込番号：6128123

[LUCARIO]

多分、「縁起が悪いから」だと思います（笑）

書込番号：6128141

[ねぼけ早起き鳥]

あはははっ、「相性が悪いから」でなくてよかった。。（苦笑い）

書込番号：6128250

[kuma_san_A1]

＞なるほど、縮小現像した場合ですか。
横幅800にしたもの(USM100の半径0.6)を追加しました。
確かに、赤い服のエッジで多少違いを感じやすくなってますね。


問い合わせるきっかけになった画像を見てもらうのがよいでしょうね。

http://homepage.mac.com/kuma_san/20070311_emmys_slct/

ここの「070311-097.jpg」などのブルーバックと肌の境界で目立っていたのです。
すでにYCC444の画像に入れ替えてあるのですが、現象が目立つ画像に関してYCC422へのリンクも作成してあります。

で、少し冷静に考えてみるとYCC422は人間の目の特性に合わせた間引きなので、風景などでの輝度情報の高周波成分を優先しつつ容量を抑えるなら有効なはずですね。
・高周波成分を優先するなら品質係数を高めてYCC422
・高彩度の色の境界があるなら品質係数を抑えてYCC444
とか選ぶと良さそうです。

ねぼけ早起き鳥さん、話の流れの中でのことなのでご容赦下さい。

書込番号：6136514

[LUCARIO]

> ここの「070311-097.jpg」などのブルーバックと肌の境界で目立っていたのです。

うわっ、これは如実に分かりますね。

他にも113, 118, 120など、ブルーバックと肌色が接している
部分はYCC422では全滅状態ですね。
YCC444の効果がとても良く分かりました。これは覚えておいて
損はないなぁ…。以後、私も活用させて頂きますm(_O_)m

書込番号：6136654

[ねぼけ早起き鳥]

おはようございます。
kuma_san_A1さん、貴重な画像をありがとうございます。
【・高周波成分を優先するなら品質係数を高めてYCC422】
【・高彩度の色の境界があるなら品質係数を抑えてYCC444】
【とか選ぶと良さそうです。】
きっちりと眼に入れたいところですが、とりあえず耳に入れておきます。

【話の流れの中でのことなので…】
こちらこそ失礼いたしました。
「行く川の流れは絶えずして、…」。。お気遣いなく、です（＾＾）

【うわっ、これは如実に分かりますね。】
LUCARIOさん、私の眼は節穴同然ってことがよく分かりました（＞＜）
「品質係数」要チェックですね。
アニメなんかでしたら、YCC422は辛そうですけど。。。

書込番号：6136722