jorismak

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.

 

Why would it work fine with Photo 1.9 then?

in my experience (comparing to a lot of open source jpeg libraries, irfanview, mozjpeg 2  / mozjpeg 3) Photoshop's jpeg export is actually shockingly good and you should not expect any other program to just blindly match it :). That's with CC 2014 / 2015 / 2017 though, but I doubt the jpeg engine changed over the years.
 
Mozjpeg3 is still the winner of them all, but I never use irfanview or imagemagick's jpeg save anymore because photoshop's is clearly better.
 
If it's possible for the Affinity team to incorporate the opensource mozjpeg3 library (a mod /fork of the 'normal' libjpeg as far as I know) it would be a winner :P, but I have no clue if this is possible license-wise and all.

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?

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.

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.

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.

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.

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.

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.

Thanks for the tips ! Been using luts in videoworld , never thought about using them in photo work. Stupid :).
 
If the 16bit conversion is indeed done in working space, that means I can work around it which is a huge help already

the problem with the viewing system of Affinity is that it is (sometimes) not possible to get a true 1:1 pixel display of the image. In other words, it's not possible to view an image _without_ scaling.
 
That means you're judging the image and quality as (image + affinity scaling). And that might be different to how other software views the image because they're scaling is different or they don't view it without any scaling.
 
Multiple places around the net will explain how important it is to judge your images unscaled (not like it's the holy grail. Viewing at intended-viewing-size or expected-print-size is of course also important) for this reason: The scaling affects the image, _always_. So it should be possible to view unscaled. True device pixels 1:1.
An option somewhere that sets the viewing-percentage _exactly_ so that there isn't any scaling is what's required / requested. It could be right next to the 'view 100%' option. I've set my Windows scaling to 100% just to get a true 1:1 in Affinity.
 
It's true that if the Windows scaling is set to a round number as 150% you can get true 1:1-pixel scaling by viewing at 75% in Affinity.
But Windows sets my Windows scaling by default to some fraction like 122.33% (because it's auto-calculated depending on the reported display size and display pixels). I can't set Affinity to a viewing percentage that's a true 1:1 pixel that way.
 
And the explanation 'you want Affinity to show the image like other software will show it' is a nice explanation, but not really true. I'm delivering the output from Affinity, in a very dumbed down way, I'm delivering pixels. I want to view those pixels and stand by what I deliver. If the end user is displaying those pixels scaled in whatever way (up / down / sharp / soft) I'm not responsible for that. It's the end-user that chooses to scale it (intended or unintended by display settings :). A bit like I'm delivering a 150x150 pixel image intended to be embedded somewhere at the side of a website. If a user then tells me "Your image looks like crap fullscreen" I'm going to think well d'uh. You're not supposed to view it fullscreen :P.
 
Adding a preset option in the zoom/view options that is called something like 'device 1:1' or 'true 1:1' or whatever, and behind the scenes does a thing like '1.0 / windows-scaling-percent * 10000.0' should get you pretty much there (or set a scaling factor like 1.0 / windows-scaling-factor). I'm just a bit afraid of rounding errors here and what that might do with the scaling still active :S.
 
Kinda the same here. If I'm delivering a pixel image I want to view what the image looks like. Whatever scaling gets applied at whatever device somebody uses to view it is not on me.
 
Another point is that when the display scaling is set in Windows, it's meant to scale text and UI elements. A good behaved graphics program like an image viewer (according to the MSDN this) will use the Windows scaling for text and UI, but will display graphics elements like the image at device pixels 'because that is what the end user expects'. Microsoft's theory here sounds good on paper to me:
If I have a small screen with a huge amount of pixels (those 15.6" laptops with a UHD screen for instance) I want the elements scaled up because otherwise they would be invisible small. But I don't want any image like that scaled because then there would be no point in having UHD pixels (if every program would scale _Everything_ up to 200% for instance). I would just end up with 'finer drawn text' and no good benefit to pixel precision.
 
If the scaling is somehow not preventable, at least give options to have control over the type of scaling (and please, B + C parameters to Bicubic or at least different bicubic-presets) so we have some idea of what it is we're actually looking at. I have the feeling you don't even know since it's "controlled by the graphics card driver", am I correct?

And I wonder if I have my Windows scaling to something like 132% if I can zoom to exactly 75.7575757575757575756% to get the 1:1 preview :P :P.
 
As said in another thread about this, _at least_ an unscaled 1:1 device-pixels mode must be there somewhere, easy accessible. Or in the options make an option to scale / view logical size or device size.
Adhering to the Windows scaling factor for a gfx application is just.. weird :)

If you don't see the red outline it probably means you have a layer in front of what you're inpainting on, or the mask is hiding the area you're trying to inpaint.
 
Or the opacity is changed or stuff like that.
 
Make sure you select the proper layer you're trying to inpaint on and that it is indeed the visible layer (with nothing on top) and that the area you're painting on is not masked out. Never had problems otherwise. (I did once use a mask on a layer I was inpainting on, and indeed the moment I reach an area that is masked out the red outline disappears while painting)

Don't get me wrong, I'm not saying at all the current viewing-with-scaling is bad. It's the new hi-res / retina world and DPI and OS-scaling-factors are getting more important. In the Windows world 'DPI" has been blatantly ignored since before Windows 7, and is only really being used by the OS itself since Windows 8 (and I think even 8.1).
 
So yeah, it's one of those things were not everything has to be like the old ways. "What we're used to before" doesn't mean it's the correct way. That's why I stress on the 1:1-device-pixel 'unscaled viewing' part, because that's what  I (at least) find important in this. How the rest of the viewing percentages go I don't care, as long as there is a quick to reach 1:1-true-device-pixel viewing size :).
What the easiest (or best) way is to accomplish this (and if it's something you're actually going to do) is completely up to you guys/girls over at Serif of course.

Hi there,
 
PS has the options in the levels dialog to do an 'auto levels', but more importantly to set the thresholds for it. You can enter an amount of percentage of signal at which you want the set the level-markers so to speak. And then it has options to do that for every channel separately, or to keep the overal link between channels and a few other options.
 
Is there something like that somewhere in Photo?
 
The per-channel thing I can do by separating the channels into a R, G and B layer and doing 'auto levels' on those layers... but I want to set the thresholds somewhere :).
 
 

Hi there,
 
PS has the options in the levels dialog to do an 'auto levels', but more importantly to set the thresholds for it. You can enter an amount of percentage of signal at which you want the set the level-markers so to speak. And then it has options to do that for every channel separately, or to keep the overal link between channels and a few other options.
 
Is there something like that somewhere in Photo?
 
The per-channel thing I can do by separating the channels into a R, G and B layer and doing 'auto levels' on those layers... but I want to set the thresholds somewhere :).
 
 

