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

 
Nikolai Semko:

Peterさん、問題は、誰でも見られるようにフォーラムに関数を投稿し、色分解を適用していることです。しかし、この関数は必要な色配列を生成せず、文字列配列だけを生成します。これは、画面上でグラデーションを実演するのではなく、印刷出力にのみ適して います。それは、豚のような存在で、他者への敬意がない。必 要なら自分たちで翻訳してください。

これはもう、あからさまな名誉毀損、誹謗中傷です。 あえて文字列型を選んだのは、構成要素が見やすく、切り分けがしやすいようにするためです。 最初のページで、私の解法テクニックを詳しく説明しました。何も説明してないじゃないか。 あなた自身が、あなたの色分解の方法を十分に理解しているとは思えません。そうでない場合は、私のように詳しく説明してください。

そして、そのような大きな声で非難するのはやめましょう。自分で手を滑らせることもあります。

 
そして、言い争いにならないように。その真相に迫ろう。
 
Реter Konow:

これは明らかな誹謗中傷であり、名誉毀損である。 文字列の種類は、構成要素を見やすく、切り分けやすくするために、あえて選びました。 最初のページで、私の解答のテクニックを詳しく説明しました。何も説明していませんね。あ なた自身が、色分解法の仕組みを十分に理解しているとは思えません。そうでない場合は、私のように詳しく説明してください。

そして、そんな大声で非難するのはやめましょう。自分でも手を滑らせるかもしれません。

すみません~、今説明を読みました。

  • まず、色を大きく3つに分解し、シニア、ミドル、ジュニアと定義しました。
  • そして、グラフを作ったり、部品の値を線で結んだりするようになりました。
  • スライダーをドラッグしてパレット内の数字が変化するのを見ていると、いつの間にか数字の変化率が変わっていて、線の上昇角度に屈折があることに気がついたのです。
  • グラフの中心に線の屈折軸を置き、それぞれの線が2つのセグメントからなり、それぞれが昇交角を持っていることを確認しました。
  • また、カラーパレットを試すことで、高い方の成分には最大上昇角度があることに気づきました。最初は67.5度だと思った。しかし、練習では63.5度であることがわかった。
  • 長い間、色成分の線分を正しくプロットする方法が分かりませんでした。未知数な部分が多かったのです。しかし、肝心なのは、グラフ上で元の色の座標をどう求めるかです。
  • パレットの操作を続けていくうちに、色の値を ある数値だけ変化させると、スライダーがある距離だけ動くことに気づきました。だんだんと、スライダーの移動距離が低次成分の値の半分であることが分かってきました。
  • 最大上昇角の線上にある高い成分の座標を求め、そこに低い成分の半分を足せば、プロット上の元の色の座標が求まると仮定しました。この仮説が正しかったことは、実践で証明されています。
  • 初期色と屈折軸の座標があれば、各パーツの角度を計算し、その線に沿った各成分の値を受け取ることができました。そのために高校の三角関数を使ったんです。

それは無理だ。もっと平凡で原始的なものです。
コードそのものよりも、もっとキャッチーに説明することは困難です。

void Gradient(uint clr,uint &arr[],uint size)
  {
   if(size==0) return;
   ArrayResize(arr,size);
   rgb c;
   c.clr=clr;
   uchar R=c.c[2],G=c.c[1],B=c.c[0];
   uint i=0, tone=uint((size-1)*(((double)R+(double)G+(double)B)/765.0)+0.4999);
   double kR,kG,kB;
   if(tone!=0)
     {
      kR=(double)R/tone; 
      kG=(double)G/tone;
      kB=(double)B/tone;
      for(i=0;i<=tone;i++)
        {
         c.c[2]=uchar(i*kR+0.4999);
         c.c[1]=uchar(i*kG+0.4999);
         c.c[0]=uchar(i*kB+0.4999);
         arr[i]=c.clr;
        }
     }
   if(tone!=(size-1))
     {
      kR=(double)(255-R)/(size-i);
      kG=(double)(255-G)/(size-i);
      kB=(double)(255-B)/(size-i);
      for(uint j=1;i<size;i++,j++)
        {
         c.c[2]=uchar(R+j*kR+0.4999);
         c.c[1]=uchar(G+j*kG+0.4999);
         c.c[0]=uchar(B+j*kB+0.4999);
         arr[i]=c.clr;
        }
     }
  }
 
Nikolai Semko:


もう1度

  • 私が作ったアルゴリズムをそのまま持ってきてください。あなたの修正なしで。
  • 色を設定します。MT4でスクリプトを実行します。
  • アラートで全色を揃える。
  • Windowsのパレットに元の色を入力します。
  • マッチングを確認する。

これは、アルゴリズムが正しく動作しているかどうかを確認するのに最適な方法です。

そして、スピードチェックに移行します。

一方、あなたは私のアルゴリズムを、自分の好きなように線を変えて、それを別のプラットフォームで動かして、自分の描画技術に従って表示したのです。これだけ独自に改変しておきながら、自分がどのように改変し、どのような状況に置いたかに気づかないかのように、私のアルゴリズムを判断するのですね。あなた自身がエラーになりそうな条件では、冷静に調べてみましょう。

 
Реter Konow:

もう1度

  • 私が作ったアルゴリズムをそのまま持ってきてください。あなたの修正なしで。
  • 色を設定します。MT4でスクリプトを実行します。
  • アラートで全色を揃える。
  • Windowsのパレットに元の色を入力します。
  • マッチングを確認する。

