Fast Compare Real8 with SSE and ColorSpaces

[guga]

Tks a lot, steve. I´ll take a look :)  :t :t :t

[guga]

Found a typo on the property of equations :icon_redface: :icon_redface:

I accidentally switched sin with cos when computing the maximum value of CLFactor (page 9 on the pdf)

The correct formula for a maximum CLFactor is, in fact, given by:

Code: [Select]

5*sin(Hue) -2*cos(Hue) <= CLFactor
So, Hue Maximum is given by:

Code: [Select]

HueMax = arctan(2/5) + arcsin (-CLFactor*sqrt(29)/29))

On the review i´m currently making, it won´t change the limits for X that cannot be bigger then 1-2/sqrt(29) but i was forced to try to see the true limits for Hue all over again in order to try to find a common formula to fix the X Axis.


The Hue angle in any means must not exceed 90º and now i came up with 2 real limits for X

YFinal > XFinal

or

YFinal < XFinal


Which one to choose, seems to be related to the White Reference for X.

When White Reference for X is smaller then White Reference for Y, then we must force X to be smaller then Y

and

When White Reference for X is bigger then White Reference for Y, then we must force X to be bigger then Y

The problem is when both are equal. (I´ll see how to handle this too)

Also, X have other limitation that can never be bigger then  1-2/sqrt(29)

I´m thinking in how to overcome all of this. I could not found a equation for X yet, but at least, found it´s true boundaries. I´m only thinking in how to put all of this together on a way that it can also works on the hundreds of matrices that can be generated from the different colorspaces.

Another thing is that the Threshold computed from X, Y and Z like:

Code: [Select]

If  X > (216/24389)
    XFinal = X(1/3)
Else
     XFinal = X*(841/108) + (16/116)
Endif

Seems to be related to the slope calculated in  the gamma fixes. I did not tried to make this Threshold obey the slope yet, because i found a bug on the property of the equations as mentioned. So, i´ll try to fix this and later see if i can really force the threshold to obey the gamma/slope limits.


Thinking

Damn equations ...It´s killing Why, why, why, CIE didn´t made the proper fixes for all of this things yet ? They do have better conditions to make the proper fix than i do.

[Siekmanski]

Just ask them to fix it. 

[guga]

 :icon_mrgreen: :icon_mrgreen: :icon_mrgreen: :icon_mrgreen:

[guga]

Ok, guys. Trying another correction for the equations. I´ll make some tests today and show the results. Let´s hope it is finally fixed. The bad thing on all of this is, when you think you fixed one part, the other one has broken Hard to find a common way to fix all those equations. Hue angle simply refuses to stay in 90º range on all color models

[daydreamer]

great work Guga :t
I am doing some work that maybe can be useful
http://masm32.com/board/index.php?topic=7708.msg84620#msg84620

[guga]

Tks DayDreamer.

I should post an example tonight. I succeeded to make the backward function works but, since i changed the properties of the equations, i´m having to change also the way it represents Chroma and Hue as percentages. Need only to adapt the percentage to the new equation and find a way to link Hue and Chroma on the backward computation, in case you want, for example to decrease Luma with a given percentage that automatically can correct the ratio between chroma/hue with and without shifting (To avoid excessive greenish or reddish the image).

Btw. Can you try to make a fast asin, atan2 and acos, sin and cos and tan and sqrt using Chebyshev method ? It will be helpfull to optimize. In Real8 and Real4, please. So i can test both. I made the functions completely in Real8, so using the asin/acos;atan etc etc in real8 will be great to test this rigth away. And later, if everything works fine., i´ll try porting everything to Real4 (Including the matrices etc) and test a version with Real4 too in order to see the true differences among them before giving a try in the SSE optimization routines suggested by marinus and JJ.

[guga]

1st Test of the corrected CieLCh equations. Luma is a integer value from 0 to 255 (Here on this example, i settled it as 0 to 100%), Chroma and Hue works on 0 - 100% of range per luma.

Needing 'only' to find out How to properly link Chroma and Hue, but the equations and their properties are fixed (i hope).  Curiosuly, the algorithm is colorizing a grayscale image at some extent. (Not recovering the original  colors, but creating new colors from the ones it already have)

Source ccode is embeded in the app. So, to read it, you need to open the file in RosAsm. Btw: Sorry for the mess up with the code. About the statuss bars, it have some minor issues when scrolling the bars, but, i´ll fix that later.

[guga]

Fixed minor problem with the scrollbar and  attached the dll that i forgot to include yesterday.

(except freeimage.dll which i uploaded on the link below due to it´size).
https://drive.google.com/open?id=1mG85imZqFt_19YoDjPEaizgL0ZBTkpvR

[HSE]

Hi Guga!

I have problems with your dll, but work with that downloaded from https://sourceforge.net/projects/freeimage/

[guga]

Hi Guga!

I have problems with your dll, but work with that downloaded from https://sourceforge.net/projects/freeimage/

Great, many thanks. Mine was the previous version. Downloaded the updated one right now :t :t :t

Later i´ll try another approach on the properties of the equation. The main problem of CieLab/CieLCH is the lack of information of the true correspondence between Hue and Chroma. I created a equation to settle it´s boundaries according to each Luma range, but on the current test, i settled it only with the max/min of the general luma, rather then the max/min on each luma range.

In order to avoid clipping in X, Y, Z i had to compute a ratio between min and max, but used the general maximum and minimum. Next test, i´ll see how it works if i settle the max/min, per luma range and create individual ratios per luma, rather then 2 general ones.

This lack of a clear correspondence between Hue/Chroma or "a"/"b" is killing. "a" and 'b" elements in CieLab were simply taken from their hats, rather then calculating as a spherical coordinates.  I´m testing with different color models and so far, it is working as expected (Without clipping, i mean). A reasonable good results seems to be when using "ECI RGB" color model.

[guga]

Testing a new colorspace called HSM (Hue, Saturation, Mixture) created by Oswaldo Severino Jr and Adilson Gonzaga back in 2009, designed to segment colors (such as human skin). The specifications of the  original algorithm was buggy and did not retrieved the backward colors. So, i fixed it to correctly works in RGb to HSM and HSM to RGB. Although it still have some clippings problems (Why people keep forgetting to handle this, is a complete mystery to me ).

Anyway, it is working, and is fast.

Some problems it still have:

1) Does not allow different color models. (I´ll implement it later in order to create a variation of the algorithm that works on all color models)
2) It has clipping problems. (I´ll fix this once i understand how to properly analyse the relation between hue and mixture)
3) Does not handle Luma. "Mixture" is, in fact a vaariation of luma, which the original author tried to represent as layers, but ´ll later see how to correctly fix this, inserting luma without loosing thew characteristics of this "mixture' thing.

Note: Despite those issues on the original algorithm, HSM seems more robust to separate and segment colors and if i suceed to combine it with mine variation of CieLCh, i´ll probably make it more robust than both and a new colorspace will be born :)

Reference info: https://www.researchgate.net/publication/265572436_HSM_A_New_Color_Space_used_in_the_Processing_of_Color_Images

Attached test file. Missing only freeimage.dll due to the size of the attachment.