Fast Compare Real8 with SSE and ColorSpaces

[guga]

I´m not sure if i understood. Tween means changing hues to avoid large difference ? Don´t know the meaning of "tween" in english. Google returned me it means 'tweak', but..still don´t understood :icon_mrgreen:. If it is, the HSV, CieLCH colorspaces already have some If conditions to deal with the Hue direction problem. The direction is checked using thresholds. To fix problems of hue directions (so, the opposed signs) is necessary to compute the "a" and "b" factor from CieLab colorspace (Or as i did directly from CieLCH).

For example, on CieLCh colorspace, Hue is determined by the following equation:

Hue  = Atan (b/a), where b is the "Bfactor" from CieLab and "a" the "Afactor" from CieLab

"a" and "b" are achieved from the X,Y, Z values from the XYZ colorspace using these formulas:

a = (X-Y)*500
b = (Y-Z)*200

whereas, Luma = Y*116-16

Also, the value of "a" and "b' can be found using the CieLCh colorspace with the following formulas:
a = cos(hue)*chroma
b = sin(hue)*chroma


The correct way to find "a" depends on the colorspce you are working with. I made a variation of CieLCH that uses XYZ values directly rather then having to migrate in between each colorspace to find the very same value.

The final values of X, Y and Z are calculated from a multiplication of Red, Green and Blue with the proper matrices for AdobeRGB, sRGb etc. and after a IF condition to check some thresholds.

The If condition is in the form of:

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


The same conditions are used for Y and Z


The complete pseudo-code to transform RGB to CieLCh is this:

Red = Red/255 ; The integer colors must be normalized 1st. So, divide each color (Integer) by 255.
Green = Red/255
Blue = Red/255

TmpRed = Red*Kfactor
TmpGreen = Green*Kfactor
TmpBlue = Blue*Kfactor

where "Kfactor" is computed using the gamma and offset adjustments . (If needed i post the formula to achieve "Kfactor" for you).

X = (TmpRed*Matrix.RedM1 + TmpGreen*Matrix.GreenM2 + TmpBlue+Matrix.BlueM3) / WhiteReferenceX
Y = (TmpRed*Matrix.RedM4 + TmpGreen*Matrix.GreenM5 + TmpBlue+Matrix.BlueM6) / WhiteReferenceY
Z = (TmpRed*Matrix.RedM7 + TmpGreen*Matrix.GreenM8 + TmpBlue+Matrix.BlueM9) / WhiteReferenceZ


where:
Matrix.RedM1, Matrix.RedM2, Matrix.RedM3 ... are the tristimulus values for XYZ colorspace used in Adobe1998, sRGB etc. Example, for sRGB, the values are:

Matrix.RedM1     Matrix.GreenM2       Matrix.BlueM3
0.4124564          0.3575761              0.1804375
Matrix.RedM4     Matrix.GreenM5       Matrix.BlueM6
0.2126729           0.7151522              0.0721749
Matrix.RedM7     Matrix.GreenM8       Matrix.BlueM9
0.0193339           0.1191920              0.9503041

WhiteReferenceX, WhiteReferenceY, WhiteReference| are the white references for observers in 2º or 10º degree described in CIE convention. For example:

For D65, 2º observer (Daylight, sRGB, Adobe-RGB)

WhiteReferenceX = 95.047 . Btw: WhiteReference is nothing more then the simple sum of the matrice values multiplied by 100. Ex: (0.4124564+0.3575761+0.1804375)*100
WhiteReferenceY = 100
WhiteReferenceZ = 108.883




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

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

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

; The above X,Y,Z are the same ones found in XYZ colorspace. I then convert them to lab and after it to hue/chroma (In fact, i make it directly on the same function) , but, below are the necessary equation used, in case you want only the CieLab convertion

; retrieve a, b and Luminance

Luma = Y*116-16
a = (X-Y)*500
b = (Y-Z)*200

and finally, achieve Hue and chroma from "a" and "b"

Chroma = sqrt(a^2+b^2)
Hue = atan (b/a)


This is the pseudo-code to convert from RGB to CieLCH. Here i´m using gamma adjustment (The "Kfactor" i created to make those equations easier and the code faster to process) and white reference to achieve a higher level of accuracy and making the image looks better according to a chosen colorspace (Adobe RGB 1998, sRGB, HDTV etc)


The whole convertion itself is not that complicated after i simplified the equations. The main problem relies on the way those conversion works. CieLab and other perceptual colorspaces have something called color discontinuity that is nothing more nothing less then a failure on the original equations (I call it simply as: bulls* )

bruce lindbloom make an effort to fix the error here: http://www.brucelindbloom.com/LContinuity.html

In fact, on a mathematical point of view, he was correct, but conceptually, it still don´t fixes the problem with those colorspaces.

