Structure search

[guga]

I´m not sure if i´m making it clear how this thing works....but What i found out after analysing the functionality of CieLab and CieLCH convertions is that what we call "luma" is nothing more than a certain range of grey.

So, from the 16 million colors we have a specific amouunt of combination of pixels that will results on a grey of 127, and other amount that will result on grey = 200 and so on. What i did was calculate the exact value for hue and chroma for each pixel, then i took the maximum and minimum values for hue/chroma for the whole colorspace (those 16 million colors) and saw what hapened.

What i figure it out is that for each grey level we have specific ranges for hue and Chroma and they seems to be unique for each level.

So, i can have more than one pixel with a chroma of let´s say 85%, but....they are related to other types of luma, because their true values will never match. This is why i used percentage for each luma level rather then their actual values.

ex:

Example, we have a pixel whose Grey = 200, then i know that the range of chroma/hue for this level is XXX and YYY. So if i have 160000 pixels attached to the grey=200, each one of them will have their unique value for chroma and hue, but displayed in percentage related to that specific level.

Pixel1 = Grey/Luma = 200, Hue = 85%, Chroma  = 65% (True Ranges for hue/ chroma  = XXX and YYY) . The percentage is related to the position of the values in the range of XXX to YYY
Pixel2 = Grey/Luma = 130, Hue = 85%, Chroma  = 65% (True Ranges for hue/ chroma  = ZZZ and KKK) The percentage is related to the position of the values in the range of ZZZ to KKK

Although they share the same percentage of Hue/Chroma, the two pixels refers to different levels of grey, each one of them with their certain ranges of chroma and hue. So, even if the percentages matches, this does not means that they have the same hue/chroma.

Doing this way i also found out that Grey is actually handled like any other color in the CieLab/CieLCH convertions. They also have their specific percentages and values for hue/chroma. What people is used to do is simply clip the values when foudn some grey color, but i didn´t limited it. I forced the function to calculate the precise values even if the pixel is grey, because, in fact, they do contains some values for hue and chroma.

This is to say, if i want to desaturate a image using the CieLCH colorspace, i don´t need to perform all the heavy computations. All i need to do is look on the proper tables for ther specific ranges.

So, if i know that a pixel is converted to grey  (say: 124) when it have a hue = 15% and Chroma = 65%, all i have to do is use those values as a limit. So, if i want to desaturate a color, all i have to do is grab the pixel whose luma =  124 and decrease the values of Hue/Chroma until it reaches 15% of Hue and  65% of chroma if i want my pixel turns onto grey = 124

What i also found it that is interesting is the fact that certain colors are deeply attached to a grey level. Ex: The color red have specific ranges for grey while blue color have uses only others grey levels. 

So, no matter how many pixels we have, all red will turn onto pixel 68, whereas light blue will always result in grey = 201 etc...We will never have a red resulting on  grey of 201 or vice-versa. This is also handy for color classification, colorization or even color match techniques.

[jj2007]

OK, let's assume that the dataset is sorted by two elements simultaneously. That means you can use the "binary" search, i.e. narrow down by halving the range until you got the element.

Now the problem is still speed: comparing REAL8 numbers is not very fast, because you do it in two steps. First the high dword, then the low one. Is there a specific reason why you are using REAL8, instead of (much faster) REAL4?

[guga]

Hi JJ.

Indeed you were right about the order of the 2nd element. I converted the result to text to see it´s value. The 2nd member only makes sense to be sorted if the 1st one is duplicated. it won´t make much difference anyway, since i can simply create another table making it order by hue, if an extra table could be needed.

The only problems is that it do contains repeteaed Chroma (a very few ones, in fact. Less then 3% of the data or so, for some gray levels), but since the hue is sorted on those specific cases, then it wont affect the result i guess.

Code Select Expand

Luma: 127 - Chroma = 4.91902228406846 - Hue = 44.83984657131926
Luma: 127 - Chroma = 4.92021648723465 - Hue = 45.52085782555232
Luma: 127 - Chroma = 4.92106465082628 - Hue = 27.81011666729317
Luma: 127 - Chroma = 4.92175724228554 - Hue = 5.97894268127245
Luma: 127 - Chroma = 4.92217636717869 - Hue = 40.40063351810875
Luma: 127 - Chroma = 4.92270364859599 - Hue = 38.13873462681201
Luma: 127 - Chroma = 4.92317135437391 - Hue = 14.33676438731702
Luma: 127 - Chroma = 4.92400158699392 - Hue = 28.68843746495414
Luma: 127 - Chroma = 4.92409200831756 - Hue = 45.50254504647477
Luma: 127 - Chroma = 4.92513148351412 - Hue = 44.81169849491374
Luma: 127 - Chroma = 4.92617916980371 - Hue = 8.12017422689824
Luma: 127 - Chroma = 4.92629781474959 - Hue = 10.87254845163805
Luma: 127 - Chroma = 4.92720821669483 - Hue = 44.14771869516645
Luma: 127 - Chroma = 4.92728409414898 - Hue = 3.79537687982782
Luma: 127 - Chroma = 4.92797163083742 - Hue = 45.48423042700837
Luma: 127 - Chroma = 4.92913024597369 - Hue = 26.00484700886813
Luma: 127 - Chroma = 4.93045309288895 - Hue = 4.34774791311986
Luma: 127 - Chroma = 4.93051962287680 - Hue = 5.58126019413311


I made it in Real8 just for precision.  Later, whern teh search is ok, i´ll analyse teh resultant values and also see if it will not change the image that much. So, maybe i can use Real4 insetad, but 1st it would be beetter fixing it so i can see if the usage of a Real4 can also result on accurated values.

[guga]

About... " First the high dword," I don´t get it...the last time you didn´t used the high dword. You basically scanned the Real 8 using comisd before copying the value to XMM0. This is what you did previously:

Code Select Expand


Proc BinSearchReal8:
    Arguments @pArray, @Value, @ElementsCount
    Uses esi, edi, edx

    mov edx D@Value
    movq XMM1 X$edx
    mov esi D@pArray
    push esi
    mov edx D@ElementsCount
    lea eax D$esi+edx*8

@DoLoop:
    cmp esi eax | jae @EndLoop
    mov edi eax
    sub eax esi
    sar eax 04
    lea eax D$esi+eax*8
    movlps XMM0 X$eax
    comisd XMM0 XMM1 | ja @DoLoop
    lea esi D$eax+8
    mov eax edi | jne @DoLoop

@EndLoop:
    pop eax
    comisd XMM0 XMM1
    setne dl
    movzx edx dl
    sub esi eax
    mov eax esi
    sar eax 3
    dec eax

EndP