[過去ﾛｸﾞ] オクレ君専用スレ Part2 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
841(1): 話題そらしたいよねｗ 01/29(水)08:12 ID:HdXN8kwj0(1/20) AAS
>>835
＞削除もへったくれもなくiCCPなど入らない
with its file headerとあるので入り得るよ
仮に画像データ本体のIDATチャンク以外を削除すると捉えるのなら、IDAT以外の必須チャンクも削除されてPNGとして成立しません
なので、オクレの理解は2重の意味で間違いです 同じ話8回目ね 大卒は都合の悪い話を無視して同じ話を繰り返すのかい？大卒なのに？
842(1): 01/29(水)08:17 ID:HdXN8kwj0(2/20) AAS
must be in 32bpp ARGB format. の主語からは逃げるだろなぁｗ
843(1): 01/29(水)08:58 ID:rkK6pj6r0(7/17) AAS
>>841-842
>入り得るよ
などというオクレの妄想など誰も聞いてはいない
「iCCPがicoファイルに取り込まれ icoがそれを解釈してICCに対応出来る」
と記載された根拠を出せよ
そもそもファイルヘッダーはiCCPでも何でもないんだが？
＞must be in 32bpp ARGB format. の主語
何だと思ってるの小学校中退知恵オクレは？
「the PNG image」
つまりこの文章は「32ビットARGB形式のPNGデータ」しか語ってないのに
省1
844(2): 01/29(水)09:03 ID:HdXN8kwj0(3/20) AAS
>>843
>根拠
何億回同じこと聞いても>>2としか帰ってこないよｗ
>この文章は「32ビットARGB形式のPNG
この文章は「32ビットARGB形式のPNG image はその全体をファイルヘッダとともに保持する」
と記載されている
ファイルヘッダの定義はICO仕様上、明確でないので一般的なヘッダつまりICCも含み得るとなります
845: 01/29(水)13:45 ID:rkK6pj6r0(8/17) AAS
>>844
その>>2にはオクレの主張する内容など何一つ無いんだwww
つまりオクレに根拠は無いwww
ウソ
＞PNG image must be stored in its entirety, with its file header
＞PNG画像はファイルヘッダーとともに全体が保存
事実
the PNG image must be stored in its entirety, with its file header and must be in 32bpp ARGB format.
PNG imageはファイルヘッダと共に全体が格納され、それは32ビットARGB形式でなくてなならない
＊全体が格納されるのはPNGファイルではなくPNGイメージで、しかも32ビットARGB形式でなくてはならないので補助チャンクは入らない
省1
846(1): 01/29(水)13:45 ID:rkK6pj6r0(9/17) AAS
>>844
＞ファイルヘッダの定義はICO仕様上、明確でない
明確じゃないものをコンピュータはどう読み込むんだよ？wwwwwwwwwwwwwww
ヘッダー ＝ ICONDIR
外部ﾘﾝｸ[html]:hiroshi0945.seesaa.net
アイコンファイルの一番先頭にあるICONDIR構造体です。
//ICONDIR構造体
#pragma pack( push )
#pragma pack( 2 )
typedef struct tagICONDIR{
省7
847: 01/29(水)15:53 ID:HdXN8kwj0(4/20) AAS
336
sage
01/29(水) 13:46:28.01
26
>>334
じゃ、色々とか誤魔化さずに具体的にどうぞ！
知ってるんでしょ？wwww
DxOの加工検知は周辺10pxの自己相関
PhotonstoPhotosは空間周波の偏り
848(1): 01/29(水)15:55 ID:HdXN8kwj0(5/20) AAS
>>846
＞明確じゃないものをコンピュータはどう読み込むんだよ？
知りません
＞アイコンファイルの一番先頭にあるICONDIR構造体です。
それが正しい根拠がないんだね 解説サイトであって仕様じゃない おしまい
849(1): 01/29(水)15:56 ID:HdXN8kwj0(6/20) AAS
ICODIRはアイコンのヘッダでPNGのヘッダじゃないよｗ
850: 01/29(水)16:06 ID:HdXN8kwj0(7/20) AAS
337
sage
01/29(水) 13:47:24.77
>>335
単にDxOでデモザイクした結果の比較でしょ！www
外部ﾘﾝｸ:www.dxomark.com
For our DxOMark camera sensor reviews, we measure the image quality performance only of camera sensors that are capable of capturing images in RAW format, and we do this before demosaicing or any JPG processing has taken place.
DxOMark カメラセンサーのレビューでは、 RAW形式で画像を撮影できるカメラセンサーのみの画質パフォーマンスを測定します。これは、デモザイクや JPG 処理が行われる前に行われます
例えばノイズの計測方法
外部ﾘﾝｸ:www.dxomark.com
省2
851: 01/29(水)16:13 ID:HdXN8kwj0(8/20) AAS
ちなみにこれが、DxOのColor sensitivityの算出方法
RAWデータの数値をRGBの3軸ベクトルとして扱い、ベクトルの分散がつくるノイズ共分散行列の固有ベクトルを元に
RGB3次元空間内の分散楕円体の容積を評価してる これがデカいと色を分離できないとみなしているわけだが全くケチのつけようもない合理的判断
画像ﾘﾝｸ[jpeg]:i.imgur.com
まぁ理解できないと思うけどｗ
852(1): 01/29(水)16:19 ID:rkK6pj6r0(10/17) AAS
>>848-849
＞知りません
じゃあ黙ってろ知恵オクレ
コンピューターデータは全て1・0のバイナリ、そのバイナリをどう読み込むかに厳密な規格が無ければ読み込めるはずが無いんだよバカか？
＞それが正しい根拠がない
先頭のバイナリで判断出来なければそのバイナリをアイコンァイルだとどうやって認識するんだ？
PCは小学校中退知恵オクレじゃないんだよ
＞ICODIRはアイコンのヘッダでPNGのヘッダじゃないよｗ
オクレの錯乱が止まらないw
アイコンのヘッダーはICODIR
省2
853(1): 01/29(水)16:23 ID:HdXN8kwj0(9/20) AAS
>>852
＞厳密な規格が無ければ読み込めるはずが無いんだよ
うん。だから「実装」はどこかにあるね。アイコンの仕様はどこにもないよ
だから「わからない」となりますし、>>2の主張と無関係というわけです
＞先頭のバイナリで判断出来なければ
先頭のバイナリの話してません
＞pngのファイルッダーは「89 50 4E 47 0D 0A 1A 0A」
どこにもそんな定義ないよ。シグネチャ「など」を一般にファイルヘッダとは言うけど、8バイトだけとする規定はどこにもない
オクレの主張はファイルヘッダとは８バイトだけだからICCは入らない、というものなのでその根拠はどこにも示されてない、となる
854(1): 01/29(水)16:36 ID:rkK6pj6r0(11/17) AAS
>>853
＞アイコンの仕様はどこにもないよ
無ければアイコンは作れませんねえ？
＞先頭のバイナリ
それをヘッダーと言うんだけどね、小学校中退知恵オクレには難しすぎる？
jpg FF D8 FF E0 00 10 4A 46 49 46
tif 49 49 2A 00 A8 E1 99 02 1D
exe 4D 5A 90 00 03
こういう約束事で厳密に定義されるからファイルは機能するんだが、機能しない仕様を定めるバカなんてチン皮だけだw
まして、ファイルの中にある構造体なんて、開始コードが何で終了コードが何と思いっきり厳密にしなけりゃ機能しないだろバカか？
省2
855(1): 01/29(水)16:47 ID:HdXN8kwj0(10/20) AAS
>>854
＞無ければアイコンは作れませんねえ？
作れるし作ってるよ。これは以前論破したのでループだね
＞それをヘッダーと言うんだけどね
別に否定しないよ。それ「も」ヘッダー PNGのICC部分もヘッダー
オクレはそれはヘッダーじゃないというが根拠はない おしまい
856(1): 01/29(水)16:51 ID:HdXN8kwj0(11/20) AAS
2chｽﾚ:dcamera
981
過去からの積み上げだよ
既存のICOファイルの解析、オープンソースライブラリ、各種技術解説 もちろんWIKIもその一部だよ
この世の何処かにきっかりした仕様書があるはずだ、というのもオクレくんの身勝手な思い込みなんだ ま、いつもどおりのフル論破だね
988
えーと、明確な仕様が公開されてるというならそれを出せば良いんだよ
でも出せないでしょ？なんでそこで終わりなの
ちなみに今MSで公開されてるのはアイコンに使われる画像の推奨規定と超絶大雑把な解説だけで
アイコンフォーマットの詳細な仕様は載ってないから実装できないよ
857(2): 01/29(水)19:28 ID:rkK6pj6r0(12/17) AAS
>>855-856
作れる、それが他の人にも見えるってのは仕様が存在するからなのな？バカには分からないだろうが
ちょっと調べりゃMSDNに出てたわw
外部ﾘﾝｸ:learn.microsoft.com
前上げたサイトもこれもプログラミングの領域のハナシで解説しているからな
明確な仕様定義が無くてどうやってプログラミング出来るんだよ小学校中退知恵オクレじゃあるまいし
858(1): 01/29(水)19:34 ID:HdXN8kwj0(12/20) AAS
ちなみに今MSで公開されてるのはアイコンに使われる画像の推奨規定と超絶大雑把な解説だけで
アイコンフォーマットの詳細な仕様は載ってないから実装できないよ
859(1): 01/29(水)19:42 ID:HdXN8kwj0(13/20) AAS
そして、ファイルヘッダーにICCは含まれない という話からは逃走、とｗ
逃げ道あげるとあっさり食いつくのでホントわかりやすいよね
860(1): 01/29(水)19:43 ID:HdXN8kwj0(14/20) AAS
>>857
たとえば、以下のフィールドについて十分な説明がありますか？
biSize (ヘッダーサイズ、必ず 40 バイト)
biWidth (アイコンの幅、ICO では 1 エントリで 2 倍の値を格納することがある)
biHeight (実際のアイコンの高さの 2 倍（XOR+AND マスク）として格納される)
biBitCount (色深度：1, 4, 8, 24, 32-bit の違い)
biCompression (ICO では BI_RGB か BI_PNG のどちらか)
→ ICO に特有の制約や Windows における仕様が詳細に説明されていなければ不十分
上下前次1-新書関写板覧索設栞歴
あと 142 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s