GregS

When I open a document in Adobe RGB, which uses a white point of D65, and allow Affinity to convert it to my working space, which is Colormatch RGB (D50 white point), and have the rendering intent set to Absolute Colorimetric, I don't see the expected blue-ish tint in the whites. Absolute Colorimetric should NOT maintain the white point, and thus, a white in a D65 based color space should shift slightly towards blue when mapped to a D50 based color space. (and this is the behaviour I have observed in the past, using Photoshop) Is the rendering intent setting even used when opening a document and converting to the working space? If it's NOT used here, when is it used?

I've upgraded to 1.6, but I don't think there has been any improvement - perhaps a TINY improvement - 16 seconds now, instead of 17......

(thread bump) I agree with Laurentia - Affinity, even now, seems to be missing CAMERA PROFILES, unless Affinity has an internal database of profiles which isn't mentioned in the documentation? The so-called "raw" files, if they are to be accurately interpreted, still have to have some form of profile.

Another thread. (and I strongly agree with user Laurentia in this thread!)

This thread seems relevant - someone asked a similar question to me over 2 years ago - no answer at all!

There's just one thing that I'm still concerned about. If I set my working space to sRGB, Affinity actually does NOT warn me about converting to my working space, even though I still have conversion warnings enabled. This makes me wonder whether Affinity is actually treating the RAW file as if it were in sRGB, which it almost certainly is not. So, I'm still not convinced all this is working properly.

Sorry for for the multiple replies, but this is important. Affinity doesn't actually say that it converted FROM sRGB to Adobe RGB - it just says it converted TO Adobe RGB, without any mention of the source colour space. . So this may be a storm in a teacup - it is presumably converting from the *camera's* profile to Adobe RGB, which of course would be the correct thing to do. Sorry for wasting your time! I understand that the camera's "profile" may not be in the form of an ICC profile - it's just data in some form that allows Affinity to interpret the raw file.

James, After doing a bit of research, it seems you are CORRECT - RAW files do NOT have a colour space. In theory, then, there should be a way for us to enter the characteristics of the R, G, & B filters in the Bayer filter, so that we have a more accurate starting point with which to interpret the raw data. Maybe the Bayer filter data is substantially the same across different brands & models of camera? Anyway, if there is no profile associated with the RAW image, why does Affinity even allow me to do a conversion to my working space? Remember, it does warn me that it is converting from sRGB to Adobe RGB. (I had set Adobe RGB to be my working space) I think I'm better off using Canon software to do the developing, because presumably Canon do have some kind of "profile" for the camera, the data for which is not stored in the RAW file. I.e, they would have intimate knowledge of the sensor, the colour filter array, and how the sensor data is processed etc etc. Regarding the Canon software reporting Adobe RGB, apparently the colour profile that is stored is independent of the RAW data - it's used in conjunction with the embedded JPEG preview. I note with interest that Adobe Camera RAW (and Lightroom) do have profiles for different cameras. If a camera isn't in their database, it warns you. https://www.color-management-guide.com/color-management-and-camera-raw.html

James, Apologies - I didn't read your post fully. I think you are incorrect regarding RAW files not being in a set colour space. How on earth can the software interpret the raw data, unless it knows what colour space the raw data is in? As I said, my RAW files are in Adobe RGB. I configured that in my camera, and the Canon software (Digital Photo Professional) reports this too. Just by the way, even if I don't convert the raw to my working space, Affinity still has to do a conversion to the monitor profile in use. If it thinks my raw images are in sRGB, this conversion will be inaccurate. Note also that the colours displayed by Affinity don't match the Canon software. I don't know whether it's only because of this issue, but I'd like to address this issue first.

James, Thanks, but I don't think you understand the situation fully. It's very simple - Affinity seems to think that my RAW files have been captured in the sRGB colour space, and this is a problem regardless of what my working space is, because it won't be able to properly convert the image into my working space if it's converting FROM the wrong colour space (sRGB). So, again, if I'm right about this, obviously it would be nice if this is fixed, but in the mean time, is there a way I can manually assign the Adobe RGB space to my RAW images in the Develop persona?

Affinity seems to be assuming that my Canon RAW (EOS M) files have a colour space of sRGB, despite the fact that they are really in Adobe RGB. The reason I say this is that if I enable colour space conversion warnings, and set my working space to Adobe RGB, it does warn me that it is converting from sRGB to Adobe RGB. Does affinity support colour spaces other than sRGB in RAW files? If not, is there a way I can assign the correct space manually in the Develop persona? (I can't seem to find a way to do this)

It appears that Affinity may simply be giving us similar controls to Adobe products, and I think this is the right thing to do: https://www.dpreview.com/forums/post/24039818 I'm only familiar with very old versions of Photoshop, so this Exposure vs Brightness issue is new to me.

I too am confused by the Brightness control - if it preserves the highlights, the word "brightness" is rather misleading, and I agree with Fixx that what the "Brightness" control really does is probably more akin to a gamma adjustment, and if that's what it does, it would be better to simply rename the Brightness control to Gamma.

12 seconds is only slightly faster than my 14 seconds, which is indeed promising. Re the dictionary - definition no 4 is the meaning I had in mind, and is a meaning used frequently in the common vernacular. I think your chosen interpretation is ridiculous - if I had really thought there was NO hope for improvement, there'd have been no point in making a post at all. I'm glad you aren't willing to continue this debate which should never even have been started to begin with. EDIT: It currently takes 17s, not 14s as I said above.

Good news! How long does it take you to open the same file, using the production version? Just by the way, definition no. 4 of the word "hopeless" at dictionary.com: "not able to learn or act, ***perform, or work as desired; inadequate for the purpose***" (emphasis mine)