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

Convert CMYK image to RGB when copying from another Designer project


Recommended Posts

3 minutes ago, >|< said:

The majority of CMYK images should be expected to look no different after conversion to sRGB. The sRGB gamut contains most of the colours found in CMYK colour spaces.

That's right and was also my first thought, but then the OP said for embedded images, which might not be handled the same way here if they contain their own applied/embedded color profile. Thus we were looking if there is some way to detect then which color space is applied to embedded images and the like. - Also don't forget there can be bugs related to this and it's handling, which wouldn't be the first time.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

1 hour ago, >|< said:

Open the Embedded Document in a new tab then click the Document Setup button in the context toolbar or use File > Document Setup (shift-ctrl-p) to discover its colour profile.

That's probably then a way for him to check, if it updates and shows up accordingly for the embedded stuff.

Quote

...I had already tried using the Doc Setup/Color Format/Convert to RGB, as well as checking the Convert opened files to working space option, and I've been doing layout long enough to see that the images are still CMYK...

Depending on the colors used there won't be much expected difference in the RGB doc, since most CMYK colors are covered by sRGB too, thus it might overall not be directly obviously visible if things have changed here.

gamut.png.dd7e814dcb28235fd4c54525cfd390e1.png

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

19 minutes ago, v_kyr said:

That's right and was also my first thought, but then the OP said for embedded images, which might not be handled the same way here if they contain their own applied/embedded color profile. Thus we were looking if there is some way to detect then which color space is applied to embedded images and the like. - Also don't forget there can be bugs related to this and it's handling, which wouldn't be the first time.

The OP wrote here that "that the images are still CMYK, and verified by clicking on an image and seeing the CMYK file name still in the upper left corner. It was obvious that when I clicked Convert, nothing happened." But that turned out to be only because the file name included "CMYK," as mentioned here.

So once we learned that, we really were not looking for anything other than an explanation for why the colors in an embedded document might look different from those in a stand alone version of that document. I think that can be fully explained by the usual & expected differences in gamut, transmissive vs. reflective color models, & so on in different color spaces.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

@R C-R That was slightly irritating to understand (at least for me), first I thought he might got an AD related indication for the actual color space usage. But it seems he himself named the files this way instead and thus those were shown up like that. - However, I hope he get's things sorted out right now.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

1 minute ago, >|< said:

To me, the OP was puzzled by colours in a CMYK document not looking different when that CMYK document was embedded in an RGB document.

As we know, the RGB colour space (presumably sRGB since the project was for a web ad) is very likely going to contain all colours that were in the CMYK document, and so the lack of a visible difference was normal.

 

Yes somehow it seems like that and there are only very few CMYK colors which aren't covered by sRGB gamut, so a visual looking difference (like partly into the opposite sRGB -> CMYK direction) can't be really seen here.

Thus I was looking if Designer maybe has somewhere an indication of the used color space for placed in images, something like the Photo "Studio->Info" panel or the like, which will show then as a prove.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

30 minutes ago, v_kyr said:

Thus I was looking if Designer maybe has somewhere an indication of the used color space for placed in images, something like the Photo "Studio->Info" panel or the like, which will show then as a prove.

If you use the Affinity Photo Info panel, you get the info from the current document's color space because (once again) a document can have only one color space.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Just now, R C-R said:

If you use the Affinity Photo Info panel, you get the info from the current document's color space because (once again) a document can have only one color space.

(Once again) I already know that it's logical for the whole doc! - The point is instead checking for embedded images etc. their initial color space as you can do in Photo.

FOR EXAMPLE: In Photo I can make a sRGB doc and place let's say a CMYK APhoto file inside. The doc itself and thus the placed inside shown file have and show up sRGB (in the Info panel for the doc). Now I expand the embedded file (which shows up now in a seperate tab with <Embedded>) and take a look into the Info panel it shows me CMYK color profile. Is it now clearer for you what I was looking for in Designer?

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

14 minutes ago, >|< said:

As far as I know, the only place any of the current Affinity apps will tell you the colour profile of an embedded file while inspecting the parent document is the Resource Manager of Publisher beta.

Good to know have to try that out and see how that overview looks like. - Something like that would be good to have in the other apps too, since they can deal with embedded files too. In Photo you can see the color profile at least in the Info panel then for an expanded embedded file .

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

1 hour ago, v_kyr said:

@R C-R That was slightly irritating to understand (at least for me), first I thought he might got an AD related indication for the actual color space usage. But it seems he himself named the files this way instead and thus those were shown up like that. - However, I hope he get's things sorted out right now.

