Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Rick Mann 


> On Nov 17, 2017, at 14:03 , Vince DeMarco  wrote:
> 
> 
> 
>> On Nov 17, 2017, at 1:45 PM, Rick Mann  wrote:
>> 
>> 
>> 
>>> On Nov 17, 2017, at 13:36 , Vince DeMarco  wrote:
>>> 
>>> 
>>> 
 On Nov 17, 2017, at 1:28 PM, Rick Mann  wrote:
 
 Nope, I'm definitely looking at pixel data. But I'll try the generic color 
 space. I don't know how it chooses device color space when it's created 
 absent any particular display-associated context.
>>> 
>>> Don't use the generic color space use sRGB for both. 
>>> 
>>> Like this instead
>>> 
>>>colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);
>> 
>> Thanks. Can you elaborate as to why?
> 
> 
> All of the devices now default to sRGB, the Asset catalogs when presented 
> with an color png file will convert them to sRGB (extended range srgb for 
> Deep color images).
> 
> the jpeg reader in the system (ImageIO) if it finds a image with no color 
> space will assume sRGB.
> 
> Always best to be explicit in what you want.

Thanks!


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Vince DeMarco 


> On Nov 17, 2017, at 1:45 PM, Rick Mann  wrote:
> 
> 
> 
>> On Nov 17, 2017, at 13:36 , Vince DeMarco  wrote:
>> 
>> 
>> 
>>> On Nov 17, 2017, at 1:28 PM, Rick Mann  wrote:
>>> 
>>> Nope, I'm definitely looking at pixel data. But I'll try the generic color 
>>> space. I don't know how it chooses device color space when it's created 
>>> absent any particular display-associated context.
>> 
>> Don't use the generic color space use sRGB for both. 
>> 
>> Like this instead
>> 
>>colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);
> 
> Thanks. Can you elaborate as to why?


All of the devices now default to sRGB, the Asset catalogs when presented with 
an color png file will convert them to sRGB (extended range srgb for Deep color 
images).

the jpeg reader in the system (ImageIO) if it finds a image with no color space 
will assume sRGB.

Always best to be explicit in what you want.

Vince



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Alex Zavatone 

> On Nov 16, 2017, at 9:27 PM, Alex Zavatone  wrote:
> 
> Profile Name: sRGB IEC61966-2.1?

Are you using 

CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();

Or as you said, not setting one at all?

You can check on a CGImageRef with 

CGColorSpaceRef colorSpace = CGImageGetColorSpace(imgRef);



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Alex Zavatone 

> On Nov 17, 2017, at 3:45 PM, Rick Mann  wrote:
> 
> 
> 
>> On Nov 17, 2017, at 13:36 , Vince DeMarco  wrote:
>> 
>> 
>> 
>>> On Nov 17, 2017, at 1:28 PM, Rick Mann  wrote:
>>> 
>>> Nope, I'm definitely looking at pixel data. But I'll try the generic color 
>>> space. I don't know how it chooses device color space when it's created 
>>> absent any particular display-associated context.
>> 
>> Don't use the generic color space use sRGB for both. 
>> 
>> Like this instead
>> 
>>colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);
> 
> Thanks. Can you elaborate as to why?
> 

Was that it?

Remember when I asked if the profile of the image was Profile Name: sRGB 
IEC61966-2.1?

It’s something related to the storage of the image.  It appears to be done 
automatically in CI as part of the saving/loading of the image.  I think it 
actually writes data adjusted based on the color space profile.

I could be wrong though, but this feels accurate.  If I’m correct, it’s part of 
the CI pipeline. 

Let me dig through the 2014 code now.  



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Rick Mann 


> On Nov 17, 2017, at 13:36 , Vince DeMarco  wrote:
> 
> 
> 
>> On Nov 17, 2017, at 1:28 PM, Rick Mann  wrote:
>> 
>> Nope, I'm definitely looking at pixel data. But I'll try the generic color 
>> space. I don't know how it chooses device color space when it's created 
>> absent any particular display-associated context.
> 
> Don't use the generic color space use sRGB for both. 
> 
> Like this instead
> 
> colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);

