Jump to content
You must now use your email address to sign in [click for more info] ×

Zai

Members
  • Posts

    5
  • Joined

  • Last visited

  1. While exporting JPEG XL files is possible, so far only lossy compression is supported. JXL is a feature-rich format, but being unable to store data losslessly limits its use as a modern alternative to TIFF or PNG. Therefor an addition of this feature would be beneficial.
  2. Right now, only 32-bit color images allow HDR rendering. 16-bit color images can only be rendered in SDR-mode and can consequently suffer from effects like banding ( assuming sufficiently smooth gradients ). However 16-bit color formats themself are able to represent visually smooth gradients, so it would be reasonable to be able to render those pictures in some form of HDR-mode ( without modifying them by lifting them into a 32-bit color format ). P.S.: This may be related to Support RGB/16 rendering on capable displays with 10/12 bit resolution.
  3. When enabling HDR mode in 32-bit Preview the image is typically too dark. Now, this is probably due to the fact that my monitor, although supporting HDR and WCG, only covers HDR 400 instead of, say, 1000. However it is not uncommon that displays ( if not targeted specifically at content creators ) have lower peak luminance than HDR10 recommends. That makes it necessary to increase exposure by two stops to get roughly the same brightness as the corresponding SDR-rendered image. It would be more comfortable if the 32-bit preview either saved the exposure setting ( as it does with the reference white setting ) or, even better, if there were an option to input the peak luminance of the used display and have AP and AD adapt the brightness levels automatically. By the way, the exposure setting does not influence the brightness of transparent backgrounds, so they will remain gray instead of white. It might be worth thinking about modifying this behavior.
  4. The simple bilinear rendering algorithm has already been criticized before as not delivering optimal results, and is was already suggested to use more advanced rendering methods like Directional Cubic Convolution Interpolation. While that would certainly be a significant improvement, I want to point out another, albeit small, issue. At certain zoom levels bilinear rendering can create white edges along the canvas borders: It's unfortunately hardly predictable at what scales these actually appear, but using nearest neighbor doesn't seem to have this issue. Also toggling hardware acceleration makes no difference. System info: Windows 10 22H2 ( HDR enabled ) Affinity Photo 2.0.0+ ( currently 2.1.0 )
  5. The Denoise layer can cause glitches that remain even after rasterizing. This can be reproduced when using two separate Denoise layers: Example files attached: Buggy 1.afphotoBuggy 2.afphoto However, a single Denoise layer can also cause this behavior. When applying Denoise to a rasterized Fill layer ( just using a normal layer doesn't "work" ) I get this: Example file: Buggy 3.afphoto Turning off OpenCL acceleration "fixes" these issues. System info: Windows 10 22H2 ( HDR enabled ) Affinity Photo 2.0.0+ ( currently 2.1.0 ) Hardware acceleration enabled ( Radeon 5700 XT, recent drivers for each AP version, currently 23.5.1 )
×
×
  • Create New...

Important Information

Terms of Use | 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.