Color change on EPS import V1 vs V2 of designer and Photo (mac version)

[mixbus]

Hello, sorry if this has been mentioned before, but I couldn't find anything on this topic. 

I have lots of EPS files that I need to resize and color convert for a client, and on import the initial colors do not match from V1 to V2 of either Designer or Photo on the Mac. 
None of the changes I need to make come out correctly since they don't import correctly from the start. 

All the import settings (color space etc...) are the same in both versions as far as I can tell.

Any ideas of what might be going on?  

Screen shots of the imported files are attached as well as the original eps I'm working off of.

Thanks.  

CDdictART#00794.eps

[Hangman]

Hi @mixbus and welcome to the forums,

This is unfortunately a known bug that has previously been reported and is still awaiting a fix. Basically what's happening is that the Cyan, Magenta and Yellow sliders are incorrectly set to 50% on opening the file when the respective slider value is 50% or above e.g,

• C:100 M:0 Y:67 K:29 opens as C:50 M:0 Y:50 K:29
• C:0 M:30 Y:100 K:0 opens as C:0 M:30 Y:50 K:0

If you need to work in V2 then you can open the eps files in V1 and re-export them as eps files (or save them as AD files) and they will then open in V2 with the correct colours which isn't ideal if you have loads to amend...

If you have V1 it's possibly going to be quicker to work in V1 for now unless you're happy to open all the files and re-export/save them. I would do a quick test first just to check the colours are correct are re-exporting...

[mixbus]

Thanks for the info. That helps to know it's a bug, and has been reported. 

I have a quick workflow in place to do the processing needed to open, change what's needed, & export them to png per clients specs.

I'll just keep using V1 for now since there are so many to do, and look for an update at some point that fixes the issue before using V2 again. 

I appreciate the help. 

 

[Hangman]

No problem at all, I hope everything goes well with the job and hopefully we'll see a fix for this issue in an upcoming release.

[lacerto]

Oddly I get this error only when opening or placing this file in Affinity Photo macOS 2.04 version, but not when opening or placing it in any other Affinity 2.x app, i.e., not when opening or placing it in Publisher 2.04, Designer 2.04, or any of the three current beta versions. On Windows the file opens fine in any version.

Interestingly, when opened using Designer 2.04 macOS version, and exported to EPS, the resulting file can then opened without problems in Photo 2.04, so it seems that the error is related to some specific color encoding style (the incorrectly read color was defined in regular CMYK decimal percentage notation component values between 0..1, but as CMYK Custom color [as 1 0 0.6700 0.2900 (cd green PMS 341)] showing that the color was initially picked from a PANTONE library).

 

In one instance, though, I think I had a situation in Photo 2.04, when opening an EPS file produced by Designer 2. where the color had correct appearance but incorrect color definition (those limited to 50%), but when I tried, I could not reproduce the behavior. 

[Hangman]

3 hours ago, lacerto said:

Oddly I get this error only when opening or placing this file in Affinity Photo macOS 2.04 version, but not when opening or placing it in any other Affinity 2.x app, i.e., not when opening or placing it in Publisher 2.04, Designer 2.04, or any of the three current beta versions.

For me it's fine in all three v1 apps but incorrect in all three v2 apps, both 2.0.4 and 2.1.0.(1790)... I'm scratching my head trying to think of reasons why the file opens correctly for you in both Designer and Publisher 2.0.4 but not Photo 2.0.4. 🤔

[mixbus]

Yes. for me it's fine in all three v1 apps but incorrect in all three v2 apps. 

From what I've ben told, these files were saved in some version of Illustrator before they got to me. 

FYI - Don't know if it matters, but I'm using an i7 intel imac running Monterey. It's the latest OS my mac will run. 

At least I can still use V1 to finish this current batch of files, and stick with it until this bug gets worked out. 

[Hangman]

Looking at the original bug report for this issue, AFD-6216, it looks as though the v2 apps are ignoring the Pantone colours specified in the eps file, despite being declared in the file itself...

They are instead being converted to incorrect CMYK values (the 50% issue), though having said that, in v1 the Pantones aren't recognised either but it appears the CMYK conversion is correct.

