色を色合いに分解する機能。 - ページ 19

新しいコメント
 

ごめんね、ピーター - ここからは私がやるわ。もう、言いたいことは全部言いました。繰り返す気は毛頭ない。

あなたや私のアルゴリズムはありません。

繰り返しますが、このスレッドで注目すべきはこの機能だけで、そこから「あなたの」「私の」アルゴリズムが導き出され、あとは手洗いです（あなたの側からも私の側からも:))

void Gradient(uint clr1,uint clr2,uint &arr[],uint size)
  {
   if(size==0) return;
   ArrayResize(arr,size);
   arr[0]=clr1; 
   rgb c1,c2;
   c1.clr=clr1;
   c2.clr=clr2;
   double R1=c1.c[2],G1=c1.c[1],B1=c1.c[0];
   double R2=c2.c[2],G2=c2.c[1],B2=c2.c[0];
   double deltaR=(R2-R1)/(size-1);
   double deltaG=(G2-G1)/(size-1);
   double deltaB=(B2-B1)/(size-1);
   R1 += 0.4999;
   G1 += 0.4999;
   B1 += 0.4999;
   for(uint i=1;i<size;i++)
     {
      R1+=deltaR; c1.c[2]=uchar (R1);
      G1+=deltaG; c1.c[1]=uchar (G1);
      B1+=deltaB; c1.c[0]=uchar (B1);
      arr[i]=c1.clr;
     }
  }
 
Nikolai Semko:

ごめんね、ピーター - ここからは私がやるわ。もう、言いたいことは全部言いました。繰り返す気は毛頭ない。

あなたと私のアルゴリズムがない。

繰り返しますが、このスレッドで注目すべきは、「あなたの」「私の」アルゴリズムを取得できるこの機能だけで、あとは手洗いです（あなたの側からも私の側からも :)）。

ニコライ 客観性は大賛成だ。スクリプトとスクリーンショットを添付します。

あなたはソリューションを改善するのが好きなのでしょう。私もそうです。

あなたのアルゴリズムは、（残念ながら）間違ったグラデーションを作っています。仕組みが分からないので、その中にあるエラーを探さなかった。でも、できるんです。

 
Реter Konow:

ニコライ 客観性は大賛成だ。スクリプトとスクリーンショットを添付します。

あなたはソリューションを改善するのが好きなのでしょう。私もそうです。

あなたのアルゴリズムは、（残念ながら）間違ったグラデーションを作っています。仕組みが分からないので、その中にあるエラーを探さなかった。でも、できるんです。

https://www.mql5.com/ru/forum/282861/page7#comment_8971634

https://www.mql5.com/ru/forum/282861/page9#comment_8987611

https://www.mql5.com/ru/forum/282861/page11#comment_8987978

https://www.mql5.com/ru/forum/282861/page19#comment_9019253
 
Nikolai Semko:

https://www.mql5.com/ru/forum/282861/page7#comment_8971634

https://www.mql5.com/ru/forum/282861/page9#comment_8987611

https://www.mql5.com/ru/forum/282861/page11#comment_8987978

https://www.mql5.com/ru/forum/282861/page19#comment_9019253

そう、あなたは自分のアルゴリズムが正しく機能すると思っている、それは自分の理論に合っているからです。それはわかった。

しかし、私はWindowsのパレットを基準にしています。アルゴリズムの出力とパレットを比較すると、その差は歴然としています。数字やビジュアルで確認できます。

それだけを見せたかったのです。

このままでも構いません。また、その方が見た目もきれいです。

 
Реter Konow:

そう、あなたは自分のアルゴリズムが正しく機能すると思っている、それは自分の理論に合っているからです。それはわかった。

しかし、私はWindowsのパレットを基準にしています。アルゴリズムの出力とパレットを比較すると、その差は歴然としています。数字やビジュアルで確認できます。

それだけを見せたかったのです。

このままでも構いません。それもまた美しい。

私が書いていることを見ていない。私は、あなたが私のアルゴリズム 自身と呼ぶ、私が取ったアプローチが好きではありません（より邪悪でない）。しかし、私はあなたのやり方がもっと嫌いで、その理由も説明しました。

 
Nikolai Semko:

は、私が書いていることを見ていないのです。あなたが私のアルゴリズムと 呼ぶ、私が取ったアプローチは、私自身は好きではない（邪悪さが少ない）。しかし、私はあなたのやり方がもっと嫌いで、その理由を説明しました。

じゃあ、Windowsのパレットも嫌なんですね。何しろ、ほぼ完全に一致するものがありますから。

 
Реter Konow:

じゃあ、Windowsのパレットも嫌なんですね。何しろ、ほぼ完璧にマッチしているのですから。

そのことはすでに書きました 。

また、パレットとグラデーションを混同しないようにしましょう。グラデーションは一次元、パレットは二次元、三次元、四次元（CMYKの場合）です。

例えば、こんな感じです。

二次元の赤いパレットです

であり、これがその一次元グラデーションである。

2つのグラデーションの接合部（黒からカラーへ、カラーから白へ）がどこに必要かを論じようとしているのですね。Windowsの「ペイント」で使われているように、真ん中のバリアントだけが正しいという主張ですね。上記の例では、1つの色成分だけが表示され、他の色成分は0であるため、より正しいと言えますが、あくまで特殊なケースです。別に断言しているわけではなく、課題によって異なるということですが、最も一般的なケースでは、色の明度（R+B+Gの合計）に応じて設定するのが理に適っているのではないでしょうか。

例えば、CorelやAdobeなどの本格的なグラフィックエディターでは、グラデーションの塗りに際して、グラデーションの「重心」を設定する項目があります。

というのは、当たり前の議論です。

この話題からカタがつく。

 
Nikolai Semko:


カラーバリエーションについてです。グラデーションは異なってもかまいません。しかし、1つの色の濃淡の全範囲は一定です。

各色は3つの成分、つまりグラフ上の3点を持っています。それぞれの線は、グラフ上で2つのセグメントに分かれています。光の屈折でセグメントが現れる。屈折の軸はグラフの中心にある。各区間の上昇角度は異なります。上昇値は、ゼロから最大値まで。図中の6つの線分はすべてプリズムを表し、その角度は各範囲で一定である。課題は、棒の各点に含まれる成分の値を求めることである。このように、私はひとつの色にすべての色合いを見出すことができます。 それ以外はすべて、このソリューションの派生的な操作である。上昇の角度を変えたり、色を混ぜたり、いろいろなことができます。基本は変わりません。

あなたのソリューションでは、色合いの範囲が不完全であるか、歪んでいます。いずれの場合も、色合いの移り変わりがスムーズでなく、調和がとれていない。


zyです。重心について - 同感です。しかし、それはグラフ上の特定のポイントを計算する操作に過ぎない。第1セグメントでは、第2セグメントよりも多くの成分値を取得することができます。そうすると、（上の例のような）「重心移動の勾配」ができるんです。

 
三目並べはできないの？
 

グラフはこのような感じです。



そして、これらのことは、Windowsのパレットのウィンドウに表示される数字の挙動を観察するだけで、理解できるようになりました。

1...121314151617181920212223
新しいコメント