I understand how that was confusing. I admitted yesterday that I had mistakenly thought the readout was showing the color space type, when it was my own naming process. Sorry for the confusion. I'm still learning about Designer. And yes, I got my concerns sorted out and mentioned it in a post yesterday that when creating an occasional ad at a different size in RGB that was originally CMYK, I'll simply open each component CMYK file in Photoshop, convert to RGB, re-save with 'RGB' in the file name, and use the Replace Image/Document option.

Link to comment
Share on other sites

1 hour ago, v_kyr said:

Is it now clearer for you what I was looking for in Designer?

Not really. The embedded file cannot use its initial color space once it is embedded in a different document. It can only use the color space of that document. So what is the point of checking its color space in the <Embedded> document window or tab?

1 hour ago, v_kyr said:

In Photo you can see the color profile at least in the Info panel then for an expanded embedded file .

A bit off-topic, but confusingly, "color profile" can refer to either an ICC color profile or to a color space ("Color Format" in Affinity-speak), but either way this specifies how colors are mapped between input or output devices via the profile connection space (PCS). It is a complicated subject, but as mentioned here, one thing to keep in mind is there are 3 different families of standardized color space profiles, only one of which is CMY based.

If nothing else, this means there is no one definitively "right" way to map the colors between RGB & CMYK color spaces.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

While I appreciate the theory that a document has only 1 color space, and that placed images or embedded documents have their color space converted, it's not true for embedded documents. (I'm not sure about (Image) layers; I'm talking about (Embedded document) layers).

Here's a simple .afphoto file where the document color space is CMYK. It contains a PDF that I exported from an RGB photo, with an RGB color space, and placed in the CMYK file.

Also two screenshots. The first of the color space for the outer (parent) document (CMYK) and the second of the embedded document (RGB) after I double-clicked it and opened a new tab in Photo for it. So I have a CMYK document containing an RGB document, in Photo.

cmykrgb.afphoto

cmyk.png.3f66db1f7b4ea9e2c784c28875aa9681.png

rgb.png.b318aeda4034ca3da6455fbef5e3f061.png

-- 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, R C-R said:

Not really. The embedded file cannot use its initial color space once it is embedded in a different document. It can only use the color space of that document. So what is the point of checking its color space in the <Embedded> document window or tab?

Seeing it's initial associated used color space, or seeing what or if a color profile was applied etc. Why do you think Publisher's Resource Manager lists those then (as >|< pointed above to), if it is that totally unimportant to know (for all the DTP and prepress/printing guys out there) since it uses the doc color space either way? OIW then why should it be important to see that Affinity is probably assigning a greyscale profile falsely to an EPS file on usage.

1 hour ago, R C-R said:

A bit off-topic, but confusingly, "color profile" can refer to either an ICC color profile or to a color space ("Color Format" in Affinity-speak), but either way ...

Let's see this the Bruce Fraser (Real World Color Management) way ...

Quote

When we reproduce color on a physical device, whether it's a monitor, a piece of transparency film, or a printed page, we do so by manipulating red, green, and blue light.

In the case of true RGB devices such as monitors, scanners and digital cameras, we work with red, green, and blue light directly. With film and printing, we still manipulate red, green, and blue light, but we do so indirectly,using CMY pigments to subtract the wavelengths from a white background - cyan absorbs red light, magenta absorbs green light, and yellow absorbs blue iight - hence the term "subtractive" primary colors. Most digital color is encoded to represent varying amounts of either R, G, and B or C, M, and Y, or, in commercial printing and some (but not all) desktop printers, C, M, Y, and K (for BlacK).

Unfortunately, these mathematical models of color are quite ambiguous. You can think of an RGB or CMYK file as containing, not color, but rather a recipefor color that each device interprets according to it's own capabilities. If you give 20 cooks the same recipe, you'll almost certainly get 20 slightly different dishes as a result. Likewise, if you send the same RGB file to 20 different monitors, or the same CMYK file to 20 different presses, you'll get 20 slightly (or in some cases, more than slightly) different images. You can readily see this in any store that sells television sets. You'll see 20 televisions all lined up, of various makes and models, all tuned to the same station, and all producing somewhat different colors. They're receiving the same recipe but their different characteristics generate different visible results. This even happens within the same make and model of television.
The RGB and CMYK models originated in the analog rather than the digital world. Neither was designed as an accurate mathematical description of color: they're really control siganls that we send to our various color devices to make them produce something that we eventually experience as color. So you should always think of RGB or CMYK numhers as tuned for a specific device.

... and for profiles ...

