I've spent hours in trying to figure this one out.
Goal
Display P3 PDF Asset in UIImageView (the PDF is 100% in P3 Color Space).
Issue
I'm creating a P3 PDF asset and adding into the Xcode. Within the Asset Catalog, the asset appears in the correct P3 color. When using the asset inside UIImageView and running on iPhone X ( physical device, supports P3 Color Space ), the asset showing is SRGB instead of P3.
Does anyone has information on how to resolve this issue?
Any help will be highly appreciated.
Roi
Use PNG directly
You mention you suspect there is a PNG inside the PDF. I would recommend to use PNG directly without a wrapping PDF.
PDFs are rendered by Apple to PNG when they are deployed on a device. This rendering may apply a specific color profile (PDF and color management is a broad topic).
Also the rendering itself might not produce the results you are expecting, see e.g. https://bjango.com/articles/idontusepdfs/
16 bits per pixel (per channel)
Apple's Human Interface Guidelines state one has to use 16 bits per pixel and export images in .png format.
When appropriate, use the Display P3 color profile at 16 bits per pixel (per channel) and export images in .png format.
see here: https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#color-management
Finally, I'd like to mention just two more settings that you are probably already using:
Compression
In the attributes inspector for image assets you should choose 'Lossless'.
Gamut
Swicht Gamut to 'sRGB and Display P3' and then make sure your image is in a 'Display P3' slot in the .xcasset file.
Test with PNG export of Sketch
Taking a look at the chromaticity diagram, one can see that the P3 color space has a larger gamut for greenish colors.
Since I am not sure whether I can recognize the difference between the two color spaces, I have made the following experiment:
inserted a artboard in Sketch
created a green rectangle with the color #00FF00
assigned under <File/Change Color Profile> the Display P3 color profile
selected the rectangle and clicked Exported selected
have chosen .png without interlacing
Then I did the very same but with sRGB ICE61966-2.1 profile.
I checked both .pngs in the ColorSync utility (can be found under /Applications/Utilities). Pressing the image info toolbar button one can see, that the correct ColorSync profiles are assigned.
In Affinity Photo I checked under <Document/Colour Format> the number of bits per channel. It was for both .pngs 8bit per channel, so I created two additional .pngs with 16bits per channel and named it accordingly.
Then I added the 4 .pngs to a .xcassets folder with the following settings:
Compression: 'Lossless'
Scale: 'Single Scale'
Gamut: 'sRGB and Display P3'
assigned the .pngs accordingly to the correct slot (either sRGP or Display P3).
Then I deployed to iPhone X.
Result: Actually I can see a difference between the green rectangles. The 'Display P3' do have indeed a more saturated green.
I exported the same thing to an old iPhone, where I can't spot any differences between the sRGB and Display P3 images.
I found it interesting that the 8-bit variant directly from Sketch also works, so 16 bits per channel doesn't seem to be a hard requirement.
Did you select the gamut setting for your asset?
How did you verifiy that the image is in SRGB on the iPhone X?
Maybe the WWDC16 talk is somethink to check again:
talk slides
Related
We're doing a cognitive experiment that requires flashing 480 black-and-white images at high speed against a neutral-gray background. The image shown is detail at about 300% zoom; the full display is 932 x 612; there are actually other clusters similar to this one elsewhere on the screen.
We have to generate these images in a source app and later display them in the experimental app. At first, we were using 24-bit PNG's with the background color built in, but despite the size of each file hovering around 10KB, the total file payload of 480 is too large and takes way too long to preload. We can, however, set a default background color in the app and put up 1-bit images. Although we can change the background color in the source application, we don't have control over bit depth there, so we are stuck generating screen captures and then downsampling to binary. We have tried this with original images that sit on both a white background and the gray background. Using ImageMagick, both of these commands yield similar results:
magick gray.png -transparent "rgb(192,192,192)" -alpha set -depth 1 out\gray-out.bmp (or .png)
magick white.png -transparent white -alpha set -depth 1 out\white-out.bmp (or .png)
The PNGs are coming out to 1.5K to 5K, so this is where we want to be. However, we're stuck with that problem aliased edge whether we start with gray- or white-background images. We've also tried the -fuzz argument (1-99%) to no effect. The resulting pseudoalias artifact that we see in these 1-bit files is the same in multiple apps, so apparently it must be built into the output file generated by ImageMagick's attempt to filter the edge, and not an artifact of any single app or the OS.
We don't quite get how an alpha channel can even be attached to a 1-bit image if it is not strictly RGBA: an alpha channel with a 1-bit image doesn't even make sense. But if an alpha channel isn't being included, then where is the map coming from in a nonbinary image to distinguish that "white" edge from a nonwhite surface? It's not the destination apps. The output files must either not be strictly binary, or else ImageMagick is not computing the channel exactly to the contour edges. (When we remove the -alpha argument, ImageMagick generates a larger file; the aliasing (e.g., when we place into PowerPoint and select Transparent Color to white) may appear in slightly different places, but the effect is essentially the same.
The question is, how is it possible to remove this artifact in a 1-bit image using ImageMagick? We'd like to get the file sizes down to the minimum.
Some related questions around Display P3 (wide gamut) image handing:
Is there a file name convention for wide gamut images, like there was for retina (#2x, #3x)?
Is there a way to add wide gamut versions to xcassets?
If we have have sRGB MyPic.png in our Xcode project, how do we use UIImage to load a P3 version?
Or...
Should we simply replace our sRGB images with Display P3 images, and let older sRGB-based devices do their best to display them?
The answers, from Apple, are here: https://developer.apple.com/videos/play/wwdc2016/712/ with PDF here: http://devstreaming.apple.com/videos/wwdc/2016/712ugi7vg8jznn3pc3u/712/712_working_with_wide_color.pdf
Some notes:
Photoshop:
Use Convert to Profile to convert to Display P3 profile
Don't use Assign Profile
Save for Web doesn't work with wide color.
Use Save As -> PNG from 16-bit source doc
Export assets as 16bit PNG files with embedded “Display P3” ICC profile
Xcode:
16-bit PNGs can be dragged into XCAssets.
Xcode will auto-generate the 8-bit sRGB derivative (or you can supply it yourself)
UIImage will automatically load the correct image for your device's display.
App Slicing will cause only the correct images to be included in your app when downloading to a device.
Way more info in that WWDC session.
Naming:
There's no standard I could find, though Webkit's page of examples uses "-P3", e.g. "MyPic-P3.png". This'd be a useful convention if you want both types of file on a server.
I know this isn't a new problem and I've done a full day (literally) of research. I use the latest Xcode 6, and I'm trying to use all PDF files as vector art resources. However, when I export these images from Illustrator in sRGB (sRGB IEC61966-2.1) , these images show up noticeably darker than if I used a png file.
Some previous suggested solutions are: setting Illustrator file color profile to "web" and choose color space "RGB", and exporting to pdf with Illustrator converting the color space to "sRGB IEC61996-2.1". The latter worked for me for one of the images... And today when I tried the same thing it didn't work!
So I tried all the other solutions, I retried, restarted, tried using different programs, renaming resources, cleaning the project... Nothing worked! The colors still look darker on screen, and the old PDF icon I made look perfect still!
The PDF looks perfect in any other viewer, including Xcode itself, by the way. It's when Xcode compiles, the images get broken (PNG files are generated, and something is wrong with their colorspace).
This is driving me nuts... Anyone else having this problem?
Depending on the screen, you can tell that the center button is quite a bit lighter than the other two icons. I intersected two just to show how distinguishable it is. But on my MacBook Air, they appear identical. Perhaps this has to do with what people say about Apple taking the compiling machine's color space into account? On my iPhone and MacBook they look very different.
Update If I change my MacBook Air's display -> color profile to sRGB, I can clearly tell the difference now. I'm retrying importing the PDF,and maybe the conversion will be correct. Will update.
I've had tremendous troubles with this. And I finally figured it out.
Apple uses sRGB for iOS. To do this you must save your pdf (convert to) in sRGB. I do this with Illustrator -> new -> profile = "web", color space = "RGB" -> save as PDF -> (in options) convert to sRGB. This is suggested by many others in similar questions' solutions. The next... Is what I found out. A trap, if you will.
CAUTION! When you copy past paths over to the new artboard in RGB, the RGB values may have been changed by Illustrator. This took me ages to figure out... Even though the saving to PDF part was right, Illustrator broke it by changing the values by default, making everything darker and more dull.
Hope this helps!
I am having my app icon be displayed as a black square instead of the intended image.
I have placed all of my AppIcons into the folder, Im wondering what could be causing this.
Your image needs to be an opaque PNG. No transparency or anything, as well as being the correct size.
If it already is that, try opening it in Preview and re-saving it as a PNG. That way OS X 'generated' it and it should be compatible. If that helps fix the issue, then your image editing program is saving in the wrong format...see info below.
Apple has this to say on generating PNGs:
For all images and icons, the PNG format is recommended. You should avoid using interlaced PNGs.
The standard bit depth for icons and images is 24 bits—that is, 8 bits each for red, green, and blue—plus an 8-bit alpha channel.
I have had this happen when the app is listed as a .png file, but the system is recognizing it as a .jpg or some other type ... find your icon in "finder" and open it with preview, go to the file menu select "export as" and make sure you choose PNG as the save format. Delete the old version in the application, delete the derived data, clean your project, and rebuild the application.
In my app, I convert and process images.
from colour to greyscale, then doing operations such as histogram-equalisation, filtering, etc.
that part works fine.
my UIImage display correctly, I also save them to jpeg files and it works.
The only problem is that, although my images are now greyscales, they are still saved as RGB jpegs. that is the red, green and blue value for each pixel are the same but it still waste space to keep the duplicated value, making the file size higher than it could be.
So when i open the image file in photoshop, it is black & white but when I check "Photoshop > Image > Mode", it still says "RGB" instead of "Greyscale".
Anyone know how to tell iOS that the UIImageJPEGRepresentation call should create data with one channel per pixel instead of 4?
Thanks in advance.
You should do an explicit conversion of your image using CGColorSpaceCreateDeviceGray() as color space which is 8 bits per component, 1 channel.