Search the Community

Read the following article about color management, which deals with the different color spaces their pros/cons etc., it gives a good common overview here! - Note that ROMM RGB = ProPhoto RGB here! Fine Art printing, part 2 Color Management (Google translated to english) Drucken, Fine Art Printing, Teil 2 Farbmanagement (German original article)

While going directly to converting the raw document to LAB/16 in AP1 allowed me to get to the background properties assigned to the channel subcolors described above it didn't in AP2 to my knowledge. But when I followed James Reston's method to first assign the ROMM RGB color profile and then convert the document to LAB/16 the background: lightness, AOpponent and BOpponent methods are still available in AP2. What's more the color profile is strikingly better when the correct steps are taken.

Well, you don't have to have an answer to this questions, but I'm hoping that someone from Serif has an answer. As long as everyone is designing in the sRGB color space for electronic displays, no one need worry about color gamuts. But if one is alternately designing for sRGB devices, then wider color gamut ROMM RGB display devices, and then much smaller color gamut CMYK print output, one needs to be concerned about specifying "in-gamut" colors. How does Serif expect one to manage these color space gamut issues? How does the Affinity software prevent someone from (or warn someone against) using the Lab color model sliders to spec an out-of-gamut color for their CMYK document?

Hello! I watched the Affinity-Tutorial "ProPhoto cs sRGB" some days ago and started to try this for my workflows. The first obstacle to overcome was, that on my mac there was no prophoto icc-profile. In this forum i found a post about that, where is was shown, that the ROMM RGB Profile should be the same. This profile is on my mac, so I gave it a try! But one thing about the ROMM-Profile I didn´t understand. In the forum-post was a link to the ICC-website to download the ROMM.icc file. I also downloaded the profile (unless the romm was on my mac) just to compare the one on my mac with the one downloaded from ICC. The one on my mac is dated with 2015 or so and the one freshly downloaded was dated with about 2006!? The settings shown via the color-sync app on my mac are also not the same... so is the ROMM on my mac still the same profile than the one from ICC? And are those really the same like the prophoto?? After my try on one of my actual projects - I tryed the same workflows than in the tutorial videos - I got stuck with some troubles... - converting my sRGB Image to the ROMM was as expected. And in some details the result of my project changes quite positively. I could really see that the bigger gammut gave some adjustment- and filter-layers more room to work. - then i tryed to export the project - like on the tutorial - via the export dialog as an jpg with an sRGB profile again. But the result was not the same, then. The color shift wasn´t the problem! The sharpness of my foto got lost? What I couldnt understand. Exporting a jpg directly from my original project file (in sRGB, not converted to ROMM) looked much better, sharper, like it should look like! So the jpeg out of the "sRGB-aphinityfile" and the jpg out of the "ROMM-aphinityfile" look enormous different, but not like the nice differences I could watch via the profile-conversion. The third and last issue on that is about the soft proof. Because my actual projects will be printed on fine art paper I use the soft proof from the producer to check the gammut. after the romm-conversion it is much more difficult to get rid of the "black" surfaces the gammut check shows. What is expected, because the romm have a much greater gammut. But maybe you can give me some tipps to handle this better, because even in my sRGB projects it is quite difficult to reach the gammut of the producer (the fine art paper) - can it be, that the gammut of this fine art paper is rather small compared with sRGB (and smaller compared with romm)? I watched the tutorials about soft proofing, but on my projects it seems much harder to reach the soft proofed gammut. Thanks for help! the icc profile for my soft proof is attached, as well as the two romm profiles, the one from my mac and the one from ICC. (Wasn´t allowed to upload the icc files) Thanks!! Andreas

Walt, thank you for you quick response. You make an excellent point. When it comes to colorspace and profiles, I am out of my depth. I'm not sure linear profiles are limited to 32 bit. At least that doesn't seem to be the case for darktable's raw processing. Nonetheless, the only built-in Prophoto profile in darktable is linear. It would appear that AP isn't recognizing this profile. I am not able to locate the linear prophoto profile in the darktable installation files in order to provide it to AP. As a work around, I have taken the ROMM RGB profile from AP and loaded it into darktable as a new output colorspace. This seems to have done the trick. This seems to give the same result as converting the file to ROMM RGB within AP. I am also able to convert from linear prophoto to ROMM in ACDsee and Krita. However, Krita seem to be able to recognize a correctly display the linear prophoto profile. In the end, I am unlikel to work in ROMM very often, but wanted to be able to in there was a need. Thanks again and Happy New Year.