If the eps file is opened in Apple Preview and exported it to a PDF and then reopened in the v2 Affinity Apps, the Pantone Colours are now recognised...

[mixbus]

That is confirmed here.

Opening the EPS in Apple Preview, export to a PDF, and then reopened in the v2 Affinity Apps, the Pantone Colors are now recognized...

[lacerto]

15 hours ago, Hangman said:

I'm scratching my head trying to think of reasons why the file opens correctly for you in both Designer and Publisher 2.0.4 but not Photo 2.0.4.

It seems the error is in the macOS Intel build, only. I am running 2.04 Photo using Rosetta because I have Intel-based plugins. Photo beta is running in native Apple Silicon mode, as are 2.x Publisher and Designer, and that explains it.

As for PANTONE (or generally spot) colors not being recognized, that is an omission in Affinity apps: they do not read in spot colors (not al least in EPS files created by Adobe or Corel, interesting to know that Preview-created spot colors are read in!), nor can they export ones in EPS format.

[lacerto]

16 hours ago, mixbus said:

Opening the EPS in Apple Preview, export to a PDF, and then reopened in the v2 Affinity Apps, the Pantone Colors are now recognized...

Well, missed the PDF part. That of course explains it. But in EPS format, Affinity apps sadly do not support spot colors, not when importing (opening or placing), and not when exporting. [And now there is additionally a glitch where 2.x macOS versions read in at least spot color alt definitions incorrectly.]

[Hangman]

27 minutes ago, lacerto said:

It seems the error is in the macOS Intel build, only. I am running 2.04 Photo using Rosetta because I have Intel-based plugins. Photo beta is running in native Apple Silicon mode, as are 2.x Publisher and Designer, and that explains it.

Interesting...

33 minutes ago, lacerto said:

As for PANTONE (or generally spot) colors not being recognized, that is an omission is Affinity apps: they do not read in spot colors (not al least in EPS files created by Adobe or Corel, interesting to know that Preview-created spot colors are read in!), nor can they export ones in EPS format.

This is something I've never really understood logic wise because this means when opening an eps file that uses Pantone Colours you end up with a colour converted document which ignores any Pantone colour specifications... In AI (from distant memory), importing an eps file effectively creates a document palette which includes all colours used in the file whether RGB, CMYK or Pantone... It would be great to see the Affinity Apps replicate that...

[lacerto]

17 hours ago, Hangman said:

In AI (from distant memory), importing an eps file effectively creates a document palette which includes all colours used in the file whether RGB, CMYK or Pantone...

Yes, and in addition swatches are created as global and assignments have been made. It would be great if this would be done at least when opening PDF files, which have spot color definitions recognized, but e,g, overprint attribute is ignored (as it is in EPS format). I am not sure if this is going to ever happen as it seems Serif officially considers EPS as an obsolete file format (e.g. font embedding is not supported, and probably never will be -- which, on the other hand, may be just a good thing as auto-conversion to outlines is very useful and is currently available only in context of EPS files). 

[lacerto]

I had yet another look on this, and it seems it is not, after all, "just" an issue related to Intel vs. Silicon build. They behave differently, but the native builds, too, may behave erroneously when reading in spot-color based alt-color definitions.

It, however, does not seem to depend on the way the color is encoded, since CorelDRAW appears to define them similarly as Illustrator (e.g., in this case like this -- on the clip I seem have a couple of typos in definitions):

%%DocumentCustomColors: (PANTONE 341 C)
%%CMYKCustomColor: 0.85 0.14 0.67 0.3 (PANTONE 341 C)

so who knows what actually triggers the error, but it is clear that something was broken in macOS code in context of reading color definitions from an EPS file, when it was updated for versions 2. There are color management issues now on macOS, and errors like these, introduced in versions 2. Should macOS users be worried? Probably not, Serif should be able to fix these errors simply by checking how the code is written on the Windows side  

@Hangman, as you seem to have reported this bug (?), have you really been able to reproduce consistently the kind of error where CMYK component values get reduced to 50%, and specifically CMYK definitions, without spot colors involved? As you can see in the clip above, this is not what happens when Photo and Designer read in Corel-encoded CMYK and spot color definitions (for 341C, which has different CMYK values because the spot colors are LAB based and will be converted to CMYK a bit differently and depending on the target CMYK). So CMYK definitions are read just correctly, but the spot color alt color definition gets misinterpreted. It might well be that the definition is actually read in context where the objects are described instead of the header section, but I did not have a closer look.

UPDATE: This error has not been fixed in the 2.1.0 release version of the apps.

UPDATE2: Oddly, i just noticed that I can reproduce this glitch also using Photo 1.10.6 (macOS Ventura 13.3.1 (a) running using Rosetta, so it is an old bug on macOS.

[Hangman]

@lacerto, I can finally reply to this post... I wanted to run some tests exporting eps files from Vectorsyler but quickly realised that VS was converting any spot colours to CMYK anyway and not exporting the spot colour itself as part of the file.

After filing a bug report a while back, a new version of VS has now been released which adds spot colur support to exported eps files so I've at long last been able to run a few tests, though VS is buggy as hell.

On 5/15/2023 at 10:57 AM, lacerto said:

@Hangman, as you seem to have reported this bug (?), have you really been able to reproduce consistently the kind of error where CMYK component values get reduced to 50%...

Yes...

On 5/15/2023 at 10:57 AM, lacerto said:

and specifically CMYK definitions, without spot colors involved?

No, the 50% issue is only ever a direct result of Pantone colours being exported in an eps file where the Affinity suite ignores the Pantone reference, converts the Pantone to CMYK but changes any converted CMYK values above 50% to 50% resulting in the washed out colours we see when opening an eps file in Affinity apps.

I can only currently test on Intel but for me both opening and placing the attached eps in all three apps demonstrates the 50% issue.

The pdf however, as expected is fine...

Vectorstyler uses it's own CMYK percentage definitions it seems...

[/Separation (PANTONE 341 CP)
/DeviceCMYK
{dup 0.95 mul exch dup 0.01 mul exch dup 0.75 mul exch dup 0.26 mul exch pop} ]

 

EPS Colours VS.eps

EPS Colours VS.pdf

[lacerto]

Thanks for getting back with this -- though I am not sure I quite got the point of using one buggy app to demonstrate false behavior of another! VS is (continues to be), as you mentioned, buggy as hell. So when you open an EPS file containing a Corel-defined PANTONE color, in one instance you can get an empty file, and in another instance something as crazy as when opening one in (macOS version of) Affinity app:

On the other hand, when I tried to export a spot color from VS (latest Windows version 1.1.085), it was more or less as expected. I used the latest V5 Solid Coated PANTONE Library that has Lab definitions, and VS both exported the spot color without problems, and used as its CMYK values pretty much the same conversion values as Photoshop, when targeting to the same profile (ISO Coated v2):

 Note that you have used PANTONE CMYK color library, not a spot color [special ink] library. I have not recently followed closely development of VS but previously I do not think the the app had any inbuilt PANTONE libraries, but it has vast support of reading them (both .ACB and .ASE based), so if installed with other apps, they will be available also in VS. The app continues to be quite useful even it has many issues. Perhaps ability to read spot colors got broken in some recent version, but exporting at least seems to work now reasonably well. But as mentioned, this misreading of alt color space values in context of spot colors seems to have stayed with Affinity apps for years (at least from version 1.10.6). It is worse on macOS versions since on Windows it seems that at least CMYK alt color definitions for spot colors get correctly read, but Lab and RGB based definitions are coarsely off (as demonstrated above; VS writes RGB based alt color definitions, which AI reads correctly and Designer incorrectly). [BTW: Notice on the video at 2:21 how secondary CMYK values so false conversion values; the right ones show at time the spot color was initially converted and in exported EPS file in Illustrator, and are nearly identical with ones shown in Photoshop. VS if full of stuff like this...]

As for getting the CMYK 50% limit, can you also get it with the EPS files used in the clip above and attached below?

pms341c_fromcorel2.eps

pms341c_fromvs.eps

UPDATE: Ok, I now got your point, opening the (VS produced) EPS file with spot color definitions in Photo (ANY Photo version running on Silicon based mac, using Rosetta = Intel build) shows that 50% limit (but not when running in native mode). Ironically, on Windows where you have Intel builds by definition, none of Affinity version show the issue. And curiously, it seems to be depending on the method the alt color is specified, whether the issue shows. So on my system (M1 chip on Ventura 13.3.1 (a)) the Corel-created EPS with spot color definition does not show the 50% limit, no matter if running in Rosetta mode or not. On the other hand, as shown in one of my earlier posts in this thread, running in native mode does not necessarily display the alt CMYK color definition correctly, either, even when not suffering from the 50% limit. It is badly broken, and as it has been for years, I am not optimistic that this will ever get fixed.

UPDATE2: If I understood correctly you and OP, the issue is further complicated by the situation where the 50% limit issue does not occur on older Intel-based macs running 1.x based apps? That much is clear the spot colors are not supported in EPS format in Affinity apps, so therefore their alt color spaces are not supported, either. But the variation of bugs in the ways they are not supported is also mind-boggling.

[Hangman]

38 minutes ago, lacerto said:

Thanks for getting back with this -- though I am not sure I quite got the point of using one buggy app to demonstrate false behavior of another! VS is (continues to be), as you mentioned, buggy as hell.

After your previous post referencing CorelDraw, literally for no other reason than wanting to find another application able to generate eps files to test against Illustrator and CorelDraw to rule out this being an Illustrator issue I downloaded a trial version of VS never having used it before in the hope of being able to quickly generate an eps file containing spot colours only to find it couldn't.

After filing a bug report they've just fixed the issue the latest release (1.1.085) so now you can and like you say, it appears to export spot colours without issue with pretty accurate CMYK conversions.

Having said that, after watching your VS videos I realised I had no sliders showing in the colour palette and was unable to get them to display despite being selected in the VS colour palette dropdown. A VS factory reset has now remedied that and now the exported eps files are no longer displaying the 50% CMYK issue, go figure!

It seems somewhat of a coincidcnce that the VS exported eps file uploaded in the previous post exhibited the exact same 50% CMYK issue as the Illustrator file in the original post of this thread. There have been a few reports of this issue with Illustrator files. Here's another example...

Logo Italian Embassy.eps

One of the useful features of VS is definitely its ability to read and write palettes in multiple formats. In the process of experimenting with that I discovered a bug in the Affinity apps in that they won't read in Lab colour when defined in a .ase file, so I'm curious as to whether your V5 Solid Coated PANTONE Library that uses Lab definitions can be opened in the Affinity Apps or is the file in question not a .ase file. I tried to open a V3 Solid Coated PANTONE Library that uses Lab definitions in AD and I end up with an empty palette, yet it opens without issue in VS.

 

3 hours ago, lacerto said:

Note that you have used PANTONE CMYK color library, not a spot color library.

I actually used the Affinity Pantone csv file located in the Resources folder, which uses RGB values, opened it in VS but defined the colours used in the test file as spot colours then exported to EPS and PDF. The exported EPS file exhibited the 50% CMYK issue when opened in Affinity 2 apps, the PDF correctly shows the spot colours.

 

Note: creating palettes in VS using csv files only supports RGB and CMYK values, not LAB or any other colour format.

Interestingly after the VS factory reset, I've reapplied the colour in the file previously uploaded file that uses the CMYK defined Pantone colours converted to spots and I've also created a version using a V3 Solid Coated PANTONE Library that uses Lab definitions (so basically the same as your test, just a slightly older version) and when opening the VS exported eps files they no longer display the 50% CMYK conversion issue, it's as per your tests where the CMYK colours are defined correctly.

 

49 minutes ago, lacerto said:

So when you open an EPS file containing a Corel-defined PANTONE color, in one instance you can get an empty file, and in another instance something as crazy as when opening one in (macOS version of) Affinity app:

I see the same thing opening your Corel Draw generated eps file in VS, pms 341 C is being interpretted in RGB (255, 0 255) in VS but CMYK (100, 53, 66, 0) in AD. based on the assignment of the ISO Coated v2 profile, though that looks like a different issue to me...

 

7 hours ago, lacerto said:

As for getting the CMYK 50% limit, can you also get it with the EPS files used in the clip above and attached below?

No, but are you able to generate an eps from Illustrator which includes some Document Custom Colours, (I assume in Adobe speak this mean Pantones converted to CMYK or is this something else entirely) since this appears to be what is causing the problems for Affinity v2 apps on opening these eps files...

pms_cmyk_swatches_vs_export.eps

pms_lab_swatches_vs_export.eps

 

[mixbus]

8 hours ago, lacerto said:

UPDATE2: If I understood correctly you and OP, the issue is further complicated by the situation where the 50% limit issue does not occur on older Intel-based macs running 1.x based apps? That much is clear the spot colors are not supported in EPS format in Affinity apps, so therefore their alt color spaces are not supported, either. But the variation of bugs in the ways they are not supported is also mind-boggling.

OP here... That is correct on my end. The 50% limit issue does not occur on my older Intel-based mac running 1.x based apps.
I am still waiting to upgrade and won't be able to test this on a M series chip for awhile. 

Thanks everyone for the amazing investigative work! 

[lacerto]

44 minutes ago, Hangman said:

V5 Solid Coated PANTONE Library that uses Lab definitions can be opened in the Affinity Apps or is the file in question not a .ase file

It is an .acb file but created from CorelDRAW latest version which has Lab definitions. I used VS to read in Corel palette and then used Photoshop script to compile an .acb file. As far as I know Affinity apps only read CMYK and RGB based definitions.

44 minutes ago, Hangman said:

I actually used the Affinity Pantone csv file located in the Resources folder, which uses RGB values, opened it in VS but defined the colours used in the test file as spot colours then exported to EPS and PDF

Ok, I was referring more specifically to "custom" CMYK that you mentioned that VS uses -- I was wondering what you meant because I assumed that VS does not come with PANTONE libraries, so the CMYK based value it would use might proceed from 341 CP, where "P" refers to process color definition (rather than Lab trying to describe a special ink). But yes, technically it was a spot color and would then cause similar error in reading the color definition.

44 minutes ago, Hangman said:

No, but are you able to generate an eps from Illustrator which includes some Document Custom Colours, (I assume in Adobe speak this mean Pantones converted to CMYK or is this something else entirely) since this appears to be what is causing the problems for Affinity v2 apps on opening these eps files...

I'll run a few tests later today. It is interesting that Affinity apps now read correctly the CMYK alt color specs of VS exported spot colors. It might be related to app specifying multiple alt color space, and this confusing the Affinity apps, but that this is so  mixed within versions, and platforms, is odd. As said, I can reproduce this issue also on 1.x versions running Rosetta mode on Silicon macs, but you have 1.x versions reading alt color spaces correctly on Intel-based macs! (And then there are cases where colors are also read incorrectly when running 1.x and 2.x apps in native mode on Silicon macs, reading e.g. Corel and VS encoded EPS files, while files encoded by Adobe then show correctly.) Affinity and VS read errors in interpreting spot special ink rendering colors are different but might well be symptoms of the same kind of reading errors. I do not know if apps typically (or even always, even when commercial library colors are referred) depend on file-specified rendering color, but it seems that there are multiple ways to describe it, and this is causing issues for Affinity apps and VS.

[Hangman]

48 minutes ago, lacerto said:

It is an .acb file but created from CorelDRAW latest version which has Lab definitions.

Out of interest, if you open your CorelDraw generated Pantone colour .acb file in Vectostyler and then export it as a .ase file in VS does it open as a blank palette in Affinity Designer or does it open correctly?

48 minutes ago, lacerto said:

As far as I know Affinity apps only read CMYK and RGB based definitions.

I have queried this, the initial feedback was that LAB colour definitions should be supported as well, though I suspect that may not actually be the case as I've played around with both XML and JSON palette's using LAB definitions since VS doesn't support CSV files with colour specs other than CMYK and RGB but on importing both the XML and JSON palettes into VS, exporting to .ase and importing to AD, I see the palette but it's completely empty so the CMYK and RGB based definitions 'only' seem to make sense, though it has been logged for investigation by Serif.

48 minutes ago, lacerto said:

Ok, I was referring more specifically to "custom" CMYK that you mentioned that VS uses -- I was wondering what you meant because I assumed that VS does not come with PANTONE libraries, so the CMYK based value it would use might proceed from 341 CP, where "P" refers to process color definition (rather than Lab trying to describe a special ink). But yes, technically it was a spot color and would then cause similar error in reading the color definition.

I realised after posting that I'd inadvertently picked the wrong csv file, hence I tested again using Serif's PANTONE Formula Guide Solid Coated V5.csv file though again it is defined using sRGB values though I don't think this is the version used internally by Affinity apps (though I could be wrong). As mentinoed above, I also tested a V3 Solid Coated PANTONE Library that uses Lab definitions and for whatever reason after a factory reset of VS I can no longer generate EPS files from VS that demonstrate the 50% CMYK issue in Affinity apps which on the one hand is good and then seems to point to this being an Illustrator eps interpretation issue in Affinty V2 apps, though like you say, you can reproduce this issue also on 1.x versions running Rosetta mode on Silicon macs, I can't in 1.x versions running Intel so yes, very odd indeed...

The Illustrator generated eps files, both the OPs and the other one I attached open in VS and AD v1.x without issue but incorrectly in v2.x on Intel Macs.

 

[lacerto]

1 hour ago, Hangman said:

Out of interest, if you open your CorelDraw generated Pantone colour .acb file in Vectostyler and then export it as a .ase file in VS does it open as a blank palette in Affinity Designer or does it open correctly?

It opens as a blank palette, but it does also in e.g. Illustrator, too, and when tried to be imported to Photoshop (CC2023), nothing is imported and the following error message is shown:

I wonder if it means the Lab color space is only supported in .acb files (or at least not supported in .ase swatch exchange)?

[Hangman]

A quick update...

I spotted that VS 1.1.085 wasn't retaining the spot colours applied to objects on the canvas when the file was saved and then re-opened resulting in having to re-apply spot colours to their associated elements.

Bug fixed within a couple of hours and 1.1.086 update released.

Interestingly I'm now seeing a repeat of the CMYK 50% issue as follows...

• Apply spot colours to a series of rectangles on the canvas using LAB specified Pantone colours in VS
• Export to an eps file from VS
• Re-open eps file in VS and the specified spot colours are now a mix of RGB and CMYK rather than the originally specified spot colours
• Open the same eps file in AD v2.x and any colour that now appears using a CMYK specification in the eps file now displays the CMYK 50% issue, any colour now designated with an RGB specification appears without the CMYK 50% issue.

I am however, on initial testing, not seeing the same issue when using a PANTONE CMYK color library to specify the colours in VS and then exporting to eps...

pms_lab_swatches_vs_export.eps

Pantone LAB Colour Palette.vstyler

 

[Hangman]

36 minutes ago, lacerto said:

I wonder if it means the Lab color space is only supported in .acb files (or at least not supported in .ase swatch exchange)?

ASE files support four colour spaces, RGB, LAB, CMYK and Greyscale, so I'm now beginning to wonder whether this is yet another bug in VS?

Edit
Response from VS - "This sounds like a bug, added it to the backlog"

 

[lacerto]

57 minutes ago, Hangman said:

ASE files support four colour spaces, RGB, LAB, CMYK and Greyscale, so I'm now beginning to wonder whether this is yet another bug in VS?

Ok, I see. After some tests it seems that it is the Lab based spot colors that get misread in Affinity apps (both 1.x and 2.x when run in Rosetta mode; and 2.x when run on Intel-based macs). On Windows this does not happen but the spot rendering color may be misread all the same. It would appear that only originally CMYK based definitions get read correctly. Lab values are possibly directly read as CMYK values and then reset (because considered "erroneous") to standard values like 0, 100, 50 (or in case of VS, mid RGB values like 127). [My test is based on AI and Corel based PANTONE spot color definitions from various libraries, most of which Lab based, and the remaining CMYK based; Lab based get misread, CMYK based do not.]

[Hangman]

It sounds like a possible mathematical error, I'm not sure whether the conversion goes Lab to RGB, followed by RGB to CMY and then CMY to CMYK but I could see a pretty simple error in the conversion formula being the culprit if that is the case...