Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Paul Coddington

  • Posts

  • Joined

  • Last visited

Everything posted by Paul Coddington

  1. I wonder if this will cause problems when there are multiple profiles on the machine from different vendors? For example, different vendors install their own sRGB profiles, but they differ in accuracy, so assigning the wrong one by accident can throw the colours out. After installations and updates, I tend to review all the ICC profiles on my machine to unclutter selection lists and make it easier to use the same profile each time. Anything I don't use, I put aside in a ZIP file in case it is needed down the track.
  2. I am working on compiling a list of problems, but it might take me a little while to check them thoroughly and decide how best to present them. As a heads up, I am encountering serious problems with Affinity Photo on Windows with HDR desktop enabled (color pickers, previews, displaying SDR documents, converting 16-bit to 32-bit, clipping warnings, some tools, are not working correctly for me). As much as I want to have MSI installers, it is more important to me to be able to archive my scanned slides in HDR format for viewing on modern displays, as the results are far more lifelike and invoke a much stronger feeling of "being there". So, prioritising fixes, especially for features not completely working yet, is most welcome.
  3. On Windows, the settings for all three apps are stored in the "%UserProfile%\.Affinity" folder (copy paste that path "as is" into File Explorer to see it, the system will automatically autocomplete the username and drive letter). It seems to me very likely that will be preserved and carried forward during uninstallation/reinstallation. The MSI should be identical to MSIX except for installation method and executable location. It would not surprise me if they could live side-by-side, but there would be no point in doing that because they will be the same version. I am assuming all this on the basis that I wouldn't expect the program code to be re-written to package it with a different installer, and .NET-based code tends to be quite portable (it is a framework that usually allows deployment by simply copying files to the installation folder without any need for an installer at all).
  4. The point of confusion here is that they have just been officially announced today as available "now" (see above link in OP post) yet have not appeared in the locations described. Perhaps we are looking too soon after the announcement and there is an update to the downloads page that has not had enough time to roll out yet? Or today's announcement accidentally rolled out a bit early and jumped the gun a bit? Patience. Sounds like they will be here very soon.
  5. Ditto. I avoid Store/MSIX apps as much as possible on my Windows desktop workstation. It is important for me to be able to arrange the Start Menu in subfolders by task/topic so I don't have to memorise all my apps and can find apps when I have forgotten the names, shorten Start Menu names for speed reading legibility, remove brand names to improve alphabetic sorting, have short names on pinned items so there are no extra eye movement zig-zags to navigate text wrapping when speed reading/scrolling them. I have some neurological problems where I become fatigued quite quickly and can be impacted by clutter, messy text wrapping, and sometimes forget what name I need to type in the search box to launch an app, so for me controlling the Start Menu entries shortcuts for as many apps as possible is an accessibility issue. If only Microsoft would allow MSIX apps to be given user-defined aliases and be put in sub menus in the advanced options it would not be an issue, but the display name is locked in when the MSIX is packaged and can't be altered after the fact without breaking package certification (so far as I know).
  6. I seem to be encountering some color management and conversion issues with v2. Issue 1 (also present in v1): It does not seem to be possible to preserve document colors when converting documents to 32-bit from any other format. They are not mapping to equivalents (dark grey becomes light grey, etc), notably vector documents in Designer, at the least (not tested with photos yet). I am not certain if this is user-error, a conversion issue or a display issue, still bogged down in system updates/tweaks with new Windows 11 install to do thorough tests at the moment. Manual correction of all colors in document for all objects would be an enormous undertaking (intent is to experiment with converting SDR vector to HDR). Issue 2 (have not tested in v1): When Affinity Photo is launched with Windows HDR-enabled desktop (12-bit HDMI BT.2100 PQ monitor profile), SDR images with embedded ICC profiles do not display correctly (have not tested with HDR documents yet), even though the application window frame, buttons and Windows desktop all do display correctly. Photos come out looking like they have been layered transparently at about 10-20% opacity on top of a pure white background. SDR photos display correctly in all monitor gamut modes on SDR desktop (10-bit USB-C, sRGB, BT.2020. BT.709, Adobe RGB), so color management is working fine under those circumstances, at least for 8/16-bit documents (RGB and LAB). Wondering if anyone else has encountered these problems? Windows 11 22H2 with NVIDIA GeForce RTX current studio drivers
  7. I was surprised to find the new templates that would most always be used for TV screens default to portrait (eg: 1080x1920 instead of 1920x1080). If it switches to last used, does that mean A4 (etc) will then switch to landscape? Might be better to be able to select portrait vs. landscape in the new document dialog rather than have to alter it afterwards? One extra checkbox next to the dimensions?
  8. This is good news for me: a little OCD niggle of mine was wanting to rename the Start Menu shortcuts for easier readability at glance, have the option of putting them in Start Menu subfolders, and to have them not wrap text badly when pinned to the Start Menu due to the extra length of the version number. Seemed a little fussy to ask though.
  9. This just caught me out as well. Was attempting to contribute to a public SVG resource, but my drop shadow got rasterised. So, I recreated the same outcome using gaussian blur on a copy of the shape instead, but that got rasterised too. Yet, when I look up SVG standards, there appears to be support for both drop shadows and gaussian blur effects. And Affinity does not rasterise gradient fills or semi-transparent objects, so this seems a bit inconsistent. It seems to be a common enough problem though: when I work with SVG files pulled from the same public resource site, I often have to convert rasterised glows and shadows to drop shadows and gaussian blurs when importing them to Affinity. Hopefully this is on the ToDo list at some point.
  10. Hi NotMyFault, After I posted, I realized that what had happened was that my gradient had been accidentally created in an 8-bit document, but remained seemingly stuck in 8-bit when the document was corrected later to 16-bit, which seemed unexpected behavior for what I had assumed about the nature of vectors. When I recreated the overlay in 16-bit, it greatly improved, although not quite as smooth as the imported SVG version I had tried to reproduce (as practice and learning curve), but people would have trouble seeing the remaining banding on an average monitor, I think. So, I can still see some very slight gradient banding on objects I create, but not on imported SVG, which indicates things could be a little better, but the problem is not enough for anyone to really notice unless really squinting. Interestingly, when I had the gradient object visible, PNG would export as 32-bit (unexpected, so was not noticed at first), but when I had it hidden, PNG would export as 64-bit. Unfortunately, I have already corrected the problem and moved on to getting my Windows 11 upgrade underway and the files I emailed in are probably not much help after all, given my initial take on the problem was erroneous. But today I learned that not all vectors (or rather effects applied to them) in a document take on the bit depth of the document, and the bit depth of the export can depend on which objects are visible. Not sure if that is expected behavior or a glitch, but at least it can be worked around once understood.
  11. I'm seeing significant banding in your sample file (which is reported as 16-bit DCI-P3) when opened in Affinity Designer on an sRGB display, but not when exported to PNG and opened in a photo viewer. I have high quality display settings enabled in Affinity, and my desktop is running in 10-bit. Which is interesting, because I am trying to solve a problem where a gradient I created in Affinity is banded during editing and after export, but gradients imported from SVG files created by others are not. So, playing with your file has led to an interesting discovery that might shed light on my problem. Your 16-bit document exports as 48-bit PNG, but mine exports as 64-bit PNG, unless I export with the vector object that has the gradient overlay visible, in which case I end up with a 32-bit PNG. Yet both documents are 16-bit to begin with, and export settings seem to be the same in all cases. However, mine has a transparent background and yours does not, so only the 32-bit output case is surprising. But the 64-bit/48-bit difference primed me to spot that I was unexpectedly exporting the gradient overlay vector as 32-bit, which was something I missed before. But now I am thinking the gradient that has given me trouble is somehow stuck in 8-bit regardless of the document it is embedded in. I accidentally started that object off in an 8-bit document, so perhaps I need to recreate the gradient FX in 16-bit (rather than copy-paste the vector into a 16-bit document, or convert the source document to 16-bit). And sure enough, that did make a difference. It now exports as 64-bit rather than 32-bit. It still has subtle banding not seen in an imported SVG of the same image (which I was recreating for practice as part of my learning curve), which is still a bit odd, but it has improved. But there seems to be something odd going on, such as vector objects somehow being partially baked as the bit-depth they were created in and not being upgraded to higher bit depths when copy-pasted or documents are set to new parameters. I'll have to have more of a play when I have had some sleep. It is late and I could be making silly mistakes. BTW I just realized the banding in your document might be a color-management issue, and I have a monitor that actually covers DCI, so switching monitor mode to DCI and relaunching Affinity to pick up the new monitor profile, your sample document is displaying without banding in Affinity. However, it also displays without banding after I switch back to sRGB mode(!), so now I have another problem to track down! I might take a break from this until I either restore my system from a backup image (to amend that backup image with latest video drivers and various updates, etc), and see if that fixes any glitches that may have developed, or perhaps get cracking on rebuilding the system with Windows 11, as that comes out tomorrow.
  12. I'm seeing an odd pattern of banding with gradient overlay in Designer at the moment, that ripples badly while adjusting settings, even in 16-bit document with 10-bit video output to calibrated monitor, not just while editing but also after export to PNG 32. Not seeing banding in SVG files imported into Affinity from elsewhere (eg: from Wikimedia Commons), but rather only in objects I create. I have emailed support tonight, but just realized my attached document was accidentally set to 8-bit (however, re-testing with a 16-bit document does not solve the problem). There has been some major optimization with the latest version, so I'm wondering if this is a new problem others are encountering? But I might have made a silly error due to fatigue, so I am not jumping to conclusions yet. I have not seen this problem before now, but I haven't used gradients much until this week (I've been doing 'old school' animation-cel style art and simple icons for software). That gradients are smooth for SVG imported into Affinity, both when edited and exported to PNG, but not for vectors created from scratch within Affinity using gradient overlay FX is an interesting puzzle. Likewise, those SVG files are smooth in photo viewers and web browsers.
  13. Yes, files have been tagged in Explorer (right click properties) and/or Windows Live Photo Gallery (used to review and amend hierarchical tags display in tree view). As described above, the subject field is being replaced with seemingly random Chinese characters and the tags field content is being truncated. Other fields remain intact. As the truncation limit seems large, a file with a small number of tags might not have a problem (but Explorer allows at least 4096 characters). --UPDATE/AMENDMENT-- I just did a quick test on a blank TIFF file, gave it bilingual Japanese/English Title and Subject fields and added 4096 random alphabetic characters to the Tags field (making sure that the last 4 characters were "FRED" to be easily spotted when truncated). A bit extreme, as I have no individual tag 4096 characters long in reality, but I do have long hierarchical tags that can add up together to 1500 characters or so. File Explorer: Title: ハウルの動く城 ❘ Howlʼs Moving Castle [2004] Subject: この世界の片隅に ❘ In This Corner of the World [2016] Tags: P6gZT6gkj...FRED (4096 chars) Open in Affinity Photo, click Save without making any alterations: Title: ハウルの動く城 ❘ Howlʼs Moving Castle [2004] Subject: 渰ᘰ䱎湵䜰蕲殖‰堀‧䤀渀 吀栀椀猀 䌀漀爀渀攀爀 漀昀 琀栀攀 圀漀爀氀搀 嬀㈀ ㄀㘀崀匀 Tags: P6gZT6gkj...FRED; P6gZT6gkjZudcqJpPBafasyiDi9oSiD8Dx4s6NvTao4hLuKNfINyooEQsOc2sm8Z; Which is interesting, because this test indicates the Tags field is actually being repeated with the repeated part truncated. Casually scrolling through my normal hierarchical tags, I would probably just see the truncated tag at the end and not realize they are all still there, but partially repeated (rather than truncated). Not quite as serious, because more easily correctable in Photo Gallery tree view (spot truncated extra tags then delete them rather than recreate tags from scratch), but Subject field is still lost and extra effort can lead to more uncertainty and errors, let alone wasted time. So, running another test with a real file (bilingual Tags, semicolon separated, hierarchical depicted with "/", 1230 characters total, longest tag 260 characters), I get 1540 characters back after Save. The 17 existing tags have been somewhat reordered, 6 seemingly random tags have been repeated then appended, with all 6 repeated tags truncated to arbitrary lengths between 40 and 55 characters (originally 58 to 260 characters). So, a tag might look like... person/Japanese Spelling (Romaji Spelling) ❘ English Spelling; ...and be repeated as... person/Japanese Spelling (Romaji Spelling) ❘ Engli; ...with no immediately obvious reason for truncation point (not a special character or language change boundary). The reordering seems somewhat arbitrary as well. It would be nice if it was sorting alphabetically for better human readability, but it isn't. Blank Test.tiff Test Result.tiff
  14. It seems to be: you can run an ICC swap macro against each image in a batch operation and it is very fast (multithreaded) and reliable, it's just that when you open a TIFF and save it again in Photo, the metadata tags get corrupted when they shouldn't. As noted in the edit, it is a file save bug only and nothing to do with batch processing after all.
  15. Accidentally posted this to Feedback subforum. Administration then moved it to MacOS. Seems I forgot to tag the OS type. Apologies. Currently exploring freeware/trial tools to see if one can act as a workaround (to swap out incorrectly embedded ICC profile for 3,000+ TIFF files without requiring them all to be individually retagged from scratch for subject/content/credits afterwards). Windows 10 Professional x64 20H2
  16. It looks like something got lost in editing, so the post ended up being moved to the wrong subforum. This bug report is for Windows 10 Pro x64 20H2, not MacOS.
  17. Photo CONTEXT Batch job attaching ICC profile to a folder full of TIFFs. Macro selected to assign ICC without conversion. Files overwritten in place (they were backed up safely before commencing). ADDITIONAL CONTEXT TIFF files have been tagged in Windows File Explorer, including: Title Subject Rating Tags Authors Date Taken Copyright Fields contain multilingual Unicode content (mostly Japanese and English, plus others). Hierarchical tags in "Tags" field has many tags of this type... category/subcategory/tag; 1000+ characters in the Tags field would not be uncommon, as there are many tags and some tags are quite long. PROBLEM After attaching the ICC profile, the metadata for the TIFF files has been corrupted. 1. Subject field content is missing and filled with random Chinese characters. 2. Tags field content is significantly truncated, there seems to be a character limit (about 800 characters) which is significantly shorter than that of File Explorer. UPDATE Have now determined that this is nothing to do with batch files, but saving files in general. Just opening a single TIFF file and clicking Save is enough to reproduce the problem.
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.