Hi Chris, Found the problem ....... Dodge and Burn not working in 32bit ROMM RGB ..... I changed to 16bit ROMM RGB and the tools work ... also in 8bit ROMM RGB they are working. Is this a bug !!!! cheers Colin

This sentence alone can be misinterpreted... I meant only with32 bits, color grading has no sense, because 32 bits is meant for tones. However when you combine ROMM RGB with 32 bits, then yes. First because the colourspace is large enough, so colour grading have space to find the right chroma, and adding the 32 bits depth, it also has room for the right intensity, without being stuck between 2 values (0 and 1). That's why I added ROMM RGB or Rec.2020 for colour than tones. A good combination is a large colour pace and a large bit depth. That's why I'm trying to try to find a process with Affinity keep this combination as long as possible before exporting. As for my background history, I was using Lightroom as my developing software, and wanted to move away. Last year I started looking around and tried Darktable. This is were I learned most of colourspace, linear etc... (and started a youtube channel of my journey of learning). I'm far from knowing everything. That's why I'm asking questions here.

Perhaps it is helpful to keep in mind that colour spaces (format) and colour profiles are two different things. Spaces are RGB and CMYK. Profiles are AdobeRGB, sRGB, U.S. Web Coated (SWOP) v2, PSO uncoated V3, ... RGB SPACE is for Monitors/Displays adding light to mix colours. => Adding Red + Green + Blue = white on your display. Within the RGB space, RGB PROFILES are for example sRGB, AdobeRGB, ROMM RGB etc... CMYK SPACE is for printing ink on paper to mix colours. => Adding Cyan + Magenta + Yellow = Black (or close to black) + K (black) to make things even darker. Within the CMYK space, CMYK PROFILES are for example PSO uncoated V3 FOGRA 52 ... U.S. Web Coated (SWOP) v2 ... So, switching from one space to the other, you will always have to change the profile as well, or not? Correct me if I'm wrong here... At least in Photo I can't select a RGB profile when I'm in CMYK and vice versa.

It would be easier if you can say what color profiles your display is supporting. E.g. my LG monitor supports sRGB, AdobeRGB, DCI-P3, and the last has the widest gamut. If i would edit a document with ROMM RGB, some colors cannot be displayed correctly and would be clipped / transformed to similar colors within the visible range of DCI-P3. I would not be able to see the actual colors, unless i switch to a ROMM RGB capable display. The other way, editing sRGB is no problem, as DCI-P3 can render all possible sRGB colors (without clipping).

Your original artwork is in ROMM (ProPhoto) RGB in 8bit. This is a large gamut color space and is not really amenable to saving or manipulating in 8bit color precision - however, that is not such a big deal here, as there are only 2 colors and no gradients, etc When you print, you need to specify the RENDERING INTENT of the conversion that is done from the working/source color space of the file into the output color space of the printer. There are four rendering intents: Perceptual Relative Colorimetric Saturation Absolute Rendering intents are different ways to instruct a conversion of a large gamut color space into a smaller space - they differ in how the colors that are out of gamut in the larger space get translated into the smaller space. For graphical artwork such as your logo, saturation rendering intent is probably best, as it will tend to preserve the blue in the logo. I am not sure how the PDF artwork was generated, but for printing the rendering intent can make a huge difference with colored graphics, versus a photographic image, for example. You do not want to convert into or assign the printer ICC profile to the artwork in Affinity Photo - just print from the source color space (ROMM RGB), specify the printer-paper ICC profile in the print dialog and tell the printer what rendering intent you want to use - the print driver software will do the appropriate conversion. You can use the printer's ICC profile to soft-proof the image in Affinity Photo - add a soft proof adjustment layer to the document and then specify the printer's ICC profile as the device you want to simulate and see if you can reproduce the problem on screen. You can also try converting the image's color space to a smaller working color space like AdobeRGB or sRGB to reduce the gamut prior to printing. Without more detail regarding your workflow, it is difficult to tell exactly why the blues in your logo are turning black. Somewhere along the way, color management decisions are being made without your full control or knowledge and the color numbers are being interpreted differently than you want/expect them to be. Kirk

Ok, so do you stay with the default color space throughout editing and then convert once you have a finished image? For me, when I open a RAW file in the develop persona the color space is sRGB. Should I keep this colour space throughout editing and into the photo persona? Should my default color space be something other than sRGB when opening a RAW file? I'm sure you saw above that RichardMH recommended switching to ROMM RGB, as it is the largest color space.

Hopefully this can clarify the issue and also clear up the concerns that Photo is discarding or throwing away anything outside of sRGB: RAW files opened in Develop go through an image processing pipeline, during which the colour information is extracted and processed—the colour space used for these operations is ROMM RGB because it provides a suitably large resolution and enables colour values to be saturated and manipulated without clipping to white. This choice of colour space was introduced in version 1.5 where there was a marked improvement in RAW files with intense colour values (e.g. artificial lighting). However, the actual document profile is in sRGB—this means the final colour values sent to the screen are restricted to sRGB. Is this deficient? Yes, and there have been discussions about how to tackle it without risking further complication for people who don't use wide colour profiles. There is a silver lining though. RAW files are developed in an unbounded (float) colour space, which means all the values that fall outside of sRGB are not clipped or discarded. If you were to then set your output profile to a larger colour space like ROMM RGB, these out of bound values can be accommodated by the larger resolution of that colour space. Essentially, you can avoid clipping values outside of sRGB when clicking Develop, and you can get them back once you're in the Photo Persona: the issue is that you can't see these values within the Develop Persona. I've experimented with one of my photographs of some intense lighting to back this up, and have attached it to this post for people to experiment with. I've also compared the results versus Photoshop CC 2019 (where you can set the colour space and it will actually affect the view transform) and, minor processing differences aside such as sharpness and lens distortion, have been able to match the intensity of colours. For Photoshop I also used ROMM RGB and increased saturation directly in the Camera Raw module. Here's the RAW file for you to try out: _1190462.RW2 Steps for this experiment: Enable Shadows/Highlights and drag the Highlights slider to -100%. Avoid any colour or saturation adjustments, add other adjustments to taste (e.g. noise reduction). Enable the Profiles option and set the output profile to ROMM RGB. Click Develop. Once in the Photo Persona, add an HSL adjustment and increase Saturation all the way. You'll be able to dramatically saturate the image without losing resolution. If you close and re-open the RAW file and try to increase the saturation within Develop, you'll notice that the colour values are restricted to sRGB—however, even with values at the limit of sRGB, you can still set the output profile to ROMM RGB and then increase them further once in the Photo Persona. And below are two images, one still in ROMM RGB, the other converted to sRGB. I'm not sure how they will display on the forum (and whether the forum software will process and convert the colour profile—hopefully not!) but feel free to download both and view them in a colour-managed application or image viewer. If your display is capable of reproducing wide colour gamuts, you should see a noticeable difference between the two. [Edit] OK, that didn't work, the forum software converts to sRGB and ruins the comparison. Here's a Dropbox link to the JPEGs and RAW file where you can download the original files: https://www.dropbox.com/sh/aof74w94f6lm3d2/AABXE2OJMfk__kjA_jb6vwmia?dl=0 Hope that helps! James

@anon2 Thanks for your reply. Based on that I tried the following: no convert the final panorama but convert the individual images and then make the pano from them. first I re-enabled the "Convert opened files to working space" - Option then I opened all images individually, (they are auto-converted from sRGB to ROMM RGB) and saved them again (ROMM RGB). after that I used the panorama-tool again with those converted images and the result was fine. To me, this is evidence that you are right ("..just assigns the ROMM profile without converting the pixel values..") and makes me more secure that no color-information is lost during the panorama-stitching since the ROMM-RGB gamut is wider/bigger than sRGB. Thanks. Fritz

