Search the Community
Showing results for tags 'aces'.
-
Hi, I was testing again Affinity Photo 2.4.2 and tried to output a ACEScg EXR via OCIOv2. Sadly it seems the operation still fails. As far as I remember a proper export never worked for me. I am on MacOS with Affinity Photo 2.4.2. I load an ACEScg EXR that I exported from Nuke (ARRI demo clip frame Helen&John) Helen-John_UHD_acescg.exr The document is properly set to ACEScg and no additional conversion takes place. I use the OCIO v2 config: studio-config-v2.0.0_aces-v1.3_ocio-v2.2.ocio from here (https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases/tag/v2.0.0) The Display Transforms set to OCIO ACES 1.0 - SDR Video for an sRGB Display. The image on the screen should look like Helen-John_UHD_display_sRGB.jpg, which I exported from Nuke. The resulting export from Affinity Photo looks like Helen-John_UHD_acescg_to_sRGB.jpg this. I am not sure what is happening, but I assume another ICC display transform is happening in the image processing pipeline after the OCIO display transform. Plus the colourspace primaries seem to shift as well. Do I do something wrong? I tried several things like enable and disable the ICC profile during export, but I am not able to get the proper result. Does someone has an idea what is going on? Helen-John_UHD_acescg.exr
-
I have an EXR from blender thats saved in ACES with the official 1.2 ACES package from the github . When I import it into AP, point the configuration file to pathTo/OpenColorIO/aces1.2/config.ocio and in the 32-bit preview window my display settings are set to the following. This gives me the correct image in the viewport which matches my blender render. However, when I go to export the image, the colors are not correct and washed out since I assume this is just a "preview" hence the 32-bit preview tab title and not applying the OCIO display transform to the final image. I tried adding a OCIO adjustment layer but couldnt get anything to work. When I did this I changed the display transform under 32 bit preview to ICC. The input colorspace is ACES-ACEScg since thats what it is and was rendered in in blender. In the Destination color space dropdown I tried a variety of options but none of them worked nor matched the OCIO display transform in the 32 bit preview of sRGB/ACES. The only way I could capture what it is supposed to look like is to either upload the "raw" ACES renders from blender or what i did which was to take a screen snip of the desktop with windows Snip & Sketch. Please help me. I am interested in being able to save ACES only - please dont direct me to look at things related to blender filmic
-
I was working on a file with a custom OCIO 1.0 config that Redshift made for Blender. I decided that I wanted to change to a un-modified OCIO 1.0 config for ACES 1.2. So I repointed Affinity Photo to that config and restarted the app. Upon opening my file I got a crash. I expected it to need to have my OCIO adjustments changed but, I don't get an opportunity to fix them. I went back to my old config and could open the file. I tried to delete all the adjustments and set the file to unmanaged in the 32-bit preview and saved a copy. But even that copy crashed Affinity Photo if I tried to use the unmodified OCIO 1.0 config. So I had to recreate my file to use another config. We will need a way to fix this sort of problem without having to start over with a new file. I hope you can use this file to build a little more robustness in how it handles moving between OCIO configs so that we can at least get back into files and correct OCIO settings. Fortunately, this was just a test file for me and nothing important. This is with Affinity Photo 1.9.2.1035 This also happens if you have a file set to use OCIO but open it on another computer that does not yet have OCIO configured in preferences. In both cases we should get a descriptive error message and an opportunity to change the OCIO config rather than a hard crash of the app. Without better error handling users would not have any idea how to fix it or assume the file was corrupt. AirwolfPos_Test.afphoto
- 4 replies
-
- ocio
- opencolorio
-
(and 1 more)
Tagged with:
-
HI, I'd like to better understand how to best implement an ACES workflow in Photo for 3D still EXR renders. My goal is to be able to work in the expanded colorspace that ACES provides for editing and be able to export my images for print (with an AdobeRGB profile) and web (sRGB). I'm currently using Octane as my render engine which at this time will only render to the sRGB primaries in linear EXR format. ACES is planned for the upcoming release however so I'd like clarification on 2 scenarios. If anyone has deeper insight into this I'd really appreciate the feedback. I watched the Affinity Photo OpenColorIO video (https://affinity.serif.com/en-gb/tutorials/photo/desktop/video/329071149), but trying to apply this process with ACES just added more confusion. @jamesritson this would be a great topic for another video! (also thanks for creating all of the tutorial videos, they're well done and very helpful!) Scenario 1: Converting a linear (sRGB) EXR render to ACEScg for editing and then exporting either an sRGB for screen or an AdobeRGB image for print As far as I understand it, there are three components to this process: Setting your color preferences OCIO config file to the ACES config (I'm using the latest 1.0.3) The 32-bit Preview panel Display Transform The OCIO Adjustment layers For the 32-bit Display Transform, what do I need to set it to in this scenario? With ICC it looks exactly as it did in my IPR in Octane. Following along with the video this would seem to be the right approach, but in the video he's using Filimc Blender which I behaves differently from ACES and I'm wondering in this case if this same approach (ICC display) works properly when converting and editing in ACES. With the 32-bit Preview OCIO Display Transform set to sRGB (view transform) and ACES (device transform) it looks darker and more green. (my screen is calibrated to sRGB), though the exposure adjustment behaves completely differently for OCIO / ACES and is much smoother as I would expect than when the DT is set to ICC. I'm assuming that the green tint is due to the fact that I hadn't added an OCIO adjustment layer. When I add an OCIO Adjustment as Source: lin_srgb, Destination: acescg the tone balances out, but the overall image is darker. I'm assuming that this is the look of the ACES transform on a linear sRGB image, but I'm not certain I'm setting this up correctly. For the OCIO Adjustment layers what would be the correct setup? From what I understand I need one OCIO layer to specify the input source type and destination type which I set as lin_srgb and acescg respectively. Then for the output I would create another OCIO layer and set it to the reverse?.. Source: acescg, Destination: lin_srgb? How would I export to AdobeRGB or another space like ROMM in this scenario? Scenario 2: Opening a linear EXR ACEScg render for editing and then exporting either an sRGB for screen or an AdobeRGB image for print I'm just future proofing here and bloating this post, but assuming that Octane updates this year with an ACEScg render option would I just append an 'acescg' siffix (my_render-acescg.exr) to the file and open it in Photo? Do I need to add an import transform OCIO layer to specify that it's ACEScg or do I just create an out transform layer? Finally 2 last questions: I'm assuming that all of my image adjustment edits will be done between the input transform OCIO layer and the output OCIO layer, please correct me if I'm wrong.. If I open a multi-layer EXR with multiple render passes, do I need to create an OCIO Adjustment layer for each pass layer or will one at the top be enough? Thanks for bearing with the 1000 questions here and I greatly appreciate any insight I can get on setting this all up correctly!
-
Dear Serif Team and Affinity Photo users, I'm a VFX Compositor & Matte Painter and I'd like to move from PS to AP. I hope you can help me with some questions regarding the Implementation and proper use of ACES and 32-bit. My background plate is exported from Nuke as an ACES - ACES2065-1 16-bit EXR file. The import into AP (1.6.4.104) works fine - the file get's recognized as an ACES file and I get the same result using OCIO. But there are a few things I can't get my head around yet: How do I pick and paint high color values? Using the exposure slider in the 32-bit Preview I see that there are high values. If I pick and paint them back in, the result is way darker. (Changing the exposure doesn't effect the false picked color) picked in Nuke for comparison I moved from PS because there is a 16Bit limitation and I had to work with ACEScc files (log encoded) and use an ICC profile to check my work. I hoped to get around this using AP. Those threads are dealing with the same issue but the information is contradictory and I can't reproduce the method quoted first. https://forum.affinity.serif.com/index.php?/topic/49815-hdr-raw-pixel-values/ https://forum.affinity.serif.com/index.php?/topic/19787--/ What is the proper workflow of importing and edit JPGs in an ACES setup in AP? Unfortunately there's no way of assigning an IDT during import (as in Nuke) but I can reproduce Nukes behavior with OCIO Adjustment Layers, which seams pretty inconvenient. (Windows Photo Viewer as comparison) Bottom left: Two OCIO nodes in sequence [ACES2056-1 to Utility - Curve - sRGB] followed by [Output - sRGB to ACEScg]. Bottom right: Two OCIO nodes in sequence [ACES2056-1 to Utility - Curve - sRGB] followed by [Utility - sRGB - Texture to ACEScg]. This post deals with the question of the right IDT for JPGs in general. I guess going the Utility - sRGB - Texture way is better, isn't it? My color settings: If you need further information or I haven't made my questions clear enough please don't hesitate to ask. I'm glad about any help or further learning resources! Thanks a lot
- 8 replies
-
- exr
- color picker
-
(and 8 more)
Tagged with:
-
Hi, I noticed a strange behavior with the release version of Affinity 1.7 that I don't recall with the last Beta versions (that I already deleted) and for sure not with the version 1.6.x. I use the Serif RAW converter to convert canon raw photo files to 32-bit linear files. When the prefs are set to 32-Bit sRGB linear, then after the raw conversion I convert the format to ACEScg. When the prefs are set to 32-Bit ACEScg, then I don't need to do anything else after the raw conversion. In both cases I export EXR (half-float files) without the check box "Color profile from name". When I loaded both files in Nuke (from Foundry in an ACES environment with each the right colorspace settings) they were looking (nearly) identical. And this made sense to me. I checked with older files EXR files (that were converted with an older version of Affinity Photo) and the two exports are visually identical. There are very small differences in the colors, this might be rounding errors. The linear sRGB file is actually ever so slightly warmer then the ACEScg file. When I do this now with the new release of Affinity Photo, the ACEScg converted file got much warmer. The two attached images (IMG_7330) were converted with version 1.7 : Prefs 32-Bit sRGB linear, Serif Engine (no tone curve), the lin sRGB was then directly exported as EXR, the ACEScg was converted with Document/Convert Format/ICC Profile to ACEScg and then exported as EXR. Both files were exported with Nuke to JPG (with the same display viewer curve RRT&ODT) The older files (IMG_8454) were converted with an older version of Affinity Photo (April 2017) I can provide the .CR2 files if necessary. Can someone explain why this happens? Best regards Daniel
-
After having used the 32-bit modes almost exclusively now since we had them available I noticed some issues with OCIO configurations and maintaining them. What I'm suggesting is a more global config file. I've attached a YAML example. YAML because it's easy to read, duplicate and modify. It can be easily exchanged when working in groups. Download project config from Shotgun, merge with own config and use it right away. Affinity currently has a config switcher that doesn't switch configs. This way it would work and it would be easy for the user to manage. The ICC part is for Affinity to determine which profile is used for converting OCIO data to ICC data for delivery use to devices and services that don't use OCIO (print shops for example). ocio affinity.yaml
-
It's reasonably simple to switch configs in Affinity but it still involves closing everything and restarting the app. You can't have two documents open that need different configs. It'd be great to do the setup of a few configs once and only require a restart when you change that setup. That way we could have open a few documents that are in difference OCIO colour spaces. I often have to switch between nuke-default and ACES nowadays. Being able to set and save (in Affinity format) what config a document used would be great and only like two or three lines of extra meta data. It would also make it easier to work in larger teams and bring work from multiple sources together. Then having an OCIOconfig node/layer which could be used to transform work from one base config to another would be really sweet. Being able to toggle through configs would also be great for last minute jobs where everybody just assumes you know their workflow and eff-off right after emailing you the logins.
-
Hi Affinity team I have two small feature requests that will make Affinity Photo and Designer fit really good into VFX, movie and TVC production. 1. My primary request is import and export in the Open EXR file format. Some of the key features of Open EXR is: High Dynamic range, up to 32 bit float. Multiple channel sets (layers / passes). Multiple compression types, both lossless and lossy. Open EXR is used all around in VFX, movie and TVC production. It is supported by, and the preferred image file format of many tools in VFX production (nuke, maya, modo, mari, fusion, scratch, daVinci resolve, etc. and even AE, but it's really bad implemented in PS). 2. The second request is support for motion picture and TV color spaces. Being able to handle Rec709, cineon (LOG), P3, Rec2020, ACES, etc. correctly in Affinity Photo and Designer would be a huge plus. I'm not a developer, but I think it could be done through the OpenColorIO color management solution, which is also widely adopted by VFX production tools. A still image editor is not the primary tool in the VFX, movie and TVC world. But it is always there as a secondary tool for doing quick fixes, converting images and vector files, developing raw files, etc. These requests I mention are weak points/not supported at all with most other image editors, and I think if Affinity Photo and Designer get's it right, it could be a huge plus, and with the very reasonable price tag I can't see reasons to not choose Affinity Photo and Designer. Cheers /johs