the problem with the viewing system of Affinity is that it is (sometimes) not possible to get a true 1:1 pixel display of the image. In other words, it's not possible to view an image _without_ scaling.
 
That means you're judging the image and quality as (image + affinity scaling). And that might be different to how other software views the image because they're scaling is different or they don't view it without any scaling.
 
Multiple places around the net will explain how important it is to judge your images unscaled (not like it's the holy grail. Viewing at intended-viewing-size or expected-print-size is of course also important) for this reason: The scaling affects the image, _always_. So it should be possible to view unscaled. True device pixels 1:1.
An option somewhere that sets the viewing-percentage _exactly_ so that there isn't any scaling is what's required / requested. It could be right next to the 'view 100%' option. I've set my Windows scaling to 100% just to get a true 1:1 in Affinity.
 
It's true that if the Windows scaling is set to a round number as 150% you can get true 1:1-pixel scaling by viewing at 75% in Affinity.
But Windows sets my Windows scaling by default to some fraction like 122.33% (because it's auto-calculated depending on the reported display size and display pixels). I can't set Affinity to a viewing percentage that's a true 1:1 pixel that way.
 
And the explanation 'you want Affinity to show the image like other software will show it' is a nice explanation, but not really true. I'm delivering the output from Affinity, in a very dumbed down way, I'm delivering pixels. I want to view those pixels and stand by what I deliver. If the end user is displaying those pixels scaled in whatever way (up / down / sharp / soft) I'm not responsible for that. It's the end-user that chooses to scale it (intended or unintended by display settings :). A bit like I'm delivering a 150x150 pixel image intended to be embedded somewhere at the side of a website. If a user then tells me "Your image looks like crap fullscreen" I'm going to think well d'uh. You're not supposed to view it fullscreen :P.
 
Adding a preset option in the zoom/view options that is called something like 'device 1:1' or 'true 1:1' or whatever, and behind the scenes does a thing like '1.0 / windows-scaling-percent * 10000.0' should get you pretty much there (or set a scaling factor like 1.0 / windows-scaling-factor). I'm just a bit afraid of rounding errors here and what that might do with the scaling still active :S.
 
Kinda the same here. If I'm delivering a pixel image I want to view what the image looks like. Whatever scaling gets applied at whatever device somebody uses to view it is not on me.
 
Another point is that when the display scaling is set in Windows, it's meant to scale text and UI elements. A good behaved graphics program like an image viewer (according to the MSDN this) will use the Windows scaling for text and UI, but will display graphics elements like the image at device pixels 'because that is what the end user expects'. Microsoft's theory here sounds good on paper to me:
If I have a small screen with a huge amount of pixels (those 15.6" laptops with a UHD screen for instance) I want the elements scaled up because otherwise they would be invisible small. But I don't want any image like that scaled because then there would be no point in having UHD pixels (if every program would scale _Everything_ up to 200% for instance). I would just end up with 'finer drawn text' and no good benefit to pixel precision.
 
If the scaling is somehow not preventable, at least give options to have control over the type of scaling (and please, B + C parameters to Bicubic or at least different bicubic-presets) so we have some idea of what it is we're actually looking at. I have the feeling you don't even know since it's "controlled by the graphics card driver", am I correct?

After adding my photoshop plugins folder and restarting, I see all my plugins in the list. (and I had the checkmark 'allow unknown plugins' checked, because _every_ plugin is listed as unknown)
 
But they are all greyed out (including Nik Color Efex and Topaz Denoise 6 which are listed as fully working on the Mac version).
 
Switching the workspace to 8bit they became all available, but I if they only work in 8bit I wouldn't really call it 'compatible' or working to be honest.
 
And the first I actually tried using is CF Systems ColorPerfect, which immediately crashed upon loading (access violation message).
 
 
Another question (which I can probably figure out be searching and reading but still), am I supposed to work this with raw files:
Open the raw file, switch to the 'develop persona' if Affinity doesn't do it itself, make adjustments in the right and when I'm done press the 'develop' button in the top left?
Also, the lens corrections I could find where all manual, are there any kind of automatic lens correction-profiles? In the case of raw files from micro 4/3 camera's which have 'embedded' distortion correction, do they apply?
 

And I wonder if I have my Windows scaling to something like 132% if I can zoom to exactly 75.7575757575757575756% to get the 1:1 preview :P :P.
 
As said in another thread about this, _at least_ an unscaled 1:1 device-pixels mode must be there somewhere, easy accessible. Or in the options make an option to scale / view logical size or device size.
Adhering to the Windows scaling factor for a gfx application is just.. weird :)