색상을 음영으로 분해하는 기능. - 페이지 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 :

Nikolay, 나는 객관성을 추구합니다. 첨부된 스크립트 및 스크린샷.

나는 당신이 당신의 솔루션을 개선하는 것을 좋아한다는 것을 알고 있습니다. 저도요.

귀하의 알고리즘은 (불행히도) 잘못된 그라디언트를 생성합니다. 나는 그것이 어떻게 작동하는지 모르기 때문에 오류를 찾지 않았습니다. 하지만 할 수 있습니다.

https://www.mql5.com/en/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 팔레트도 좋아하지 않습니다. 결국, 나는 그녀와 거의 완전히 일치합니다.

나는 이미 그것에 대해 썼습니다 .

팔레트와 그라디언트를 혼동하지 마십시오. 그래디언트는 1차원 개념이고 팔레트는 2차원 또는 3차원 또는 4차원(CMYK에 대해 이야기하는 경우)입니다.

예를 들어:

이것은 빨간색의 2차원 팔레트입니다.

이것은 1차원 그라디언트입니다.

두 개의 그라디언트(검정에서 색상으로, 색상에서 흰색으로)의 접합이 필요한 주제에 대해 논쟁하려고 합니다. 당신은 중간에 있는 변형이 유일하게 올바른 것이라고 주장합니다. 왜냐하면 Windows 그림판에서 사용됩니다. 위의 예에서 하나의 색상 구성 요소만 나타나고 나머지는 0인 경우 예 - 이것이 더 정확하지만 이것은 특별한 경우일 뿐입니다. 아무말도 하는게 아니라 그냥 풀고 있는 문제에 따라 다르다는 얘기지만 색의 명도(R + B + G의 합)에 따라 가장 일반적인 경우로 설정하는게 논리적이라고 생각합니다.

예를 들어 Corel 및 Adobe와 같은 보다 심각한 그래픽 편집기에는 그라디언트 채우기와 관련하여 그라디언트의 "무게 중심"에 대한 설정이 있습니다.

이것은 논쟁의 여지가 없습니다.

나는 이 주제에서 쫓겨났다.

 
Nikolai Semko :


색상 범위에 대해 이야기하고 있습니다. 그라데이션이 다를 수 있습니다. 그러나 한 색상의 전체 음영 범위는 일정합니다.

각 색상에는 세 가지 구성 요소가 있습니다. 즉, 그래프의 세 점입니다. 세 개의 선이 그들을 통과합니다. 각 선은 차트에서 두 개의 세그먼트를 가집니다. 세그먼트는 빛의 굴절에서 나타납니다. 굴절 축은 그래프의 중앙에 있습니다. 각 세그먼트에는 고유한 상승 각도가 있습니다. 상승은 0에서 최대로 이동합니다. 차트에 작성된 6개의 세그먼트는 모두 프리즘입니다. 각도는 각 범위에 대해 일정합니다. 작업은 이러한 세그먼트의 각 지점에서 구성 요소의 값을 찾는 것입니다. 이것이 내가 같은 색의 모든 음영을 찾는 방법입니다. 다른 모든 것은 이 결정의 파생 조작입니다. 상승 각도를 변경할 수 있고 색상 등을 혼합할 수 있습니다. 베이스는 변함이 없습니다.

솔루션에서 음영 범위가 불완전하거나 왜곡됩니다. 어쨌든 음영의 전환은 부드럽고 조화롭지 않습니다.


추신 무게 중심에 대해 - 동의합니다. 그러나 이것은 그래프의 특정 지점 계산을 조작한 것일 뿐입니다. 두 번째 세그먼트보다 첫 번째 세그먼트에서 더 많은 구성 요소 값을 얻을 수 있습니다. 이것이 "그라디언트의 이동된 무게 중심"이 나타나는 방식입니다(위의 예에서와 같이).

 
약간 틱택토 zabatsat?
 

차트는 다음과 같습니다.



그리고 이 모든 것에 대해 Windows 팔레트의 창에 있는 숫자의 동작을 관찰하여 간단하게 왔습니다.

사유: