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

lacerto

Members
  • Posts

    5,729
  • Joined

Posts posted by lacerto

  1. 1 hour ago, henryanthony said:

    Interesting. I understand what you are saying but, have to take your word for it because I cannot set CMYK source to ISO Coated v2 and target sRGB. Seems V1 won't allow it as far as I know. Be advised I have a lot to learn regarding Affinity. I use only a small percentage of the capabilities.

    The specific CMYK and RGB color profile pair that you have effective in the document is not important -- I was just mentioning the ones I had active because the values are different from yours. It seems you have the Affinity default CMYK and sRGB profiles (US Web Coated V2 and sRGB) effective in your document. It just seems that something went wrong when you converted the CMYK values to HSL. The other two conversions (to RGB and RGB Hex) are correct.

    See the video below. The easiest method to have colors converted is to turn off the lock in the Color panel and just switch the color model while having the object to be converted selected:

    Note how the document is created by using US Coated Web v2 as the CMYK profile, just to demonstrate the conversion values from that profile to the default sRGB profile (resulting in values that you have in your document, except for HSL conversion which had failed in your document). After that the document color mode is switched to RGB (using sRGB profile), to demonstrate that the color values and visual appearance stay the same (the visual appearance could change, if the sRGB profile cannot produce the defined CMYK values, but in this case it can). After that, the document color mode is switched back to CMYK and then the CMYK color profile is changed from US Web Coated v2 to ISO Coated V2 (by using "Assign" option so that the existing color values are not changed). Finally the CMYK value C76 M5 Y25 K5 is converted to RGB, RGB Hex and HSL to demonstrate how the conversion values are slightly different because the CMYK source profile is now different.

    When an Affinity document is created, it gets its active and latent color profiles assigned according to settings specified in Preferences > Color. These profiles determine how colors are converted from one color space to another, when using the Color panel. The assigned color profiles can be changed either by assignment or conversion via File > Document > Color (or Document > Convert Format / ICC Profile and Document > Assign ICC Profile commands in Photo) so that subsequent color conversion use a different source and destination profiles. It is a good idea to keep the lock of the Color panel turned on (the default setting), to avoid inadvertent color conversions, and have it unlocked only when actually wanting to convert colors (or temporarily checking the actual definition an object has). When the lock is turned on, switching the color model within the Color Panel will just show the color values in different color spaces without changing the selected objects' actual definitions. 

  2. Please note that conversions are dependent on the source and target profiles. 

    My CMYK source was ISO Coated v2 and target sRGB, and I got the following (tested v2 Affinity apps):

    image.png.673f0e6300d02871f2faf569761163d2.png

    <html>
    <h1 style="background-color:rgb(255, 255, 255);">CMYK 76, 5, 25, 5 Conversions to RGB, RGB Hex and HSL as copied from AD and AP Version 18:22 AM 6/6/2023</h1>
    <h1 style="background-color:rgb(0, 166, 185);">rgb(0, 166, 185)</h1>
    <h1 style="background-color:#00A6B9;">#00A6B9</h1>
    <h1 style="background-color:hsl(186, 100%, 36%);">hsl(186, 100%, 36%)</h1>
    </html>

     

  3. Here is yet another take on color management within a browser based color matching, palette creation and conversion utility. PANTONE Connect is a web-based service, whether as accessed from within Photoshop (or alike) as a plug-in, or used independently with a supported browser. The web app is more limited than e.g. former PANTONE Color Manager based utility that allowed profile based conversions (but IMO less accurately than doing the same e.g. within Adobe apps). But considering decreased printing needs with special inks, and modern late-bound production workflows (based on LAB based rendering of colors and RIP-produced conversions), combined with ISO workflows, need for profile-based accurate CMYK conversions is not as critical as it used to be.

    But the point is that there is basically no such thing as "CMYK colors" in display (RGB-based) environment, so whether CMYK definitions and profiles are supported at "browser-level" (or even at framework or OS level) is not necessarily the key question. Color management in a professional app is ultimately something that must be fully controllable at app-level, so the knowledge and logic needs to be enclosed and developed into the app itself. Rendering and conversions can be accurate even without dependence on "native" OS / framework / library based support (like within Adobe environment where Windows users by default use Adobe ACE based color engine and color management, instead of using Microsoft ICM based technology). The results are often a bit different, depending on the chosen technology. As mentioned, conversion values were different also when using the now legacy PANTONE Color Manager with user-specified profile and lighting environment.

    a) Photoshop CMYK document in US Web Coated v2 color space, C76 M5 Y25 K5 entered and matching special ink searched from within PANTONE Solid Coated v5 library (a different special ink might be found as the best match if using e.g. newsprint profiles, but then again, bright special inks would be an odd choice in such production conditions). The small swatches show PANTONE Connect suggested closest PANTONE Library matches within Photoshop: 7110 C (in Formula Guide Coated), 3123 CP, and 7110 CP (in Color Bridge Coated), and  P 121-7 C (in CMYK Coated). 

     cmyk2pms_desktop_ps.jpg.20577d67be5c0b0edae57e9faab4b6f0.jpg

    b) The closest matches in Formula Guide using PANTONE Connect web service:

    cmyk2pms_web_pantone_connect.jpg.03e9eb876356494cf1d492cd7c38a1f3.jpg

    "CMYK-equivalent" values of special inks are not shown in full color data, which is probably just wise because of gamut differences and lack of profile based matching. CMYK values however are shown when using Cross-Reference search within process-color based PANTONE libraries, e.g. below are the color details for 7710 CP:

    cmyk2pms_web_pantone_connect2.jpg.11ae25606b456235c533510f31e1a5ed.jpg

    It cannot be readily seen which profile is used for the CMYK values, and I have not found any documentation that explains the conversion, but so much is clear that colors are rendered differently within browser and Photoshop with a CMYK-based document open (I tried most common profiles to check if there is a clear best match, but without success). Especially 3123 CP (the closest process-color match that PANTONE Connect suggested for special ink 7110 C) looked pretty much different in Photoshop and within browser (where the colors were close enough). In terms of color accuracy in print production it is obvious that process colors should be evaluated and matched somewhere else than within a browser, even when using utility like PANTONE Connect.

    On the other hand, PANTONE Connect (still very much an app in development, and with many usability flaws) shows that there is no fundamental reason why a browser-based app could not be used for color conversions and rendering CMYK-based color values (like those in PANTONE's own CMYK based libraries), even if there is no native (browser-based) CMYK support. It is clearly on a different level when compared to free web-based color conversion utilities. When using modern bright and wide-gamut displays it is most important to be able to handle RGB values properly in the context of the monitor color gamut. If that is not controlled, everything else (like CMYK color rendering) naturally fails badly, as well (even if color values expressed were based on actual knowledge and experience, and production specs explicitly stated).

    UPDATE: As a real-time matching utility PANTONE Connect is more or less useless since its value-based (ad-hoc) color rendering is more or less horrible in all "supported" color models. This can clearly be seen above where the user-entered CMYK value is rendered and then "matched" against found library colors (whether process colors or special inks). The real-time rendered color is as bad as in any non-color managed web app, even when rendering user-defined sRGB values (on a wide-gamut display), but the found matches at least provide a clue on how the found library colors look like in color-managed environment and which one is the best match of the defined color... All in all, the utility has well deserved its one star rating in Adobe Plug-in collection. 

  4. 13 hours ago, matt0810 said:

    Trying to match CMYK to PMS but impossible and not sure what colour is correct, when entering a CMYK colour into online PMS conversion tool as they are showing completely different CMYK colours.

    If you use PMS to refer to PANTONE special inks, you should understand that whenever you have Affinity apps, their display of PANTONE inks is limited in more than one way. First, Affinity-based PANTONE rendering colors are defined in sRGB color space (rather than profile independent LAB), so their rendering is already artificially restricted so even if the hardware and current document color mode allowed display of full PMS color gamut, the library limitation would not permit it. Second (and worst), when you have Affinity document in CMYK color mode, all colors, including PANTONE special inks, are rendered to simulate the document CMYK target, and would typically show more desaturated than when printed on paper.

    If you have printed swatches, you should use them as a reference, especially in lack of software that can simulate more realistically the gamut of special inks. 

    Comparison of rendering of the same PANTONE Coated special ink in InDesign (where PANTONE rendering colors have been specified in color-profile independent LAB color model), and Affinity Publisher, where the rendering colors have been specified in sRGB, and where the document color mode further determines the appearance of these colors [Note that the forum limits the color space to sRGB, but the screenshot gives an idea of relative differences]: 

    image.png.d513a3affccb523094d18ae57a6d3d4d.png

    Having said that, a web service that show "CMYK-equivalents" of PANTONE special inks (obviously without any color management), is the least trustful reference of what PANTONE inks are going to look on paper.  

     

  5. 7 hours ago, Red Sands said:

    Browsers are not colour managed and are made for the screen's preferred colour space (sRGB), so it's close to the worst place to validate colours for print.

    Most modern web browsers are color managed, in some, like Fireworksfox, you need to turn it on (to make it do more than just assume sRGB). 

    You can test if yours is by visiting

    https://cameratico.com/tools/web-browser-color-management-test/

    On OS filesystem level the situation is as you described, but that has nothing to do with color values shown correctly or incorrectly on a web-based service. Technically they could be accurate, but most often they are not, but instead display color conversions based on abstract formulas without applying any kind of profile-based color management, and should in general be avoided.

  6. 16 hours ago, NotMyFault said:

    It is a bug (or known limitation) that edge initialising works only with scale factors up to 2x

    I am not sure what you mean? With certain specific situation or algorithm? In my example where I applied over 5 time (almost) uniform scaling, the unwanted antialiasing is still clearly seen. And it is certainly still applied in the 3x2px bilinear sampling which gets stretched to 500 x 20 (appr. 167x horizontally and 10x vertically). Unless I misunderstood something it would seem that these workarounds are very specific. 

    16 hours ago, NotMyFault said:

    Bonus bug: even if you deactivate anti-aliasing in blend range for a layer, rasterise ignores this 

    Aren't blend range based antialiasing settings only applicable on vector shapes / text? On the other hand, when exporting to e.g. PNG, I can force nearest neighbor as resampling method but that would then also leave layers where antialiasing is wanted (e.g. text) hard edged. "Interpolation" should ideally be very specifically and locally appliable. 

  7. On 6/2/2023 at 9:29 AM, NotMyFault said:

    @lacerto why do you resample to 12.8px size? Timecode 1:20 in your video. It does not make sense to use fractional document sizes, probably you know.

    Affinity apps do round up that to 13px [EDIT: they do not, but behavior is most often identical whenever scaling is not uniform], and it does not matter at all whether I uncheck the aspect ratio lock and manually enter the value to 13. The point is, if the scaling is not duplicative (and integral), Affinity apps will apply antialiasing on edges, even when using Nearest Neighbor resampling algorithm. In Photoshop Nearest Neighbor does what it promises, stays hard-edged, no matter how the image is distorted, whether when resizing pixel selection, or resampling a document.

    It is not just Nearest Neighbor that In Affinity apps works badly, as regards edge handling. Edge antialiasing is absurdly bad also when using other resampling algorithms, it is kind of feathering without asking for any (as if having initially used either feathering or antialiasing when selecting pixels).

    Example: 3x2px resampled to 500x20px using Bilinear algorithm in Affinity Photo 2:

    3x2_to_500x20_bilinear_aphoto.png.d31d24564eac630299911c08ea1c8f64.png

    The same thing done in Photoshop 2023:

    3x2_to_500x20_bilinear_ps.png.9aca02a3d67d1dd9904c569efdccb6b4.png

    I am not sure what you mean by saying that "antialiasing breaks down when using large scale factors". Here the image has been scaled up at factor of > 5, to 4,000x1,444 (manually rounding up height to nearest integer, though as mentioned, this is trivial as the app does edge antialiasing anyway):

    image.png.8d71b89f0c6f4e923b78e073bb10d120.png

    Antialiasing is as bad as ever, but if you mean that it is insignificant in larger sizes because of viewing distances are typically bigger then of course that is true. But hard-edged resampling is very important when working with small bitmaps, and it should naturally operate flawlessly, both on canvas and especially when resampling.

  8. 8 hours ago, amoraleite said:

    And this workaround is painful: ( If you want to scale individual layers using a different resample method, you need to copy/paste it into a new temporary document, Resize / Resample the temporary document, and copy/paste the result back into the original document.).

    If it only were that "simple". E.g., whenever pixels really need to be interpolated/resampled (and not just duplicated), bilinear sampling (blurred edges) will result even when using "Nearest Neighbor" as the algorithm. Just compare the difference between PS based nearest neighbor based interpolated transformation of selected pixels vs. doing the same via document resize in Photo:

     

     

    There was a recent 10-page discussion on reasons why this happens:

    Note that on canvas (without document resampling), blurred (antialiased) edges occur even when resizing (enlargening a pixel selection) by duplicating pixels but just in width or height -- only perfect scaling (multiplying by factor of 2, 3 etc. both the width and height) of a rectangle shape selection of solid RGB black pixels produces unblurred (non-antialiased) edges.

  9. I would use Word, as its Mail Merge is specifically created for stuff like that:

    image.png.58bdbd160869d58e499c4d04337e512b.png

    You could subsequently be able to import such Word document with styles and enhance it in Publisher.

    If you do not have Word, you can use LibreOffice Writer to create much the same (by "cheating a bit"):

    image.png.030609086203d786e2e4d179925af321.png

    After having merged in LibreOffice (and saved as a Word docx to be imported into Publisher), the records are in separate pages but it is an easy job to remove page breaks and have continuous flow.

    Either way you get a merge document that has empty fields (rows) removed, and field-specific paragraph formatting that is easy to edit in Publisher.

  10. 10 hours ago, Hangman said:

    I’m curious, what was the mistake you made,

    I created an AI file with multiple PANTONE spot colors from diverse libraries (the intention being using Lab, RGB and CMYK as color modes used to define the rendering color), one of which appeared to be CMYK based, but I mistakenly interpreted a triangle mark as a spot color symbol (which in AI is of course a circle in the middle, and a separate mark). So what I thought was a CMYK based spot color was just a global non-spot CMYK definition in one of the PANTONE libraries, which kinds of colors never have been problematic.

    BTW, as a kind of an answer to what I wondered above, whether apps typically or always depend on rendering instructions given in context of spot color descriptions, the answer is no, at least in context of CorelDRAW, which, when referencing PANTONE library colors, asks at file open time, whether a referred library color should be linked to "this or this" PANTONE color library containing the referred swatch name, meaning that it could then be rendered in different ways on screen, depending on which library it was linked to. In context of user-defined spots defined in RGB and HSB (in AI), they seem to be converted to EPS main color mode (e.g. to CMYK or RGB), and e.g. InDesign honors these values, but CorelDRAW does not, though it is not far away, either (it is not "off" but just not accurate so some conversion is involved). As far as spot colors are actually used (as special inks), rendering of course is pretty irrelevant, but in situations spot color information is totally lost (as it is in case of Affinity apps, and currently also in VS), reading correctly the alt color spaces becomes crucial. 

  11. Sorry, sadly I made a mistake so no matter how the spot color rendering color is specfied (at least from Corel and Illustrator saved EPS), it will get misread (in app versions and environments where this happens). OP's initial post already showed that this happens also when the spot color is CMYK based. But the tests at least showed that all other modes cause the error, as well.

     

  12. 6 minutes ago, Hangman said:

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

     Who knows, but RGB and HSB based spot color definitions get misread in a similar way than Lab based (reset to 50) so my guess is that the code simply just reverts to standard values (edges and midway) whenever reading something that does not "make sense" within expected spectrum.

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

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

    image.png.6564c6691a468e6279e0603dfd897601.png

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

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

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

  17. Anyone with Adobe history should be aware of the differences between Adobe and Affinity apps as regards stroke alignment, and PDF creation (the latter only supporting center-aligned strokes):

    1) Affinity apps only support inside and outside alignment with closed shapes, while e.g. InDesign does not have this limitation. Accordingly when importing IDML, Affinity apps apply center alignment on all open paths without adjusting positions, resulting in flawed design.

    a) InDesign:

    stroke_alignment_id.jpg.dec6422a579648650a9453eacb364551.jpg

    b) Affinity Publisher (IDML import):

    stroke_alignment_apub.jpg.d557a887068792a8f47aa27d4f86bbf1.jpg

    2) When exporting to PDF, Adobe apps adjust the positions of strokes (and dimensions of closed shapes with strokes) so that they stay as strokes but are center-aligned (instead of expanding strokes to closed curves). This can be seen when opening an InDesign created PDF:

    stroke_alignment_pdf_by_id.jpg.b6d8d8dbf61b765f401599a111014e7c.jpg

    Because of these differences, it may be a better idea to transfer Adobe-based jobs containing non-centerline based designs as PDF files rather than as IDML files. I do not currently have AI subscription active so I cannot check whether Illustrator CC versions now also support inside and outside aligned strokes in open paths, but the CS6 version only supports them in closed curves, similarly as Affinity apps.

  18. You can avoid antialiasing artifacts also by using clipping (instead of masking), either with PT generated masking grid along with Add or Divide Blend mode (depending on whether you want to reveal black or white parts), or using XORed shapes, and completely avoid antialiasing of edges (keeping them as vectors).

    image.png.666609c5c8e258d2d6c81a4db1d5b236.png

    Procedural_Texture_weird_behaviour_fixed.afphoto

    PDF/X-1a productions:

    Procedural_Texture_weird_behaviour_fixed_v01.pdf

    Procedural_Texture_weird_behaviour_fixed_v02.pdf

     

  19. It was late and I was not thinking clearly, so here's a more thorough description on how Affinity apps handle placed CMYK images:

    1. If they have embedded color profiles, they are honored (not discarded, as by default when placed e.g. in InDesign). If the profile is in conflict with the profile used at PDF export time (which would normally be the same that is specified for the document), colors of the placed file will be recalculated when exporting to meet the requirements of the target CMYK color space.
    2. If they do not have embedded profiles, the "document" kinds of placed files (Photoshop PSD, Adobe Illustrator AI, EPS files, PDF files that are placed to be interpreted) will have the CMYK profile assigned according to the setting that was in force in Preferences > Color at the time the file was placed, and not based on the hosting document color profile.

    If you subsequently change the document CMYK color profile, these files will not be updated to refetch their assigned color profile from current preferences. In version 1 apps you could update the profile by "replacing" the placed files (by fetching them again via Resource Manager from the file system). In version 2 apps you need to physically remove the placed file and then place it again.

    If the placed files are "non-document" kind (JPG, TIFF) without a profile, they will stay unmanaged, which basically means that they will get the document color space at export time (in a word: will get their native colors passed through). This happens whether the document color space is changed via File > Document Setup > Color (whether by assigning or converting), or whether changing a new color profile at export time (using "late" conversion).

    So, to answer to your question, if you have already converted your raster images into the final target CMYK values and want to be sure that those exact values get passed through when you place the file in Publisher, no matter which export CMYK profile is eventually used, save your images in JPG or TIFF format and without a profile (do NOT use Photoshop PSD); or: embed a profile with images that matches the export CMYK profile and make sure that the placed files are up-to-date. To avoid conversion of native CMYK values, do not match the color profile "late" (that is, change the profile at the time of export): even if your placed images with an embedded profile matching the new target would retain their color values, the native CMYK definitions would be converted. There is no late "reassign" option available in Affinity apps (one that "keeps numbers"), so if there is need to reassign and keep the color values, do it via File > Document Setup > Color, using "Assign".

  20. 3 hours ago, Poussart said:

    "the late-bound conversion option in Affinity apps".

    I mean the situation where you specify a color profile in context of exporting to PDF.

    image.png.de422e5e3ecb02323ff2721317e84034.png

    If the specified profile is not "Use document profile", all native CMYK color values are recalculated, in addition to placed files with a conflicting profile (I think that in some situations a forced recalculation of CMYK color values can be caused even if specifying explicitly the same color profile the document is using). So the recipe for reassignment and keeping the color values would be using File > Document > Color and changing the CMYK color profile while using the "Assign" option. But that operation does not refresh profile assignments of CMYK images that do not have embedded profiles, nor does it result in marking the CMYK images with conflicting embedded profiles as ones that are non-conflicting and should have their native CMYK values passed through.

    3 hours ago, Poussart said:

    I assume that this "Convert image colour spaces" should be clicked on so that the RGB images are converted to CMYK and this is my current setting. But with CMYK set for the overall colour space, is'nt this an uncessary repetirion?

    Yes, that option is used when wanting to force conversion of placed RGB images to CMYK when exporting to press-related PDF presets that allow RGB images (like PDF/X-3 and PDF/X-4 and any non-PDF/X based export method using PDF version 1.4 or later -- and as Affinity apps do not support version 1.3, this means any non-PDF/X-based export method within Affinity apps). Affinity apps always convert native color values to CMYK [in context of PDF/X methods and when specifying "CMYK" color space], even if the target PDF version allows RGB definitions, and this option does not have effect on that.

  21. 1 hour ago, Poussart said:

    a) link images that are RGB and rely on the pdf export (with the desired overall profile) to do all the conversion

    I would recommend this. If you have images in RGB, you will always get the optimum conversion, even when doing the late conversion (in context of PDF export). Basically I would never use the late-bound conversion option in Affinity apps because it results in full conversion of all CMYK defined colors, including native K100 like text that you would typically want to keep as K100. All that would become four-color black if you chose to export NOT using the document CMYK.

    Having CMYK images placed in Affinity apps easily becomes absurdly complex. First, because images that are handled as documents (like Affinity Photo or Photoshop file formats) will have their native CMYK profiles honored, while non-document images (like JPG and TIFF) will have CMYK profiles assigned as defined in Preferences > Color at the time these files were placed [NOT the document CMYK profile as you might assume]. And secondly, because of version changes: In v1 apps these files could have their CMYK profiles reassigned by refreshing the links in Resource Manager, while in v2 apps they need to be physically removed and placed again (having the correct target profile specified in Preferences > Color).

    There is a fundamental difference between Adobe apps (InDesign) and Affinity apps: the former basically always discard CMYK profiles of placed images so the native CMYK values get passed through. Affinity apps always convert them if there is a "conflict". What makes a conflict, may be hard to detect.

    Correction: What was stated above is relevant in cases color profile is not embedded within placed CMYK images. If it is, the embedded color profile is honored so the conflict is easy to detect, but not necessarily easy to resolve (to reassign placed images with the new target, to not cause unnecessary recalculation of color values).

  22. On 5/19/2023 at 1:51 PM, walt.farrell said:

    Well, it's logged as a bug, at least.

    Good to know, but as said, the earlier feature existed pretty much gratuitously because the line breaks came with the data so no effort was needed to "support" the feature. Making it "broken", however, means that control characters are intentionally removed. That may be well grounded so therefore (and because the feature would be easy to get back) my guess is that the feature will not necessarily be back, unless supported in another, less direct, way. But who knows. 

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