Thanks. Can you elaborate as to why?



-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Vince DeMarco 


> On Nov 17, 2017, at 1:28 PM, Rick Mann  wrote:
> 
> Nope, I'm definitely looking at pixel data. But I'll try the generic color 
> space. I don't know how it chooses device color space when it's created 
> absent any particular display-associated context.

Don't use the generic color space use sRGB for both. 

Like this instead

colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);

Vince


> 
> 
>> On Nov 17, 2017, at 06:54 , Steve Christensen  wrote:
>> 
>> It sounds like you're looking at image file data rather than buffers of 
>> pixel data. If so then I wouldn't make the assumption that the encoded bytes 
>> in two PNG files will be identical for identical images. Depending on how 
>> flexible the file format is, then particular parts of the encoded image 
>> could be written to different locations in the two files. It seems more 
>> reasonable to draw the images to compare into CGBitmapContexts configured 
>> identically and them compare the active portions (i.e., width * 
>> bytesPerPixel <= bytesPerRow) of the bitmap buffers.
>> 
>> As for color space to use, Apple recommends "that you use calibrated (or 
>> generic) color spaces instead of device color spaces. The colors in device 
>> color spaces can vary widely from device to device, whereas calibrated color 
>> spaces usually result in a reasonably accurate color." 
>> (https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/DrawColor/Tasks/UsingColorSpaces.html)
>> 
>> Steve
>> 
>> 
>>> On Nov 16, 2017, at 6:31 PM, Rick Mann  wrote:
>>> 
>>> I'm trying to write a unit test for some code I wrote that generates one 
>>> image from another. In the main app, the source data comes from Open CV as 
>>> a buffer of 3 byte-per-pixel elements. My code generates a CGImage. In the 
>>> unit test, I load a saved version of one of those images from a PNG file to 
>>> UIImage, get at the buffer, pass it to my code, and then compare the result 
>>> to a saved version of that same output.
>>> 
>>> The saved version is a PNG. I load that, and then get the data buffer using
>>> 
>>>   let fiData = fi.dataProvider?.data as Data?
>>> 
>>> I do a similar thing with the generated CGImage. Then I compare the two 
>>> buffers, byte by byte. They are similar, but contain differences (sometimes 
>>> more than I would expect). But if I save both as PNG and look at them in 
>>> Preview they look identical.
>>> 
>>> My guess is something's happening somewhere with color correction. In my 
>>> code, I make a CG(bitmap)Context, specifying device RGB color space (should 
>>> that be generic?). I don't really know what happens to the PNGs I save and 
>>> load.
>>> 
>>> Is there a way to ensure the bytes in the buffer are compressed and 
>>> decompressed exactly as written?
>> 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/demarco%40apple.com
> 
> This email sent to dema...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Alex Zavatone 

> On Nov 17, 2017, at 3:28 PM, Rick Mann  wrote:
> 
> Nope, I'm definitely looking at pixel data. But I'll try the generic color 
> space. I don't know how it chooses device color space when it's created 
> absent any particular display-associated context.
> 

Rick, this reminds me of what I ran into.  I’m hoping it’s this simple. When I 
saved the images, i didn’t specify a color space either.  From what I remember, 
seemed like the system was trying to out think the programmer and ended up 
simply being a PITA.  

Fingers crossed that this is it.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Rick Mann 
Nope, I'm definitely looking at pixel data. But I'll try the generic color 
space. I don't know how it chooses device color space when it's created absent 
any particular display-associated context.


