C / C++ / MFC

Re: Urgent Help ~!! Convert Lab to RGB [modified]

28-Jan-08 23:57

azusakt wrote:
I have to make a library to convert the Color from Lab value to RGB value. However, I have no much idea on the calculations or algorithms.

But documentation exists http://en.wikipedia.org/wiki/Lab_color_space#Advantages_of_Lab[^].

There is also the very nice Guillaume Leparmentier's article [^] here at CP.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

[my articles]

Mr. Surprise29-Jan-08 7:35

Mr. Surprise

29-Jan-08 7:35

I guess, by using an array structure you can do this. For Example:

<br />
static COLORREF arColors[] = {<br />
RGB(0,255,0),<br />
RGB(0,255,255)<br />
};<br />
<br />
char* arNames[] = {<br />
"green",<br />
"cyan"<br />
};<br />
<br />
for(int i=0; i<2; i++)<br />
{<br />
arColors[i] = i;      // you can try "atof"<br />
arNames[i] = atof(i);<br />
}<br />

modified on Wednesday, January 30, 2008 4:09:09 AM

Re: Urgent Help ~!! Convert Lab to RGB

azusakt29-Jan-08 19:10

azusakt

29-Jan-08 19:10

Thanks for you reply.

Can you provide me a sample code for converting Lab value to RGB value?
I've read some documents, they said the step should
1. convert Lab -> XYZ
2. convert XYZ -> RGB

I don't know how to write such calculations.

Re: Urgent Help ~!! Convert Lab to RGB [modified]

Mr. Surprise29-Jan-08 22:07

Mr. Surprise

29-Jan-08 22:07

This is a constant RGB macros of the COLORREF structure. Anyway, from 0 to 255 numeric values are equivalence a 24-Bit COLORREF's scope. If you want to chance only RGB macros, you can use the
typedef struct tagCOLORREF structure.
Forexample:

<br />
#define XYZ(int i1, int i2, int i3) 0<br />
<br />
int* pNewInt = new int[255];<br />
pNewInt = NULL;<br />
#ifdef COLORREF<br />
for(int i=0; i<255; i++)<br />
{<br />
// I'm not sure just as already it will be defined a XYZ macro.<br />
RGB(pNewInt[i],pNewInt[i],pNewInt[i]) = XYZ(pNewInt[i],pNewInt[i],pNewInt[i]);<br />
}<br />
delete []pNewInt;<br />
#endif

That is must be a defined tagpoint struct what own yourself.

modified on Thursday, January 31, 2008 6:05:14 AM

Storing ptint setup info

g_sandipan28-Jan-08 23:12

g_sandipan

28-Jan-08 23:12

Dear friends,

I am opening the selected printer's document property dialog from my application.
I am using the following code

PRINTER_DEFAULTS PrinterDef = {NULL, NULL, PRINTER_ALL_ACCESS};
HANDLE hPrinter;
PDEVMODEW pDevmode = NULL;
if(OpenPrinter(PRINTER_NAME, &hPrinter, &PrinterDef))
{
int nSize = DocumentProperties(this->m_hWnd, hPrinter,
PRINTER_NAME, NULL, NULL, 0);
pDevmode = (PDEVMODEW)LocalAlloc(LPTR, nSize);
DocumentProperties(this->m_hWnd, hPrinter, PRINTER_NAME,
pDevmode, NULL, DM_IN_PROMPT );
ClosePrinter(hPrinter);
}

Now I want to cature the paper size changes made by the user on document property dialog.
Please Help.

Sandip

Floating point arithmetic

User 345557728-Jan-08 23:12

28-Jan-08 23:12

Check out these two code paths:

float s = 1.0f + pow(2.0f,-8.0f) + pow(2.0f,-18.0f);

float fRes1 = 1024 * s;

float fRes2 = 0.0f;
for(int i=0; i<1024; ++i)
    fRes2 +=s;

now watch the results:
fRes1: 1028.0039
fRes2: 1028.0002

This was tested on Intel Dual-core, VS2005. the direct multiplication was compiled to use fmul, the accumulation was compiled to use fadd. The scalar value s was crafted to know analytically which is the correct result. it is fRes1 (the fmul result).

Can anyone shed some light on the source of the difference??

it can't be (i think) a direct precision issue - all arguments and intermediate values are *exactly* representable in single precision.

any insight would be greatly appreciated!

-Ofek

modified 23-Jan-21 21:03pm.

Maxwell Chen28-Jan-08 23:32

28-Jan-08 23:32

It's of float issue. Using double instead will solve this.

Maxwell Chen

CPallini28-Jan-08 23:36

28-Jan-08 23:36

OfekSH wrote:
it can't be (i think) a direct precision issue

