Thread: Re: [Lcms-user] Unsigned int support?
An ICC-based CMM for color management
Brought to you by:
mm2
From: Bob F. <bfr...@si...> - 2004-09-28 14:45:05
|
On Tue, 28 Sep 2004 ma...@li... wrote: > > Well, is not directly supported by "normal" format specifiers, > but one can easily add support for that by using user-defined > formatters. There is a function, cmsSetUserFormatters() > specifically for doing so. Ok, thanks. I was not aware of that. > But at that point, despite lcms would accept such format, the > precision would remain 16 bit. ICC profiles does not allow > for more resolution, well, CLUT based ones, I mean. So, if the > issue is about reading this particular encoding, user formatters > is all you need. Otherwise lcms cannot handle precision above > 16 bit. Please note that using 32 bit instead of 16 would > double the memory/CPU requeriments for devicelink computation, > and really there is no need for doing so in almost all cases. Right. Passing 32-bit data through a 16-bit algorithm results in 16-bit precision. However, there is no other option if the data available is 32-bit. Does LCMS copy and reformat the pixel data into its own allocated buffers, or does it read/write the user data "in place" without copying to/from buffers in some native representation? Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: <ma...@li...> - 2004-09-28 16:08:36
|
Bob Friesenhahn <bfr...@si...> said: > > Does LCMS copy and reformat the pixel data into its own allocated > buffers, or does it read/write the user data "in place" without > copying to/from buffers in some native representation? Inplace. There is an small overhead doing that in such way, but the memory savings are enormous. For example, an unsigned int formatter for RGB (quick and dirty, just as example): LPBYTE UnrollUINT(register LPCMMCARGO info, register WORD wIn[], register LPBYTE accum) { unsigned int* pixel = (unsigned int*) accum; wIn[0] = (WORD) ((double) (0xFFFFL * pixel[0]) / 0xFFFFFFFFL); wIn[1] = (WORD) ((double) (0xFFFFL * pixel[1]) / 0xFFFFFFFFL); wIn[2] = (WORD) ((double) (0xFFFFL * pixel[2]) / 0xFFFFFFFFL); accum += 3*sizeof(unsigned int) return accum; } The function is called by lcms for each single pixel, with "accum" holding a pointer to the user supplied buffer (that one passed to cmsDoTransform) and have to decode the current pixel to "wIn" as 16-bit values. Then, should return a pointer to the next pixel in buffer. Finally, is just a matter of registering this formatter passing a pointer to this function as argument to cmmSetUserFormatters Regards Marti. |
From: Glenn W. <gw...@pa...> - 2004-10-03 00:26:38
|
Has anybody done any work on using LittleCMS.DLL with C#? Im interested in code snippits showing examples how to use DllImport with Structs and UnmanagedTypes. This would give me a big head start. Glenn Wilton > gw...@pa... < |
From: Bob F. <bfr...@si...> - 2004-10-03 15:32:29
|
On Sun, 3 Oct 2004, Glenn Wilton wrote: > Has anybody done any work on using LittleCMS.DLL with C#? > > Im interested in code snippits showing examples how to use DllImport with > Structs and UnmanagedTypes. This would give me a big head start. I recommend writing a thin object wrapper in Managed C++. C# will work with objects implemented in Managed C++ just fine. .net supports a wide variety of pixel storage types. Code would need to be written to unpack/pack data in those storage types. GDI+ (which .net wraps in binary form) interfaces well with C++. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: <ma...@li...> - 2004-09-28 16:08:48
|
Bob Friesenhahn <bfr...@si...> said: > > Does LCMS copy and reformat the pixel data into its own allocated > buffers, or does it read/write the user data "in place" without > copying to/from buffers in some native representation? Inplace. There is an small overhead doing that in such way, but the memory savings are enormous. For example, an unsigned int formatter for RGB (quick and dirty, just as example): LPBYTE UnrollUINT(register LPCMMCARGO info, register WORD wIn[], register LPBYTE accum) { unsigned int* pixel = (unsigned int*) accum; wIn[0] = (WORD) ((double) (0xFFFFL * pixel[0]) / 0xFFFFFFFFL); wIn[1] = (WORD) ((double) (0xFFFFL * pixel[1]) / 0xFFFFFFFFL); wIn[2] = (WORD) ((double) (0xFFFFL * pixel[2]) / 0xFFFFFFFFL); accum += 3*sizeof(unsigned int) return accum; } The function is called by lcms for each single pixel, with "accum" holding a pointer to the user supplied buffer (that one passed to cmsDoTransform) and have to decode the current pixel to "wIn" as 16-bit values. Then, should return a pointer to the next pixel in buffer. Finally, is just a matter of registering this formatter passing a pointer to this function as argument to cmmSetUserFormatters Regards Marti. |
From: <ma...@li...> - 2004-09-28 16:09:39
|
Bob Friesenhahn <bfr...@si...> said: > > Does LCMS copy and reformat the pixel data into its own allocated > buffers, or does it read/write the user data "in place" without > copying to/from buffers in some native representation? Inplace. There is an small overhead doing that in such way, but the memory savings are enormous. For example, an unsigned int formatter for RGB (quick and dirty, just as example): LPBYTE UnrollUINT(register LPCMMCARGO info, register WORD wIn[], register LPBYTE accum) { unsigned int* pixel = (unsigned int*) accum; wIn[0] = (WORD) ((double) (0xFFFFL * pixel[0]) / 0xFFFFFFFFL); wIn[1] = (WORD) ((double) (0xFFFFL * pixel[1]) / 0xFFFFFFFFL); wIn[2] = (WORD) ((double) (0xFFFFL * pixel[2]) / 0xFFFFFFFFL); accum += 3*sizeof(unsigned int) return accum; } The function is called by lcms for each single pixel, with "accum" holding a pointer to the user supplied buffer (that one passed to cmsDoTransform) and have to decode the current pixel to "wIn" as 16-bit values. Then, should return a pointer to the next pixel in buffer. Finally, is just a matter of registering this formatter passing a pointer to this function as argument to cmmSetUserFormatters Regards Marti. |