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

jorismak

Members
  • Posts

    132
  • Joined

  • Last visited

Everything posted by jorismak

  1. I get the feeling that Affinity Photo now uses OpenCL for even more tasks, and the problem is that the power of the HD6xx series is not strong enough to actually be a performance benefit. Or the shared memory is causing issues or slowdowns, something like that.
  2. Thanks! That at least explains why it _can_ be so much worse for _some_ users... Now to hope it'll be fixed somewhere in the near future :).
  3. Ok, so my Intel driver was still on v27 because that's the latest supplied by my device manufacturer. Did the DDU thing (did it before, I know how it works... downloading the latest driver and then killing the network is required, because otherwise Windows will install a new one automatically if you're not fast enough :P). Installed the latest official Intel v30 drivers. Performance on Affinity 1.9.2 seems worse now with OpenCL enabled, although still miles better than 1.10.0. Opening files is faster without OpenCL enabled on both versions. The display updates quicker without OpenCL enabled on both versions. But on 1.9.2 the difference between OpenCL enabled and disabled isn't that pronounced. On 1.10.0 the speed of updating the display / preview is _sooo_ much slower it's unworkable with OpenCL enabled. But... doing the 'motion blur > 800px' test, Affinity Photo 1.9.2 is actually quicker to update _with_ OpenCL enabled compared to OpenCL disabled. But 1.10.0 the same thing is _very_ sluggish and just as slow as doing the 800px motion-blur filter on the CPU alone. Opening a file (a .NEF or a .tif) also seems to 'freeze' the application for a bit, where the display window gets a bit corrupted and then updates again. This isn't happening on 1.9.2. Opening the NEF with 1.10.0 with OpenCL enabled also makes it very obvious how the file is loaded: You see the Develop persona without any tone curve applied, then the display corruption happens, then you see the image again, then the base-curve gets applied. If I then press 'ctrl+3' to zoom in a lot, you really see the tiles of the preview window being redraw. This all isn't happening with OpenCL disabled, but it's also not happening on 1.9.2 (OpenCL enabled or disabled). Trying to dial in the 'defringe' parameters is just plain impossible on 1.10.0 with OpenCL enabled. Sometimes it takes _seconds_ for the screen to redraw. You don't know if a change you made had no effect or you are just not seeing the updated preview yet. On 1.9.2 with OpenCL enabled the changes are _instant_ (if the defringe radius isn't crazy high) and moving the sliders is smooth and gives instant preview while you are dragging the sliders. @ATP Source? You don't have a marking of being Affinity staff, and from looking around not that much changed on the Windows side (but I can't look at the inside of course). I'll be back on 1.9.2 for the time being...
  4. Unfortunately, no, not this time. If I can still download them, I'm more than happy to try one by one until I found the one where the regression occurs :). Even loading a RAW file or a 16bit TIFF file is noticeably slower, and you now notice the window being 'redrawn in squares' (as in, you notice the window being updates in chunks). It's not just 'noticeably slower', it's pretty much unworkable. Just opening a RAW file in develop and then zooming in to 200% takes a couple of _seconds_ for the window to update to full resolution, while without OpenCL and on Photo 1.9 it's pretty much instant.
  5. Same thing here with an integrated Intel HD620. Affinity Photo 1.10 final is much slower in rendering and updating with OpenCL enabled than it was in 1.9. Disabling OpenCL made it quicker for me :(. My other machine with a GTX1060 (desktop) seems to run fine with it enabled though, although I have the feeling tha tit also runs a bit slower there than it did before. It's at least not slow enough to disable OpenCL. On a laptop like yours with two GPUs, maybe you need to flag in Windows that the Affinity Photo app is supposed to use the 'performance' GPU. Or in the Nvidia panel, you can say that the application should run on the dedicated GPU. Maybe you are using your HD630 behind the scenes and running into the same issues as I (and others) have with an Intel HD6xx and Affinity Photo 1.10.
  6. Just tested again with Affinity 1.9.2, with OpenCL enabled. Much better / much faster.
  7. Hi, I installed 1.10 (after reading about it on some other site?!) and I noticed that just opening a RAW file and trying to zoom and move around in it, the display is really slow in updating (I also really notice it's updating in 'tiles', you see pieces of the photo being updated as you drag the exposure slider around for example). Just zooming in by using the '200%' shortcut makes the pixels very... well, pixelated. And I have to wait _a couple of seconds_ for the real file detail to come. So at first I'm looking at the file with 'fit to window'. When I then zoom in, it seems like those pixels on my screen get zoomed in (so I'm looking at a +/- 1900x1000 image zoomed in immensely) and then after a couple of seconds the rest of the pixels from the RAW file load, and I'm looking at the full detail the raw file has. Now, here is the thing: This also happens with a regular TIFF file, although it _is_ faster. But something is clearly slower in updating the display. Also, when I'm zooming in and out real fast, it seems like it suddenly freezes for a few seconds and then catches up again. A YouTube video that is playing on another monitor is then also freezing for a bit. The moment I turn _off_ OpenCL, everything is much faster! Zooming and moving around is fluent and instant. But I guess filters run slower? I don't remember having to turn that option off in 1.9. I know it's just a little integrated Intel CPU on an ultrabook, but from the benchmark it seems things should be quicker and more importantly: If the GPU would be slower, it shouldn't try to use it, but I also didn't have this on previous Affinity Photo versions.
  8. Just discovered the Reflect mode, and I want to know how to do the same effect in Imagemagick / Vips / G'mic, so I want the formulas :). I'll take a look at the links posted here to see if I can figure it out. What I discovered: If I take the luminance of my 'source layer', create a new layer filled with a yellow warming color, and use the luminance of my source layer as a mask, the reflect blend mode at 20% seems to do basically the same as Nik's very nice Color Effex 'Skylight' filter. It warms things up in a subtle way but also adds some saturation, but not so much in the shadows. Gives a very nice warming effect if your image was shot with clouds or pure in the shadows, or an auto-whitebalance made it 'too neutral / cool'. Way nicer than just adding a warming color with 'Soft Light', Photo Color Filter or other tricks.
  9. (getting the thread back alive) Maybe I can turn the question around into the problem he seems to be _really_ having: The 'soft proof' for Affinity Photo gives very different results to the soft-proof of Photoshop. Particularly, the blacks seem to be at least gray with my printer-profile in the soft-proof, while Photoshop still displays a pretty-much-black. So both are set to 'relative' intent, and both with black-point-compensation, yet the result is clearly different. Also, if I enable the 'gamut warning' in Photoshop, I can push the saturation of the image _way_ higher before Photoshop starts giving out-of-gamut warnings.. but if I check 'gamut check' in Affinity Photo, it gives a lot of gamut-warnings almost straight out of the box, and I can't push the saturation at all without getting more gamut warnings... This is all on the same (Mac) machine, with the same display-profile loaded and with the same printer ICC profile. Particularly the out-of-gamut warnings which seem to be given waay to early make it impossible to do any real soft-proofing with Affinity Photo on my setup.
  10. DxO still host the last free version I was told. It should be somewhere on the site . It's here https://nikcollection.dxo.com/nik-collection-2012/ Requires an email to download though .
  11. Really ? That can't be true.. I would consider that basic functionality, specially the blend modes..
  12. I decided to give Affinity Photo another go .. my workflow keeps changing / evolving so I thought to just try it to see if it's more usable these days compared to the early 1.5 beta's. I'm running into a few things where I'm thinking that I'm just missing it, or there must be another 'affinity-way' to do it. I can't seem to find a way to set the levels overlay to a specific blackpoint by sampling the image. Like the basic 'black, mid and white point' droppers in the levels-dialogbox. I only need black-point for now, but can't seem to find any of those. Now, I need to open the info tab, add a color sampler to a specific point (maybe even add a blur-fx underneath if I want average values, because the color sampler doesn't seem to have a size control.. the color-picker does, but not the color sampler). I drop it on the point, and I can get RGB values in the 0 - 255 range. But the levels-overlay takes values in percent.. so I need to convert the values from the color sampler to percent by doing (x / 255) * 100, and enter those values manually in the R, G and B channels in the levels-overlay... quite a bit of work! The other thing that I can't seem to find (and must surely exist somewhere) is the 'Divide' blending mode. I hovered over all the blending modes but none do what I expect from 'Divide' , so it doesn't seem to be a simple naming-difference. Now, I have to duplicate a channel and use 'Apply image' with another layer and enter 'DR / SR', 'DG / SG' and 'DB / SB' in the formulas to divide one layer by another layer. Not as slow as the levels-black-point but still a lot harder than just selecting the Divide blend mode and keep on going... Where are those functions in Affinity (I'm on 1.6.5.112) and / or what are they called because I can't seem to find them.
  13. I believe this is because the cropping (And other stuff) can be 'non-destructive'. Pick the layer you're working on / working with, right click it and try 'rasterize'. See if the picture 'received' by Color Efex now matches more.
  14. Same here. Switching blend mode to 'add' crashes it. (had a source layer dragged into it, enabled the 'equations checkmark' but didn't change any value yet. Blend mode to 'add' -> crash. This is in 1.6.0.75. On a related note, can someone point me in the direction to do the same as the following Photoshop apply-screen (note the 'invert', 'add' blending and the scale of 2) Basically, I want to compare to layers and to make the 'difference' between the two, so that I can set the new 'difference' layer to 'linear light' and apply the changes that way. (So, compare two layers to make the difference between those two, then apply those differences to a completely different layer) (and no, I can't use the built-in frequency-separation, I'm using this for something else).
  15. Where do you see to 'convert to 8 bit' ?? I never touched 8bit mode in Affinity since the very first Windows beta.
  16. Although i congratulate you on the release for the iPad version, can you share something about the how the development teams are allocated within Sherif? Seeing an iPad release kinda stings with me seeing the poor state the Affinity Photo release 1.5 is in (and 1.6 betas not showing much improvement). If it are separate development teams, then I have nothing to whine about. If resources actually went from Affinity Designer / Photo windows towards an iPad version I have serious doubts about the future commitment to that project... That being said, I don't use the Mac version of course, is Affinity Photo 1.5 and 1.6 beta having as much issues on Mac as it is on Windows?
  17. I know a lot of people that want to 'start' with the jpeg-output in a RAW editor, and tweak it from there. That is what I meant. The same with all the (early) x-trans users that just plain liked the jpeg output more but couldn't get ACR to match it closely :). Anyway, it was just a way to explain _what_ was happening, and that it is not a fault _in theory_. But you absolutely have a point that 'more pleasing out of the box' will help, specially when people start comparing raw converters. It's nice that it can produce great results, but if you need a lot of tweaking to get there, people tend to start using other stuff. Specially in the pro world, where the mantra of 'time is money' is simply true. A raw converter that needs 3 sliders tweaked a little bit vs a raw converter that doesn't is very clear in my mind :). I also think the 'pleasing from the start' comes from supporting different camera's and raw files. Some people have been complaining that their raw files start out way too dark and it appears a new (Beta) update fixed it. I believe (as an example) people not thinking the raw development was OK from Olympus OM-D E-M5 mark2 files, but my OM-D E-M10 mark1 files came out great from the start. So it depends on camera body and everything. Maybe make an official 'support' request with a sample raw file from you so they can tweak the default response? Wouldn't be the first time they did that from what I read on the forum.
  18. It means that the output C1 and ACR create are most often not at all what your camera would create if it was set to jpeg. C1 and ACR don't try to clone the look of your camera, they develop the raw how they think it should be developed, and that means it can look different. Most notably, C1 uses a film-like curve by default that gives the images some extra 'pop' from the get-go, and ACR also has a tone-curve applied that is more meant to normalize the output of all the sensors out there, so they all come out pretty similar in response. In other words, ACR (in 2012+ mode any way) applies a tone curve and leaves the output to be 'neutral'. Both the C1 and ACR method give lower contrast around the levels of well-exposed skintones (let's say around 55% to 65% IRE) why they often seem 'brighter' in the mids. That all being said, AP does little to nothing to make the images 'pleasing' with default values. It's rather bare-bones and straight shooting in the RAW development -> does little to the data so you can tweak it any way you want to. Yes, that means you might have to apply a curve that has a slight s-curve to it. This will will make the image pop a bit more and boost anything from 50% and higher, giving you the brightness in the mids you seem lacking. And if the curve is applied in luminance-only mode (something like LAB mode) that means your brightness increases and gives pop, but the color intensities stay the same. I'm betting that if you brighten that image you see the colors don't seem so saturated anymore. Since they're darker, you see more of the color. If you add white (make it brighter) the color seems less intense. So, you're absolutely right in what you see, but I don't think it's viewed as 'an issue', just a different output by default. And like I said, AP does way less to your files 'by default' then other programs like C1 and ACR do. ACR does a lot to your file that you can't turn off :). Maybe the other way of viewing things is like this: There is no 'one correct way' of developing the RAW data, only multiple ways to do it, and you can choose which you find more pleasing or takes the less work to get to a pleasing result. Most often photographers want the RAW converter to match the camera's JPEG output by default (Since that is what they saw on the display when they took the picture :)) but like I said, there is no one 'correct' way. Your camera is just one way to deal with the sensor data, programs do other stuff with it. Did you ever took a look at the (Free / opensource) Rawtherapee? It gives you _all_ the options. There are like 6 options to set brightness+contrast in there. Normal programs pick one, but there are multiple ways to do things.
  19. Sort of what I said : linear space in 8 bit is wrong and should never be used. But.. linear space in 16 bit is used a lot and completely ignored by Affinity Photo. In 32 bit floating point, linear space is even the standard / norm :).
  20. I asked about this in a previous post somewhere (I called it a bug I believe ). Affinity photo does not support ICC profiles with a linear gamma,while in 8bit / 16 bit. They appear and work fine if working with 32 bit files. I do gamma correction with imagemagick or Photoshop and then work with Affinity photo. OR I load the file in Photoshop, save it as 32bit and then open that in Affinity Photo. Then you can do all the editing you want in linear space (while actually seeing it gamma corrected for your monitor ) and save it back. But you do have a 32 bit file. If you ever want to go back to a linear 16bit file you'd have to use Photoshop or something else again. Another way they explained it to me is that you can open your linear file in Affinity photo , and then add a LUT layer with a 3d LUT loaded to view the file normally on your monitor. Keep that LUT layer always on top, to use as a proofing layer. When saving, remember to disable the LUT layer so you actually save linear data again. Which LUT to use and where to get it depends on your colour profile that you want to work in. My files are linear-adobergb so I use a lut that converts it to normal Adobe RGB while working. A gamma of 2.2 is never exactly correct, but it's often 'close enough'. (sRGB isnt entirely 2.2, there are parts in the shadows there the gamma is different. So not a constant gamma. Adobe RGB is 'constant' but it's more 2.19 than 2.2 (2 + 51/256). I don't know why linear ICC profiles are ignored / removed with 16 bit files. On 8bit I understand (you don't want linear space in 8bit, it will posterize like crazy) but 16 bit is used a lot. Scanner output as a simple example.
  21. No issues with crashing here, and images with sRGB or AdobeRGB 16bit work just fine. Didn't try any wide-gamut stuff in Nik though.
  22. Hmm, no.. it's not 'limited' to 16bit.. it's more like "only working in 32bit" :P. But linear-space work in 8bit isn't recommended at all and will cause problems, so I wouldn't hold it against the Affinity team if they prevented linear spaces on purpose in 8bit
×
×
  • 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.