I think the opposite.

OfekSH wrote:
all arguments and intermediate values are *exactly* representable in single precision.

for instance, when executing s*1023 + s sum, you cannot line up the addition arguments without precision loss.

Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

[my articles]

Maxwell Chen28-Jan-08 23:39

28-Jan-08 23:39

I replaced all occurrences of float with double, and removed all the tail f, then the results match.

Maxwell Chen

CPallini28-Jan-08 23:51

28-Jan-08 23:51

Maxwell Chen wrote:
I replaced all occurrences of float with double, and removed all the tail f, then the results match.

Of course, because you're cheating!
Big Grin | :-D

double numbers have a 52 bit mantissa (float have a 23 bit one) and, for instance, OP's s*1023 and s numbers can be comfortably lined up for addition without precision loss.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

[my articles]

User 345557728-Jan-08 23:53

28-Jan-08 23:53

Maxwell - thanks for your reply!

what do you mean by 'results match'? match mine, or match each other?
i already tried going double, and still got different results:

double d = 1.0 + pow(2.0,-8.0) + pow(2.0,-18.0);

double dRes1 = 1024 * d;

double dRes2 = 0.0;
for(int i=0; i<1024; ++i)
    dRes2 +=d;

on my machine gives:
dRes1= 1028.0039062500000
dRes2= 1028.0002441406250

which didn't even budge the difference down.
do you get different results? on what machine/compiler?

modified 23-Jan-21 21:03pm.

Maxwell Chen28-Jan-08 23:57

28-Jan-08 23:57

My result:

dRes1 = 1028.003906250000000
dRes2 = 1028.003906250000000

Visual C++ 2005,
Intel Centrino Core 2 Duo, T2400

Maxwell Chen

User 345557728-Jan-08 23:57

28-Jan-08 23:57

Pallini - thanks, you're right of course, but i suspect there's more to it. going double didn't make any difference (see my post to Maxwell below).

modified 23-Jan-21 21:03pm.

CPallini29-Jan-08 0:13

29-Jan-08 0:13

I tried and got, like Maxwell Chen, the same result (1028.0039062500000) for both dRes1 and dRes2.
I'm using VC++ 2005 on Windows XP.

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

[my articles]

User 345557729-Jan-08 1:46

29-Jan-08 1:46

Sorry for the delay - just returned from lunch. Upon further investigation, the difference is between debug and release builds. Debug build compiles to fpu code:

	//double dRes2 = 0.0;
00C1A579  fldz             
00C1A57B  fstp        qword ptr [ebp-48h] 
	//for(int i=0; i<1024; ++i)
00C1A57E  mov         dword ptr [i],0 
00C1A585  jmp         CurrentFunction+0C0h (0C1A590h) 
00C1A587  mov         eax,dword ptr [i] 
00C1A58A  add         eax,1 
00C1A58D  mov         dword ptr [i],eax 
00C1A590  cmp         dword ptr [i],400h 
00C1A597  jge         CurrentFunction+0D4h (0C1A5A4h) 
	//{
	//	dRes2 +=d;
00C1A599  fld         qword ptr [ebp-48h] 
00C1A59C  fadd        qword ptr [ebp-28h] 
00C1A59F  fstp        qword ptr [ebp-48h] 
	//}
00C1A5A2  jmp         CurrentFunction+0B7h (0C1A587h)

which gives the wrong result, while release builds SSE code (along with loop unrolling):

	//double dRes2 = 0.0;
004CAB82  xorps       xmm1,xmm1 
004CAB85  mov         eax,80h 
004CAB8A  lea         ebx,[ebx] 
	//for(int i=0; i<1024; ++i)
004CAB90  sub         eax,1 
	//{
	//	dRes2 +=d;
004CAB93  addsd       xmm1,xmm0 
004CAB97  addsd       xmm1,xmm0 
004CAB9B  addsd       xmm1,xmm0 
004CAB9F  addsd       xmm1,xmm0 
004CABA3  addsd       xmm1,xmm0 
004CABA7  addsd       xmm1,xmm0 
004CABAB  addsd       xmm1,xmm0 
004CABAF  addsd       xmm1,xmm0 
004CABB3  jne         CurrentFunction+80h (4CAB90h) 
004CABB5  movsd       mmword ptr [esp+38h],xmm1 
	//}

which gives an accurate result.

setting the FPU control word to double or extended double precision solved it - i guess either your FPU control word was already set right, or you tested it in release builds.

thanks for everyone's time!

modified 23-Jan-21 21:03pm.

Maxwell Chen29-Jan-08 4:33

29-Jan-08 4:33

I tested in debug build.

Maxwell Chen

The villain is found!

User 34555776-Feb-08 1:06