lcms-user Mailing List for Little cms color engine (Page 20)
An ICC-based CMM for color management
Brought to you by:
mm2
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(15) |
Jun
(24) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(12) |
Nov
(17) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(34) |
Feb
(7) |
Mar
(7) |
Apr
(16) |
May
(4) |
Jun
(14) |
Jul
(34) |
Aug
(54) |
Sep
(11) |
Oct
(25) |
Nov
(1) |
Dec
(6) |
| 2003 |
Jan
(27) |
Feb
(54) |
Mar
(23) |
Apr
(68) |
May
(82) |
Jun
(36) |
Jul
(45) |
Aug
(45) |
Sep
(49) |
Oct
(30) |
Nov
(65) |
Dec
(23) |
| 2004 |
Jan
(52) |
Feb
(52) |
Mar
(35) |
Apr
(38) |
May
(93) |
Jun
(22) |
Jul
(51) |
Aug
(50) |
Sep
(73) |
Oct
(28) |
Nov
(30) |
Dec
(51) |
| 2005 |
Jan
(22) |
Feb
(79) |
Mar
(38) |
Apr
(51) |
May
(95) |
Jun
(60) |
Jul
(56) |
Aug
(49) |
Sep
(22) |
Oct
(43) |
Nov
(15) |
Dec
(40) |
| 2006 |
Jan
(51) |
Feb
(31) |
Mar
(37) |
Apr
(25) |
May
(9) |
Jun
(13) |
Jul
(17) |
Aug
(66) |
Sep
(7) |
Oct
(12) |
Nov
(14) |
Dec
(31) |
| 2007 |
Jan
(18) |
Feb
(9) |
Mar
(22) |
Apr
(18) |
May
(5) |
Jun
(25) |
Jul
(2) |
Aug
(15) |
Sep
(12) |
Oct
(40) |
Nov
(10) |
Dec
(23) |
| 2008 |
Jan
(21) |
Feb
(56) |
Mar
(12) |
Apr
(23) |
May
(47) |
Jun
(75) |
Jul
(24) |
Aug
(2) |
Sep
(7) |
Oct
(26) |
Nov
(20) |
Dec
(16) |
| 2009 |
Jan
(14) |
Feb
(1) |
Mar
(29) |
Apr
(54) |
May
(18) |
Jun
(16) |
Jul
(5) |
Aug
(3) |
Sep
(38) |
Oct
(6) |
Nov
(25) |
Dec
(28) |
| 2010 |
Jan
(11) |
Feb
(26) |
Mar
(2) |
Apr
(10) |
May
(45) |
Jun
(94) |
Jul
(11) |
Aug
(32) |
Sep
(18) |
Oct
(37) |
Nov
(19) |
Dec
(34) |
| 2011 |
Jan
(21) |
Feb
(16) |
Mar
(16) |
Apr
(29) |
May
(17) |
Jun
(18) |
Jul
(7) |
Aug
(21) |
Sep
(10) |
Oct
(7) |
Nov
(15) |
Dec
(6) |
| 2012 |
Jan
(13) |
Feb
(16) |
Mar
(15) |
Apr
(12) |
May
(15) |
Jun
(31) |
Jul
(22) |
Aug
(15) |
Sep
(46) |
Oct
(21) |
Nov
(15) |
Dec
(33) |
| 2013 |
Jan
(19) |
Feb
(17) |
Mar
(31) |
Apr
(17) |
May
(27) |
Jun
(24) |
Jul
(26) |
Aug
(11) |
Sep
(9) |
Oct
(22) |
Nov
(14) |
Dec
(16) |
| 2014 |
Jan
(20) |
Feb
(66) |
Mar
(29) |
Apr
(13) |
May
(9) |
Jun
|
Jul
(11) |
Aug
(21) |
Sep
(15) |
Oct
(5) |
Nov
(5) |
Dec
(10) |
| 2015 |
Jan
(6) |
Feb
(26) |
Mar
(26) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(5) |
Aug
(11) |
Sep
(8) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(9) |
Apr
(3) |
May
(16) |
Jun
(26) |
Jul
(32) |
Aug
(27) |
Sep
(9) |
Oct
|
Nov
(4) |
Dec
(10) |
| 2017 |
Jan
(11) |
Feb
(44) |
Mar
(6) |
Apr
(8) |
May
(1) |
Jun
(2) |
Jul
(34) |
Aug
(28) |
Sep
(3) |
Oct
(9) |
Nov
(3) |
Dec
|
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(6) |
Dec
|
| 2019 |
Jan
(18) |
Feb
(16) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(3) |
Oct
(10) |
Nov
(1) |
Dec
(3) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(17) |
Jun
(23) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(10) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(1) |
Dec
|
| 2022 |
Jan
(8) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(13) |
Nov
(12) |
Dec
|
| 2023 |
Jan
|
Feb
(1) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(5) |
Jul
(3) |
Aug
(8) |
Sep
|
Oct
|
Nov
(1) |
Dec
(9) |
| 2024 |
Jan
(8) |
Feb
|
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Roger B. <gr...@vi...> - 2016-07-10 21:42:38
|
Looks like I'm becoming a "regular contributor" to this list...
I don't find it easy to figure out C# signature for all the lcms C
functions...
The original C function looks like this :
cmsUInt32Number cmsGetProfileInfo(
cmsHPROFILE hProfile,
cmsInfoType Info,
const char LanguageCode[3],
const char CountryCode[3],
wchar_t* Buffer,
cmsUInt32Number BufferSize);
The "best" DLLImport I could come up with, in C# is this :
[DllImport(@lcms2Path, CharSet = CharSet.Unicode)]
public extern static UInt32 cmsGetProfileInfo(
IntPtr hProfile,
int InfoType,
[MarshalAs(UnmanagedType.BStr)]string languageCode, //
UnmanagedType.BStr = A COM-style BSTR with a prefixed length and Unicode
characters.
[MarshalAs(UnmanagedType.BStr)]string countryCode,
[Out, MarshalAsAttribute(UnmanagedType.LPWStr)]
StringBuilder buffer,
UInt32 bufferSize);
And, in code, I call the function like this :
StringBuilder Buffer = new StringBuilder(255);
UInt32 Buffer=0;
UInt32 descSize;
descSize = cmsGetProfileInfo(hSource, 0, "en", "US", Buffer, 0);
When I execute the function, descSize = 0 and Buffer is empty...
----
I also tried this Import statement :
[DllImport(@lcms2Path, CharSet = CharSet.Unicode)]
public extern static UInt32 cmsGetProfileInfo(
IntPtr hProfile,
[In] int InfoType,
[In] string languageCode, // UnmanagedType.BStr = A
COM-style BSTR with a prefixed length and Unicode characters.
[In] string countryCode,
[Out] StringBuilder buffer,
[Out] UInt32 bufferSize);
But don't get any better?
For curiosity, I also tried the following in C :
wchar_t* Buffer;
cmsUInt32Number BufferSize, DescSize;
BufferSize = 0;
Buffer = NULL;
cmsInfoType Info;
Info = cmsInfoDescription;
DescSize = cmsGetProfileInfo(rgbProfile, Info, "en", "US", Buffer,
BufferSize);
When I execute the function, DescSize = 20 but Buffer is null and BufferSize
= 0.
/ Roger
|
|
From: Roger B. <gr...@vi...> - 2016-07-10 17:10:46
|
LittleCMS2.6 API.pdf page 83 states : void cmsDoTransform(cmsHTRANSFORM hTransform, const void * InputBuffer, void * OutputBuffer, cmsUInt32Number Size); hTransform: Handle to a color transform object. InputBuffer: A pointer to the input bitmap OutputBuffer: A pointer to the output bitmap. Size: the number of PIXELS to be transformed. First Example ---------------------------------------------------------------------------- -------------------- RGB Image is 4 pixels wide by 4 pixels high (3 bytes/pixels). Do I encode 16 pixels x 3 bytes/pixels = 48 as Size? The size of the byte array is 48, yes, but there are only 16 pixels to process : Byte[] Input = new byte[48]; Byte[] Output = new byte[48]; UInt32 pixels = 16; cmsDoTransform(xform, Input, Output, pixels); OK, this works. Second Example ---------------------------------------------------------------------------- -------------------- RGB Image is 512 pixels wide by 512 pixels high (3 bytes/pixels). Do I encode 262144 pixels x 3 bytes/pixels = 786432 as Size? The size of the byte array is 786432, no choice, but there are only 262144 pixels to process : Byte[] Input = new byte[786432]; Byte[] Output = new byte[786432]; UInt32 pixels = 262144; cmsDoTransform(xform, Input, Output, pixels); No, this does NOT work, MemoryAccessViolations? Oops!!! I think I understand what my error is : Input is RGB but Output is *CMYK* (in my code), so I need to allocate 4 bytes for each pixel on the output buffer!!!!! Byte[] Input = new byte[786432]; Byte[] Output = new byte[1048576]; UInt32 pixels = 262144; cmsDoTransform(xform, Input, Output, pixels); This is working!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Thank you Christian and Noel -- I owe you each 12 beers and a pizza, if ever you pass by Montreal ;-) Marti Maria, please consider add a small example in the future to the API documentation? // Roger ------------------------------ Message: 5 Date: Sun, 10 Jul 2016 09:15:36 +0200 From: Christian Schmitz <rea...@mo...> Subject: Re: [Lcms-user] Upper limit cmsDoTransform To: lcm...@li... Message-ID: <F47...@mo...> Content-Type: text/plain; charset=us-ascii > Am 10.07.2016 um 02:18 schrieb Roger Breton <gr...@vi...>: > > The following code works : > > Byte[] Input1 = new byte[6500]; > Byte[] Output1 = new byte[6500]; > UInt32 pixels = 6500; Are you sure it'S not 6500 * 4 bytes for 6500 pixels? Or * 3 for RGB? Sincerely Christian -- Read our blog about news on our plugins: http://www.mbsplugins.de/ |
|
From: Christian S. <rea...@mo...> - 2016-07-10 07:15:45
|
> Am 10.07.2016 um 02:18 schrieb Roger Breton <gr...@vi...>: > > The following code works : > > Byte[] Input1 = new byte[6500]; > Byte[] Output1 = new byte[6500]; > UInt32 pixels = 6500; Are you sure it'S not 6500 * 4 bytes for 6500 pixels? Or * 3 for RGB? Sincerely Christian -- Read our blog about news on our plugins: http://www.mbsplugins.de/ |
|
From: Noel C. <NCa...@Pr...> - 2016-07-10 00:44:03
|
Do you have 1 byte per pixel?
Not likely. More like 4, right? Now think about your allocation
numbers...
-Noel
-----Original Message-----
From: Roger Breton [mailto:gr...@vi...]
Sent: Sat, July 9, 2016 8:18 PM
To: lcm...@li...
Subject: [Lcms-user] Upper limit cmsDoTransform
The following code works :
Byte[] Input1 = new byte[6500];
Byte[] Output1 = new byte[6500];
UInt32 pixels = 6500;
cmsDoTransform(xform, Input1, Output1, pixels);
But anything above 6500 pixels resulted in MemoryAccessViolations.
I can't possibly have to break an image down into 6500 bytes chunks, in
order to process its color?
There has to be a better way?
/ Roger
------------------------------------------------------------------------
------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user
|
|
From: Roger B. <gr...@vi...> - 2016-07-10 00:18:37
|
The following code works :
Byte[] Input1 = new byte[6500];
Byte[] Output1 = new byte[6500];
UInt32 pixels = 6500;
cmsDoTransform(xform, Input1, Output1, pixels);
But anything above 6500 pixels resulted in MemoryAccessViolations.
I can't possibly have to break an image down into 6500 bytes chunks, in
order to process its color?
There has to be a better way?
/ Roger
|
|
From: Roger B. <gr...@vi...> - 2016-07-09 21:24:35
|
All along, earlier this week, I was fighting a MemoryAccessViolation at the time of calling cmsDoTransform(HANDLE, InputBuffer, OutputBuffer, Size). Then I started experimenting with very small images, like 1 pixel wide x 1 pixel high. All of a sudden, the MemoryAccessViolation was gone! So I used larger and larger image sizes, 4x4, 16x16, 64x64 -- everything was working. So I went back to my original RGB test image, 864 pixels wide x 288 pixels high, and BANG!, that MemoryAccessViolation again? So I decreased the image size down progressively : 1 - 288 x 288 -> didn't work? 2 - 256 x 256 -> didn't work? 3 - 128 x 128 -> Victory!!! The image size is 48 kilobytes, thus passing 49,512 bytes in memory to cmsDoTransform. Maybe there is a buffer size built-in "upper limit" that can be managed by .NET? I hate to have to break the image in chunks... Best / Roger |
|
From: Roger B. <gr...@vi...> - 2016-07-09 17:05:13
|
This Import statement :
[DllImport(@lcms2Path)]
public static extern void cmsDoTransform(
[In] IntPtr xform,
[In] byte[] InputBuffer,
[Out] byte[] OutputBuffer,
[In] UInt32 Size);
Und this function call :
Byte[] Input = new byte[X];
Byte[] Output = new byte[X];
pixels = X;
cmsDoTransform(xform, Input, Output, pixels);
work!!!!!!!!!
I tested X = 1024 and it still works -- arbeiten.
For some reason, this code was not working before :
Byte[] inputBitmapData = new Byte[stride * myBitmapFrame.PixelHeight];
myBitmapFrame.CopyPixels(inputBitmapData, stride, 0);
Byte[] outputBitmapData = inputBitmapData.Clone() as Byte[];
What ist important is that ich bin making progress!!!
Danke shön, Edgar
/ Roger
|
|
From: Roger B. <gr...@vi...> - 2016-07-08 19:03:34
|
I am still having difficulty with calling cmsDoTransform with
variable-length arrays of bytes.
I always get MemoryAccessViolations errors.
Today's preliminary testing suggest I would have better luck using fixed
size arrays.
What will happen if I break down my bitmap image in fixed size chunks?
Suppose image size = 104 bytes
Suppose I chose Fixed array size = 64 bytes
My new C# pinvoke function signature would look like this :
[DllImport(@lcms2Path, CallingConvention = CallingConvention.Winapi)]
static extern void cmsDoTransform(
IntPtr xform,
[MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 64), In]
byte[] inputColors,
[MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 64), Out]
byte[] outputColors,
uint Size);
Then, I will iterate cmsDoTransform 2x with 64 bytes each.
Upon return, it will be up to my code to throw away the remainder 2 x 64 =
128 - 104 -> 24 bytes.
I guess I will have to pad these extra 24 bytes with 00.
But, would this work?
At least, this approach has the merit of avoiding MemoryAccessViolations.
Best / Roger
|
|
From: Roger B. <gr...@vi...> - 2016-07-08 13:21:27
|
Project > Selected Target Framework = 4.5.1 ------------------------------ You have to look at the project settings in Visual Studio: Project>Properties>Application>Target Framework: Here you have to select at least .NET 4 Edgar |
|
From: Roger B. <gr...@vi...> - 2016-07-07 21:28:35
|
I give up, I can't figure out this Access violation. I just don't have the programming smarts to succeed at calling this function from C# to transform images. Thank's for your help and patience. I'll try my luck with some other library. MfG / Roger -----Original Message----- From: lcm...@li... [mailto:lcm...@li...] Sent: Saturday, July 2, 2016 8:01 AM To: lcm...@li... Subject: Lcms-user Digest, Vol 110, Issue 2 Send Lcms-user mailing list submissions to lcm...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/lcms-user or, via email, send a message with subject or body 'help' to lcm...@li... --------------------------------- On the one hand you can have several declarations/imports of cmsDoTransform e.g.: public static class NativeMethods { [DllImport("lcms2.dll")] public static extern void cmsDoTransform( [In] IntPtr Transform, [In] byte[] InputBuffer, [Out] byte[] OutputBuffer, [In] UInt32 Size); [DllImport("lcms2.dll")] public static extern void cmsDoTransform( [In] IntPtr Transform, [In] ushort[] InputBuffer, [Out] ushort[] OutputBuffer, [In] UInt32 Size); [DllImport("lcms2.dll")] public static extern void cmsDoTransform( [In] IntPtr Transform, [In] double[] InputBuffer, [Out] double[] OutputBuffer, [In] UInt32 Size); } |
|
From: Edgar L. <lo...@co...> - 2016-07-07 15:55:42
|
You have to look at the project settings in Visual Studio: Project>Properties>Application>Target Framework: Here you have to select at least .NET 4 Edgar Am 07.07.2016 um 16:57 schrieb Roger Breton: >> Perhaps I should have mentioned that you need at least .Net 4 In 3.5 it's > available but does not work... > > According to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP I > have Version 4 but it's worth updating to a newer version... > >> > https://social.msdn.microsoft.com/Forums/en-US/be7ad7d6-972f-4a39-ae90-55660 > d66c561/iccprofildaten-via-colorcontext?forum=wpfde) > > Danke shön für der Microsoft Forum link -- ich sprache nicht viele deutche > aber I will try to read/translate as best I can. > > ------------ > > I used your DLLimport declaration and suggested code aber, yetz, ich bin > haben "Memory violation" problem. > Das ist meine humble C# code : > > [DllImport(@lcms2Path, CallingConvention = CallingConvention.Winapi)] > public static extern void cmsDoTransform( > [In] IntPtr Transform, > [In] byte[] InputBuffer, > [Out] byte[] OutputBuffer, > [In] UInt32 Size); > > IntPtr hSource = > cmsOpenProfileFromFile("C:\\Windows\\System32\\spool\\drivers\\color\\AppleR > GB.icc", "r"); > IntPtr hDestination = > cmsOpenProfileFromFile("C:\\Windows\\System32\\spool\\drivers\\color\\Coated > GRACoL2006.icc", "r"); > > IntPtr Transform = cmsCreateTransform(hSRGB, TYPE_BGR_8, hDestination, > TYPE_CMYK_8, INTENT_RELATIVE_COLORIMETRIC, 0); > > PixelFormat inputFormat = myBitmapFrame.Format; > > // copy image data to byte[] > int stride = myBitmapFrame.PixelWidth * inputFormat.BitsPerPixel / 8; > Byte[] inputBitmapData = new Byte[stride * myBitmapFrame.PixelHeight]; > > myBitmapFrame.CopyPixels(inputBitmapData, stride, 0); > > Byte[] outputBitmapData = inputBitmapData.Clone() as Byte[]; > > cmsDoTransform(xform, inputBitmapData, outputBitmapData, > (uint)(myBitmapFrame.PixelWidth * myBitmapFrame.PixelHeight)); > > ---------------- > > The error occurs on this last line of code: > > System.AccessViolationException > Attempted to read or write protected memory. > > The error does not point to which element to cmsDoTransform that is causing > the AccessViolation? > > The inputBitmapData is a pointer. > So is the outputBitmapdata. > > I will continue searching for more details.... > > MfG / Roger > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > -- lakeBits Inh. Edgar Loser Haydnstr. 25 78464 Konstanz Tel 0049 7531 5844154 0 Fax 0049 7531 5844154 9 http://www.colymp.com/ mailto:lo...@co... |
|
From: Roger B. <gr...@vi...> - 2016-07-07 14:57:40
|
> Perhaps I should have mentioned that you need at least .Net 4 In 3.5 it's available but does not work... According to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP I have Version 4 but it's worth updating to a newer version... > https://social.msdn.microsoft.com/Forums/en-US/be7ad7d6-972f-4a39-ae90-55660 d66c561/iccprofildaten-via-colorcontext?forum=wpfde) Danke shön für der Microsoft Forum link -- ich sprache nicht viele deutche aber I will try to read/translate as best I can. ------------ I used your DLLimport declaration and suggested code aber, yetz, ich bin haben "Memory violation" problem. Das ist meine humble C# code : [DllImport(@lcms2Path, CallingConvention = CallingConvention.Winapi)] public static extern void cmsDoTransform( [In] IntPtr Transform, [In] byte[] InputBuffer, [Out] byte[] OutputBuffer, [In] UInt32 Size); IntPtr hSource = cmsOpenProfileFromFile("C:\\Windows\\System32\\spool\\drivers\\color\\AppleR GB.icc", "r"); IntPtr hDestination = cmsOpenProfileFromFile("C:\\Windows\\System32\\spool\\drivers\\color\\Coated GRACoL2006.icc", "r"); IntPtr Transform = cmsCreateTransform(hSRGB, TYPE_BGR_8, hDestination, TYPE_CMYK_8, INTENT_RELATIVE_COLORIMETRIC, 0); PixelFormat inputFormat = myBitmapFrame.Format; // copy image data to byte[] int stride = myBitmapFrame.PixelWidth * inputFormat.BitsPerPixel / 8; Byte[] inputBitmapData = new Byte[stride * myBitmapFrame.PixelHeight]; myBitmapFrame.CopyPixels(inputBitmapData, stride, 0); Byte[] outputBitmapData = inputBitmapData.Clone() as Byte[]; cmsDoTransform(xform, inputBitmapData, outputBitmapData, (uint)(myBitmapFrame.PixelWidth * myBitmapFrame.PixelHeight)); ---------------- The error occurs on this last line of code: System.AccessViolationException Attempted to read or write protected memory. The error does not point to which element to cmsDoTransform that is causing the AccessViolation? The inputBitmapData is a pointer. So is the outputBitmapdata. I will continue searching for more details.... MfG / Roger |
|
From: Edgar L. <lo...@co...> - 2016-07-07 11:23:53
|
> Does this code actually work for you? Yes is does. Perhaps I should have mentioned that you need at least .Net 4 In 3.5 it's available but does not work... (s. https://social.msdn.microsoft.com/Forums/en-US/be7ad7d6-972f-4a39-ae90-55660d66c561/iccprofildaten-via-colorcontext?forum=wpfde) The second thing that might cause some trouble: some jpeg (of digicams) do not really contain an icc profile, they are just tagged (in exif) to be SRGB or AdobeRGB. E.g. if exif:InteroperabilityIndex contains R03 it's an AdobeRGB image, s http://regex.info/blog/photo-tech/color-spaces-page7 But! I just checked my AdobeRGB images taken with my Nikon or my Canon, and in every case ColorContext did work... > Where does the "StreamToArray" method comes from? The StreamToArray is a simple helper method (I forgot to cite) e.g.: public static Byte[] StreamToArray(Stream input) { if (input is MemoryStream) { return (input as MemoryStream).ToArray(); } else { using (MemoryStream ms = new MemoryStream()) { input.CopyTo(ms); return ms.ToArray(); } } } Edgar > > First of all, when creating a BitmapFrame with PreservePixelFormats the > ColorContext is *always* nill!!! > It does not work for me, with the JPEG files I tried. > > I would *love* for the ColorContext to come across as I would be able to > create an ICC profile from memory, the way to do it. > It is perfect! Except, it does not work. > > In all my testing, so far, I have NOT been able to retrieve a ColorContext > (embedded ICC profile) from a JPEG image. > > Second question... > > > Best / Roger > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > -- lakeBits Inh. Edgar Loser Haydnstr. 25 78464 Konstanz Tel 0049 7531 5844154 0 Fax 0049 7531 5844154 9 http://www.colymp.com/ mailto:lo...@co... |
|
From: Roger B. <gr...@vi...> - 2016-07-06 23:58:08
|
Edgar,
You wrote :
> // create lcms inputprofile
> IntPtr inputProfileH = IntPtr.Zero;
>I f (biFrm.ColorContexts != null) {
> byte[] inputProfile =
> StreamToArray(biFrm.ColorContexts[0].OpenProfileStream());
> inputProfileH =
> Basic.Lcms.NativeMethods.cmsOpenProfileFromMem(inputProfile,
> (uint)inputProfile.Length);
Does this code actually work for you?
First of all, when creating a BitmapFrame with PreservePixelFormats the
ColorContext is *always* nill!!!
It does not work for me, with the JPEG files I tried.
I would *love* for the ColorContext to come across as I would be able to
create an ICC profile from memory, the way to do it.
It is perfect! Except, it does not work.
In all my testing, so far, I have NOT been able to retrieve a ColorContext
(embedded ICC profile) from a JPEG image.
Second question...
Where does the "StreamToArray" method comes from?
Best / Roger
|
|
From: Roger B. <gr...@vi...> - 2016-07-03 13:43:17
|
I want you to know that I found a nu-get package for C# designed to extract metadata, including ICC profiles, out of JPEG, TIF, BMP. PNG and a host of other images. https://drewnoakes.com/code/exif/ It's very interesting... Here is a sample of an ICC profile metadata extracted from an RGB JPEG image : [10] "JPEG Component 1 Unknown (0) component: Quantization table 0, Sampling factors 2 horiz/2 vert" object {string} [11] "JPEG Component 2 Y component: Quantization table 1, Sampling factors 1 horiz/1 vert" object {string} [12] "JPEG Component 3 Cb component: Quantization table 1, Sampling factors 1 horiz/1 vert" object {string} [13] "JpegComment JPEG Comment *\0" object {string} [14] "JFIF Version 1.2" object {string} [15] "JFIF Resolution Units none" object {string} [16] "JFIF X Resolution 1 dot" object {string} [17] "JFIF Y Resolution 1 dot" object {string} [18] "JFIF Thumbnail Width Pixels 0" object {string} [19] "JFIF Thumbnail Height Pixels 0" object {string} [20] "ICC Profile Profile Size 3048" object {string} [21] "ICC Profile Version 2.0.0" object {string} [22] "ICC Profile Class Display Device" object {string} [23] "ICC Profile Color space RGB " object {string} [24] "ICC Profile Profile Connection Space XYZ " object {string} [25] "ICC Profile Profile Date/Time 2009:03:27 21:36:31" object {string} [26] "ICC Profile Signature acsp" object {string} [27] "ICC Profile Device attributes 4294967296" object {string} [28] "ICC Profile XYZ values 0.964 1 0.825" object {string} [29] "ICC Profile Tag Count 16" object {string} [30] "ICC Profile Profile Description sRGB IEC61966-2-1 black scaled" object {string} [31] "ICC Profile Blue Colorant (0.1431, 0.0606, 0.7141)" object {string} [32] "ICC Profile Blue TRC 0.0, 0.0000763, 0.0001526, ... snip ... 0.9955596, 0.9977722, 1.0" object {string} [33] "ICC Profile Device Model Description IEC 61966-2-1 Default RGB Colour Space - sRGB" object {string} [34] "ICC Profile Green Colorant (0.3851, 0.7169, 0.0971)" object {string} [35] "ICC Profile Green TRC 0.0, 0.0000763, 0.0001526 ... snip ... 0.9933471, 0.9955596, 0.9977722, 1.0" object {string} [36] "ICC Profile Luminance (0, 80, 0)" object {string} [37] "ICC Profile Measurement 1931 2° Observer, Backing (0, 0, 0), Geometry Unknown, Flare 0%, Illuminant D65" object {string} [38] "ICC Profile Media Black Point (0.0121, 0.0125, 0.0103)" object {string} [39] "ICC Profile Red Colorant (0.4361, 0.2225, 0.0139)" object {string} [40] "ICC Profile Red TRC 0.0, 0.0000763, 0.0001526, ... snip ... 0.9933471, 0.9955596, 0.9977722, 1.0" object {string} [41] "ICC Profile Technology CRT " object {string} Next question is how can I use this data to create an ICC profile that I pass to LittleCMS? There is cmsOpenProfileFromMem but I am sure it's going to take me a while to figure the correct memory structure. I could use cmsCreateRGBProfile to create a matrix/shaper profile from the extracted data? Which is what the embedded profile in this JPEG was all about. My goal, in my application, is to determine whether the open image in Windows WPF *has* an embedded profile and if that is the case, to use the embedded profile to convert color to the monitor's profile. / Roger |
|
From: Roger B. <gr...@vi...> - 2016-07-01 14:09:14
|
Edgar,
I am surprised (und pleased!) that the compiler accepts multiple functions
with similar declarations -- only the arguments change.
So the run-time is smart enough to use the 'correct' function call, given
the parameter type?
Wow!
MfG / Roger
---------------------------------
On the one hand you can have several declarations/imports of cmsDoTransform
e.g.:
public static class NativeMethods {
[DllImport("lcms2.dll")]
public static extern void cmsDoTransform(
[In] IntPtr Transform,
[In] byte[] InputBuffer,
[Out] byte[] OutputBuffer,
[In] UInt32 Size);
[DllImport("lcms2.dll")]
public static extern void cmsDoTransform(
[In] IntPtr Transform,
[In] ushort[] InputBuffer,
[Out] ushort[] OutputBuffer,
[In] UInt32 Size);
[DllImport("lcms2.dll")]
public static extern void cmsDoTransform(
[In] IntPtr Transform,
[In] double[] InputBuffer,
[Out] double[] OutputBuffer,
[In] UInt32 Size);
}
|
|
From: Edgar L. <lo...@co...> - 2016-06-30 15:57:18
|
On the one hand you can have several declarations/imports of
cmsDoTransform e.g.:
public static class NativeMethods {
[DllImport("lcms2.dll")]
public static extern void cmsDoTransform(
[In] IntPtr Transform,
[In] byte[] InputBuffer,
[Out] byte[] OutputBuffer,
[In] UInt32 Size);
[DllImport("lcms2.dll")]
public static extern void cmsDoTransform(
[In] IntPtr Transform,
[In] ushort[] InputBuffer,
[Out] ushort[] OutputBuffer,
[In] UInt32 Size);
[DllImport("lcms2.dll")]
public static extern void cmsDoTransform(
[In] IntPtr Transform,
[In] double[] InputBuffer,
[Out] double[] OutputBuffer,
[In] UInt32 Size);
}
on the other hand you could just use the version with byte[]:
In this case you would have to "marshal" your float/double/short data to
byte[] yourself.
If you have some e.g. double data somewhere in a stream, file, blob, and
c# is passing
this binary data as byte[] to you, you can use this version.
Of course you can also take a "simple" declaration with IntPtr and do some
System.Runtime.InteropServices.Marshal.PtrToStructure(),
.StructureToPtr(), .Copy()...
before and after calling cmsDoTransform.
I prefer the first/second way
Edgar
Am 30.06.2016 um 16:41 schrieb Roger Breton:
> Edgar,
>
> Thank YOU so much!!!!
>
> One question...
>
> In the following code :
>
> public static class NativeMethods {
> [DllImport("lcms2.dll")]
> public static extern void cmsDoTransform(
> [In] IntPtr Transform,
> [In] byte[] InputBuffer,
> [Out] byte[] OutputBuffer,
> [In] UInt32 Size);
> }
>
> Why (warum) do you pass a pointer to a byte array (byte[])?
>
> (I understand image pixel data = bytes)
>
> I am no C# specialist BUT that makes the function "less universal" than if
> you were to pass a straight, basic 'IntPtr'?
>
> The reason I ask is, are you not limited to the type of data you can pass
> cmsDoTransform then?
>
> In my original pinvoke declaration, I use pointers to 'double[]' arrays :
> this will not work (arbeit) with your 'byte[]' declaration anymore?
>
> I was thinking of, perhaps, the solution is create a second class to host
> your cmsDoTransform function call and continue using my first cmsDoTransform
> to process individual 'double[]' data type.
>
> Is that what you do?
>
> MfG / Kindest regards,
>
> / Roger Breton
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
--
lakeBits Inh. Edgar Loser
Haydnstr. 25
78464 Konstanz
Tel 0049 7531 5844154 0
Fax 0049 7531 5844154 9
http://www.colymp.com/
mailto:lo...@co...
|
|
From: Roger B. <gr...@vi...> - 2016-06-30 14:57:11
|
Edgar,
Thank YOU so much!!!!
One question...
In the following code :
public static class NativeMethods {
[DllImport("lcms2.dll")]
public static extern void cmsDoTransform(
[In] IntPtr Transform,
[In] byte[] InputBuffer,
[Out] byte[] OutputBuffer,
[In] UInt32 Size);
}
Why (warum) do you pass a pointer to a byte array (byte[])?
(I understand image pixel data = bytes)
I am no C# specialist BUT that makes the function "less universal" than if
you were to pass a straight, basic 'IntPtr'?
The reason I ask is, are you not limited to the type of data you can pass
cmsDoTransform then?
In my original pinvoke declaration, I use pointers to 'double[]' arrays :
this will not work (arbeit) with your 'byte[]' declaration anymore?
I was thinking of, perhaps, the solution is create a second class to host
your cmsDoTransform function call and continue using my first cmsDoTransform
to process individual 'double[]' data type.
Is that what you do?
MfG / Kindest regards,
/ Roger Breton
|
|
From: Edgar L. <lo...@co...> - 2016-06-30 08:16:37
|
> If I could develop my application strictly in C, my problems accessing > LittleCMS would be non-existent, > but I need to develop in C# :( Working with C# is not too bad! >[...] > cmsDoTransform(cmsHTRANSFORM Transform, const void * InputBuffer, > void * OutputBuffer, > cmsUInt32Number Size); > > (Not sure what the 'const' keyword in front of the first void * statement > does?) By writing 'const' Marti is telling us, that cmsDoTransform will not touch the data in InputBuffer. I.e. we can either pass a const void* or we can pass a void*. If he would had omit to write 'const' and we would have just a const void* inputBuffer we could not pass this pointer to cmsDoTransform (compiler error)... (s. http://stackoverflow.com/questions/4064286/c-const-keyword-explanation) > [DllImport(lcms2Path, CallingConvention = CallingConvention.Winapi)] > static extern void cmsDoTransform(IntPtr xform, IntPtr inputColors [in], > IntPtr outputColors [out], uint Size); > > So my question becomes how do I pass pointers to the these buffers in my new > declaration? > I read somewhere about the need to use the keyword 'unsafe' but I am not > sure. > Also read about the need to use the attributes [in] and [out] in marshalling > the data. > (The Marshalling of data is a HUGE topic in itself as I found out through my > hours of reading online) > > Ultimately, my goal is is to convert JPEG or TIFF images from one color > space to another through LittleCMS. It's not that difficult... Here is what I'm using (somehow stripped, without error handling, without cleanup...) public static class NativeMethods { [DllImport("lcms2.dll")] public static extern void cmsDoTransform( [In] IntPtr Transform, [In] byte[] InputBuffer, [Out] byte[] OutputBuffer, [In] UInt32 Size); } // We use WPF classes to read binary data of the images: // Namespace: System.Windows.Media.Imaging // Assembly: PresentationCore (in PresentationCore.dll) BitmapDecoder biDec = BitmapDecoder.Create(.....) BitmapFrame biFrm = biDec.Frames[0]; PixelFormat inputFormat = biFrm.Format; uint lcmsInputFormat = 0; FormatConvertedBitmap fcb = null; // if we have an input format that we cannot use direktly in lcms // we have to create a temporary bitmap with lcms compatible format and use this instead of biFrm if (inputFormat == PixelFormats.Bgra32) { lcmsInputFormat = 0x44499; // Lcms.Format.TYPE_BGRA_8; } else if (inputFormat == PixelFormats.Bgr24) { lcmsInputFormat = 0x40419; // Lcms.Format.TYPE_BGR_8; } else { inputFormat = PixelFormats.Bgra32; // we enforce Bgra32 format lcmsInputFormat = 0x44499; // Lcms.Format.TYPE_BGRA_8; fcb = new FormatConvertedBitmap(biFrm, inputFormat, null, 0); if (fcb == null) { throw new Exception("Unable to create FormatConvertedBitmap"); } } // create lcms inputprofile IntPtr inputProfileH = IntPtr.Zero; if (biFrm.ColorContexts != null) { byte[] inputProfile = StreamToArray(biFrm.ColorContexts[0].OpenProfileStream()); inputProfileH = Basic.Lcms.NativeMethods.cmsOpenProfileFromMem(inputProfile, (uint)inputProfile.Length); } else { inputProfileH = Basic.Lcms.NativeMethods.cmsCreate_sRGBProfile(); } IntPtr outputProfileH = .....; // create your lcms output profile IntPtr lcmsTrafo = NativeMethods.cmsCreateTransform( inputProfileH , lcmsInputFormat , outputProfileH , lcmsInputFormat // output format = input format , YourRenderingIntent , 0); // copy image data to byte[] int stride = biFrm.PixelWidth * inputFormat.BitsPerPixel / 8; Byte[] inputBitmapData = new Byte[stride * biFrm.PixelHeight]; if (fcb == null) { // we copy pixel data from original image biFrm.CopyPixels(inputBitmapData, stride, 0); } else { // we copy pixel data from format converted bitmap fcb.CopyPixels(inputBitmapData, stride, 0); } // I have to copy the whole data, to get a copy of alpha channel (lcms 2.7) Byte[] outputBitmapData = inputBitmapData.Clone() as Byte[]; NativeMethods.cmsDoTransform(lcmsTrafo, inputBitmapData, outputBitmapData, (uint)(biFrm.PixelWidth * biFrm.PixelHeight)); // create a new image, based on outputBitmapData: BitmapSource ccb = BitmapSource.Create( biFrm.PixelWidth, biFrm.PixelHeight , biFrm.DpiX, biFrm.DpiY , inputFormat , null , outputBitmapData , stride); // create e.g. .png file: BitmapEncoder biEnc = new PngBitmapEncoder(); biEnc.Frames.Add(BitmapFrame.Create(ccb)); biEnc.Save(YourOutputStream); -- lakeBits Inh. Edgar Loser Haydnstr. 25 78464 Konstanz Tel 0049 7531 5844154 0 Fax 0049 7531 5844154 9 http://www.colymp.com/ mailto:lo...@co... |
|
From: Roger B. <gr...@vi...> - 2016-06-30 00:27:07
|
If I could develop my application strictly in C, my problems accessing
LittleCMS would be non-existent,
but I need to develop in C# :(
I am seeking help with re-coding the cmsDoTransform declaration.
Right now, I use this :
[DllImport(@lcmsPath, CallingConvention = CallingConvention.Winapi)]
static extern void cmsDoTransform(
IntPtr xform,
[MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 2), In] double[]
inputColors,
[MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 3), Out] double[]
outputColors, uint Size);
In code, I use this :
double[] input = { 0.5, 0.5, 0.5, 0 };
double[] output = { 0, 0, 0, 0 };
cmsDoTransform(xform, input, output, 1);
As you can see, I pass individual RGB values [in], recovering CMYK values
[out].
The cmsCreateTransform looks like this :
IntPtr xform = cmsCreateTransform(hSRGB, TYPE_RGB_DBL, hDestination,
TYPE_CMYK_DBL, INTENT_RELATIVE_COLORIMETRIC, 0);
Works perfect.
But now, I need to pass 'pixels' (to convert bitmap images) values instead
of individual device values.
Obviously, I need to modify the pinvoke declaration to accommodate the
difference in data type.
I am no C# specialist (maybe someday?) but I read that I may not need very
meticulous marshalling of data between my C# and lcms.dll.
So I am looking for a way to rewrite the declaration to accommodate more
than just 'double'.
In C, the original cmsDoTransform function require a Handle to the Transform
(another pointer), pointers to an input and output buffers, and the size of
the buffer themselves :
cmsDoTransform(cmsHTRANSFORM Transform, const void * InputBuffer,
void * OutputBuffer,
cmsUInt32Number Size);
(Not sure what the 'const' keyword in front of the first void * statement
does?)
So my first awkward/intuitive shot at rewriting the function in C# call
looks like this :
[DllImport(lcms2Path, CallingConvention = CallingConvention.Winapi)]
static extern void cmsDoTransform(IntPtr xform, IntPtr inputColors [in],
IntPtr outputColors [out], uint Size);
I have not tried running this code yet but I have been reading quite a bit
about pointers and how they have a fixed size, no matter the type of data
they point to.
So my question becomes how do I pass pointers to the these buffers in my new
declaration?
I read somewhere about the need to use the keyword 'unsafe' but I am not
sure.
Also read about the need to use the attributes [in] and [out] in marshalling
the data.
(The Marshalling of data is a HUGE topic in itself as I found out through my
hours of reading online)
Ultimately, my goal is is to convert JPEG or TIFF images from one color
space to another through LittleCMS.
Thank you so much in advance for your kind help.
/ Roger Breton
|
|
From: Noel C. <NCa...@Pr...> - 2016-06-27 00:38:53
|
Hi Marti and all, We have a case where we have a grayscale image expressed as 4 values per pixel, the first three are channels, identical to one another, representing the grayscale value, while the fourth is Alpha. You could describe this as GGGA. The image has a grayscale profile. We would like to transform and copy that image into an RGBA color image with a color profile. The output RGBA buffer uses the predefined types TYPE_RGBA_8, TYPE_RGBA_16, or TYPE_RGBA_FLT. Before LCMS 2.8, we expressed the input grayscale image as follows: #define TYPE_GxxA_8 (COLORSPACE_SH(PT_GRAY)|EXTRA_SH(3)|CHANNELS_SH(1)|BYTES_SH(1)) #define TYPE_GxxA_16 (COLORSPACE_SH(PT_GRAY)|EXTRA_SH(3)|CHANNELS_SH(1)|BYTES_SH(2)) #define TYPE_GxxA_FLT (FLOAT_SH(1)|COLORSPACE_SH(PT_GRAY)|EXTRA_SH(3)|CHANNELS_SH(1)|BYTES_SH( 4)) This all worked fine except of course the A value was not copied. We had a routine that would copy the A values separately. Now we'd like to use the new 2.8 preserve extra channel feature, but the LCMS 2.8 won't copy the A value because the number of extra channels from the grayscale input (3) doesn't match the number for the color output (1). Our first obvious idea was to define and use these for the grayscale image: #define TYPE_GGGA_8 (COLORSPACE_SH(PT_GRAY)|EXTRA_SH(1)|CHANNELS_SH(3)|BYTES_SH(1)) #define TYPE_GGGA_16 (COLORSPACE_SH(PT_GRAY)|EXTRA_SH(1)|CHANNELS_SH(3)|BYTES_SH(2)) #define TYPE_GGGA_FLT (FLOAT_SH(1)|COLORSPACE_SH(PT_GRAY)|EXTRA_SH(1)|CHANNELS_SH(3)|BYTES_SH( 4)) This seems to work fine with LCMS 2.8, and now copies the A across since there's just the one extra A channel in both input and output formats. However, my questions are these, since grayscale images don't normally have 3 channels of data... Is this valid? Since it's a grayscale image does LCMS use all three values or just the first one? Do we pay a performance penalty for asking LCMS to transform 3 channels that are all exactly the same? Thanks in advance for sharing your wisdom. -Noel |
|
From: Noel C. <NCa...@Pr...> - 2016-06-24 00:48:58
|
Your transform specifies the data types for input and output.
Specifically, the 2nd and 4th arguments of the cmsCreateTransform call
set the size and sequence of the input and output data respectively.
Then when the transform is executed, it processes the data per that size
and sequence.
For example, the following would set up to transform an image set up as
a sequence of 8 bit RGBA pixels...
cmsCreateTransform(InputProfile, TYPE_RGBA_8, OutputProfile,
TYPE_RGBA_8, Intent, Options);
Once a particular transform is created, its use in a cmsDoTransform call
will cause the processing of the data at the specified pointers in the
manner specified in the cmsCreateTransform call, for as many pixels as
you specify.
-Noel
-----Original Message-----
From: Roger Breton [mailto:gr...@vi...]
Sent: Thu, June 23, 2016 7:44 PM
To: lcm...@li...
Subject: [Lcms-user] Double or byte
I would like to start converting Bitmap images.
So far, with Marti's help, I have been perfectly content with converting
single pixel values, from RGB to RGB, from RGB to Lab and so on.
But converting entire images is a different kind of challenge.
The example on Page 10 of LittleCMS2.6 tutorial does not specify the
consequence of passing different data types to the library.
It only list the function call with its parameters :
> cmsDoTransform(hTransform, YourInputBuffer, YourOutputBuffer,
YourBuffersSizeInPixels);
So far, Input and Output buffers in my function call were arrays of
double :
double[] input = { 0, 0, 0, 0 };
double[] output = { 0, 0, 0, 0 };
This is my function call :
> cmsDoTransform(xform, input, output, 1);
But now, my Input and Output buffers can no longer be declared this way?
In C#, I use :
IntPtr InputBufferPointer = ImageData.Scan0; <---- The 'Scan0' property
comes from the Bitmap data object and indicates the address of the first
scanline
So my new cmsDoTransform call looks like this :
> cmsDoTransform(xform, InputBufferPointer, OutputBufferPointer,
NumberOfPixelsPerScanLine);
The only question I have is what happens to the type of data passed to
cmsDoTransform?
The Bitmap data is copied into an array of BYTES :
byte[] imagePixelsValues = new byte[bytes];
// Copy the RGB values into the array
Marshal.Copy(InputBufferPointer, imagePixelsValues, 0, bytes);
Does the compiler know to automatically cast the byte values to doubles?
Or is that done by LittleCMS?
I am confused...
/ Roger Breton
------------------------------------------------------------------------
------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user
|
|
From: Roger B. <gr...@vi...> - 2016-06-23 23:59:23
|
I would like to start converting Bitmap images.
So far, with Marti's help, I have been perfectly content with converting
single pixel values, from RGB to RGB, from RGB to Lab and so on.
But converting entire images is a different kind of challenge.
The example on Page 10 of LittleCMS2.6 tutorial does not specify the
consequence of passing different data types to the library.
It only list the function call with its parameters :
> cmsDoTransform(hTransform, YourInputBuffer, YourOutputBuffer,
YourBuffersSizeInPixels);
So far, Input and Output buffers in my function call were arrays of double :
double[] input = { 0, 0, 0, 0 };
double[] output = { 0, 0, 0, 0 };
This is my function call :
> cmsDoTransform(xform, input, output, 1);
But now, my Input and Output buffers can no longer be declared this way?
In C#, I use :
IntPtr InputBufferPointer = ImageData.Scan0; <---- The 'Scan0' property
comes from the Bitmap data object and indicates the address of the first
scanline
So my new cmsDoTransform call looks like this :
> cmsDoTransform(xform, InputBufferPointer, OutputBufferPointer,
NumberOfPixelsPerScanLine);
The only question I have is what happens to the type of data passed to
cmsDoTransform?
The Bitmap data is copied into an array of BYTES :
byte[] imagePixelsValues = new byte[bytes];
// Copy the RGB values into the array
Marshal.Copy(InputBufferPointer, imagePixelsValues, 0, bytes);
Does the compiler know to automatically cast the byte values to doubles? Or
is that done by LittleCMS?
I am confused...
/ Roger Breton
|
|
From: Tobias E. <me...@ho...> - 2016-06-23 14:46:56
|
On Monday 20 June 2016 21:47:48 Kai-Uwe Behrmann wrote: > Am 20.06.2016 um 12:19 schrieb Tobias Ellinghaus: > > I am currently struggling to use a profile with a parametric tone > > curve for softproofing. Is there a know limitation regarding that? > > When I use a straight gamma it works. Alternatively I can dump the > > profile to disk or memory and read it again to get something > > working. > > Could you compare with the cmsCreate_sRGBProfile() API? Such a profile doesn't work either. Interestingly I can't even salvage it by going through the cmsSaveProfileToMem/cmsOpenProfileFromMem cycle. Tobias PS: This is with lcms 2.7 from Debian. |
|
From: Tobias E. <me...@ho...> - 2016-06-23 14:36:17
|
On Monday 20 June 2016 23:55:24 Marti Maria wrote: > Hi Tobias, Hi, sorry for the late reply. > could you explain a little bit more how you use this profile with > softproofing? I am creating a transform with cmsCreateProofingTransform(Lab_profile, TYPE_LabA_FLT, output_profile, TYPE_RGBA_FLT, softproof_profile, out_intent, INTENT_RELATIVE_COLORIMETRIC, cmsFLAGS_SOFTPROOFING | cmsFLAGS_NOCACHE | cmsFLAGS_BLACKPOINTCOMPENSATION); and use that later with cmsDoTransform() > What result do you expect? I expect that the image is shown as if it was exported to the softproofing intent first. > What are you getting? With the profile with a parametric tonecurve (sRGB in my example, but there are others, too) the use of softproofing doesn't affect the image at all. It still looks the same as when no softproofing is enabled. Other profiles used the same way work though. > This would > help to catch the bug if this is the case It might very well a bug on my side. > Thanks > Marti Tobias > On Jun 20, 2016 12:19 PM, Tobias Ellinghaus <me...@ho...> wrote: > > Hello, > > > > I am currently struggling to use a profile with a parametric tone curve > > for > > softproofing. Is there a know limitation regarding that? When I use a > > straight gamma it works. Alternatively I can dump the profile to disk or > > memory and read it again to get something working. > > > > The code to create the profile is here: > > > > https://github.com/darktable-org/darktable/blob/master/src/common/colorspa > > ces.c#L286-L297 > > > > and > > > > https://github.com/darktable-org/darktable/blob/master/src/common/colorspa > > ces.c#L238-L284 > > > > I would appreciate any hints about what is happening. > > > > Thanks > > Tobias > > -------------------------------------------------------------------------- > > ---- What NetFlow Analyzer can do for you? Monitors network bandwidth and > > traffic patterns at an interface-level. Reveals which users, apps, and > > protocols are consuming the most bandwidth. Provides multi-vendor support > > for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using > > capacity planning reports. http://sdm.link/zohomanageengine |