Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

691 profile views
  1. Thanks In my experiments, I'm careful not to drag any non-transparent pixels from the source layer off the canvas with the Move Tool, and I find that Rasterize works just as well as Rasterize and Trim. I'm afraid that using the Move tool will create something else, in the very canvas.
  2. @NotMyFault : thank you for your analysis. For the title, I made it deliberately provocative to get attention. I had observed an illogical behavior and I was looking for a suspect: I offered a misinterpretation of w and h because these two variables are poorly documented in the available online help. For example, in the online manual (the link you provide), w and h are really presented as width and height of the document, not of the layer. Besides, there is no clear definition for the various terms proposed such as “document” or “spread”. Anyway, the issue does not come from a misunderstanding of document variables w and h. Similar anomalies can be observed with much simpler equations such as x=300+(x-300)/a and y=200+(y-200)/a (homothety with respect to point (300,200), of ratio ‘a’) as soon as the Move tool has been used on the layer, even for a simple move without deformation. These anomalies can be avoided if the displaced part is set into a selection before moving it or, following your advice, by rasterizing the layer before applying to it the Equations filter. Incidentally, where did you find this need for rasterizing so as not fooling the Equations filter? I never heard of that before. A subsidiary question: what is different between a pixel layer and the same layer processed with the Move tool and which would disappear in the rasterizing operation?
  3. The point is not to accommodate with the behaviour of my macro (I gave a way for that), it is that this behaviour is not acceptable. I built my process only to put it in evidence. Maybe I misunderstood something —in this case, please explain! I join the video record you asked for. odd_behaviour.mp4
  4. I recently wrote formulas for the Equations filter that map the initial rectangle of a pixel layer into a truncated diamond inscribed in this rectangle x=x y= h/2+(y-h/2)/(1-(1-a)*abs(1-2*x/w)) where ‘a’ is a glider-controlled variable between 0 and 1 (perfect diamond for a=0 and no distortion for a=1) To save time in experimentations, I made a macro of it, at http://www.oitregor.com/numeric/affinity_photo/divers/losange.afmacro (to be imported within Macro panel). It generally works as expected, as shown below: However it sometimes fails. I specially met up against this issue after using the Move tool. In the following picture, I prepared a detailed, simple process to show what can happen —and a possible way to avoid it. I would be happy to understand what occurs, whether it is a bug somewhere in Affinity Photo or a misunderstanding of mine.
  5. Thank you for answering My OS is Big Sur. Things became worse with the new version 10.4 concerning the shortcut for masking the application. With 10.3, I was able to change it to ALT K. This is no longer possible with the new version and the shortcut for "Afficher la selection de pixels" remains stuck to CMD H, whatever I can attempt in the Preferences
  6. I have a problem with the keyboard shortcuts in Affinity Photo in French language since I switched from the Apple Store version to the Serif version (i) There is a conflict between the shortcuts assigned by default to the menu "Hide application" and "View> Show pixel selection", both to CMD H (ii) I cannot cancel or modify the shortcut for "Show pixel selection". It remains stuck at CMD H and I had to change the shortcut to hide the application. I was able to switch to ALT H, but it's still pretty boring. This problem vanishes if I revert to Apple Store version 1.10.1 but it goes back when I revert to Serif version (1.10.3). There is no point in trying to save the shortcuts from the Apple Store version and reload them in the Serif version. This problem appears for the French language, but not for the English language. Out of curiosity, I watched what is happening in the Italian language. Luckily, the CMD H shortcut to hide the application is preserved, but there is still a problem with the shortcut assigned to "Show pixel selection", which is already assigned elsewhere (CMD W), but there we can change it. Happy Italians! (I haven't watched for other languages)
  7. I was aware of the recipe. I tried, once again. Unsuccessfully again... In principle, all this work can be done directly from the Preferences. Alas, this fails too. The shortcut for this menu 'Afficher sélection pixels' resists to all this cleaning attempts
  8. @Pauls, you are right, I cannot explain why I did not see it yesterday. Unfortunately, the story does not end there. The input box for 'Afficher la selection de pixels' (in French, because the issue concerns the French menu) seems inoperant. Whatever I put in this box, the shortcut for this menu remains frozen to CMD H. Far more annoying, I cannot recover this CMD H for hiding the application @NotMyFault: thank you, I am not the only one with this kind of problem, little recomfort! Divide_bug.mp4 @all other guys: in fact, I meet up against two different bugs connected with the Divide blend mode. I prepared a short video to show how they look (1) when a layer is divided by its own copy, some pixels with fully saturated colors do not appear white (2) when one applies a box blur live filter on a pixel layer, a lot of fancy colors appear for small radius (other blurs are also affected, but less severely. Depending on the options in the Preferences for performance, I observe one of these two bugs, but never the two at the same time.
  9. Thank you for your trials. For Walt.Farell, I join the afphoto file (including history) of my attempt. I did not obtain exactly the same result, but it remains anormal. Concerning my hardware, my video card is an AMD FirePro D500 (Metal Family : Pris en charge, Metal GPUFamily macOS 2). The metal acceleration is activated in my Preferences bug_divide.afphoto
  10. Sorry for the delay. I can no longer upload to your dropbox, but if you are still interested, you can get the file at http://www.oitregor.com/divers/boxblur_divide_bug.afphoto. The bug does no longer appear with the 10.1 version directly downloaded from Serif website... but I met up against another one ( ) boxblur_divide_bug.afphoto
  11. I noticed various bugs in the French version of AP 10.1 which I just bought directly from the Serif site. I am working under MacOS 11.5 1 - Bug in Divide blend mode In principle, any layer divided by its own copy should give white everywhere, even for pure black pixels. The following screenshot shows very different results. It displays the effect of a double gradient Red-Black-Green (colors everywhere fully saturated) divided by itself. Seemingly, white is recovered everywhere if we add blue component, i.e. when none of the colors is fully saturated. 2 - Keyboard shortcut issues These issues only affect the French version (not the English version). The system CMD H shortcut should hide the application itself, but it does not because it has been also assigned to the "Show pixel selection" menu. Unfortunately, we cannot resolve the conflict by assigning another shortcut to this menu because it no longer appears in the Preferences lists for shortcuts None of these issues existed in version 10.1 distributed by the Apple Store. In return, there were other bugs in the Divide blend mode 🙂
  12. I met up against a spectacular bug when applying a Box Blur live filter (in Divide blending mode) to a RVB pixel layer. I had discovered this bug in version 1.10.0 (MacOS and Windows), but soon after I tried beta version and found that the bug was gone. So I said to myself that it was already fixed and that I just had to wait for the next official version. But 1.10.1 came, I tried it, and I saw the bug was still there —at least with MacOS. I tried to see if the topic had already been discussed but I couldn't find anything so I am sending this message. I had prepared a detailed report, but I left it in French (sorry!). Things are a bit more complicated than the previous presentation, because this bug combines with a display artifact that I think is inevitable when the scale factor is not 100%. The bug itself apparently affects all blur filters, but much less dramatically than the Box Blur. Au départ, j’ai voulu reprendre une vieille recette pour transformer une photo en dessin au crayon, à savoir dupliquer la photo, inverser la copie, la mettre dans le mode de fusion Densité Couleur – (l’affichage devient tout blanc) et appliquer un flou gaussien à l’une de des deux copies. Généralement, on passe ensuite en N&B en désaturant complètement et on obtient une version au crayon de l’image de départ ; il ne reste plus qu’à ajuster le rayon de flou pour obtenir le rendu désiré. En principe, on devrait obtenir le même résultat en désactivant le réglage d’inversion et en remplaçant le mode de fusion Densité Couleur – par le mode Diviser. Ce n’est apparemment pas le cas, et en plus le résultat change quand on zoome sur l’image, ce qui fait deux effets désagréables. Pour bien voir ce dernier effet, on peut fusionner toute l’image dans un nouveau calque, et là, surprise, on n’a pas le même affichage, sauf si on zoome à 100 %. En fait, je ne suis pas trop surpris de cette dépendance avec le facteur d’échelle car je l’ai déjà rencontrée plusieurs fois. Je l’attribue à un artefact de la construction de l’affichage, une sorte de moirage, quand l’image contient plusieurs calques avec différents modes de fusion. Mon hypothèse est que ce qu’on voit sur l’écran ne résulterait pas d’un calcul complet de l’image avant de la réduire aux dimensions de l’écran, mais qu’on ferait cette réduction calque par calque avant de prendre en compte les modes de fusion ; autrement dit, il n’y a qu’à 100% qu’on voit réellement ce qu’il y a dans l’image, et si on veut l’examiner avec un facteur d’échelle plus petit, il faut tout fusionner dans un nouveau calque. Mais il y a autre chose. Même à 100% d’échelle, on n’obtient pas le même résultat qu’avec le mode Densité Couleur - du moins tant qu’on conserve le calque de flou. Il faut le fusionner, et là, on va bien retrouver la même chose, mais c’est l’impossibilité de voir l’image définitive pendant qu’on fait le réglage, et c’est aussi un renoncement aux méthodes non-destructives pour le travail sur les images. Il semble donc y avoir une sorte d’incompatibilité entre le mode Diviser et le calque de flou. Les choses vont devenir encore plus spectaculaires quand on passera du flou gaussien au box blur. Lorsque le rayon est très petit, on va passer par un vrai feu d’artifice sur les couleurs primaires et secondaires, totalement inattendu et passablement suspect, à nouveau avec un affichage dépendant du facteur d’échelle. Enfin, là encore, on ne retrouvera le résultat attendu, c.à.d. quelque chose de voisin du flou gaussien pour la même valeur du rayon, que si on fusionne le filtre avec son calque parent.
  13. Hello When enhancing a layer, one can check that identical results can be obtained by (i) Adding a high-pass filter in linear light blend mode (ii) Or adding an unsharp mask filter (in normal blend mode) with a gain factor of 1 and a radius curiously threefold larger than the high-pass radius (for instance, 10 px for the high-pass filter and 30 px for the unsharp mask) The same comparison performed with a well-known competitor software (somewhat more expensive) cannot lead to the same exact identity because of different definitions for the high-pass filter, but one can look for the best agreement when varying the gain and the radius in the unsharp mask. Then, the best radius is not exactly that of high-pass filter, but it remains close to it. I wonder whether the radius scale read in the unsharp mask dialog box of AP is not threefold too large. Obviously, this does not prevent the good operation of unsharp masking in AP
  14. Hello I am currently writing tutorials about blending modes (for instance, see http://www.oitregor.com/numeric/affinity_photo/ouvre2_tutoAP.html?8e —french only, sorry) and I met up against odd behaviour with vivid light mode. Roughly speaking, duplicating a layer, inverting the copy and putting it in vivid light mode should result into a 50% grey display, except possibly for black pixels which lead to a division by 0 —unless Affinity Photo does not follow the common formulae for this mode. I tried the experiment with the following picture Il is made of two gradients, the upper one involving mid-range tones, neither too clear nor too dark while the lower gradient involves darker tones, near black, but not only pure black. After the process (duplicating, inverting, vivid light mode) I obtained tones far from the expected 50% grey for the lower gradient, as shown below : Same result in MacOS and Windows. Any explanation, if any ? Thank you
  15. I'm not sure how DR evaluated in the equation? This is not a real equation, but a kind of pseudo-code. DR is the previous DR in the right hand side and the new one in the left side. For instance, the product blend mode would be obtained with DR=DR*SR (to be understood as DR_new=DR_previous*SR). Only the right hand side is to be entered into the AP box roundup(0.5-0.3*SR-0.59*SB-0.11*SB) Should that be 0.59*SG? Of course. I suffered from many mistakes in the process, I corrected a lot of them directly in the AP box and I did not always reported these corrections in my text processor... and unfortunately I used this text version to prepare my post. Sorry! Actually, I did not dare to directly deal with color pictures. I began the work with grey pictures, where the code is far simpler. Not that simple to get it right the first time, but I succeeded fast enough to be reasonably confident to tackle the color case. Now, I want to emphasize that my misadventures are not at all a condemnation of this Apply Image menu. Simply, in case of complex equations, better to have a true text editor at hand with a compatible copy and paste function!
  • 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.