将颜色分解为阴影的功能。 - 页 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）。

比如说。

它是一个二维的红色调色板

而这是它的一维梯度。

你想争论的是两个梯度（从黑色到彩色和从彩色到白色）的交界处需要在哪里。你认为中间的变体是唯一正确的，因为它们是在Windows的Paint中使用的。在你上面的例子中，只有一个颜色成分出现，其余都是0，是的--它是正确的，但这只是一个特殊情况。我不是在断言什么，我只是说这取决于手头的任务，但我认为把它放在最一般的情况下是合乎逻辑的，取决于颜色的亮度（R+B+G之和）。

例如，在更严肃的图形编辑器中，如Corel和Adobe的编辑器，当涉及到渐变填充时，有一个关于渐变的 "重心 "的设置。

这是一个不费吹灰之力的说法。

我正在弹射离开这个话题。

 
Nikolai Semko:


我说的是颜色范围。梯度可以是不同的。但一种颜色的全部色调是恒定的。

每种颜色都有三个组成部分--图形上的三个点。有三条线穿过它们。 每条线在图上有两段。这些片段是从光的折射中出现的。折射轴在图形的中心。每段都有不同的上升角度。上升过程中，从零到最大值。图中的六条线段都代表一个棱镜。 它们的角度在每个范围内都是恒定的。任务是在条形图的每个点上找到一个组件的值。通过这种方式，我找到了一种颜色的所有色调。其 他的都是这个解决方案的衍生操作。你可以改变上升的角度，你可以混合颜色，等等。基础仍然是一样的。

在你的解决方案中，色调的范围要么不完整，要么是扭曲的。在这两种情况下，色调的过渡都是不顺利和不和谐的。


zy。关于重心--我同意。但这只是对图形上特定点的计算的一种操作。你可以在第一段中得到比第二段更多的成分值。所以你会得到一个 "梯度重心转移"（如上面的例子）。

 
你不能做井字游戏吗？
 

该图看起来像这样。



而对于这一切，我是通过简单地观察Windows调色板窗口中的数字行为而来。

1...121314151617181920212223
新评论