Jump to content

Paul Coddington

Members
  • Posts

    14
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. 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
  8. 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.
  9. Photo 1.9.1.979 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.
  10. Yes, I will wait for them to fix it as I have plenty of things to go on with for now. I don't need to export Designer projects to TIFF immediately. I am using LAB color space to create vector images with very precisely specified colors that I want defined by absolute (LAB) values not ICC-relative RGB values. I have just seen Affinity Publisher crash attempting to open a LAB Adobe Illustrator file (it defaults to open *.AI files in Explorer, as it turns out, and I am converting some older *.AI files to *.AFDESIGN, so discovered this by accident yesterday). So all three Affinity apps seem afflicted by the same bug for various contexts that invoke an underlying shared LAB module it seems. At least with me posting this, support now have confirmation that multiple users are affected, not just one. My system will have uploaded a few crash reports as well.
  11. Yes, I expect that is the case (even the export dialogs for both look the same). Photo crashes for me if I use it to try and export the same Designer files to TIFF, so it will likely be a problem in a shared library used by all three applications. I have no trouble exporting them as any other color space I've tried so far.
  12. I have a similar problem which may be related. Except I am attempting to export 16-bit Lab TIFF from Affinity Designer projects rather than open them in Photo. Basically, selecting Lab for export as TIFF immediately crashes the program for both Affinity Photo and Designer.
×
×
  • 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.