For example, using Y*116-16 will necessarily lead to an error on the way color is perceived, since we are generating a "gap" of 16 values on the equations (I have no idea how to fix that properly. So...i´m using Bruce´s suggestion)

One way to fix those colorspaces is create a new one as i did last year. The colorspace i designed is spherical, using all 3 dimensions as the vertices for Red, Green and Blue without any usage of those "gaps". The usage of a spherical colorspace seems more logical and accurate since "color' is nothing more then the form that our eyes (brain, in fact), perceive an eletromagnetic wave after passing through our eyes and cells responsible for color perception. Eletromagnetic waves travels in space in all directions, at the same speed.  Considering a tridimensional space, then we can then represent each x,y,z axis as Red, Green and Blue and work with them proportionally (Spherically), instead using those crazy equations actually used. It is a variation of a TSL colorspace as i mentioned earlier. I succeeded to create a formula to convert back, but still have problems, because i have to find the limits the resultant values and after a while i gave up trying. maybe eventually i´ll restart that work.

[daydreamer]

sorry I try to practice english everyday,but sometimes it sneaks in wrong words and I am not native english speaker
think of you open up a dialog of image resizing in a image program,photoshop etc,you get a dialog of different interpolationalternatives,linear etc
but think interpolation while in HSV,HSL or CieLCH color space image,Hue channel

[Siekmanski]

Hi guga,

Interesting topic.

As far as I understand you are calculating a new colored image by using the luminance
of a source image and the chroma colors of a reference image?

So the calculated final image has max. 256 different colors?

[guga]

Hi Daydreamer. I asked because im also not a native english speaker   

I understood now. But when you open a dialog and change the Hue angle, the equations used are always those ones i posted. The problem is that hue is directly related to chroma and not with luminosity. So, when changing hue you end up also changing chroma and vice-versa. The main problem i´m facing is find the relation between chroma and hue on such a way that when you are doing the reverted operation (CieLab to RGB) there will no more need to clip anything.

Hi Siekmanski :) Yes...for this preliminary tests i´m transferring only a maximum of 256 colors. Once i suceed to fix those damn problems on the CieLCH equations, i can then try to make the new image contains 65536 and later 16 millions colors. But, i choose to try the very basics 1st to see if it works. But, this technique i´ll do later, once i finish to find a way to fix the CieLCH equations.

So far it works ok on a maxmimum of 256 colors. It get´s the luminance of all pixels on the colored image and searches for the ones that best macthes with the luminance of the gray image and do the transfer. To make it extend the amount of colors, i´ll need to search for the neighbor pixels and see what chunck of pixels on the gray image matches with the same chunck of pixels on the colored one. (Transferring the texture, then.)

The resultant image, so far is Ok, i mean, I was able to transfer the exact same luminance of both images and transferring the chromacity of the reference to the target (gray). If i then convert the new colored image to grayscale again, it will have the same gray pixels as before the convertion . This shows me that the transfer was ok:)