Quote

Profiles are conceptually quite simple, though their anatomy can be complex. ...

For now, though, we'll concentrate on their function.

A profile can describe a single device, such as an individual scanner, monitor, or printer; a class of devices, such as Apple Cinema Displays, Epson Stylus Photo 1280 printers, or SWOP presses; or an abstract color space. such as Adobe RGB (1998) or CIE LAB. But no matter what it describes, a profile is essentiany a lookup table, with one set of entries that contains device control signal values RGB or CMYK numbers- and another set that contains the actual colors, expressed in the PCS, that those control signals produce.

A profile gives RGB or CMYK values meaning. Raw RGB or CMYK values are ambiguous they produce diffent colors when we send them to different devices. A profile by itself, doesn't change the RGB or CMYK numbers it simply gives them a specific meaning, saying, in effect, that these RGB or CMYK numbers represent this specific color (defined in XYZ or LAB).
By the same token, a profile doesn't alter a device's behavior - it just describes that behavior. ...

 

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

2 hours ago, walt.farrell said:

Also two screenshots. The first of the color space for the outer (parent) document (CMYK) and the second of the embedded document (RGB) after I double-clicked it and opened a new tab in Photo for it. So I have a CMYK document containing an RGB document, in Photo.

Nope. The embedded file uses the parent document's color space, period. It does not matter what the new tab says because it is not showing the color space of the document once it is embedded in the parent.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 hour ago, v_kyr said:

Unfortunately, these mathematical models of color are quite ambiguous.
{...}
So you should always think of RGB or CMYK numhers as tuned for a specific device.

Which is why I said "If nothing else, this means there is no one definitively 'right' way to map the colors between RGB & CMYK color spaces."

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

On 2/13/2019 at 9:49 PM, R C-R said:

Nope. The embedded file uses the parent document's color space, period. It does not matter what the new tab says because it is not showing the color space of the document once it is embedded in the parent.

For what seems like a definitive answer on this (which happened to come up in another topic),

My net from James's response: Yes, the embedded images or documents keep their own color space, except as needed for presentation on-screen or when exporting. Which should mean that no one needs to worry about what color space is the embedded image or document. It will look right on-screen, and it will look right when exported.

Yes, physically in the .afphoto/design/pub document they can have different spaces, but it doesn't matter from a practical or visual perspective.

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

4 minutes ago, walt.farrell said:

My net from James's response: Yes, the embedded images or documents keep their own color space, except as needed for presentation on-screen or when exporting. 

He said:

Quote

So for the benefit of clarification, you might be able to technically have RGB layers (specifically, embedded documents and placed images) within a CMYK document, but you cannot avoid the colour conversion that is performed to ensure those layers display correctly.

This means the conversion is non-destructive, but the embedded document is still converted to the parent's color space for use in the document it is embedded into. This is easy to see from this simple test:

Create a new document with any RGB or CMYK color format. Add a pixel layer & brush something on it in any color other than grey. Place another document with any RGB or CMYK color format in it. Now change the color format of the new document to greyscale. The embedded document will be displayed as a greyscale image, because a document can use only one color space.

Now change the Now change the color format of the new document back to the original RGB or CMYK color format. The pixel layer will remain greyscale but the embedded document will still retain its color, although it may look different if its color format is not the same as the parent document it is embedded into. This is probably most evident if the embedded document uses 16 bit color & the parent layer uses 8 bit color.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

43 minutes ago, >|< said:

Walt is correct. The embedded object is not converted. There are colour conversions in rendering the display or an export, but the embedded object itself is not converted.

It is converted non-destructively for use in the parent document. That's why changing the color format of the parent document does not affect the color format embedded in any embedded documents it might include.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

19 hours ago, >|< said:

Fact: the actual embedded object is not converted. A representation of it is rendered in the document colour space, but the object itself is not converted.

Technically, if you mean an "(Embedded Document)" layer considered as an individual object, as @James Ritson mentioned in the other topic, you cannot avoid the color conversion of that object in the parent document. The embedded document is not converted, but the layer must be.

But technicalities aside, as @walt.farrell mentioned, in practical terms users don't have to worry about this color space conversion.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Just for grins, I created this embedded embedded.afdesign file to see what happens when a document has an embedded document that has an embedded document of its own. There does not seem to be a limit on how 'deep' one can go with that, but I got frequent app crashes when trying to do various things in the <embedded> tabs, & there was not much repeatability in what would crash it.

The one, not at all surprising, thing that would crash it consistently & immediately is trying to Place the saved document into itself. 

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • 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.