-
Posts
6,823 -
Joined
-
Last visited
Posts posted by NotMyFault
-
-
11 hours ago, Ninjas said:
Hi Walt,
In Affinity Designer for iPad. Version 1.10, is it possible to save an embedded tab in layers as png?
Not directly (original content), maybe indirectly (export of rendered image)
- copy layer
- close document
-
create new from clipboard
- above steps 1-3 ensure that only content from embedded file is visible. You can skip this if your file has no edits active, and the embedded file is scaled to 100% (move tool)
-
export as png
- This saves a new file based on the rendered content (not 1:1 the original data), using the export settings regarding document and color format etc.
-
13 minutes ago, Wosven said:
WHat do you mean? There are a Levels and a Curves adjustements, but I don't find any modification —and resulting on the image, on the Levels one.
Hi, do you see the visual difference between 3 and 4?
Layers 3 and 4 are identical except the nested curves adjustment is inactive in 3.
and that is the magic: the curves adjustment on 3 and 4 is intentionally neutral, all sliders at default. So it should have no effect both in 3 and 4. but if its active it the levels adjustment starts working.
the levels adjustment in 3 and 4 only modifies the alpha channel, you need to switch to alpha to see that white level is set.
Hope that answers your question. And thanks for asking, i modified my post to make this more clear.
-
Thank you Walton for additional input.
I've seen your screenshots already, but to really analyze the cause of the issue it would be required to reproduce how the issue where started or caused, and therefore the jpg images of the scanned files (not a screenshot) would really help, and one .afphoto file that where created by "your" workflow. Unfortunately it is not possible to get this information from the screenshots you already provided. There are too many potential causes for the white lines.
If this is not possible for you, unfortunately I'm unable to help in this case, but other forum members or Affinity moderators will hopefully step in.
Regarding transform panel and pixel alignment, have a look here:
https://affinity.help/photo/English.lproj/pages/Panels/transformPanel.html
https://affinity.help/photo/English.lproj/pages/DesignAids/pixelAlign.html
Have a nice evening
-
Just my 2 cents: I would rate this as a feature, not a bug. It simply includes an BW adjustment with defined weights for RGB channels.
Normally you are using the levels adjustment to actually change the levels, and use the rendering to visually check the resulting effect to the document. I think it is technically and functionally required to show the rendering converted to grayscale.
If you want to work on RGB channels and stay with RGB, using the RGB / CMYK levels adjustment could be the better option.
-
1 hour ago, walt.farrell said:
If I wanted to add the levels adjustment, is that done after the merge visible? I've never heard of using an adjustment that way, but it sounds interesting.
In this case, after merge visible. But it can be used without merge visible in other cases.
Differences between images could be very subtle ( 1/255 of RGB values), and easy to overlook visually. The levels adjustments boosts such subtle differences to 100% white, much easier to spot agains black background.
-
30 minutes ago, waltonmendelson said:
These white lines print and they can be erased.
What do you man by "can be erased"?
31 minutes ago, waltonmendelson said:Workflow: Working in Photoshop,
Do you mean Affinity Photo or Photoshop? Do you copy within one application, or between Photoshop and Affinity apps?
Could you please upload one of the scanned images as jpg, and one Affinity Photo document where the issue is visible`?
-
I found at least some consistency for adjustments and filters in their behavior:
- Nested to clipping positions, alpha gets ignored. Effect is only applied to RGB chanels
- Nested to masking position: Effect gets applied to all RGBA channels.
- For me, this sound reasonable.
- What I'm missing (and requested as feature) is a new 3rd nesting position where filters get only applied to alpha channel.
- It would be even better if users where able to select on which individual channels adjustments and filters get applied, e.g. only R channel. This could simplify lots of workflows, e.g. selective denoise on RGB channels, selective blur on alpha channel to feather a mask, selective min / max blur on alpha channel to shrink/grow mask, ...
-
drum rolls
I found that on my PC it takes 297-272 +1 = 26/60 seconds after file is opened where it is actually shown blurry, until it gets fully sharp.
The video has 60 fps. Please find extracted images from video, file number can be converted to time code:
17 seconds * 60 fps= 1020 frames
271: last before image gets rendered
272: first with image rendered, it is very blurry
274: images gets slightly sharper, still blurry
... more UI elements show up, IQ does not change
296: last with image rendered blurry
297: first with image rendered sharp
So i assume that the rendering never becomes sharp on your PC for to be found reasons (GPU driver, Photo bug, ...)
Command to extract images from video with ffmpeg:
ffmpeg.exe -i "2021-08-12 22-10-52.mkv" out%06d.png
271
272
274
296
297
-
22 minutes ago, walt.farrell said:
Does that mean that the .afphoto file opens for you and the white strokes around the letters are not blurry?
Yes, it is perfectly sharp, with the following constraint: it takes a split second until the rendering is fully stabilized. This process is too fast to provide a clear descriptions how the images looks in the meantime. I will try to export images from the video
-
Hi Walton,
sorry to hear about your issues.
Could you explain a bit you process how do you scan the images, store the scanned images, and the process the images in Photo?
And what you want to achieve by these steps?
In the first place, i do not understand why you are using selection, copy and paste. Affinity offers other methods to hide unwanted parts of the images which might be better suited:
- Using a rectangular shape nested as clipping mask to the original scanned image layer
- Using a mask layer
Never the less, the issues could be caused by one of the following common issues. I absolutely do not want to say there is any mistake on your side, but could you please double-check:
- layers not pixel aligned (check with transform panel, while move tool is active)
- Not using snapping / force pixel alignment while moving or selecting
- GPU driver issues (check if latest driver is used)
- Rendering of images in Affinity could temporary show artifacts, especially when using any zoom level other than 100%, or by GPU driver issues. Please check if the white lines are visible after "merge visible" or in exported files.
It would help to solve the issue if you could upload the afphoto files.
-
Affinity is working hard on using GPU acceleration for the Affinity suite. On the one side, this is amazing as it can bring the best performance for these apps by utilizing all the valuable GPU resources you have paid for when purchasing the PC. On the other side, OpenCL support is not a top priority for GPU vendors like AMD and Nvidia, as both have own competing solutions. And maybe Affinity has its own learning curve to master this API technology. Coming back to your question
12 hours ago, Guzzi said:The only question is, why wasn't this necessary in the previous versions? Do I have to expect further surprises? I updated to 1.10.0 again.
As Affinity continues to optimize its usage of OpenCL API, there might be exiting performance benefits, but in some cases some quirks by new releases. I suggest to give it a try, it becomes more stable with every release. Personally, i don't see any OpenCL issues for my PC / GPU, most issues which still bother me are totally independent from OpenCL.
-
@LCamachoDesign Unfortunately i cannot reproduce the issue you describe.
Could you please try the following text to find out if only the rendering on monitor is blurry, or the actual image data is blurry:
-
Once you observe the blurry rendering:
- put a fresh copy of the original layer on top (paste, or place)
- and set blend mode to "difference",
- then "merge visible".
- It should be all black. To spot even minor non-black pixel, add a levels adjustment with white level set to 1% (default is 100%).
- Save the file and upload.
This test should show if this "only" a rendering issue, or a more severe bug.
Currently, i reported a few rendering issues, but all related with alpha channel handling, there might be more. It could also be only a Nvidia driver issue, plase try to install the latest "Studio" driver.
-
Once you observe the blurry rendering:
-
Despite the announcement, nested levels adjustment on alpha channel do not work.
1 pixel layer with partial alpha
2 curves on alpha is working
3 levels on alpha does not work
4 levels on alpha in combination with neutral curves adjustment on alpha does work
-
8 hours ago, walt.farrell said:
I think you should be using, and reporting bugs against, the retail release. That is where Serif expects to see testing and reports about new problems right now.
I thing we both misread Patrick’s reply. It’s not about beta vs non-beta, it’s about opening a new post for issues and keep this announcement thread clean.
I’ve hided my misplaced posts, and will report the beta issues in the correct section when I have more time.
Sorry for starting this confusion (by trying to save some time on my side using links across sections)
-
5 hours ago, Guzzi said:
Hi Cris,
Or rather: I can't find a setting anywhere where you can activate or deactivate OpenCL. In the meantime I have researched and found that OpenCL is always activated under Windows 10 and cannot be deactivated.
Guzzi
Hallo Guzzi,
das findest Du hier:
https://affinity.help/photo/de.lproj/pages/Extras/hardwareAcceleration.html

-
Hi, do you paste (via OS clipboard) from other apps, e.g. browser? There are older reports about issues with using this method.
As workaround, you could try to save all "bitmaps" into separate files first (e.g. png or tiff), and the use File>Place to put them into your document. When copying from browser, instead save from browser to file directly (preferred option). Otherwise you may use snipping tool or even Photo (New from Clipboard, then export as PNG).
Another hint: Sometimes you can simply recover from presumably hanging Photo by hitting ESC key once, if lucky this allows to save your work, but then you should end/ restart Photo to be on the safe side.
-
3 hours ago, ra.skill said:
Attached below is the uncut original image in Affinity Photo which came from Unsplash.
Also attached is the Designer file with my cut version embedded and where you can see the ghosting around edge.
Thank you for providing the files.
Here are my 2 cents about the possible reason for the ghosting:
- surrounding to the clipped canvas, there is still a lot of non-trimmed remaining background. You can see it if you increase the canvas size.
- Your document uses mm instead of px, which could lead to fractional pixel-sizes (when converted from mm to px).
Combined, these issues could lead to anti-aliasing and create 1-2 pixel wide line ghosting in from the invisible pixels outside the clipped canvas.
Possible solution :
- In the embedded document, reduce the canvas size by a few px in both axis.
This removed the ghosting in the document.
I agree with you and @Lagarto that the behavior of Affinity apps is not optimal, but I'm unsure to call this a bug. There is issue afp-4537 maybe related, where layers larger than the cropped canvas where used in combination with masks (or adjustments with inherent masks), see
-
Update to 1.10.0.1127 (non-beta)
- The issue slightly evolved, but is partially unsolved (for levels adjustment)
Good news: now working
- nested curves on alpha
- nested channel mixer on alpha
Still not working:
- nested levels adjustment
But there is a trick: if you add a (neutral) nested curves or channel mixer, the nested levels adjustment starts working!

-
Can you explain what changed with defringing?
Photo Persona or Develop Persona?
I couldn't spot any change regarding "increased maximum radius", but it seems the crash caused by negative radius, introduced in 1.9, solved in 1.10.0.1135 beta, but then reoccurred in 1.10.0.1127.
On 7/28/2021 at 3:07 PM, Patrick Connor said:Improved performance with:
- Panorama stitching
- Defringing and increased maximum radius
-
After the crash issue has been solved in several betas (1.9. to 1.10), it is back again into production 1.10.0.1127. Oh boy.
-
A quick update after 1.10.0.1127 has been released:
- Issue still unsolved
- Every adjustment (or filter) affecting the alpha channels breaks anti-aliasing. This practically means every adjustment, not limited to curves/levels/channel mixer, unless you select "protect alpha".
-
Hi,
based on the video, i try some wild guesses:
- A temporary line while move tool active, not visible in exports (or merge visible)
- you may have scaled the placed image, leading to fractional pixels at the edges leading to unwanted anti-aliasing at edge pixels
- Color format conversion issues (e.g. Photo in RGB, Publisher in CMYK)
It would help if you can provide the sample file to reproduce (Photo input and publisher result, and export)
-
Hi,
Welcome to the forum. I did not fully got the issue, could you please provide a screenshot and some more details?
As a general advise, you have much better control via masks when using sharpening tools in Photo Persona. Refinement simply applies a global sharpening wich often Leads to unfortunate results, e.g. for sky and clouds or amplifying noise in otherwise smooth areas.
-
8 hours ago, BofG said:
The higher the bit depth the more colours you have, so the graduations can be finer.
Absolutely true in principle, but beware using RGB/32 as this uses linear color profiles and introduces lots of unnecessary complications. /16 is all you need and enough to get butter smooth gradients.
Another unfortunate complication comes from Affinity: it could imply forced dithering of gradients with inadequate 8 bit methods, at least until 1.9.x.



[1.10.1127] Any image saved in .afphoto format becomes blurry
in V1 Bugs found on Windows
Posted
I don't think that the issue has anything to do with the document content. I assume it is simply a bug with rendering of potentially any content. For yet unknown reasons, Affinity sometimes does not reach the final rendering state, based on MIP Maps.
More about MIP Maps usage:
And see my earlier reply in this thread confirming that with screenshots clearly showing Photo starts with low-res rendering and then iterates to final quality. This can be seen for any document content - normally too fast to notice.