lacerto

One update to the file size increase mystery. I now tested taking a RAW photo with iPhone 16 Pro. I chose to export this file via Apple Photos by first opening the image (originally saved as a .DNG file) in Preview, and exporting from there in TIFF format using the default 16 bit per channel format. When subsequently opening this TIFF file in Affinity Photo and saving as .aphoto, I can experience file size bloat whenever I apply an adjustment layer, merge it, and save it as an .aphoto file (using a new filename). So based on this the issue seems to be somehow related to TIFF file format (which Apple Photos uses), and especially 16-bit per channel images. But based on experiences described by @Ldina, similar bloat can be experienced when processing .DNG RAW files. Because .DNG is based on TIFF 6.0, the reason for this behavior might be some bug in Affinity apps related to TIFF file structure.

It is basically to avoid inadvertent color conversions when you switch the color model within the Color Panel. E.g., assume that you have R255 G0 B0 defined in RGB color model and then you switch to CMYK color model, and back to RGB. If you have lock off, you will have a different RGB definition when you come back, because you have actually first converted the original RGB color definition to CMYK, and then the CMYK value back to RGB. If the lock is on, the definition would stay the same when you return back to RGB, and having the lock turned on the only way to perform an actual conversion would be entering a color value and pressing Enter. Note that the conversion will be done according to an underlying secondary document color profile (when you create a new document, it will get the underlying document color profiles according to what is specified under Preferences > Color). The color lock is a fundamental feature in Affinity apps so it is a good idea to learn thoroughly how it operates.

Yes, there seems to be related behavior. Can you further increase the filesize by adding other adjustments then merge, then save as? TIFF files (of which DNG files are some kinds of sub types, I think), can be complex and have all kinds of tagged information. Perhaps this confuses Affinity Photo and causes this strange bloat whenever merge is performed?

Yes, this is what I have been doing all the time, showing it also on the video clip. I additionally have always saved as (in .aphoto format) using a new filename, so no overwriting, should that matter anything. My latest screenshot shows filesizes in three simple steps, each time save as performed to an .aphoto file using a new filename. These steps are: 1) opening an Apple Photos converted 16-bit TIFF file for editing and saving it immediately as an .aphoto file 2) Adding an adjustment layer and saving as a new .aphoto file 3) Merging the adjustment layer so that only 1 pixel layer exists, and saving as a new .aphoto file. This is originally a HEIC file size of which is 3042x4032px and takes 2MB disk space. There must be something in these files that prohibits Affinity apps from discarding the old data, but it seems these files are actually 8-bit RGB files (showing when exporting an original HEIC file and opening it e.g. in Photoshop). But it is not RAW data, RAW mode is enabled separately in iPhone Pro 16, and these files are saved as .DNG.

UPDATE: Now I tested this by creating an empty 16-bit per channel RGB image (3000x4000px), then filled it with a stock photo, and applied adjustment layers, merged and saved as an .aphoto file, and cannot reproduce the kind increase in file size as with images initially opened for editing from iPhoto Pro 16 HEIC images (from Apple Photos) -- even if doing this process repeatedly So perhaps there is something involved in these images that causes the file increase...even if I cannot reproduce this in e.g. Photoshop. @Ldina, can you see the same, the growth in filesize only happening with the HEIC images converted to 16-bit TIFF by Apple Photos? Here's the latest edition, a nice iPhoto HEIC shot of our sofa fabric, with initial save, then Vibrance adjustment layer applied (no change), finally merged to one pixel layer and saved as, and puff, double the file size (technically about 70MB is required to save uncompressed this kind of pixel data):

I do not understand why people keep on repeating this. I have now tested this with numerous 16-bit per channel images opened for editing from Apple Photos in TIFF format, and saved as .aphoto files. As mentioned, e.g. a file that theoretically takes about 73MB to save its pixel data uncompressed, typically takes about 30% more when initially saved in .aphoto format. When an adjustment layer is applied and merged and the image is flattened to a single pixel layer (clipped to canvas size), it might increase to take double the size that is required to save the data, even if each time saving as with a new filename, in .aphoto format. And this can be continued to further increase the file size. There might be a moment (or even a logical trigger), when purging happens, but I have not found it so far. I have not tested if this is specifically an issue related just to 16-bit per channel files, but I have not previously noticed these kinds of issues with regular 8-bit per channel images, and it may well be that save as (using a new filename) works consistently there, and purges the file from old stuff. Also, as mentioned, when exporting to e.g. TIFF or PSD format, there is no wasted space issue. The tested files have of course no saved history. Is nobody else able to reproduce this behavior? (The tests I have done so far have been performed solely on macOS, editing HEIC files saved by iPhone 16 Pro, but I cannot see this significant, other than perhaps in producing 16-bit per channel images for editing.)

