lacerto
-
Posts
5,806 -
Joined
Posts posted by lacerto
-
-
15 hours ago, jackjohnbrown said:
I must be doing this incorrectly - when I add those adjustments to my project (copying what is shown in the video) my palette is still just as big, though the tones do change.
It is a bit tricky design as the "additional" orange tones probably cannot be removed with this method without using rasterization, since it seems that the brush profile is applied last, causing smooth transition of edge colors even after quantization curves have been applied. There is additionally opacity and Darken blend mode applied on the brush curve that make the case more complex than one that I used in the demonstration recording.
So depending on the goal the quantization trick shown might require some further modifications (also considering whether the edge colors which are wanted to be reduced are created with direct color definitions or by using modifiers like coloring, opacity and blend modes). The three quantization "parameters" (Gradient Map Adjustment, Posterize Adjustment and Black and White Adjustment) typically also need to be twiddled a while to get the desired effect.
Note that rasterization itself is not a quality compromise since blend modes, effects, vector brushes etc. will cause export time rasterization anyway.
The video clip below demonstrates reduction of the original orange tones from 48 to 2:
I have also attached the design you posted with Quantization group added and the required modifications made to achieve what is demonstrated on the video. Note that if you create a document palette with the complete design (texts and the record itself), the number of orange tones increases so obviously there are opacity / smoothening effects elsewhere in the design that cause this.
-
15 hours ago, Sitaara said:
You are happy! It doesn't stop for me. It may be that if I only have to hold down the left mouse button for a short time (less than a second), it might work, but as soon as I have to hold it down a little longer (one to three seconds), poof, gone.
If you can reproduce the problem consistently with a specific file (also after having closed and reopened the file, and the app itself, and especially after restarting the computer), it would be useful to post the file for examination of devs.
I have a feeling that the error is somehow related to mouse capture, and for me the error often goes away after I start the app again after it has crashed, or anyway, it cannot be reproduced consistently. But as said, I think that this error has been there as long I have used Affinity apps (and does not happen with any other apps).
-
I do get this very often, too, but then crashing might suddenly stop. I have not been able to find out what specifically causes it, or which action stops the problem, but I think this behavior has been there forever. And I think this might be only on Windows. It is definitely not a PC problem.
-
I did not have a closer look on the document at hand but I would assume that ilovepdf does OCG layer merge based on common names (possibly existing on the first page to be merged). Adobe Acrobat Pro, PDF/X-Change and PDF Studio all do layer merging by allowing the user to select the layers (on single or multiple pages) on to be merged (even if having different names), and then optionally pointing the target layer with which the selected layers should be merged with, so if there is complexity in the document, one would probably need a more advanced tool.
-
On 4/5/2024 at 9:00 AM, NotMyFault said:
Do the 4 arithmetic blend modes work natively in CMYK, or is there a temporary transformation to e.g. RGB or HCL color format (like in BM HUE, COLOR)?
IMO they do work natively for many blend modes, but I have not looked this closely, and especially not in context of many F/Xs and diverse contexts where blend modes can be applied, and I suppose there are also bit-depth and color mode limitations (at least practical ones) as for functionality of specific blend modes. Basically the document color mode determines whether RGB or CMYK channels will be used. If an object uses e.g. RGB color definition, the values will first be translated (without converting the colors of objects themselves) to CMYK mode (and vice versa) based on active color profile environment. I have not tested LAB color mode (or anything else than 8-bit RGB and CMYK.
As for subtraction or difference, I think you would need to invert the intensities to have a more intuitive perception of difference between e.g. C values in two images placed on top of each other (because difference of e.g. C100 and C99 cannot be demonstrated meaningfully if other components are not involved and would produce M100 Y100 and K100 in three other channels).
E.g. the image below would describe the intensity difference of C channel of the flower image I used above between ISO Coated v2 and Uncoated Fogra 29 profile (using less ink), and illustrates how much more C ink would be applied on an image printed on coated paper (or less on uncoated paper). So the Difference blend mode can be used in calculation but it is typically not useful without further manipulation.
-
18 hours ago, Séverine said:
In the meantime, I just found a quite easy and free solution with the online tool here : https://www.ilovepdf.com
Thanks! I have thought that these are pretty much the same tools as on https://tools.pdf24.org/ but no, the merge really merges the layers with the same name while the pdf24 tools do not!
-
As a side note to doing desaturation in CMYK mode, there are multiple ways without needing to preprocess the image. The major point is that when working in CMYK color mode, you pretty much get what you see:
Converting to grayscale (e.g. by using Black and White adjustments with sRGB or NTSC conversion values, the latter being pretty much the same as applying K-only) often produces out of the box the most balanced and rich but still guaranteed neutral results (with no color casts, as black ink only is used).
-
In my experience blending modes can be used in either RGB or CMYK color mode but the results are different depending on whether the resulting color values will be calculated with RGB and CMYK channels. Therefore one cannot use blend modes in RGB color mode (not even using CMYK color definitions) and expect blends to have similar results in a CMYK output, or vice versa. Calculations themselves are accurate and fully predictable in either color mode, but you just need to pick the correct document color mode to get expected output.
-
I now created versions using Glyphs 3, and these show basically correctly in macOS versions of Affinity apps (even if show bigger leading than defined), including showing correct style link behavior. The Glyphs 3 versions also install on Windows and behave more or less correctly in InDesign. But then show badly corrupted in Affinity apps!
-
1 hour ago, Alfred said:
I think the word you’re looking for is ‘incorrect’! The weight class Regular/400 is inconsistent with the Bold descriptor.
Basically yes. But as far as I know Apple deliberately messes up with especially supplemental fonts, possibly against misuse (illegal copying). Who knows...
E.g., as mentioned, when I initially extracted style corrected versions of Khmer MN using FontForge, and tried them on Windows, the fonts did not work on Windows version of Affinity apps (but did work in InDesign). When I later regenerated these fonts using FontLab 8.3. (and on macOS), these versions worked otherwise fine in Affinity macOS apps (including styling links), but nothing at all is shown in the Glyphs panel. I think these oddities are related to crippled meta data in these fonts.
UPDATE: This demonstrates what is mentioned above:
The issue with the Glyphs panel could probably be fixed by adding Unicode ranges and Codepages in font metadata, but then it is a pretty much a mystery why the FontLab created versions will not install on Windows platform at all (but FontForge extracted versions did, and also worked without issues in InDesign).
UPDATE2: I only just noticed comments by @kenmcd above as for the Apple AAT fonts and non-standard tables. This obviously explains the issues with Windows installation and the Glyphs panel.
-
Khmer Bold does not have Bold style link, but Regular, and both fonts also use the same regular weight class (400) so Affinity apps basically behave as expected of an app that reads style links (even if in many cases incorrectly).
On Apple, however, many apps seek bold version of the font by using the Style name, some possibly even Full name (or PostScript name), when Cmd+B or Bold button is used, even without style and weight class linking. This happens e.g. in Word and Pages (which basically does not even list the font, but recognizes it if pasted via Clipboard).
I corrected the errors in the font styles and generated new ones, but could not get them display right in Affinity apps (probably because of issues with the Khmer script); the fonts behave correctly in InDesign (including styling link behavior) but none of the glyphs show in Publisher. This is in many ways a "typical" macOS supplemental font, with non-standard font meta data.
-
13 minutes ago, Dan C said:
These additions will further cement Affinity as the best advanced design suite on the market
This is promise-ware in its purest form. "Further cement" -- the first thing we should see is getting rid of marketing clowns that use these kinds of ballooned phrases that have no ground in reality. But I guess there is plenty left where that came from.
-
1 hour ago, Rainer-Uwe Bielefeld said:
I think I should check the PDF export settings with my friend first. Then we'll see ...
Because the output of the attached PDF was in PDF v1.6, my guess is that the PDF was exported with "PDF (Flattened)" preset. This method uses PDF v1.6 and does what it says on the tin, that is, "flattens" everything, meaning that it creates a single image of the whole spread. Perhaps there was a misunderstanding (fairly common in e.g. POD-context) of the term "transparency flattening", which only means that live transparencies should not be included in the PDF output. PDF 1.6, however, does specifically NOT do that, but just "flattens" everything to an image (but would enclose the whole spread in one transparency group using RGB blending mode, probably caused by outer F/X used in some picture frames in the design, so some extra confusion from there, too).
[Note that the industry also uses term flattening for things like layer removal = flattening everything to "paper" background without a transparency and flattening text = producing a file without embedded fonts but rather having the text content either in outlines or rasterized in high resolution, so the term "flattening" can indeed be confusing.]
If this is a collaboration article (e.g. something like "one self-contained press-ready device CMYK spread with all images and fonts embedded") to be included in a larger publication, the safest export method from Publisher would be using PDF/X-1a:2003 -- unless the complete magazine is created with Publisher, in which case it much depends on the final PDF press settings, which PDF version should be used in placed PDFs to avoid rasterization (e.g., if PDF 1.7 can be used in final PDF, any PDF version is compatible; if the final PDF needs to be in PDF/X-4, PDF/X-3 and PDF/X-4 can be used, but not anything else; if the final PDF needs to be in PDF/X-1a, any placed PDF is typically rasterized).
If the main publication is created with InDesign or QuarkXPress, it is basically free how the export from Publisher is made, as these apps can produce the kind of PDF needed in press without worries of "PDF compatibility" and inadvertent rasterization, which in Affinity Publisher context happens if mixing "incompatible" PDF versions in placed content.
-
Emboldening and italicizing (done either via the shortcut Ctrl/Cmd+B or Ctrl/Cmd+I, or a toolbar button), is broken in Affinity apps anyway and only works in simple cases (like families that only have four styles). Even if the font has proper style linking defined, like Myriad Pro (a pretty complex style linking across 40 styles in the family -- the font is by Adobe so style linking is impeccable):
A typical issue is that emboldening and/or italicizing might work, but it is not a proper toggle because turning off bold or italics activates a different styling from what was the initially used. Or, that emboldening and/or italicizing fails in the first place and are linked to wrong fonts. Sometimes key shortcuts work correctly but the buttons do not.
Style linking does work properly e.g. in Adobe apps, CorelDRAW and Microsoft apps (and LibreOffice apps of which I have only checked Windows versions), also on macOS where such style linking is not that common.
But in Affinity apps, this is what happens, on either platform (the recording is on Windows):
As mentioned, sometimes keyboard shortcuts and styling buttons give different results in Affinity apps (but in case of Myriad Pro Light, the results are identical). This issue has been demonstrated years ago but I am not sure if it has been reported; if not considered "by design", it is probably one of the last ones in the list of issues to be fixed, especially if it is true that Affinity apps are "macs first", as has been suggested. Just for a reference: in Pages the Bold button also switches Light style to Bold (not Semibold as it should), but when toggled, the correct initial style (Light) is reverted. I am 100% sure that this is the way Apple thinks the "Bold" button or shortcut Cmd+B) should work (ignoring style linking which is likely to be considered a legacy Windows feature from the times Windows had inadequate methods for font enumeration in menus and presenting different styles under a common family name; traces of this can still be seen e.g. Microsoft Word, which does not even try to use common family names but nevertheless maps styling links correctly).
-
You can do quantization to exact number of colors using a trick that I have shown a couple of times on this forum (earlier video clips probably deleted because of Affinity forum max storage limit), using the Gradient Map, Posterize and Black and White adjustments (in this order) on underlying layers (projected against a solid background):
Note how Affinity apps create a document palette based on effect of adjustments even if part of the manipulated layers fall outside of the background (so that the image actually still has dozens of orange tones, quantized number being effective only within the boundaries of the background rectangle).
-
4 minutes ago, Gigatronix Pete said:
It is 2 x 3mtr x 3mtr wall images
The physical dimensions as such should not be a problem, but if the job has transparencies, exporting to EPS means that transparencies will be flattened and there might be large rasterized areas involved, which could potentially cause memory issues. But this is just guessing, and it is hard to tell if there is anything in the design that could be done otherwise to make EPS export work.
-
1 hour ago, Gigatronix Pete said:
When I asked them they said this came up when they tried to open the EPS files
Ok, thanks for the update. This is odd. Is it a very complex file, or is the size of the artboard very large? There is a chance that exporting using Level 2 PostcScript makes a difference. Could they open the PDF versions without issues?
-
Your customers might have expected specifically Illustrator EPS files which retain native Illustrator elements and full editability in Illustrator. Affinity apps cannot create such EPS files but only standard EPS files with some limitations (e.g. fonts are converted to outlines, and spot colors and overprint settings are not exported). Standard EPS files also do not retain layer structure of the document, and their editability is very limited. Illustrator should be able to open such files, though, so check what your customers mean when they say that they cannot open the files in Illustrator. Also, open the exported EPS files using your Affinity app to ensure that they are not corrupted.
Exporting using PDF format (or SVG, if it is a question about RGB mode documents) might work as alternative formats if EPS files simply just do not work. You could also try if exporting using PostScript level 2 works better (but it is unlikely that this could be the cause of the problem).
-
-
5 minutes ago, loukash said:
You can somewhat emulate it by turning antialiasing off and finetune using coverage map.
It is quite different. The coverage map kind of applies how (on what parts) antialiasing is turned off (or diminished). It typically works poorly with type. One of my posts above shows what the blend options based (partially) disabled antialiasing does. It is a really poor workaround with small point sizes.
-
10 hours ago, loukash said:
Interesting! I never realized that something like this even exists – possibly because I've rarely ever used a bitmap editor for typography work.
In small point sizes aliased text (earlier achieved with bitmap [system] fonts of different sizes) typically works much better than antialiased vector-based type rasterized real-time. When looked at certain distance, the human brain (appropriately limited eyesight) creates the best possible combination of accuracy and smoothening of edges. This has become less necessary in the event of high-res (4K) displays, but the feature is still quite useful in situations DPI is less than optimal.
-
7 hours ago, Medical Officer Bones said:
Just for testing: also works fine in PhotoLine when anti-aliasing is turned off.
In my experience non-antialiased rendering of text works identically in any app that supports the feature. I have tested so far Photoshop, GIMP, CorelPHOTO-PAINT (both Windows and macOS), and Acorn. All these apps also can fetch hinted versions of glyphs (e.g. TrueType hints for 2 and 5 for LiSu), but more generally: they do non-antialiased rendering identically for any fonts I have tested, whether hinted or not, whether TrueTypes or PostScript based outlines.
Affinity apps basically just turn on all antialiased pixels above certain threshold:
...and here is how it is done in Acorn (and PS, CorelPHOTO-PAINT and GIMP, and...):
-
5 hours ago, Discover Hawk said:
It's like this, after testing, GIMP's performance is also not good in this situation.
Do you mean that it is sluggish, or what? It seems that this is a question of app's support of TrueType hinting, and when I tested this with Photoshop (25.6.0) and GIMP (2.10.36), using LiSu, and FontLab 8.3 (using Monochrome hinting), the results are identical as for rendering.
-
Disregarding the font, it seems that there are app-related differences that are fundamental as for rendering of non-antialiased type. I initially (and naively) thought that turning off antialiasing in Blend Options would "simply" just revert to turning off resolution-dependent skeleton glyphs math. That is, that having "None" as an antialiasing method in apps like GIMP, Photoshop and any of the Affinity app trio would give identical rendering, when having the same document DPI.
That it is obviously NOT so, it is a worth of a more fundamental study or declaration!
How can I export a Raster Photo project, with layers, so that windows (non-affinity) users can open it?
in Affinity on Desktop Questions (macOS and Windows)
Posted
How did you manage to do it? I tried to save (pixel) layers with Aphoto v1 and Aphoto v2 on both platforms and chose compatibility box at export to PSD, but did not find any way to export content with layers in PSD format. As opening apps I tried Photoshop CC 2024 (latest version), Photopea, Corel PHOTO-PAINT 2023, GIMP (latest version) and even Affinity Photo (both v1 and v2, and on two platforms) but none of them could detect any layers in the PSD file exported from Affinity Photo, so obviously none was saved.
Perhaps there is some setting in the app preferences that determines whether layers are truly exported, but so far the customary TIFF format that explicitly saves "Affinity layers" at user request seems to be the only way (in addition to native .aphoto format) to save layers from Affinity Photo, and I am not sure for what purpose, because these TIFF files, when opened in afore mentioned apps (Photoshop, Corel PHOTO-PAINT, GIMP), are not detected (so the only app that seems to read them in TIFF format is Affinity Photo; it should be noted that not even Affinity Photo v1 can read TIFF files with Affinity layers created with Affinity Photo v2).
PSD layers as such seem to be well (publicly) documented (non-proprietary part of PSD format) since at least Photoshop, Photopea, Corel PHOTO-PAINT, GIMP, Acorn and Pixelmator Pro can both create and read PSD files containing layers and fully share this information with each other. Affinity Photo, too, reads these PSD files with layers, but if trying to save back, forces change of the file format to .aphoto.
Since the title of the thread specifically mentions Windows, I assumed first that this is somehow a "Windows-only" issue but as implied above I just tested this thoroughly on macOS (Sonoma 14.2.1) and the incompatibility problem appears to exist there, too. This sounds odd, since PSD "compatibility" is clearly implied in APhoto Help and .PSD is listed as one of the supported export formats (with only a note that text will be rasterized on export). So as you and @nezumi seem to have achieved a less sad ending, I wonder if I am just missing something?