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

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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

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

[Alex Zavatone]

Nah.  I checked the results on two of my devices and the simulator to make sure 
I had a grip on what was going wrong.  

When I took all the saved images and opened them up.  I’d expect each set of 
them to have the same error it’s not a colorspace profile.  

The reason this mattered was that I was saving out the image within the app 
just to test and compare.  We were doing drivers’ license photos, so if things 
were going wrong, I had to know by how much.

All I can remember from that was that it was something related to the 
colorspace profile that was added to the image based on which device the image 
was saved onto.  






> On Nov 16, 2017, at 9:58 PM, Rick Mann  wrote:
> 
> Do you literally mean moving the iOS simulator window to a different monitor, 
> even though there’s never a display context in any of this code?
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
>> On Nov 16, 2017, at 19:55, Alex Zavatone  wrote:
>> 
>> I was basing my assumption on this line of your email:
>> 
> 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.
>> 
>> In that, I was assuming that the image from the CGImage that you mention is 
>> similar should be the same.  
>> 
>> My guess here is that the PNG that you saved has a colorspace applied to it. 
>>  But it seems odd that the bytes are different unless the image is run 
>> through a transform with CI.  I wouldn’t expect one either.  
>> 
>> About 3 years ago when I was looking into similar things, I came across a 
>> nice explanation of the CI pipeline, in the Apple Docs that did a good job 
>> explaining what happens where and when.  Even in the display of image items 
>> that are saved/loaded to/from disk.  
>> 
>> Everything came down to not accommodating the color profile or something 
>> related to that.  
>> 
>> I even got different results when testing on 2 monitors.  
>> 
>> An easy way to rule out my hypothesis would be to check the results on two 
>> different displays with different color calibration and see if that has some 
>> effect or no effect at all.
>> 
>> 
>> A quick walk through the CI pipeline docs will probably trigger something 
>> that will answer your question.
>> 
>> I’ll see it I can find the ones that were useful to me for you.
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Nov 16, 2017, at 9:29 PM, Rick Mann  wrote:
>>> 
>>> OpenCV is not relevant in this case, that was just background that I 
>>> probably didn't need to include.
>>> 
>>> I'm generating an image buffer, saving it as PNG through UIImage, then 
>>> generating it again, and comparing it to the UIImage bytes I get by opening 
>>> the previously-saved image. I'm not specifying anything other than device 
>>> RGB color space when I create the CGBitmapContext I use to generate the 
>>> image buffer.
>>> 
 On Nov 16, 2017, at 19:27 , Alex Zavatone  wrote:
 
 Before looking into OCV, my wild guess is that it may have to do with the 
 colorspace of the image.  What are you setting it to? Profile Name: sRGB 
 IEC61966-2.1?
 
 
> On Nov 16, 2017, at 8: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
> 
> 

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

[Rick Mann]

Do you literally mean moving the iOS simulator window to a different monitor, 
even though there’s never a display context in any of this code?

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

> On Nov 16, 2017, at 19:55, Alex Zavatone  wrote:
> 
> I was basing my assumption on this line of your email:
> 
 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.