> On Nov 17, 2017, at 06:54 , Steve Christensen  wrote:
> 
> It sounds like you're looking at image file data rather than buffers of pixel 
> data. If so then I wouldn't make the assumption that the encoded bytes in two 
> PNG files will be identical for identical images. Depending on how flexible 
> the file format is, then particular parts of the encoded image could be 
> written to different locations in the two files. It seems more reasonable to 
> draw the images to compare into CGBitmapContexts configured identically and 
> them compare the active portions (i.e., width * bytesPerPixel <= bytesPerRow) 
> of the bitmap buffers.
> 
> As for color space to use, Apple recommends "that you use calibrated (or 
> generic) color spaces instead of device color spaces. The colors in device 
> color spaces can vary widely from device to device, whereas calibrated color 
> spaces usually result in a reasonably accurate color." 
> (https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/DrawColor/Tasks/UsingColorSpaces.html)
> 
> Steve
> 
> 
>> On Nov 16, 2017, at 6:31 PM, Rick Mann  wrote:
>> 
>> I'm trying to write a unit test for some code I wrote that generates one 
>> image from another. In the main app, the source data comes from Open CV as a 
>> buffer of 3 byte-per-pixel elements. My code generates a CGImage. In the 
>> unit test, I load a saved version of one of those images from a PNG file to 
>> UIImage, get at the buffer, pass it to my code, and then compare the result 
>> to a saved version of that same output.
>> 
>> The saved version is a PNG. I load that, and then get the data buffer using
>> 
>>let fiData = fi.dataProvider?.data as Data?
>> 
>> I do a similar thing with the generated CGImage. Then I compare the two 
>> buffers, byte by byte. They are similar, but contain differences (sometimes 
>> more than I would expect). But if I save both as PNG and look at them in 
>> Preview they look identical.
>> 
>> My guess is something's happening somewhere with color correction. In my 
>> code, I make a CG(bitmap)Context, specifying device RGB color space (should 
>> that be generic?). I don't really know what happens to the PNGs I save and 
>> load.
>> 
>> Is there a way to ensure the bytes in the buffer are compressed and 
>> decompressed exactly as written?
> 


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Avoiding color transformations in PNG/UIImage/CGImage ops?

2017-11-17 Thread Steve Christensen 
It sounds like you're looking at image file data rather than buffers of pixel 
data. If so then I wouldn't make the assumption that the encoded bytes in two 
PNG files will be identical for identical images. Depending on how flexible the 
file format is, then particular parts of the encoded image could be written to 
different locations in the two files. It seems more reasonable to draw the 
images to compare into CGBitmapContexts configured identically and them compare 
the active portions (i.e., width * bytesPerPixel <= bytesPerRow) of the bitmap 
buffers.

As for color space to use, Apple recommends "that you use calibrated (or 
generic) color spaces instead of device color spaces. The colors in device 
color spaces can vary widely from device to device, whereas calibrated color 
spaces usually result in a reasonably accurate color." 
(https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/DrawColor/Tasks/UsingColorSpaces.html
 
)

Steve


> On Nov 16, 2017, at 6:31 PM, Rick Mann  wrote:
> 
> I'm trying to write a unit test for some code I wrote that generates one 
> image from another. In the main app, the source data comes from Open CV as a 
> buffer of 3 byte-per-pixel elements. My code generates a CGImage. In the unit 
> test, I load a saved version of one of those images from a PNG file to 
> UIImage, get at the buffer, pass it to my code, and then compare the result 
> to a saved version of that same output.
> 
> The saved version is a PNG. I load that, and then get the data buffer using
> 
>let fiData = fi.dataProvider?.data as Data?
> 
> I do a similar thing with the generated CGImage. Then I compare the two 
> buffers, byte by byte. They are similar, but contain differences (sometimes 
> more than I would expect). But if I save both as PNG and look at them in 
> Preview they look identical.
> 
> My guess is something's happening somewhere with color correction. In my 
> code, I make a CG(bitmap)Context, specifying device RGB color space (should 
> that be generic?). I don't really know what happens to the PNGs I save and 
> load.
> 
> Is there a way to ensure the bytes in the buffer are compressed and 
> decompressed exactly as written?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com