lacerto
-
Posts
5,777 -
Joined
Posts posted by lacerto
-
-
13 hours ago, thomaso said:
Theoretically it might work to create a colour profile as a separate file (.icc) for your various documents of icon designs and thus influence the colour appearance globally, regardless of app or computer.
Not just theoretically, because it could be done with abstract ICCs that are based on Lab color definitions. Any one color value can be mapped to another with a LUT, OS and device independently. I am not saying that it is practical at the moment, but possible. Also, color groups/styles in AI and CorelDRAW would allow complex app-specific color mappings and the kind of design OP is looking for. Affinity apps are very poor in these kinds of workflows.
-
Creating an app palette would allow creating an app-specific (e.g., related to Publisher only) palette with (named) color definitions, and assignments that stay when a document is closed and reopened. The app palette can also be edited and edited swatches will be available app-wide in all documents; changes to definitions of app swatches would be shown by losing the assignment link to an edited swatch (that is, existing assignments will never be updated with a changed definition).
This is not the same as a document-specific global swatch, the features of which are capability of having an overprint attribute and depending children, and capability of having an editable color definition and have the change reflected in all objects (including depending children) using the assignment.
It is also possible to create .csv based custom color libraries and place them in the same folder amongst PANTONE color libraries (.csv files), and specify them as RGB or/and CMYK, and optionally as Spot. Color assignments made by using these swatches, too, will be retained when the document is closed and reopened (and will lose an assignment link if changes are made to the color definitions). These swatches would be different from the ones of an app palette in that they cannot be edited within an Affinity app, yet appear as global swatches with saved custom names, and accordingly show as names swatches on the Tint view of the Color panel (which is also their default view, similarly that of global swatches). The swatch names could be used when adding these colors into a document palette (and optionally making them true global swatches capable of having overprint attribute and child tints). These kinds of custom libraries would also be automatically available for all three Affinity apps, but I think they would be lost whenever apps are updated, even if used with an .EXE based installation (that is, in a folder which would remain unchanged at program update), so backup copies would need to be saved so that the definition files can be copied back to PANTONE library folder after an update.
I have not tested whether custom .csv libraries could work in context of Microsoft Store based installations, nor have I tested this on macOS where these files would need to be placed in the app container when using Affinity store based versions. I have no idea whether this could work with Apple Store purchased versions, at all, but on macOS it is clear that these kinds of custom files cannot survive an app update, and that the changes need to be made for each of the three apps -- so probably not worth the trouble.
EDIT: I remembered incorrectly the placement of PANTONE libraries on Windows so instead of using Common folder for all three apps, they are placed in app-specific folders (similarly as on macOS, in app-specific packages).
It is good to understand that if these kinds of "global" swatches are used to create true document-based global swatches, the link to the original swatch definition is lost and there is no way to see whether the definition of underlying original color has changed. Personally I do not see problem here as there should also be a way to protect a document-based color definitions from such changes. The point of this post was just to remind that there are ways to have user-defined color swatches automatically available for Affinity apps; whether they need to be used as document-wide global colors (with features like overprinting, editability and depending child tints), is up to the user,, but if not, the original swatch assignments are permanent (or perhaps it is more appropriate to say "permanentish" -- Affinity color assignments are confusing and kind of feeble, very easily lost).
-
An example would be nice!
In my rather superficial and schematic tests PDF/X-4 files placed for passthrough generally behave well in a sense that they are not rasterized and their native colors are passed through when exported from an Affinity app (disregarding the app that initially created these files). On the other hand, I have noticed that multiple PDFs (including PDF/X-4, and ones created solely by Affinity apps) do not seem to interact expectedly with each other e.g. in Adobe Acrobat Output Preview or Packzview, meaning e.g. that overprint and blend mode attributes are not correctly rendered nor calculated, even if the attributes themselves appear to be exported. This means that the actual effects on paper of complex jobs placed on top of each other or on colored background are utterly hard if not impossible to predict. RIPped proofs (if not printed ones) would be the only way to ensure expected output.
Attached are PDF/X-4 exports made by Affinity Publisher 2.4.0 and InDesign CS6 using the same components, and only the export created by InDesign shows effects of interactions of all involved files when using tools like Adobe Acrobat Pro 2020 and Packzview.
-
19 minutes ago, Julien_dedale said:
I inisist that I don't talk about physical size, a pixel on a screen is a pixel, zoomed or not (the size its render is another question. If I have an image of 100px, I want it to measure 100px, whichever the number of millimeters it's displayed at the end. It works well with jpg and pdf expor
In that case I do not understand what same or exact size (on different devices) means (assuming that your image really has the same amount of pixels). 1 px measures different width and height depending on the device, e.g., as shown on my post, I can have my laptop screen filled with pixels in range of 800 x 600px => 3840 x 2400px (+/- effect of scaling) so the size of the image will vary while having it zoomed at 100% level all the time.
-
I do not think that there is a realistic way to control that.
There are many factors that affect the actual width a specific amount of pixels measure on a computer display:
...and the ultimate variable is the user and their preferences:
-
2 hours ago, Return said:
For Windows, Mac and Linux
It is not an actual preflight tool but a great PDF editor and a good accompanion to e.g. Packzview, and the same (perpetual) license can be used on two of the three supported platforms.
-
I ran a test on using merge (concatenation / collecting to a new document) functionality of qpdf and PDFtk vs using replace functionality of of PDF-Tools when using PDF/X-1a source files, and could not have the former two to keep PDF/X-1a compliance. I am not sure if these command line tools have replace page or delete page mode so that the replacing pages could in a way be placed in an existing PDF "shell" without losing the essential document features, but it does not appear to be so. Just extracting pages from another document does not appear to transfer these properties (this might be something that would be carried in the future when using PDF 2.0).
Anyway, PDF-Tools (and PDF-XChange coming with PDF-Tools but which can be acquired also independently) can do this. Unfortunately it is available only for Windows. It would be good to know if there is something equivalent on macOS that can do this (or if there is an online service that can do this platform-independently) -- offline tool would be preferable (and I wonder if PDFtk actually uses Internet in conversion, as it appears to take some time and has an Internet address in PDF producer box).
-
6 hours ago, rzolau said:
Ha, that explains everything!
No, it is still more complex 🙂
When having a PDF placed in interpreted mode, a placed PDF with DeviceCMYK colors (no profiles embedded) will get assigned with the working place CMYK color profile as defined in Preferences > Color (which by default in Affinity apps is U.S. Web Coated v2, but which I have set on the video clip below to ISO Coated v2), and if your document CMYK color profile (where you place the PDF) is different (like on the video clip a new document is created with ISO Newspaper CMYK profile), there is a profile conflict and your interpreted K75 will get accordingly converted to four-color black!
The way ligatures and OpenType features are interpreted is a kind of a typographic horror show so thanks for pointing it out! Now we know that if the source PDF has anything that really matters typographically, interpretation mode should never be used (it is really odd that the source document settings are completely ignored, yet you cannot affect the way ligatures and OpenType features get interpreted by using the settings of the hosting document, either).
But when using the Passthrough mode, you get the native K75 at PDF export no matter what your profile environment is (and no matter which kind of embedded profile, if any, the placed CMYK PDF uses). And you get the correct ligatures and OpenType features passed through, as well.
The video clip shows behavior in Designer 1.x but it is identical still in Designer 2.4.0 (Windows versions only tested):
-
16 hours ago, jdc5294 said:
Didn't know I could mention those programs out loud here without getting flogged, by the way
I am not sure if it is 100% up to the etiquette, but as long as you're basically doing these kinds of things in purpose of helping users of Affinity apps (instead of trying to sell something, or mention the competition to harm Serif), it has been kind of ok to mention 3rd party tools (sometimes also competitive) that are useful when creating documents with Affinity apps.
Adobe trio very often gets mentioned on the forum because that's where many users of Affinity apps come from, and often expect (rightly or wrongly) identical results when using similar tools, operations and workflows. It benefits the users of Affinity apps to understand the differences and describe, often with direct comparison with an Adobe app, what they need to do to get expected results.
Personally I think it is a clear forte of this forum to allow at times blunt comparisons and even harsh critique against the Affinity apps. They have so many strong points (often superseding the competition), and they are in continuous development, that it is definitely worth to stay persistent and learn to use these apps thoroughly -- sometimes it means, learn to use them "properly" (in a different way that they were designed to operate), sometimes learning workarounds (mostly easy ones but sometimes tedious).
-
Personally I would do this kind of job by using a PDF editor and merging press-prepared documents, just replacing specific pages (page numbers saved as a list) and saving the opened CMYK PDF with a new name, meaning that the resulting file will have identical properties, but just have specific pages replaced with grayscale versions.
One such tool is PDF-Tools. In the following the replacing file and page ranges have already been defined into a custom batch job, which also changes the initial view to scrolling facing pages with a cover page and sets the magnification option to fit page:
Using a PDF editor has the benefit of not needing to play with page positioning, print marks and export settings because these things have already been done in the source files. -
12 hours ago, jdc5294 said:
I was definitely hoping for a solution where a full color document with color raster and vector images would be automatically changed to grayscale in the export process.
I do not see any other way than what I showed in my post, but that, too, may require some preparation (like switching between K100 <-> Gray/RGB black), and handling of placed PDFs (= need to use Interpret mode to have their color space changed to RGB and Grayscale). and also post-processing, like manually changing page boxes from trim to media/bleed page by page, and handling non-symmetric bleeds (which Affinity apps cannot deal with automatically).
The video clip below shows the procedure of creating a mixed mode publication, after you have created your all CMYK and and all Grayscale versions. The building blocks are attached, including an RGB version that has black text as RGB 0, 0, 0.
But basically the method shown could be used pretty effectively to get fully professional output. Hopefully Affinity apps at some point will have InDesign [Black] intelligence which keeps K values in grayscale exports, and auto-converts K100 to RGB 0, 0, 0 in RGB exports -- and that Publisher has its page box bugs and usability issues related to the page box and K-Only button fixed -- these fixes would make creating mixed-mode print jobs very smooth.
-
Thanks for demonstrating this new feature! This appears to be a genuinely new ((if not unique) concept and while it appears to be pretty resource-heavy, I must say I was impressed by the implications and the promise, also considering PDF 2.0. Maybe we are on verge of experiencing something truly new in multi-purposing and creating alternative PDFs -- my brain hurts already, and I sincerely welcome the pain caused by having to expand a bit my (age-old) professional universe 🙂
-
2 hours ago, Martyn Folkes said:
@lacerto, why do you say styles are a less reliable way to do it?
Sometimes there are manual overrides that do not get easily changed, and forcing a style definition can have consequences where you lose one attribute when forcing another. Affinity apps especially typically need to have local formatting secured with character styles because simply just reapplying the same style might cause losing local formatting. If the task is easy enough (look for text with RGB 0,0,0 fill and replace it with CMYK 0,0,0,100, or vice versa), it is basically a one-click job to have it done. If there are swatch assignments, it could easily be done that way, too (and if assignments are global, this would probably handle tinted blacks, as well).
But I have not tested this much in practice so you might well get good results with styles. Select same and select all by type feature (available in 2.x version of Publisher) can also be very useful in jobs like this.
-
On 3/1/2024 at 1:11 AM, rzolau said:
indeed the culprit is the macOS Universal Conrol -- disabling it has the desired effect of PDF being embeded, and I can choose which PDF passthrough mode to use
Thanks for sharing, this is odd, but good to know.
Basically you should just use the Passthrough mode if you want to retain all features of the original file. Just remember the so called "PDF compatibility rules" that are in force within Affinity apps, so that placed content will not be rasterized.
Note that when you have Passthrough mode, the shown content is rasterized on display so you cannot use the color picker to verify the color values of placed content. You need to export the PDF and then examine the color values to make sure that the native values have been retained.
EDIT: Note too, that the color picker always shows color values in document color mode so in case your document color mode is RGB, you would see K75 values of an interpreted PDF converted to RGB, according to your current profile environment.
Attached is a DeviceCMYK K75 dummy PDF, which was placed in a Designer 1.x document as passed through and then exported, and the original color values are retained.
devicecmyk75_placed_exported.pdf
PS. What you mention about ligatures and OpenType features in interpretation mode is interesting, I'll check the behavior.
-
Using adjustments only results in having four-color-gray on "grayscale" pages, so if you print commercially, this is not a solution (at least if your goal is to save in printing costs).
I would do this as follows:
- Prepare your color document in CMYK mode. You can use RGB definitions for native shapes and colorful text if you want to benefit from the full RGB color gamut. Specify all black text that needs to be in K-only using CMYK color model, and CMY set to 0.
- Export your RGB document. [OR: If you want your K100 blacks as RGB 0,0,0, wait until you have converted K blacks to RGB blacks.]
- Export as "All pages" a fully colorful CMYK document using the document CMYK profile. If you have bleeds, include them but do not include any print marks.
- If you have placed PDF in color, mark them to be exported as "Interpreted" (instead of "Passthrough"), since in Affinity environment color space of the "passthrough" PDFs is retained (because Affinity cannot perform that kind of deep modifications in placed content, similarly as e.g. InDesign or QuarkXPress).
- If you want to have K100 text on the grayscale pages to become K100 (instead of dark gray having something like 87% blackness)m change the color definition of K100 text to RGB 0, 0, 0 or Grayscale 0 (they are practically a same thing within Affinity apps). You can do this in one go using the format option of Find Replace tool.
- Now export "All pages" by specifying explicitly "Grayscale" as export color mode and choose "Grayscale D50" as the color profile (if you do not have anything more appropriate available). Here, too, if you have bleeds, include them but do not include print marks.
- Prepare an empty Publisher document that uses the same format and CMYK color profile as your original CMYK publication. Now place the grayscale version of your PDF in this document, expand the placed content suggestion on the left column so that you have all pages shown in the list of pages to be placed, then select them all, and on the empty page of the hosting document, click in the exact middle of the page of the hosting document, or draw a page rectangle of the size of the document (including the bleed, if applicable) on the hosting document so that all pages from the grayscale PDF version are placed in the new document. If you have bleeds, change the Page box for each imported page so that page crop is set correctly to include bleeds. If you do not have bleeds, then the default "Trim" crop option is correct. Publisher is buggy at the moment and might have placed the pages inaccurately (specifically if you just clicked in the middle of the page instead of having drawn the page rectangle) so you need to check that placed pages have been positioned correctly.
- Now that you have grayscale versions of all pages placed, use the Resource Manager, and for each page that you want to have in full color, replace them one by one with the all CMYK version of the publication. Publisher will automatically fetch the correct destination page from the replacing PDF so if you select page 4 in Resource Manager and replace that with the all CMYK version, page 4 from that document will be chosen.
- Now export the document using the same CMYK settings using PDF (press ready) preset, which is the most flexible export method and will not rasterize any of your placed PDF content. Do not include ICC profiles because all your CMYK pages will be DeviceCMYK, and all your grayscale pages "DeviceGray".
Attached are PDFs of a simplified project. The placed content has RGB image, RGB Photoshop image with transparency, placed CMYK PDF, native RGB shapes, and K100 text placed on each of the four pages.
color_and_gray_allgrayscale.pdf
The weak point of this method is needing to have PDFs with color content set in Interpretation mode since that might result in e.g. font replacements and other interpretation errors. That would not be a problem in the referred "other" application, at least if your "other" is the "other" of mine.
Another possible weak point is if your printer requires e.g. PDF/X-based preset method, since Affinity apps have a thing called "PDF compatibility rules" which e.g. means that a non-compatible placed PDF content will be rasterized. And rasterization results in having four-color conversion and accordingly ruins the grayscale plans.
-
1 hour ago, paleolith said:
When you refer to "native art", do you mean generated, such as for example filling a rectangle with a specific RGB value, which might be outside the CMYK gamut?
Yes, basically objects (shapes, text) where you define color values (and model) with internal tools. Whatever color model you use to define a color value for a fill/stroke, gradient stop etc. attribute for these objects, the definition is saved as a native value and used when you export so that the initial gamut is fully exploited. Often design principle might actually be opposite, to produce output that is visually coherent both on digital and print media.
-
2 minutes ago, bbrother said:
Once you have complete your editing/creation work and decidee what paper you will print on, select the appropriate color profile settings and perform on-the-fly conversion while generating a new PDF copy that will be used for print.
Because Affinity apps cannot keep color "numbers" (= InDesign feature), it is not recommended to export using a non-document target profile, because this results in conversion of all native color values (which are in "conflict" with the new target) -- meaning e.g. that all K100 values are converted to four-color-black. If mere change of CMYK profile is wanted (without conversion of color values), the recommended method is to choose File > Document > Color, and use the Assign option when choosing an alternative CMYK profile. If the current and new CMYK profiles deviate strongly from each other, "Convert" option should be used, instead, but then the K-only values need to be done again. Affinity apps also do not convert swatch definitions so all swatch assignments are lost in context of conversion.
-
2 hours ago, Barto said:
Is there a way I can test either on screen or printing with a different app? With my current apps/printer, I can't recreate the issue myself and have only had issues when seeing to tother for printing.
It is often difficult to reproduce transparency flattening related issues because print-time rasterization can be handled in different ways by different devices, but Affinity apps have been notorious of producing jobs containing mixed color objects (especially if containing mixed color profiles) with transparencies poorly. I have run some initial tests with version 2.4 apps and it might indeed be that there are now some improvements, and measures taken in direction where mixed mode exports and especially mixed transparency blend modes are tried to be avoided, so it is possible that just sending a PDF that has been re-created with the same setting that you have used so far, now works.
However, without preflight tools that make it possible to properly preview PDF internals, and make fixes if needed, flattening transparencies (using PDF/X-3 or PDF/X-1 export methods) is a good way to ensure that what you see (when viewing an exported PDF) is pretty much what you will get on paper.
-
1 hour ago, Graphical Chris said:
Does anyone know if you can convert an RGB image within Publisher to a CMYk image?
It should be your principal workflow to always place photos and other RGB images in RGB color mode and just have them (automatically) converted to CMYK at export time, using the correct CMYK color profile. You can have your press-oriented document in CMYK/8 color mode and place and define native shapes in RGB and then convert to CMYK (CMYK document color mode does not mean that the app automatically converts colors to CMYK when placed or defined; Affinity apps allow kind of dual-color environment, similarly as e.g. InDesign). There is typically no need to convert images to CMYK beforehand.
-
41 minutes ago, paleolith said:
How should I be set up so that my RGB export has R0 G0 B0 text, and my CMYK export has C0 M0 Y0 K100 text, while doing normal conversion for non-text?
You basically cannot, if your job also has color content. You could have RGB 0, 0, 0 black exported to RGB black for digital purpose and K100 (actually gray 0) for press, but then you'd need to export the press job using grayscale mode, and that would not work with native color RGB objects (which would be in gray). There is no equivalent of "[Black]" swatch of InDesign that exports as K100 in press exports, and RGB 0, 0, 0 in digital exports so if you want to have that, you need to convert text black for both purposes (which is not necessarily a big job since you can use e.g. Find / Replace to convert all K100 text to RGB 0,0,0, or vice versa, in one go; or use text styles, which, though, is less reliable way to do it).
As you are going to export to press, too, I would choose CMYK as the primary color mode and define text as K100, and all native art in RGB (that is perfectly possible, since Publisher will keep your RGB definitions without converting them to RGB (just remember to have lock turned on in the Color panel if you use that to define object colors). You would naturally also place all your images in RGB color mode. When making the final digital export, you would then convert K-100 black to RGB 0, 0, 0.
There are benefits of primarily using CMYK color mode, e.g., to have the "K-Only" button available, which would let you have your grayscale images automatically processed as grayscale (or control the conversion/non-conversion manually for each image) when exporting to CMYK, instead of being converted (typically inadvertently) to four-color black. Keeping the job as CMYK will also make your press-related exports more relaxed, considering the need to have the optimum CMYK document target profile applied, as you would not need to make document color mode swaps just to make the right CMYK color profile assignment.
-
5 hours ago, rzolau said:
This is problematic as each time I import I have to correct the color. Any suggestion how to "force" AD to preserve CMYK colors from the PDF?
Hi @rzolau, and welcom to the forums.
You mention that you drag and drop your PDFs onto a Designer artboard. This is equivalent to using File > Place, and using the default placement mode, which is "Passthrough". Please check that this mode is shown on the context toolbar when you have the placed PDF selected.
On the other hand, you also mention that you can select the "imported" text, specify formats like ligatures, etc., and this implies that instead of placing the document, you have actually opened a PDF for editing? It is crucial to know which way you have your DeviceCMYK PDF brought in Designer, since the advises vary depending on what you have done.
Also, please ensure that you are viewing the resulting PDF with an app that does not show recalculated color values. E.g. Adobe Acrobat Pro might use a simulation based on target ICC profile and show translated color values, in case the viewed PDF has embedded ICC target, and in this case the simulation profile must match the embedded target profile.
As for your second question, if it is a document that has been placed for passthrough, all native formatting is retained and whatever you have active in the hosting document, only applies to text that you have created in that document. As for interpreted or opened PDF, I would assume that formatting of the source document is used, but I have not examined this thoroughly, and know that certain settings, like overprinting attribute, is not correctly read by Affinity apps, so there is point in checking all these kinds of formats when not just placing for passthrough.
-
8 hours ago, kenmcd said:
Still not sure what you are trying... but it sounds like you have multiple versions installed, and that is most likely the issue (the corruption).
Yes, sorry, I was confusing. I misunderstood what you had done: I thought that you had created COLRv0 table instead of an assumed COLRv1 table, and totally lost the track and forgot that the original font was based on an SVG table. It seems that Affinity apps always export PAL/COLR based font as curves instead of embedding it, which does not much matter when exporting symbols like emojis, but is a clear minus when exporting alphabetic content.
-
Try exporting your PDF using PDF/X-3 or PDF/X-1a. Both of these formats will flatten the transparencies included in your placed PDF content, and should fix the problem.
The problems other people are experiencing are related to print-time flattening of live transparencies. They often get flattened with miscellaneous issues.
-
In which way do you need to "fix" the scores?
If you open a Sibelius-created PDF v1.4 file in Publisher, you need to have all Sibelius notation fonts installed on your computer to have Publisher render the text (and notation) correctly.
If you place a Sibelius-created PDF 1.4 file in Publisher, and leave the placement mode at its default value ("Passthrough"), you should make sure that you also export using PDF v1.4 or later non-PDF/X-based export method, since all PDF/X-based export methods will rasterize non-PDF/X-based placed PDF content left in "Passthrough" mode.
If you let Affinity app to "Interpret" placed content (which the "Fix" operation of Publisher Preflight does), you need to have all fonts embedded in the placed PDF installed and make sure that the fonts also get correctly mapped.
Whenever you place PDF content for "Interpretation", you cannot edit the content, so if your intention was to edit the content, you need to open the Sibelius-created files instead of placing them.
Note, too, that Sibelius files are in RGB color mode. You should ask your printer if it is ok to have them in RGB color mode (where black is RGB 0, 0, 0). This is important, since if you export interpreted ("fixed") placed RGB PDF content to CMYK, all RGB 0,0,0 content will be converted to four-color-black, which you probably do not want. When you export "passthrough" content, the original RGB color mode is retained (unless the content gets inadvertently rasterized), but this may be unacceptable to the printer who expects the file to be in CMYK color mode (and using K-ink only).
There are ways to do a properly created K-only PDF export from a Sibelius RGB content, and it basically involves exporting to Grayscale color mode either Interpreted content, or opened content (or opening the content and converting everything to K100, and then exporting to CMYK). What needs to be done much depends on what you need to edit, and what your printer expects.
Best way to create dynamically embeddable object?
in Affinity on Desktop Questions (macOS and Windows)
Posted
Abstract ICCs can be applied as per layer so basically limited even object-wise. As ICCs are external files, it would be possible to have a global effect on all documents where the same ICC is applied, if the ICC file is edited or replaced. I have tested this in PS where I can e.g. create s specific color in LAB, apply an adjustment layer that changes the color in a specific way (using e.g. HS, Curves or Levels adjustment), then export the effect as a LAB .icc and use that as per layer via PS Color Lookup adjustment, and have exactly identical color transformation that was achieved with adjustments.
In Affinity apps it would basically be possible to use Soft Proof adjustment layer-wise, but the problem is that the abstract ICCs that I have created from PS do not behave identically as when applied as an abstract profile within PS (even if the demo abstract ICCs that come with PS and macOS do). But LUTs that PS creates at the same export procedure DO behave identically in both apps and produce the expected transformation, and LUTs are also external files. The effect of LUTs can also be limited to single layers (objects), so it would seem that it is possible to use them for the kinds of purposes described here.
Whether it is practical depends on workflows one is accustomed to, and working with LUTs and abstract ICCs is admittedly very different from palette-based global assignments and color transformations that can be achieved by color groups/styles based mappings in apps like Illustrator or CorelDRAW. But as these kinds of methods are not available in Affinity apps where not even document color palette creation (with auto-assignments) and automatic maintenance is supported and where existing assignments are so easily lost and poorly translatable across documents, the alternative methods might be at least worth a look. LUTs are available as a layer adjustment in all three apps but it seems that they can be created only in Affinity Photo and Publisher Photo Persona. Also, it seems that the kinds of adjustments included in export are limited (
e.g., I have have not been able to export effect of an HSL layer to a LUT fileEDIT: I just retried and now it worked without problems so I might just have done something wrong on my first try).UPDATE: I just tested this and unfortunately a LUT file is not linked so the changes made to the file will not be automatically updated in objects where a LUT is applied. What a bummer. Abstract ICCs probably would be but at the moment they do not behave reliably in Affinity apps, and also cannot be created with Affinity apps.
UPDATE2: It is the same in PS, too, so even if the linked LUT or abstract ICC file changes, it will not be automatically updated unless reapplied (which is in itself a task that can be done because full link to source is displayed, and if files are placed in default folders, simply just selecting the same LUT or abstact ICC will reapply the effect). In a way this is reasonable, but there is e.g. no notification of an outdated link (updated LUT or profile).