Hi Lee, Thank you for replying back, but I’ve sorted out the problem since I posted that message. It isn’t a ROMM RGB vs sRGB thing causing the softness that I first thought. It appears that when you go from, Open to Browser to select your RAW image, then to the Develop Persona, then eventually to the Photo Persona as per normal editing, the image softens. And it’s soft because I wasn’t sharpening the image in Develop first; I’ve only ever done that in Photo not knowing any better. I only noticed this recently, because it was the first time I decided to edit an image from start-to-finish using the latest Affinity version ( and trying out ROMM RGB as well for potential printing down the track ) and not going through Nikon View then to Affinity to finish off the image like I have in the past. It sure is a learning curve. Anyway, many thanks again for your time and interest. Cheers! Tony

In the Designer file you have the underlying RGB color values defined in ROMM:RGB: ISO 22028-2;2013, and in the Publisher file you have them defined in sRGB. If you assign the former to latter, or latter to former, you get identical colors in view whether your document color mode is CMYK or RGB. In the video, I reverse the underlying RGB color modes without changing a single color value and end up having the Publisher document showing as your Designer document showed, and vice versa: underlyingrgb.mp4 So the apps and palettes work as they are designed. Affinity Publisher and Designer have dual color modes but that is not so obvious because the underlying "other" working space is not explicitly shown.

I can reproduce this if I'm using ROMM RGB. But that's true of the retail version wich doesn't have OpenCL. OpenCL seems to give me the correct render when using ROMM RGB as if I use the retail and set ROMM RGB I get the green cast. The first part of the video shows what I'd expect to see when OpenCL is on. The second part of the video, when you turn it off shows the green cast and looks wrong to me.

First, a RAW image does not have a color profile. It is simply the raw sensor data; what the camera saw. Any clipping would occur during the Develop process, when Photo creates a developed image from the RAW image. At that time, the settings in the Develop Assistant determine whether Photo produces a 16-bit RGB image or a 32-bit RGB image. In Preferences/Color you can specify the color profile to use with 8- or 16-bit RGB images, and you can specify the color profile to use with 32-bit RGB images. When you press Develop, Photo produces an image as specified in the Develop Assistant (16-bit RGB or 32-bit RGB). Before you press Develop, while operating in the Develop Persona, Photo will display and (I think) operate on the image using the color profile specified in Preferences/Color for the kind of image that will be produced when you press Develop. So, for example, if I have told the Develop Assistant to produce a 16-bit RGB image, and I have told Preferences/Color that my preferred color profile for 16-bit images is sRGB IEC61966-2.1, then the Develop Persona will be operating with that profile applied to my RAW image. At least, that's my current understanding, and if I open a RAW image with those settings, and look in the Develop Persona's Info Panel, it says that sRGB IEC61966-2.1 is being used. On the other hand, if I have told the Develop Assistant to produce a 32-bit RGB image, and I have told Preferences/Color that my preferred color profile for 32-bit images is "ROMM RGB: ISO22028-2:2013 (Linear)" then the Develop Persona will operate with that profile applied to my RAW image. If I open a RAW image with those settings, the Info Panel will say that the image profile is "ROMM RGB: ISO22028-2:2013 (Linear)". As ROMM-RGB is a much wider gamut profile than sRGB, less clipping will occur when I press Develop. Of course, even in case 2, at some point I will have to display or print the image. At that point, the characteristics of the output device come into play, and further clipping may occur.

I noticed the same behavior in 2021 with version 1.10.4.1198. Like you I had set my color profiles to "ROMM RGB" for both RGB and "32bit RGB". A noticeable color cast was introduced in the exact same step as you described. I switched the "RGB Color Profile" back to "sRBG" and the issue is gone. Color profiles can always be good for surprises... This old discussion was a great help for locating the solution in the settings. 👍

