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.

Guillermo Espertino

  • Posts

  • Joined

  • Last visited

Everything posted by Guillermo Espertino

  1. I'm not expecting anything. The shift+click on canvas is merely accidental (when you want to click on an actual object to add it to the selection but you miss and click on the empty space instead). It's not something you *want* to do, but it's something might happen from time to time, and it's not ok that the application freezes when it happens, is it?
  2. Forgot to mention. Reproduced in Designer 2.0.4, Windows 10 on two different computers with completely different hardware spects (one has nvidia GPU, the other one has AMD).
  3. This one is easy to reproduce: On a new document, create 2 or more text objects, switch to the select tool and shift+click on all the text elements to select them. With the text elements already selected, shift+click on the canvas. The application will switch to the text edit tool and freeze. When the file is as simple as the example above, the application is operational again after several seconds, but with complex files it stays frozen (or at least the time it takes to become operational again is longer than I was willing to wait) At any rate, it doesn't seem to be the right behavior of the select tool to switch to text edit after shift+clicking on the canvas (which seems to be the behavior when there's only one text object selected before shift+clicking on the canvas).
  4. Good news, the problem with negative values has been fixed in MrLixm's AgXc
  5. Maybe I'm stating the obvious here, but make sure you extract the OCIO folder and point to the proper ocio.config file If it doesn't work, please file a bug report in the same github page. The author of the fork is a very helpful person.
  6. For all the people wanting to use AgX on Affinity apps, I have somewhat good news: MrLixm has forked AgX to work with OCIO v1: https://github.com/MrLixm/AgXc The fork works flawlessly for linear rec.709 CG, although it can't yet deal with potential negative values from RAW photos. AFAIK, the lack of clipping methods in OCIO v1 was what made Troy Sobotka use OCIO v2 for AgX. So, it's not a perfect solution and it might present some issues when working with photographs, but for the people who want to edit their EXR renders in Affinity Photo with the AgX view or OCIO layer transforms, it will be a good temporary solution until Affinity are upgraded to OCIO v2. Hope this helps!
  7. And how exactly do you edit the alpha channel in Photopea? And why are you talking about Photopea in the first place?
  8. Photopea is quite impressive for a free web app, but it's a bit silly to compare it to Affinity Photo. It's just an 8-bit sRGB image manipulation software, it fails to do proper associated alpha and it bakes high dynamic range destructively into a clipped 8-bit sRGB image. For a serious imager it's just a toy.
  9. Every program mentioned above has issues when dealing with alpha. Even Photoshop. Photoshop does a decent job with formats that use unassociated alpha, but it sucks when it comes to images with associated alpha (like EXR). You need a plugin to keep Photoshop from destroying proper associated images. GIMP the last time I checked did pretty much the same as Photoshop (i.e. everything is mostly fine if your workflow involves unassociated alpha), and the channels were relatively useful. The alpha channel is editable when it is a mask and it lets you paint directly to channels without affecting the alpha (the mask), so it can be used for packing textures as channels. Exports TGA with separate mask without premultiplying too. Krita is a decent painting program, but it's super slow and its image manipulation capabilities are quite limited, and its channels panel is close to useless. Personally I think that Affinity Photo is pretty much ok, but it seems to associate RGBA images upon import. There are prefs for OpenEXR, but TGAs and PNGs are out of luck. I don't understand why people say they can't save unassociated TGAs, though. I tried and it's possible. At any rate, I think that offering the same options available for OpenEXR alpha for the rest of the formats would improve the situation substantially.
  10. Maybe I wasn't clear. I meant that Affinity may be multiplying the alpha channel in the projection buffer, so the RGBA output of the final composite is associated. That would mean in practice that every transparent pixel got multiplied by 0 where alpha is 0, resulting in a pixel that is 0,0,0. And that would also mean that, for unassociated output formats as PNG, a division has to be performed to recover the solid color values from the semi-transparent pixels, but what's 0 remains at 0 since you can't divide by zero. We can't know what the code is doing because it's not available, so anybody who is not a part of the Serif stuff may make an educated guess, but that's it. Now, if I am right and that's the case, we don't know the reasons for that. I'm going to guess again: Maybe the reason behind that decision is performance, because you have to display the result of your composite at variable zoom levels and the filtering required for scaling the whole projection of your compositing with transparency REQUIRES associated alpha (that's a fact) At any rate, It's probably not a simple thing to fix. It's not that they just have to stop replacing transparent RGB with zeros. The whole pipeline might be tied to the alpha state of the composite and doing something else could potentially mean redesigning the whole pipe. On the other hand, the workaround cited makes sense with the desired result: If you want to use alpha AS A MASK, then it means that alpha isn't tied to RGB. Alpha as a mask is a temporary state. If you look at the alpha-over operation, it's clear that unassociated alpha has to be pre-multiplied since it's not ready to be composited. This is crucial: The alpha over operation is different for associated and unasociated images, because unassociated images need to be associated to be composited properly! So, with that in mind, it sort of makes sense that if you want to keep your RGB without transparency and your alpha as a mask, use an RGB image without transparency and a separate mask instead. It's not really a workaround, but the way that users should expect it to act. RGBA transparency is *always* associated. That being said, it's true that channels in affinity apps are somewhat inaccessible. Maybe some UI tweaks allowing more direct manipulations of channels is all we need.
  11. 1. Is there really an automatic deletion of RGB set to 0, or is it alpha association (multiplication) taking place and then reversed for unassociated alpha formats? You can't tell as the code is not available. 2. It's not that simple. When you apply convolutions (such as gaussian blur) or even transforms like rotation or scale, the image has to be associated. Keeping the alpha channel as a separate mask might introduce artifacts or undesired color bleeds. 3. That could be useful to produce an unassociated alpha image manually, yes. There's room for improvement in the channels handling in Affinity Photo, that's for sure. 4. The override for the import is already there in the prefs, and the options are quite complete. Export is tricky. Introducing that feature would allow users to do what you need, but also to produce files that are not compliant with the output fileformat specs.
  12. This is an interesting problem. Probably one that is impossible to be properly fixed. Affinity Photo, same as Photoshop and others, has unassociated alpha internals. So it has to multiply and divide RGB by alpha lots of times during processing, depending on which tool is applied to the image. That's a design burden that comes with a price. An example? Try opening an associated alpha EXR in Photoshop... Now see how it screwed your transparent emissions. A lot of people got used to alpha as a mask. The "unassociated" state of the alpha channel. The one that has to be multiplied by the alpha-over operation. So the game industry, assuming this is the natural state of an alpha encoded image, started to use channels for things that RGBA images were never intended for (like encoding textures for PBR shaders, for instance). But if you take a look at the history of digital imaging, it becomes quite clear that alpha channel was created as a means to represent occlusion, where RGB was always represented emission. With that in mind, the alpha as a mask (unassociated, key, straight or whatever you call it) is just a temporary state. When the image with the mask has to be composited over a background, the alpha channel must be multiplied in order to get rid of the undesired emissions. You can produce a correct associated-alpha image from an unassociated one, but not the other way around, because an associated image (a CG render, for instance) might have emissive and transparent pixels that are impossible to be expressed as unassociated alpha. So, if Serif wanted to please the VFX guys, moving to an architecture that aims to keep alpha association minimizing the need of predivision would be the way to go. But the apps must also work for the DTP people, who are more likely to be fine with the things the way they are now. And then there are also people from the gaming industry, who need some specific hacks to work too, like channel packing. Nobody managed so far to produce a software package that does it right for everyone. Digital compositing apps like Nuke or Fusion have the tools for dealing with this stuff, but with the cost of extra complexity (you really need to track your alpha association down your compositing tree and know what you're doing, and there are still operations that require a potentially destructive division, like some color grading operations). It may seem that Photoshop, or Photopea, or whatever app you want to name does it right when it comes to achieve a specific goal, but none of them has all the fronts covered. It's just not possible because it's a mess: every format has its own specs for alpha, and then programs seem to "prefer" one or the other alpha format. This seems a matter of expectations, as there isn't an unique solution that makes it right for everyone. Or at least nobody seems to have found it yet, so it's probably unfair to ask for it as it was an easy fix.
  13. Although I would love to have an associated workflow for my EXRs I think it's impossible to achieve this in any application with unassociated alpha internals.
  14. Ah, that's great. Very interesting, thanks for sharing. It's good to see that there is a workaround to make masks that are non destructive and complex, but it would be lovely if Affinity spared us the work of recreating that setup in a more handy, ready to use, feature. This method you shared is a great proof of concept that shows that the building blocks for the features are just there, and it's only matter of exposing it in the UI. I really hope this takes off.
  15. I've been following several threads about masking and there's something that customers often complain about regarding masks in Affinity, and it's the inconvenient workflow for editing them, the lack of filters, etc. Many people ask features to bring Affinity Photo closer to Photoshop when it comes to editing those masks, but I think it can be done better, and more in line with the unique non-destructive workflow Affinity apps have: Turning a layer or group of layers into a mask non-destructively with a realtime filter. Affinity Photo already has amazing realtime filters that allow complex editing without having to rasterize the actual layer, making masks act like that seems a natural evolution and makes sense in the big picture, as no big changes have to the UI and it doesn't conflict with the existing features. Of course I can't say whether the internal architecture allows this approach, but from our perspective as users it would be a huge improvement.
  16. They are quite useful for branding too. Having the ability to fine-tweak positive/negative versions, for instance. Or coming up with a combination of weight and any other feature fits better with your design is a plus
  17. I'd love to see this feature implemented in Affinity products, it's really useful
  18. This is very annoying. You have to make sure that every single artboard you duplicated via alt+drag has integer coordinates, otherwise you'll get wrong dimensions or undesired edge antialiasing on export. I think that when the document units are pixels, artboards should ALWAYS move in integer increments. It makes no sense to have artboards that are not aligned to the pixel grid.
  19. Hi, this is also affecting exports to 32 bit EXRs which is completely unexpected and undesired, as the format has room for storing the actual information without needing dithering at all. The problem doesn't affect exporting only: rasterizing vector layers also applies that unwanted dithering. The option should be extended to general rasterization (probably the prefs dialog is the right place for that).
  20. Hi, This is an extremely simple feature that would be very useful to everyone using software tracking for time management and billing: Expose the active document name in the window title (like MS Office, Adobe apps and others do). This would allow software tracking the active application window not only to know what application is being used, but also the document that is being edited. In our studio we use Manic Time for that task, but there are others that use the same parameter. Windows 10 timeline uses also that parameter if its available (it shows in the timeline view, minimized apps, etc.). Right now Affinity apps on Windows only display the application name in the window title area, and that way it's impossible to know what document has been edited if you want to check your tracking history and record what you spent the day working on. It would be a huge time saver if we could get that information in our tracking software. Thanks in advance!
  • 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.