Jump to content
You must now use your email address to sign in [click for more info] ×

PNG Images incorrectly rendered in CMYK space


Recommended Posts

EDIT 2: See updated topic here

I saved out two versions of the same 3D render. One JPG and one PNG. The scene shows 2 wine bottles on a gray surface.

I create a new document in AP, in CMYK color space.

When I place the files into AP, the JPG looks correct but the PNG looks wildly off. Very low contrast and some odd color shifts. If I switch the document to RGB color space, both the JPG and the PNG look the same.

Linked PNGs seem to be rendering incorrectly in CMYK space, unless there is some hidden setting that is causing the issue.

Curiously, the preview thumbnail for the page has the opposite problem. It represents the PNG correctly, but gives the JPG a very blue cast. Again the problem is solved when switching the document to RBG space.

I've attached both images.

EDIT: After I uploaded both images into the browser, I saw that the version I exported as a JPG (file name PNG_bug.jpg) appears bluish green just like the Thumbnail. Yet on my computer the exported JPG looks neutral gray. So I took a screengrab of what I see in AP, which shows the pretty neutral gray on both the JPG and PNG. Neutral gray is what the scene is supposed to look like. This may shed light on the matter to someone familiar with the color management pipeline.

PNG_bug.jpg

Screen Shot 2018-09-28 at 11.17.04 AM.png

Screen Shot 2018-09-28 at 11.28.54 AM.png

OriginalRenders.zip

Edited by ffca
Updated to new thread
Link to comment
Share on other sites

It may be relevant that the PNG image format  does not support CMYK. But I'm not precisely sure how that should affect your file.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

1 hour ago, walt.farrell said:

It may be relevant that the PNG image format  does not support CMYK. But I'm not precisely sure how that should affect your file.

Hmm maybe that has something to do with it. I never have this problem in InDesign though or other CMYK spaces like Illustrator.

Your comment prompted me to check the behavior of Affinity Designer, and it shows the same odd rendering. So this is either a bug in code shared by both programs, or it's simply the way Serif intended PNGs to look. But if I didn't know, I would think there's something wrong with my render and make a new version overcompensating for a problem that never existed. So to me that makes it a bug. 

Link to comment
Share on other sites

Hi ffca,

This is what I get if I simply load them both in APhoto:

capture-002248.jpg.6dba93218b64a070f6c4f61902da87c5.jpg

The JPG is on the left. Both converted to cmyk.

Does the render application have the ability to embed a profile? If so, see if using the same RGB profile as you are using in APhoto and see if that makes a difference. Then convert to CMYK, save as an APhoto version , then bring that/those into your working document.

Link to comment
Share on other sites

MikeW,

Thanks for the response. I use Blender for 3D, and it does not assign profiles on export.

When I open the PNG in APhoto and then change the color space to CMYK, I see what I expected to see in the other programs—a slight shift in values but nothing extreme. After poking around in Designer and Publisher, I think I found the reason. It's because Photo automatically assigns a profile when the image is placed, whereas the other two Serif programs do not because of my preference settings. I had "Convert opened file to working space" disabled in Designer and Publisher.

Now that I understand this, it looks like Publisher does not honor the "Convert opened files to working space" setting when placing an image.

I enabled that option, and placed the PNG with the same washed out results, even after restarting Publisher. However when I tried opening the PNG into a new document, the profile was automatically assigned. When I then switched that new document to CMYK space, the conversion was as expected—just a slight shift in colors.

Do you agree that this is unexpected behavior, and should I make a new post about it?

Link to comment
Share on other sites

Yes, I think there is an issue...but hold that thought.

Here's QuarkXPress with both images. JPG is on the left.

capture-002250.png.8858f5b0102c70d08fb670f8b4302db8.png

And here are the same in APub...like you show. Again, JPG is on the left.

capture-002252.png.c53749ff7345cfd884fe3f6ab2643d30.png

However. When I get images from clients, one of the first things I do with images not coming from a professional is to open them in my image editor and save as a JPG or TIFF with my working RGB profile. Only then do I place it into my layout application. And when I do this with the PNG source file, the appearance is fine. It is also fine if I convert to profile in my image editor and resave as a new PNG file which is shown below. The newly saved PNG is the one with the red box around it.

capture-002253.png.6fea964d5d092bed3b9d15f588bcc767.png

OK. Because of how InDesign, QXP, Viva Designer and several other applications display (and output) the original PNG source file, there does seem to be an issue with PNG files from Blender. But do note, I also tested several PNGs & JPGs from clients and there is no issue inside of APub nor APhoto/AD. So I don't know what to say about why there is this difference.

I hope Serif employees take a look at this issue. APhoto, Apub & AD ought to treat them as do the other applications I tried in. But it's obvious Affinity applications do not.

Sorry I couldn't write and say, "Hey, do this and all is well."

Take care, Mike

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.