I exported from darktable a 16Bit tif in linear prophoto rgb colorspace. I opened this document in AP (first attachment as screenshot). AP seems to be crushing the blacks with a purple cast in the shadows. I've opened the same file in several other programs (Capture One, Capture NXd) and the file seems to be rendered much closer to what it does in darktable. Then I convert the file to ROMM RGB and it seems to lighted the shadows and remove the color cast (second attachment as screenshot. Is it possible that AP is not recognizing the tif file color space properly, i.e., it doesn't recognize linear prophoto rgb as ROMM RGB? I've also attached the 2 tif files. DSC_2409_Prophoto.tiff DSC_2409_ROMM.tiff

@R C-R: Yes, I was sure. Furthermore, how many bits (16 or 32) which color format (8-, 16- or 32-bit RGB, etc.) and which ICC profile (sRGB, Adobe RGB, ROMM RGB) are used during the processing, especially in the Photo persona, seem to be three independently configurable aspects of the processing, an impression that one doesn't automatically get when one learns that the Develop persona works in 32-bit float and uses the ROMM RGB profile. Indeed, I had assumed up until now, that ROMM RGB implied 32-bit processing and 32-bit RGB color format, and that the advantages of both developing and editing using 32-bit floating point calculations in ROMM RGB would outweigh the slowness of floating point calculations. I think I, at least, really need to understand what @James Ritson was warning against when he wrote, "Honestly, I wouldn't recommend touching 32-bit unless ... ." Did he mean color format 32-bit RGB or 32-bit floating point processing, or are these equivalent for him. Specifically, too, I would like to know some of the pitfalls of "32-bit" to which he alludes.

Does it mean I cant use ROMM RGB for 32bit ? Very bad ... 😐 I give up because only Serif knows how to enable the ROMM RGB setting ...

Thanks, Hubert. I read @James Ritson's answer in that thread, obviously in a way that he never intended, weighing each and every word twice and thrice, and coming up with more questions than answers. A cursory reading reveals what seems to be a contradiction between the virtues of development done in 32-bit floating point, the advantages of editing (in the Photo persona) in a wider-gamut color space than sRGB, and the ominous sentence that begins, "Honestly, I wouldn't recommend touching 32-bit unless you're doing something that demands precision above what 16-bit offers, e.g. close-ups of clouds or skies [...]" I think 32-bit processing and working in, say, ROMM RGB are two different animals. At least, that's the only way I find to avoid that contradiction. The abrupt cut to the take-home message, not to use 32-bit unless ..., is, in my case at least, unhelpful, for it's exactly the sky and the clouds, blown out in the JPEG generated in-camera and quite evident in Develop, that I will want to preserve, if not enhance, in the Photo persona. Maybe James would not consider that to qualify as "close-ups of clouds or skies." Finally, the reason that James gives for avoiding 32-bit if possible is enticingly nebulous: "but it brings about other issues into your typical image editing workflow." I suspect that I am experiencing some of those issues, and could avoid them altogether by configuring Develop to output 16-bit RGB using the ROMM RGB profile; however, my understanding of why I might not want to opt automatically for the seemingly greater flexibility of 32-bit RGB and ROMM RGB would be enhanced by a tutorial that clarifies the terms 16- and 32-bit processing; 8-, 16- and 32-bit RGB color format; sRGB and ROMM RGB profiles and illustrates the advantages and disadvantages of 32-bit editing.

I've bought myself a beautiful HP Envy notebook with a 4k display. I wanted a 4k display, because the colour space on such a display comes close to Adobe RGB, and is much better than normal HD displays. Normally only ridiculous powerful and expensive gaming notebooks have such a display, but this is a normal notebook. I just had to import it from the US, since HP Europe doesn't sell them (sigh). I also bought the X-Rite i! Studio to calibrate the display, the printer, and the scanner. I first calibrated the display. The calibration settings want the brightness set to 120 cd/m², and that was far less than what it was set to. So I wondered why. It turns out that if you set the display too bright, you may see details that will disappear if you print a photo. After I did some more research, I found that the sRGB profile specifies a brightness setting of 80 cd/m², and the Adobe RGB profile a setting of 160 cd/m². The setting of 120 cd/m² is exactly in the middle of these settings. I usually use the ROMM RGB profile, and that one requires a setting of 142 cd/m², so I used 142 cd/m² (or close to it) for the calibration. The before and after calibration colours were not very much different, contrary to the situation with a normal HD display. There the differences are dramatic. My first question is, was I correct in setting the brightness to 142 cd/m² for the calibration ? The next point is calibrating my camera. It seems it is possible to make a colour profile of my camera, and use that when developing a raw picture. I could not find how to do that in Affinity Photo, but I know it is possible with Adobe products. Can it be done with Affinity Photo? My last question is about the omission of some modern ICC profiles in the standard set of profiles that is provided with Affinity products. The European Color Initiative has some modern RGB and CMYK profiles on its download page , like the eciRGB_V2 profile, or some CMYK profiles for coated and uncoated paper. I used one of those profiles for a project. Perhaps these profiles should be included as well in the standard set ?

@Chris B Thanks for your reply and taking the time to test this on your system. Automatic conversion is on, but since the profile of the file and my Working-RGB-Profile are both ROMM RGB, there is nothing to convert. Perhaps you may want to try again with the RGB-Profiles set to ROMM RGB? Thanks in advance.

Hi @SeanZ, here's a quick breakdown of the pixel formats and what happens: As you've observed, when you open a RAW file in Affinity Photo it's processed in a working pixel format of 32-bit float, which is unbounded. This prevents values outside the range of 0-1 from being clipped and discarded, and allows for highlight recovery. Colour operations are processed in ROMM RGB (ProPhoto), which helps colour fidelity even if the intended output colour space is sRGB. You are essentially working in the highest quality that is reasonable. When you click Develop, by default, the pixel format is converted to 16-bit integer, which is not unbounded. Any values outside the range of 0-1 will be clipped and rounded, so you should ensure you are happy with the tones before you proceed (e.g. using highlight recovery, changing black point etc). The colour space is also converted to whichever option you have chosen—by default, this is sRGB, but you can change this by clicking the Profiles option on the right hand side and choosing another output profile like ROMM RGB or Adobe RGB. I say by default, because you can change the output format to 32-bit HDR on the develop assistant (the tuxedo/suit icon on the top toolbar). Be very mindful, however, that 32-bit in Affinity Photo is a linear compositing format as opposed to nonlinear. Adjustments will behave differently (typically they will seem more sensitive) and blend modes may produce unexpected results. I would avoid working in 32-bit unless you either want to author HDR/EDR content—this is not the same as HDR merging and tone mapping—or you need the precision for more esoteric genres like deep sky astrophotography. A lot of customers think working in 32-bit is going to offer them the best quality possible. Whilst this is technically true, there are many caveats and I would seriously advise against it unless you have a specific requirement for this format. To answer your questions: Technically, the answer is yes, but it's like I mentioned above: unless you have a very specific requirement to work in 32-bit, any loss in quality will be negligible. 16-bit nonlinear precision is more than enough for 99% of image editing use cases. Here's an example of my workflow: I will often choose a wider colour profile like ROMM RGB, then make my image look as flat as possible in the Develop Persona, usually by removing the tone curve and bringing in the highlights slightly if they are clipping. I'll then develop to 16-bit and do all of my tonal adjustments in the main Photo Persona. I have yet to complain about any loss in quality The functionality is more or less the same, but the Develop Persona has more intuitive sliders. In fact, in demos I will frequently explain to people that if you want to do some simple destructive edits to an image, you can simply go into that persona and use a few sliders rather than have to build up a layer stack. One key difference will be the white balance slider: when developing a RAW file, it has access to the initial white balance metadata and the slider is measured in Kelvin. Once an image is developed, however, this slider then becomes percentage based and takes on an arbitrary scale. Whatever works best for you, I think. My approach, which I explained above, is pretty fool proof, but you can do as little or as much work during the initial development as you feel is appropriate, e.g. you might want to add luminance noise reduction during the development stage, perform defringing, change white balance etc. Just be aware that if you perform certain steps like noise reduction during the initial development, you can't undo them. With noise reduction, I prefer to add a live Denoise layer in the Photo Persona, then mask out the areas I want to keep as detailed as possible. Again, though, it's down to personal choice. Hope that helps!