Hi Jochen.
I´m not sure if the Low Dword values on the table are unique. I´ll take a look at them :t :t :t. But...even if they are unique, how a look up table containing only the low dwords will work better ?
The main routine to calculate those values used in the KFactorMap are computed way before the main converter (RGBtoCieLCH and CieLCHtoRGB) starts. The values are calculated from the gamma and offset related to each monitor/camera/colorspace etc (Adobe1998, Bruce, SMTP etc etc)
; and create our KFactor Map for each color. Put the resultant values on the main Structure to form the table
xor ecx ecx
Do
call FindKFactor ecx, D@pOutStruct
inc ecx
Loop_Until ecx > 255
And the main routine is at:
; RGBtoCieLCH_Ex
Proc FindKFactor:
Arguments @Color, @pMatrix
Structure @TempStorage 64, @pKfactorColorDis 0, @pKFactorWhiteRefXDis 8, @pKFactorWhiteRefYDis 16, @pKFactorWhiteRefZDis 24, @TmpGreenDis 32, @TmpBlueDis 40, @pAFactorDis 48, @pBFactorDis 56
Uses esi, ebx, ecx, edx, edi
finit
lea ecx D@pKfactorColorDis | fild F@Color | fmul R$FloatOne_255 | fstp R$ecx
mov esi D@pMatrix
; Points to the Start of KfactorMap array
mov ebx esi | add ebx WS_Matrix.KFactorMapDis ; Points to the start of the KFactor Map array in WS_Matrix Structure
xor edx edx
mov eax 8;Size_Of_KFactorMap
mul D@Color
add ebx eax
; newColorRed = ((R@Red+0.055)/1.055)^2.4 ; where2.4 = gamma, 0.055 = Offset, 1.055 = Offset+1. Better precalculating them as i did.
lea ecx D@pKfactorColorDis
.Fpu_If R$ecx > R$esi+WS_Matrix.GammaEncode.TresholdDis
fld R$esi+WS_Matrix.GammaEncode.GammaDis | fld R$esi+WS_Matrix.GammaEncode.OffsetDis | fadd R$ecx | fmul R$esi+WS_Matrix.GammaEncode.OffsetPlusDis | fyl2x | fld1 | fld ST1 | fprem | f2xm1 | faddp ST1 ST0 | fscale | fxch | fstp ST0
.Fpu_Else
fld R$ecx | fdiv R$esi+WS_Matrix.GammaEncode.SlopeDis
.Fpu_End_If
fmul R$Float100 | fstp R$ebx;+KFactorMap.ColorDis ; Original i wrote it as KFactorRed, KfactorGreen, KfactorBlue, but, in fact it is only 1 color/pixel to check. So... 256 in total
EndP
These functions are giving me a tremendous headache. I just found out that the threshold must be analysed (On the main convertiopn function CieLCHtoRGB and not the above one;) ) . When i convert colors such as Red = 12, Green = 14, Blue = 0, the resultant vaules after tyhe multiplication of the matrices are below the "WS_Matrix.GammaDecode.Treshold". So i´ll need to try to find a integer value and put that liek another members of the structure i´m using to create the table. Once i found if the threshold can be converted to a integer, it would be eaiser to make the check doing the convertion back after the matrix multiplication.
Something like:
mov eax D$esi+ThresholdInteger
fld R@TmpRedDis | fmul R$esi+WS_Matrix.GammaDecode.SlopeDis | fmul R$Float255 | fistp D@TempColorCheck
If D@TempColorCheck < eax
return D@TempColorCheck ; the color of this pixel was found under the treshold.
Else
; perform check on the loop up table (Binary search, or whatever other method)
EndIf
I hope i can find a way to create a integer related to this threshold. The only problem i see is that we will need extra coding (mul by slope and mul by 255) to pixels that are found in less then 13% of the cases.
A true pain make those functions works correctly and to get things worst, all the papers i read so far are utterly complicated and tends to put different equations to create the very same thing, rather then simply trying to merge those equations together and then try to simplify all of this.
At least i´ve got the function works (well..kind of :icon_mrgreen: :icon_mrgreen:) and the only thing that needs to be done is optimize all of this.