However, it still is ocurring some clippings on the colored image due to this damn lack of limits on the CieLab/CieLCH equations.  I´m struggling to find something as simple as a fraction to stablish the limits. SOmething like: x (From luma1) = Chroma/Hue ; y (From Luma2_ = Chroma (From luma2)/Hue (Also from luma2) etc etc etc.

If the equations were linear it would be eaiser but... :icon_eek: :icon_eek: :icon_eek:

It´s important to fix the CieLCH issues because on the reference image (colored) one, there´s no need to search for thousands of repeated colors or the ones that are perceptual indistinguishable from each other. I can create a sort of sample file from the reference image more accurated then. This is to say, if i have a colored image of 960*720, i don´t need thousands of colors combinations. I´ll need only a few bunch of them. I can create a file containing, something around 65000 thousand different (unique) samples to be chosen for any transfer technique needed. So, no matter if i extend the final limit to 65536 or 16 million colored images (Unnecessary, btw, since from all 16 million colors, only a few thousands of them are perceptual different from each other), it will always look for the same 65536 samples of the reference one to create the new color image. It will only depends of the position of the pixels etc. Also, if i later start using the neighbour pixels technique, it is possible to create a new color pixel biased on the reference (I mean, a new color that don´t exists on the original reference image). For example 2 pixels in between one have the same (or similar) hue, but different chromacity. Then, all is needed is take the average chromacity and hue among them to create the new pixel existent in between.

Sure, i can also create a file (or several files) containing 16 million colors samples, but so far i´m doing slow to see how it works.

[Siekmanski]

Can you post the original source and reference images?
So I can play with the algorithms.....

[guga]

Sure  :t :t :t

let me only clean up the code before posting. I´m doing it right now.

[guga]

Hi SiekManski

Here is the cleaned file (I had to upload in my google drive because it´s big for upload here).  I created a small app to be tested. You only need to load an image and incrase/decrease the Scroolbar btn to change the luminance up or down. This is a dumb test for the RGBtoCieLCH and CieLCHtoRGB convertions.

The main routines responsible for the conversion are the functions:

    RGBtoCieLCH_Ex
    CieLCHtoRGB_Ex

They are located inside a function i named as "NewAdjustLuma" This functon simply adjust the luminance. So it increases or reduces the luminance from those conversion functions.

Also, for the data that is preloaded when the app starts, the function is: SetupWorkSpaceMatrixDataEx located in the WM_CREATE on the main window procedure.

SetupWorkSpaceMatrixDataEx is responsible to create all necessary data to be used on the conversion functions. It generates the gamma values, white references , compute the adaptation method (I´m using the default mode. I created a serie of equates for the several different color models, but, the better is use CS_MATRIX_SRGB_D65_HDTV as it is. On this way we can test on the same method.

WS_Matrix is a huge structure where all necessary data is calculated and preloaded once the application starts. is upon some members of the WS_Matrix that the functions "RGBtoCieLCH_Ex" and "CieLCHtoRGB_Ex" grb the necessary ata, simply pointing to the proper addresses rather then haveing to calculate all over again for every pixel.


Btw...The source code is for RosAsm, so it´s embedded in the app. I uploaded a new version of RosAsm i uses to my personal tests here: https://www.tapatalk.com/groups/rosasm/rosasm-download-t2.html  I tried to upload here, but the file is big for the attachement.  No need to make deep configurations, just unzip rosasm on any directory and once the configuration dialog shows up, simply points the asked files on the proper path. (Equates.equ, clip.txt etc...) Those files are located on the RosAsmFiles subdirectory. So you need only to point there when(or if) asked.

And here is the link to the test file for the CieLCH convertion. (If you need i rip the asm source alone and also i can try making a pdf explaining the funcionality of the functions, or the convertion algorithms.)

https://drive.google.com/open?id=1gztsNpNw4_61oHYrURpc1b81tyW_1hKZ


About the images i use to test, i suceeded to attach here

Note: Those routines and test app is not for the grayscale to color convertion. What i sent was the CieLCH convertiosn to be fixed 1st. The other part of the code necessary for the grayscale to color is kinda huge and i´ll need to clean that too, because it´s a total mess the way it is already.

Can you help trying to fix the CieLCH convertions, 1st  and later when we succeeded we give a try on the colorization method ? Maybe it be better understand the whole code, i guess.

[guga]

And here´s the source for the CieLCHtoRGB and RGBtoCieLCh functions.

Btw....the "convert" button on the test file i sent, do...nothing To make easier i removed the mess that was related to it. It was the one responsible for converting from gray to color, but since on this test i removed that code to we test 1st the colorspace convertions, i forgot to remove that button as well :redface: :redface: :redface:

[HSE]

Btw....the "convert" button on the test file i sent, do...nothing

Very, very funny. I was thinking that was so slow 

[guga]

 :redface: :redface: :redface: :icon_mrgreen: :icon_mrgreen: :icon_mrgreen:

Once the fixes of the colorspace conversions were sucessifull i´ll post another version without that btn. And later another one containing the full (and cleaned) code to the gray to color transfer. :t :t

[Siekmanski]

Thanks, where can I get the image of the woman with the colored lips?

[guga]

Attached here

[jj2007]

Hi Guga,

See http://masm32.com/board/index.php?topic=94.msg83812#msg83812 for an update on the "find the number" problem.

[guga]

Tks a lot, JJ :)  :t :t :t

I`m creating a pdf about the CieLCH routines describing the algorithms and trying to figure it out some limits of it to be used on the backwards convertion from CieLCH to RGB. As soon i finish, i´ll post it here to see if you guys can help me finding the correct limits for this. The goal is make the backwards calculation more accurate  avoiding clipping the final result. And, of course, once it´s fixed we can try optimize it further. I read your´s algo on fastsin to later use on the CieLCH routines, and it´s amazing :)

The next  optimizations will be in sin, cos, atan and power (exponencial, logaritm etc) functions :)

[guga]

Hi Guys

Here is a pdf with the functionality of the RGB to CieLCh colorspace. Can someone help me seeing if the math operations (and it´s properties) are ok ?

I tried to build the properties of the math to make easier to the conversion backwards works ok.

I found out that

Chroma, Luminance and Hue have direct relations/limits/dependencies among them.

The final property of all of that seems to be:

Luma > 116* [ (5*Afactor - 2*BFactor)/1000 ] -16 ; where "BFactor" and "Afactor" are the "a" and "b" values for the CieLab colorspace

For Chroma, i found that this relation/limit is:

Chroma  <  [(1000/116)*(Luma+16)] / [5*cos(Hue)-2*sin(Hue)]

Knowing these properties are important to build the backward computation (CieLCHtoRGB), 1st check for it´s limits before trying to convert back.