> 
> In that, I was assuming that the image from the CGImage that you mention is 
> similar should be the same.  
> 
> My guess here is that the PNG that you saved has a colorspace applied to it.  
> But it seems odd that the bytes are different unless the image is run through 
> a transform with CI.  I wouldn’t expect one either.  
> 
> About 3 years ago when I was looking into similar things, I came across a 
> nice explanation of the CI pipeline, in the Apple Docs that did a good job 
> explaining what happens where and when.  Even in the display of image items 
> that are saved/loaded to/from disk.  
> 
> Everything came down to not accommodating the color profile or something 
> related to that.  
> 
> I even got different results when testing on 2 monitors.  
> 
> An easy way to rule out my hypothesis would be to check the results on two 
> different displays with different color calibration and see if that has some 
> effect or no effect at all.
> 
> 
> A quick walk through the CI pipeline docs will probably trigger something 
> that will answer your question.
> 
> I’ll see it I can find the ones that were useful to me for you.
> 
> 
> 
> 
> 
> 
>> On Nov 16, 2017, at 9:29 PM, Rick Mann  wrote:
>> 
>> OpenCV is not relevant in this case, that was just background that I 
>> probably didn't need to include.
>> 
>> I'm generating an image buffer, saving it as PNG through UIImage, then 
>> generating it again, and comparing it to the UIImage bytes I get by opening 
>> the previously-saved image. I'm not specifying anything other than device 
>> RGB color space when I create the CGBitmapContext I use to generate the 
>> image buffer.
>> 
>>> On Nov 16, 2017, at 19:27 , Alex Zavatone  wrote:
>>> 
>>> Before looking into OCV, my wild guess is that it may have to do with the 
>>> colorspace of the image.  What are you setting it to? Profile Name: sRGB 
>>> IEC61966-2.1?
>>> 
>>> 
 On Nov 16, 2017, at 8: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/zav%40mac.com
 
 This email sent to z...@mac.com
>>> 
>> 
>> 
>> -- 
>> 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?

[Alex Zavatone]

I was basing my assumption on this line of your email:

>>>  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.

In that, I was assuming that the image from the CGImage that you mention is 
similar should be the same.  

My guess here is that the PNG that you saved has a colorspace applied to it.  
But it seems odd that the bytes are different unless the image is run through a 
transform with CI.  I wouldn’t expect one either.  

About 3 years ago when I was looking into similar things, I came across a nice 
explanation of the CI pipeline, in the Apple Docs that did a good job 
explaining what happens where and when.  Even in the display of image items 
that are saved/loaded to/from disk.  

Everything came down to not accommodating the color profile or something 
related to that.  

I even got different results when testing on 2 monitors.  

An easy way to rule out my hypothesis would be to check the results on two 
different displays with different color calibration and see if that has some 
effect or no effect at all.


A quick walk through the CI pipeline docs will probably trigger something that 
will answer your question.

I’ll see it I can find the ones that were useful to me for you.






> On Nov 16, 2017, at 9:29 PM, Rick Mann  wrote:
> 
> OpenCV is not relevant in this case, that was just background that I probably 
> didn't need to include.
> 
> I'm generating an image buffer, saving it as PNG through UIImage, then 
> generating it again, and comparing it to the UIImage bytes I get by opening 
> the previously-saved image. I'm not specifying anything other than device RGB 
> color space when I create the CGBitmapContext I use to generate the image 
> buffer.
> 
>> On Nov 16, 2017, at 19:27 , Alex Zavatone  wrote:
>> 
>> Before looking into OCV, my wild guess is that it may have to do with the 
>> colorspace of the image.  What are you setting it to? Profile Name: sRGB 
>> IEC61966-2.1?
>> 
>> 
>>> On Nov 16, 2017, at 8: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/zav%40mac.com
>>> 
>>> This email sent to z...@mac.com
>> 
> 
> 
> -- 
> 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?

[Rick Mann]

OpenCV is not relevant in this case, that was just background that I probably 
didn't need to include.

I'm generating an image buffer, saving it as PNG through UIImage, then 
generating it again, and comparing it to the UIImage bytes I get by opening the 
previously-saved image. I'm not specifying anything other than device RGB color 
space when I create the CGBitmapContext I use to generate the image buffer.

> On Nov 16, 2017, at 19:27 , Alex Zavatone  wrote:
> 
> Before looking into OCV, my wild guess is that it may have to do with the 
> colorspace of the image.  What are you setting it to? Profile Name: sRGB 
> IEC61966-2.1?
> 
> 
>> On Nov 16, 2017, at 8: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/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 


-- 
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?

[Alex Zavatone]

Before looking into OCV, my wild guess is that it may have to do with the 
colorspace of the image.  What are you setting it to? Profile Name: sRGB 
IEC61966-2.1?


> On Nov 16, 2017, at 8: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/zav%40mac.com
> 
> This email sent to z...@mac.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

Avoiding color transformations in PNG/UIImage/CGImage ops?

[Rick Mann]

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