You probably get the best results if you can export your drawings in PDF format from the CAD application itself. I do not think that there is necessarily anything wrong with your DWG file, since the fact that Affinity Designer crashes when it tries to open the file is not an indication of anything else than poor quality of Affinity DWG import filter. I opened your file with Illustrator CC2025, CorelDRAW 2023 and QCAD, and while none of these apps is a professional CAD application, none had issues in opening the document, but there are many options to be chosen at import time, and missing fonts, etc., so there is significant variance in interpretation of the drawing, depending on the app used, but I hope you have some use of the PDF exports made from these applications when trying to open them in an Affinity app: GA_plans_Warford_ Illustrator_CC2025.pdf GA_plans_Warford_ Corel2023.pdf GA_plans_Warford_ QCAD.pdf

Hello, @Detective-Dohnut, welcome to the forums! You seem to have the document in CMYK color mode (most probably the default U.S. Web Coated v2, so when you pick what you think a HSL color value of the first ellipse, you actually pick its CMYK converted value (0:44 timepoint in your video clip): As you have the color lock turned on, the picked value is shown retaining the HSL model, but you can see that both the hue and saturation values have already changed from what you had, so when you subsequently change the Lightness value, the secondary ellipses get a color that is based on different hue and saturation.

Yes, it is Apple Photos that does the conversion. It does it whenever a HEIC file (at least in condition of opening a LIVE photo using iPhoto 16 Pro; I have not tested what happens if LIVE is turned off). All other apps that I have tested, however, retain the embedded wide color gamut, and only Affinity Photo has sRGB as the assigned (truncated) profile. UPDATE: Oddly, if I export "Unchanged original" from Apple Photos, the image has the Display P3 profile embedded, but it is an 8-bit per channel RGB, not 16-bit, as when opening for editing as a TIFF conversion! Not much appears to be documented in what Apple does here, but the size and color issues experienced with Affinity Photo are a separate thing. I do this on the video, and I think that OP mentions having done so, as well (but also having done at times successive saves using the same filename). EDIT: To make it clear, the size issue is ony related to saving as (merged, single pixel layer) data to native .aphoto format. I can e.g. export to 16-bit per channel TIFF and get expected file sizes. Similarly as @Ldina, I can go on adding complexity on the image, e.g. adding multiple adjustment layers, mixing them, but when I merge everything to one pixel layer, and save as to a new .aphoto file, the file size appears to keep on increasing, or stays the same. UPDATE: History is not saved, but something else appears to be accumulating. EDIT2: Just for information, v2.5.7 has no change to this behavior.

Here is capture of what happens basically with whatever I have tested. This is a shot saved in HEIC format using iPhoto 16 Pro of a random stock photo, which is then picked from Apple Photos in latest Sequoia for editing (this is deliberate, instead of extracting the original and opening the file, which is currently not possible because Affinity apps do not support the HEIC (HEIF) format Apple uses. As can be seen, the colors are first truncated to sRGB (instead using embedded wider color gamut like any other app I have tried) and then, when saving, filesize is 96MB, and after applying an effect and merging it, and saved as, 142MB. The image might of course have become more "complex" as a result of adjustment but the theoretical file size required to record the color information of an image of this size and color depth is about half of what was used. I ran the same test in Photoshop and saved in .PSD format and the image size stayed the same, 73,2MB, before adding a Vibrance adjustment, and after having merged the effect and saved as using different filename (and keeping it .PSD). It stays the same whatever is done within one pixel layer (canvas), even if it is just one color, as long as no compression is used. That is the space that it theoretically takes, then there can be extras like embedding a color profile, history, etc. But taking a double what is needed, and more, takes an Affinity aficionado to understand / explain. Anyway, considering that the original takes 1,73MB (and pretty much the same no matter what is photographed), I understand the concern, and the temptation to let Apple Photos do its editing magic, rather than using dedicated "professional" editors 🙂 filesizeincrease.mp4

I did exactly that, but without expected discard.

I have MacBook Air M3, Sequoia, Photo v2.5.6, and iPhone 16 Pro, and 16-bit HEIC RGB images with Display P3 internal color profile open in e.g. CorelPHOTO-PAINT 2023, Photoshop CC 2025 and PixelMator, when opened for editing from within Apple Photos context menu, in 16-bit RGB TIFF format with "Apple Wide Color Sharing profile", and when opening in Acorn, with Display P3, so I am seeing restricting to sRGB only when opening in Affinity Photo. As for the file size, an original HEIC file(2316 x 2088px) that took 1.7MB as a HEIC image takes e.g. in PSD format about 43MB, and in TIFF format with ZIP packing about 28MB, and would increase in size significantly with adjustment layers saved, but flattening and saving (without needing to save as) would return to previous sizes, so I do not seem to be able to reproduce the size issue with other apps. But when trying with APhoto, the initial .aphoto size of the test photo was 57MB. It did not increase in size when adding an adjustment layer and saving, but when rasterizing (flattening to a single pixel layer), the size increased to 106MB, and stayed the same even if saving as. Even saving as with a different name does not result in expected decrease of file size: 102MB. This is, indeed, odd behavior.

Ok, thanks. On Finnish/Swedish keyboard the mute keys are customarily the tilde, dieresis, circumflex, grave and acute accent (in addition to having å, ä and ö as regular keys), which allow to produce most but not all the Western European special [diacritic] characters (not used in Finnish or Swedish) without needing to switch keyboard language/layout and without needing to type Alt+Num codes, and I wrongly assumed that the same rationale would be applied in e.g. US English keyboard where there is culturally more frequent need for e.g. Spanish special characters. UPDATE: Additionally, my further notes regarding soft keyboards were specifically related to Windows touch keyboard, not the accessibility feature named On-screen Keyboard (which is a poorly written and much less useful app). UPDATE2: On Windows 11 (at least), one can select United States-International keyboard layout, which makes mute tilde available (so by pressing the tilde key, a waiting state for the second key is triggered instead of producing directly the tilde). On a regular US keyboard the tilde key is not mute. On macOS (at least latest versions), alternatives for letter n can be produced by holding down e.g. the n key and picking an alternative from a popup menu that shows (for the letter n, eñe would be the first choice).

Hello @Chantz, and welcome to the forums. Please note that if you use F/X Gradient Overlay, the gradient will always be rasterized when exported (as will other F/X effects, as well). So try to use the Gradient Tool, instead. Note too that if you have transparencies involved (including blend modes), and the PDF export method does not allow transparencies (e.g., when exporting to PDF/X-1a or PDF/X-3), the transparencies will be flattened by using rasterization.

Thanks @Hangman, very useful. I found additionally that the issues seems to be related only to .png and .jpg files (and as for JPG, only the RGB files), so one way to avoid the problem would also saving your raster images in TIFF or PSD format (or if using JPG, placing them in CMYK format). Or, forcing conversion of image color spaces, in which case all raster images will be converted to target CMYK and profiles are unnecessary.

I tried to reproduce this with 2.5.6 both on Windows (Pro 11 23H2) and macOS (Sonoma 14.6.1 and Sequoia 15.0.1) but could not. Is there a specific condition when this error happens? It is a HUGE regression as it makes the PDF production still one step back from standard... Now that they finally touched the feature, this happens...

...and to push it a bit further, if you can save your bitmaps as e.g. 16-color PNGs (they are 8-bit, not 4-bit, though, but capable of saving indexed any information that 4-bit BMPs), you can save some disk space, AND, surprise, additionally edit your bitmaps and immediately save back, as long as you have just one pixel layer (I tried this with .GIF, as well, but could not reproduce it): openeditsaveindexed.mp4

...and to return to the actual topic, you could use as a workaround exporting to 16-color palettized GIF (or PNG), which would probably be the closest that you can get with Affinity apps, and then work with GIFs from thereon, if applicable. Sizewise you get even some benefits, 9KB vs 169KB original (unless you use RLE). test.zip As for the .bmp format itself, and indexed formats in general, I could not agree more with posters seeing their usefulness. That's why they are still fully supported in professional apps.

It does not refer to the topic, and they are not responds but edits. The forum does not allow deleting a post, or emptying contents of an existing post, so I just typed something (indicating that the content is no longer valid). I emptied all my posts up to a certain time point because I had to delete attachments (which I often have in my posts). Leaving text without image content would have been confusing, as well...

On a Windows computer [at least on many European keyboards], the tilde key (~) is typically ”mute”, meaning that it waits for another key input before output, so the plain tilde needs a space character to be produced, and the other glyphs with a tilde attached, a related other character. The Spanish lower and upper case eñe can be produced by pressing the tilde key and then n or N. If a mute (combining) tilde is not available, the Glyph Browser’s search feature is your best friend. Type there ” n ” (space, n, and space) to get all variants of the letter n displayed: In the similar manner, you can have other Spanish special characters, the inverted question and exclamation marks, displayed simply by entering in the glyph search box the word "mark" (without quotation marks). When using a touch keyboard (or soft keyboard where you can input a character with a pointing device or a pen), you can typically produce these special characters also by holding down n/N or ? or ! keys a while and making an alternative selection:

There is basically nothing wrong with your color settings, but I would ensure at least the following to see if it helps: 1) First, make sure that your document color mode is RGB (RGB/8) rather than CMYK. If it is CMYK (which it would be if you create your Designer document from within the Press section), the colors of your document will be displayed as if permanent soft proof were turned on, meaning that your RGB color definitions would be shown as if printed in CMYK (in your case the default is U.S. Web Coated v2 (which is Affinity default). If you have earlier been working with Adobe apps, this does not happen there because soft proof is a mode that can be turned off and on so your RGB definitions would be shown true even in a CMYK document. 2) Second, if you switch color modes in your typical workflows, beware that Windows color management is not always as steady and reliable as could be wished, so at times device-specific color profiles, even when based on device-based measurements (ICC profiles), do not "take". Sometimes just restarting the computer fixes these kinds of issues. Your device is capable of showing 160% of sRGB color gamut so there is a good reason to use a color profile that matches the device, but you also need to make sure that device settings are correct, and it is recommended to use a calibrator time to time to measure display wear, etc. The instructions are device specific so not easily advisable on a forum like this. The problem could of course also be "resolved" by limiting capabilities of your device to sRGB, which would work fine in your current workflow (producing something for SVG -- in which case it would be useful also to make sure that the document RGB color profile is sRGB rather than Adobe RGB), but would of course otherwise limit your color-related operations.

I checked behavior in Illustrator (CC2025), and the same happens there, so the point is really to "just" be aware of this. The behavior is totally logical, but probably not "expected" by most of us. It was good that you pointed out this so that the reason for the behavior is now exposed. Personally I, too, would prefer the text frame to be stayed put, but adjusting the enclosing frame depending on the glyph is of course a valid reason. UPDATE: The behavior is identical also in CorelDRAW. In apps like CorelDRAW and Illustrator, where it is possible to convert artistic/point type of text to frame/paragraph/area type of text, and vice versa, it is also obvious that this "unexpected" behavior is actually more logical, even desired behavior, because when this happens, the changed content in both kinds of frames stays aligned (the same glyphs are aligned), while the the bounding box is repositioned. This is because in frame text kind of container the shape of the glyph can extend beyond the bounds of the container, while in artistic kind of container the bounds are determined by the shape side bearings of the object/glyph itself. This is less obvious if it is not possible to convert the type of the text object (as I believe it is still the situation within Affinity apps? UPDATE: No longer, as shown in later posts within this thread, so this is possible now also within Affinity apps.)

You are of course entitled to your opinion. I do not think that Artistic Text Frame does NOT behave "as designed", so it is not necessarily a bug, but I do not want the frame to be repositioned horizontally (from left) depending on its content. I assumed that OP was surprised by this behavior, as well. The way to avoid this is to change to Frame Text.

Well, I showed how the same text stays put when the content is changed whenever it is contained in Frame Text, but the X-coordinate is changed when contained in an Artistic Text Frame. For most fonts that I tested this can be consistently reproduced, but I, too, noticed that it does not happen with some other style within Söhne Family (even when the text is contained within an Artistic Text frame). I have not been able to reproduce the frame position change with any font contained in a Frame Text so therefore I offered it as a solution. But I have not of course gone through all fonts of the world to "prove my point". But IMO the fact that the frame is repositioned, is a clear flaw, and unwanted behavior. But that's perhaps just me.

It is not clear what kinds of images are involved, but as you seem to have Adobe RGB as the default RGB/8 profile, one thing worth knowing is that if you open RGB PNG files without a profile within Affinity apps, they will be assigned with the sRGB color profile and NOT the current working space color profile, like Adobe RGB. I think that this might be a bug. There are no problems if you open TIFF files without a color profile, so Adobe RGB would be assigned if that is set as the working space RGB color profile. Notice that e.g. in Photoshop, "no color management" (e.g., applied if there is some conflict, or a situation that cannot be dealt in a controlled manner) means: assign the working space color profile. Within Affinity apps it might mean: use factory default sRGB as fallback. Anyway, something like that seems to be going on in your working space, so within Photoshop you see more saturated colors, as if Adobe RGB might be the dominant color profile, while when you open the same file (non-color-managed flavor) in an Affinity app, you get (inadvertently) the same unaltered color values displayed in a lower-gamut sRGB color profile. But without knowing details, this is just guessing, one possible explanation. UPDATE: I checked, and the behavior (defaulting to sRGB when no profile is embedded) is identical with JPGs. TIFF and PSD files without a profile however are assigned with working RGB profile.