-
Posts
6,692 -
Joined
-
Last visited
Posts posted by NotMyFault
-
-
-
Please inspect the history panel. It shows what functions you activated last, and can give hints what caused the removal from group.
Try do undo / redo the last steps.
There are several keyboard shortcuts, one which you might have triggered by mistake, which can put layers into or out of groups.
When you make screenshots, please use the default tools from Windows / Mac, and include the full Application window. It will help to support you when we can see all details from the beginning.
If the screenshot contains something you don’t want to share, you can edit the screenshots in Photo or designer and remove those areas. If possible use PNG format for screenshots.
-
Every rule needs to be interpreted.
I bump unfixed but still relevant issues in the following circumstances:
- no tag has been assigned yet.
- Major releases came out (V2) and does not contain a fix. I want to avoid that issues raised in V1 get forgotten, especially as older posts where moved to „archive“.
- roughly once a year, but only in case I stumbled over the same issue again, either in my own edits or when other users posted issues which relate to the issue. Other users may simply open new bug reports, and often the symptoms do not lead to the issue easily.
- I fully agree that at least 12 month should pass before bumping again.
- Other users (not the user who reported the bug) are affected by the same issue, you may leave a polite +1 or „I’m affected too“, or simply follow the thread. Those additional reports are relevant so Affinity gets an indication how many reports about the same issue occour. But please avoid bumping in too short time periods to avoid the „nagging“ clause mentioned by GarryP.
I love the Affinity forum for the very respectful and polite culture in general.
-
On 9/20/2021 at 2:08 PM, matthias.linsbauer said:
which makes working with exr files very unpractical.
First, I rate this as bug and hope Affinity is able to fix this or at least provides an option during opening exr files to automatically recombine the channels.
While waiting for that to happen, it is simple to recombine channels with help of channels mixer and blend mode add as workaround.
In Photo you may record a macro to automate the process completely.
-
I can only confirm than the method described by smadel is the best suited (fast, easy, effective) in this specific case to replicate the PS workflow.
There are official V1 tutorials describing this method.
All other methods may work or have additional benefits, but make it more complicated (in this specific case).
- thomaso and henryanthony
-
2
-
-
this happens in case the layer is not correctly aligned to integer position, or layer DPI has changed by stretching.
Use the transform panel to check layer position (while move tool is active).
Document must use pixel as units (not point or any other physical unit).
-
I have improved the formulas and created a live filter version.
No more need to use apply image and destructive workflow.
-
And here the formula for a pure live version for the bitwise blend modes:
for RGB: var n1=vec3(pow(2,n)); var n255=vec3(255); irem (trunc (vec3(R,G,B)*n255 /n1), vec3(2)) *n1 /n255
Input: n (from 7 to 0)
You need one high level group per pit of color depth, blend mode add.
In every HL group,
- one group for top layer, with blend mode "lighten" or "darken" and optionally "invert adjustment" (same for all 8 groups of course in one file)
- one group for bottom layer, blend more "normal"
- a PT filter, and input n set to the bit depth.
The demo file uses two symbol layers borrowed from Designer to simplify the usage as you could drop any layer content into the symbols, and resize the document to any x/y dimension.
Could be extended to 16 bit color depth
Could be extended to CMYK, GRAY, LAB color modes by adjusting the channel names (and using vec4 instead of vec3 for CMYK and scalars for GREY)
-
I often use a brute force method and add a new pixel layer, and keep it active in layer stack. While using color picker or adjusting colors in color panel.
If you have a group selected in layer stack, color picking could accidentally destroy all layers inside the group if you apply colors by mistake. Depends on tool chosen, but tools may switch automatically when changing layers.
normally pixel layers won’t get a color applied - but if there are inside a group, there are filled with the color.
Only undo can then save your day. But occasionally the impacted area is not visible due to zoom level and the damage is done.
-
So is the issue solved?
-
I now have an idea for a live filter version to create these blend modes. It will get messy as we need to create huge amounts of helper layers but should work:
- for 1 bit of color depth, you can use blend modes lighten to implement OR, and darken to implement AND.
- XOR based on Blend modes subtract over result from (lighten, darken)
-
For 2 or more bit of color depth, we need to use linked layers or symbols to create one group per bit.
- isolate the corresponding bit from both layers, and store it as 0 or 1.
- Shift back the result (after blending) to the correct bit position (/ 2 ^ position)
- combine the results of each group using blend mode add
@Ldinaare you interested into trying this as exercise?
-
5 hours ago, thomaso said:
"shame" ≠ Schande (German) but also might simply express "it's a pity" (= schade):
"It's
interesting howa pity that one can use a program for so long but never notice some things..."Sorry I’m non native English. My usual dictionary says shame = Schande and gives multiple examples confirming this interpretation
12 hours ago, debraspicher said:It's a shame for web images. I don't usually use outer stroke over a color that would show through. It's interesting how one can use a program for so long but never notice some things...
Debra, i did not intend to offend you. Sorry for causing any inconvenience. I was asking out of curiosity because I could not interpret those 3 sentences in combination. It’s a shame, but you don’t use the function. Then why wondering that you never noticed- what exactly, using outer stroke, getting unwanted transparency between stroke an fill, … ?
I don’t need any explanation from your side. Sorry again. On the other side. Why assuming the worst in my post and giving such a strong reaction?
Again, these questions came to my mind, don’t feel obliged to waist any more time in this matter. -
When using sharpening, the essential requirement is to use zoom level 100%, or integer multiple of 100%.
Otherwise Affinity will create a false preview where sharpening (or noise) effects look dramatically stronger.
-
1 hour ago, debraspicher said:
It's a shame for web images.
Why it is a shame, and for what or whom?
1 hour ago, debraspicher said:It's interesting how one can use a program for so long but never notice some things...
Seems this is an issue rarely having an noticeable impact as lacerto said.
And there are easy workarounds. Why use an outer stroke in this specific case (same color, 100% opacity)? Center stroke of double width produces the intended visual result.
Affinity has limited resources so issues with higher impact needs to get prioritized for fixing.
On 1/28/2023 at 8:05 AM, lacerto said:Some apps can deal with the issue in context of export by automatically overlapping inner and outer parts of these kinds of objects so that the gap is covered
Interesting, do you have more details? Does it work for raster and vector export formats?
Specifically in case of vector formats, how are these layers adjusted? Increasing stroke size? Combining stroke and curve into one curve? Applied to text layers?No matter which approach is used, it will definitely modify the original curve / stroke of the file. So if you export e.g. to svg and re-import again the layers will differ. I dont say this is a bad thing, but at least users should have a choice.
For me it is a question of „Philosophy“: Affinity apps tend to export layers „literally“. In some cases users may prefer if Affinity would apply some adjustments to heal common issues, e.g. closing gaps like in this case.
-
7 minutes ago, StefanK said:
But it might just be more pleasant to use. But if you can easily change that, why not?
Agree
-
1 hour ago, StefanK said:
I'm still a little unhappy with the clone brush. Aligning the brush with the outline of the source is not possible because the source brush is just a cross. But the detection range is much larger.
Isn't it possible to make the source brush look the same as the clone brush? So two identical brushes?The cross simply marks the center of the brush. It does not give a preview of the brush / brush size when choosing the source position.
If you dig a bit deeper in the functionality of Photo you may discover other tools like patch tool which are more capable, non-destructive workflows using additional pixel layers, and source modes.
If you want more control over the source area, other workflows are better suited. -
-
1 hour ago, lacerto said:
Display P3 is a wider color space than sRGB while I think that the display in my mac model is not capable of showing more than (approximately) sRGB color space, and I recall that originally (using previous operating system versions, like Big Sur that initially came with the computer), the embedded color profile used to be called just "Display".
I think this is mixing up several things and not accurate.
All Apple devices support „Display P3“ since many years. It is a subset of DCI-P3, but definitely larger gamut than sRGB.
the main issue is that Mac tend to create many new individual device-specific profiles (for every single physical Mac), all sharing the same name, thus confusing Afffinity apps who use a wrong profile based on profile name (which is identical for many different profiles).
this might be caused by „night shift“, „True Tone“ and other technology used to adjust display color rendering to viewing conditions like ambient lightning and color temperature.
-
22 minutes ago, NotMyFault said:
Which OS/App do you use for printing?
Thanks for your reply. This leaves only one question open: which app used for PDF printing actually causes the issue?
Probably the issue is not related to Affinity, but lies in the print settings of the other app. -
Affinity offers two methods to interpret displacements.
the older one is using red/green color channels for x/y direction, and seems to be Affinity specific (incompatible with Photoshop version of filter using the same name).my laymen’s interpretation: the delta between neighboring pixels color values defines the distance the pixel is shifted (displaced), multiplied with the strength factor.
the newer method is called sobel 3x3
https://en.wikipedia.org/wiki/Sobel_operator
And (when memory serves me well) more in line how other apps implement this function and what v_kyr described.
For practical uses, you cannot shift every pixel independently from neighboring pixels, because always the delta is used to calculate both direction and distance. I mention this because I tried to use the live filter version as a kind of surrogate for the (destructive) move tool to shift pixel content and controlling direction with the other layer content, but this makes such an approach impossible.
-
Hy, can you provide a test document (.afpublisher format) showing the issue, and screenshots of the export settings used to create the PDF?
Which OS/App do you use for printing?
What happens if you open the PDF in Publisher and print the PDF from Publisher?
-
Yes, but it requires a lot of manual work.
A PNG image results in a bitmap/pixel type layer.
you can use various methods to select areas, and copy them into new bitmap layers containing only those parts, and copy/move/rotate/rescale them.
make yourself familiar with the selection tools, and the move tool / transform panel.
https://affinity.serif.com/en-us/learn/
you can find more information in the online help or video tutorials covering the basics.
Photo is better suited than Designer for those pixel oriented workflows.
Another option is using 3rd party vector tracing tools to convert the bitmap image into a vector document. Then you can use Designer (or Photo) to edit the document, allowing scaling in size without quality loss.
-
Hi @DanDoe and welcome to the forum.
Are you able to elaborate more about the exact setup of your system and the conditions triggering the issue?
Are you able to spend some time investigating and changing parts of the setup to nail down the exact cause and which components emitting the sound?
If yes, it might be possible to find the cause of the issue, and maybe workarounds or a lasting solution.
If no, we can only add another case (now 2).

Colors or details reduced in JPG/PNG/TIFF export
in Affinity on Desktop Questions (macOS and Windows)
Posted
the differences are only visible when zoomed out (40% in my case when showing the complete image).
You must zoom to exactly 100% to compare images. Otherwise mipmap rendering and alias settings will cause rendering artefacts especially for small details like stars.
Small details are exaggerated when zoomed out. This affects starts in your case, or any added noise or sharpening.
When you zoom to 100%, both images are rendered identically.