これは、アルゴリズムが正しく動作しているかどうかを確認するのに最適な方法です。

そして、スピードチェックに移行します。

一方、あなたは私のアルゴリズムを、自分の好きなように線を変えて、それを別のプラットフォームで動かして、自分の描画技術に従って表示したのです。これだけ独自に改変しておきながら、自分がどのように改変し、どのような状況に置いたかに気づかないかのように、私のアルゴリズムを判断するのですね。あなた自身がエラーになりそうな条件だから、冷静に見極めよう。

ピーター アラートに3桁の256通りの組み合わせは必要ないんだ。色が欲しい。あなたの関数でやったことは、本来あるべき姿であるcolorをuintに変換したことだけです。その論理は私の理解を超えているので、私はあなたのアルゴリズムには入りませんでした。

 
Nikolai Semko:

ピーター 3桁の色の組み合わせが256通りもあるアラートはいらないよ。色が欲しい。私があなたの関数で行ったことは、色を文字列ではなく、本来あるべきuintに変換したことだけです。あなたのアルゴリズムについては、その論理が私の理解を超えているため、まだ手をつけていません。

数字で確認するのが一番です。色の濃淡は目で見て比較することはできません。モニターが異なれば、認識も異なることがあります。だからこそ、数字が一番のチェックポイントになるのです。

しかも、無理な理屈は一切なし。学校の三角法

1.6つのセグメントの角度を計算する。

2.そして、これらのセグメントの各点における値を計算し、配列に書き込む。

それだけです。

 
Реter Konow:

数字で確認するのが一番です。色の濃淡を目で見て正確に比較することはできません。モニターが異なれば、認識も異なることがあります。だからこそ、数字が一番のチェックポイントになるのです。

しかも、無理な理屈は一切なし。学校の三角法

1.6つのセグメントの角度を計算する。

2.そして、これらのセグメントの各点における値を計算し、配列に書き込む。

それだけです。

しかし、実際には、私の機能は不具合なく動作し、4倍も高速になりました。5のアルゴリズムを提供したときの結果を待っています。クリップボードからコピーするだけでも時間がかかるのに、さらに時間がかかるとは。

 
Nikolai Semko:

しかし、実際には私の機能は不具合なく動作し、4倍高速になりました。5のアルゴリズムを提供する際には、その結果を待っています。クリップボードを介してコピーするだけでも時間がかかったのに、さらに何かと時間がかかるんですね。

ニコライさん、それじゃ幼稚園児みたいじゃないですか。4倍速い」という発言は、証明されていないため無効です。


  1. MT5で私のソリューションのあなたのバージョンで行をコメントアウトすると、あなたは違いを見ることができます。

canvas.TextOut(300,10,"Время формирования градиентного массива из 256 элементов = "+string(t)+" микросекунд",ColorToARGB(clrWhite));

この線は、なぜか矩形全体の描画に影響します。でも、それは私の不具合ではありません。チェックしてみてください。

あなたが持っている不具合について、引き続き調べています。本当に私のアルゴリズムのせいなのか、確かめたいのです。


そして、数字の無駄な明滅を消してください。不要なものはすべて取り除いてください。元の色が1色のグラデーションを持つ単純な矩形を一度表示させてみましょう。余計なギミックは一切なし。

 
一般的には、2色間のグラデーションの配列を取得する関数の方が便利です。よりシンプルで、実際に役立つように。
void Gradient(uint clr1,uint clr2,uint &arr[],uint size)
  {
   if(size==0) return;
   ArrayResize(arr,size);
   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);
   for(uint i=0;i<size;i++)
     {
      R1+=deltaR; c1.c[2]=uchar (R1+0.4999);
      G1+=deltaG; c1.c[1]=uchar (G1+0.4999);
      B1+=deltaB; c1.c[0]=uchar (B1+0.4999);
      arr[i]=c1.clr;
     }
  }

ある色から白や黒へのグラデーションが必要な場合、この関数でそのように得ることができます。

   color clr=clrViolet;
   uint CLR[];
   Gradient(clrWhite, clr, CLR,100); // получаем массив из 100 элементов градиента от белого цвета до цвета clr 
   Gradient(clr, clrBlack, CLR,100); // получаем массив из 100 элементов градиента от цвета clr до черног цвета  


ファイル:
 
Реter Konow:

数字で確認するのが一番です。色の濃淡を目で見て正確に比較することはできません。モニターが異なれば、認識も異なることがあります。だからこそ、数字が一番のチェックポイントになるのです。

私は「告発」に参加します、耐えられなかった :)

プログラミングをしてはいけないという良い例です。GUI全体がこのような書き方をしているのであれば、長い間見ることはないでしょう。:(

どの行も「傑作」です。これだけエラーや失敗が積み重なれば、mql4はうまくいくだろうという期待も高まります。mt4が使われる理由がわかりました。

このようなコードの公開と、その後の批判に対する反応は、フォーラムの参加者を尊重していないのではと思います。彼らはあなたに危害を加えたいのではなく、あなたを助けたいのです。

アルゴリズムの比較については、視覚的に比較することができます。あなたのアルゴリズムが「ウィンドウズ・シェード」に99%近いシェードを出すということを、数字で証明したわけではありません。

左側があなたのアプローチ、右側がニコライ・セムコの アプローチという感じです。(ニコライ・セムコの スクリプトを改造したものを使用)。


ファイル: