Re: Welcome to native OCIO/ACES support in After E...

Shebbe · ‎Nov 04, 2022

Thanks for the updated configs. I have a small point about the names. If the idea is to have multiple ACES configs in release all should have a clear naming convention. I know the studio/cg configs are versioned but the ACES version itself is now missing from the folders and thus in the list in the selection. Consider naming these too and if you think it is too confusing to have 2 times a version number I'd remove the package version not the ACES versions, because that is much more important to know the differences. Especially if ACES 2.0 will also sit alongside it when it releases. I'd do it like this:

Shebbe · ‎Nov 03, 2022

Yes please! +1

Shebbe · ‎Nov 03, 2022

It's already been a while since the beta with OCIO got introduced. I'm really happy with it's implementation but it's not perfect yet. There are some serious issues that need to be adressed and some other quality of life improvements needed to make this work smoothly for everyone. Here is my summary of things I hope to see improved or added. It's quite a lot and no fancy pictures so bear with me! 1. OCIO 2.x Display Transformed exports This is probably the most important one to adress. With OCIO v2.x configs the ACES display view transforms are separated from the colorspaces. This design is a good step forward because it removes the need to list all the viewing conditions paired with every display space as it's own unique color space inside the list itself (making the list unnecessarily long) and can be it's own list for the viewer. Problem: What "breaks" here is that whenever we have the desire to send off tonemapped exports for review we can't bake the view in. Thus we can only export scene referred files which is far from ideal because we'd have to take it elsewhere to make the preview file. Solution: Add a switch option to choose a color space from the Displays list in the config instead of the Color Spaces list on export settings. A conversation about this on ACESCentral can be found here where Derek showed me a similar approach for a custom write node he made for Nuke. 2. OCIO based exports and ICC/video profile tagging Problem: In the same thread of the issue above I was talking about ICC profiles. And while I think they should have no place in the workings of OCIO itself, this still may be a desirable choice for exports. If we export a still/video with some view transform we should also be able to tag it accordingly. When it comes to video files the exports are always tagged BT.709. What if we need HDR? This same issue is present in Adobe Color Managed btw just but not for stills which use ICC which can be embedded. Solution: Add a proper way to tag files on the way out. Whether you want to hard link these to the display view transforms for ACES or not is up to you. It would mean you are responsible for maintaining it and the quirky thing about it is that OCIO is a platform that lends itself to adaptability for custom workflows and needs. One could go into the config and remove/change/add color spaces and displays. Those would break then. Also fully custom configs could be added, say TCAMv2. These would not have linked tagging in place. Therefore leaving the tagging to the user may be the better solution? 3. Input Color Space bug with .png files Problem: When a .png file gets any Color Space assigned it becomes too dark. This happens with any OCIO config. Solution: Fix it 🙂 4. Scopes QoL changes Problem: Currently the scopes always read scene data. For display referred workflows this is fine but we don't always want to see our scene referred data. Especially if we are working with very high values the autoscale also doesn't make the waveform very useful. Another issue is that the vectorscope either interprets the data as Rec.709 or Rec.2020. This would be correct if the reading was after the view transform but it reads the scene which should be the chosen working color space. Solution: - Add an option to read display referred. - Make the scene referred readings adapt to the chosen working color space instead of being fixed by the user choice. - Add option to turn off autoscaling for waveform so we can see if there are negative values or values very high above 1.0 even if they are small relative to the comp. So 1. Clamp, 2. Adaptive scale, 3. Show all (or whatever name works) 5. Info Panel QoL changes: Someone had this great suggestion. Like Photoshop we could have two values shown. The default scene values and a second with display referred values reading after the display view. This will be especially useful if we need to nail client colors for sRGB/Rec.709 deliverables. 6. OCIO Roles Problem: OCIO roles can't be utilized currently and aren't exposed to the user to change away from the defaults defined in a config. Solution: Add the option to select the OCIO roles in the management settings and also utilize them within the software. 7. Colorpicking Problem: With the working space typically wider than display space color picking doesn't match the typical sRGB/web values we need to use in certain areas. Solution: Add a dropdown menu to pick different colorspaces as input values to the color picker. By default it should be set to the Color Picking role. 8. File Input Color Space QoL changes: Problem: With OCIO we manually manage all incoming data. OCIO roles and aliases can semi automate this process but for most files we will still have to manually assign the proper one. This process is incredibly cumbersome because we select 1 file -> Interpret footage.. -> Main -> Color -> change color space -> Interpret footage -> Remember interpretation -> select all other similar files -> paste interpretation. Waaay to many steps! Solution A: Add the color space list to the preview area above the project list and make it selectable there even when multiple files are selected. Solution B: Make interpret footage possible for multiple files selected at once. And maybe also reorganize the interpretation panel so the color tab is part of the tab you open instead of the second tab. 9. OCIO effects QoL changes: Problem: Right now we have support for OCIO File Transform and OCIO Color Space Transform. They work as intended but Color Space Transform only functions if OCIO is enabled. Furthermore we don't have OCIO Display right now. This means that we can't set up manual OCIO color management if we'd desire and we'd have to resort back to the fnord OCIO plugin. Solution: - Add OCIO Display as effect or integrate it as second mode inside the Color Space transform like how it's handled in fnord plugin. - Add support for loading built-in or custom configs to the OCIO Color Space Transform and OCIO Display so we can use it in manual management setups. That's all I have at the moment. Quite a lot, but I think some of them can be adressed fairly easy. I hope it's all clear and you can come up with solutions before release so we can get the most out of working in OCIO once it hits!

Shebbe · ‎Oct 30, 2022

With which config is that happening? Did you test with the same config loaded on the fnord OCIO plugin?

Shebbe · ‎Oct 22, 2022

Did you make sure you also set your output to be Rec.709 in the export settings?

Shebbe · ‎Oct 22, 2022

We are anxious to get this into your hands so we can learn more about the features you want us to focus on. This is not meant to replace a dedicated 3D product. We are building a 3D toolbox to enhance your creative options directly within After Effects. By @Christine Goldby It's very hard at this stage to think about features we'd like to see if the entire goal of the new 3D engine is also unclear. I understand that it cannot become a dedicated 3D app like Blender/C4D etc. but what is the general purpose? Are we supposed to use it as final render? If so, to what level? A "realtime" engine similar to Element 3D and other plugins are incredibily taxing if you want proper visuals and don't come anywhere close to raytracing/pathtracing quality. Aliasing is also pretty bad in such engines. And what about shaders/materials? I'd assume at least some form of PBR. And will it be for motion design? For VFX? Both? What kind of other tools can you create with the skill and knowledge of your team? There are just so many directions a 3D engine/toolbox can go that I can't say Adobe, I really need it to do this or that. Becuase I have no idea what I would want to use it for in the first place. It's current state is too basic for that. It would make sense to have a more developed version of this with more tools that can stimulate creative ideas in a direct manner. Otherwise the suggestions from us will potentially be all over the place.

Shebbe · ‎Oct 22, 2022

I think these are great suggestions! Especially the one where you could view both scene and display values at the same time.

Shebbe · ‎Oct 22, 2022

Using the LUT based ACES 1.0.3 config should render out correctly when choosing Output - Rec.709. If you export to ProRes4444 the file automatically becomes tagged as Rec.709 and the result should be identical. I just tested this myself to confirm. You can't do this currently with the OCIOv2 configs as they don't have the RRT in the various display transforms because that is only available in the OCIO Viewer. Adobe still needs to think of a way to adress this workflow issue. The fnord OCIO plugin can do View mode where you can select the rendering intent. You could use this in the meantime...

Shebbe · ‎Oct 21, 2022

Yes ofcourse you can lower the saturation but doing so reduces it for that hue on the entire range if done with simple math like global HueVsSat curves. What you want is a solid way to tonemap the captured dynamic range and compress the gamut in such a way that you can retain as much information as possible without clipping/sticking to the edge of the display as soon as you hit it. Desaturation towards white is the 'obvious' fix and behave similar to shooting film, but not always the most beautiful for what you're trying to communicate. But at least you want a DRT to be robust, works 99% of the time, and also have tools available to the artist to manage such outliers like a gamut compressor. Especially for data that is not even on the spectral locus which most cameras have.

Shebbe · ‎Oct 20, 2022

PS. Sorry, I can't share that clip as it's property of a client hence the crop. If I ever have some test material happy to share. But if you're curious, this is what it looks like through the DaVinciDRT. I'd say a pretty good job as the clipping or clumping against the target display hull doesn't really feel that harsh. And the desaturation towards the core is not physically accurate but a welcome side effect of the type of DRT (or it was engineered) to simulate higher brightness than the brightes color the target display can show.

Shebbe · ‎Oct 20, 2022

Ah you meant working out for users instead of working 🙂 Yea I don't know, we have iPhone HLG footage coming in quite often. We change their colorspace to Rec.709 to match your timeline so the operation nulls. Wish they'd add a disable management option though similar to PerserveRGB in AE otherwise it will still treat it as Rec.709 and convert again if you place it in an HDR timeline instead. Totally broken. But anyway, after the disabling we use a LUT of the DaVinciDRT HLG to Rec.709 Gamma 2.4 so we can include tonemapping. We can grade under the LUT for further adjustments. Actually pretty much the same as we handle any other log encoded material when managing/grading in Premiere We'll likely switch to ACES if OCIO will make it to Premiere Pro and ACES 2.0 releases and stay away from what Adobe is doing at the moment. The current conversions + tonemap impelmentations don't really clip anything as Premiere operates in 32bit float but having to do half of what is supposed to be the task of a solid display rendering transform in grading is very clunky and counterintuitive especially with the crude tools we have available like Lumetri Color where most of the controls are designed to operate only on 0-1 range.

Shebbe · ‎Oct 20, 2022

HeyJoanna, - both Beta OCIO configs are broken - can't get proper colors displayed in viewer no matter whch sRGB transform I use in the viewer - no problems with built in 1.0.3 config and custom 1.2 config The configs aren't really broken, it's just the way OCIOv2 works. If we want to be able to export display views the color spaces need to be added into the config as it's own full defined color space. If you run your own config you can add this as it's own entry but all OCIOv2 configs will work like this unless ACES decides to change their configurations. Adobe could also decide to alter the config but since they're still beta it's not really relevant at the moment. The older OCIOv1 config is LUT with the RRT already in the transforms. Now they live separate. What Adobe should also do is add an OCIO Display effect similar to the fnord plugin and Nuke so you can have it on an adjustment layer. - is there a way to still use display color profile? Right now it seems the best we can get is display the viewer in sRGB, but I have a calibrated WsRGB monitor, so sRGB values come out too saturated. With the default CM in AE, after everything was configured we could check in the View menu "Use display color management" which added one last operation in the chain of pushing the sRGB viewer colors through the system monitor color profile - with the new OCIO color management that option in the View menu is grayed out This is not how OCIO color management is intended to work. Your display should be calibrated to a specific display standard and software that run OCIO should do a clean feed to that display. If your monitor is much wider than sRGB it's very likely you have an sRGB profile setting in it's menus. Calibrate on that or create a separate calibrated profile for sRGB if it can be hardware calibrated. - the old CM could read embedded color profiles in source footage, not all, but jpgs came in as sRGB, rec709 footage was recognized as rec709 etc. The new OCIO CM just gives up and applies the scene color profile to everything, could we get the same behaviour as the old one? If it thinks it's an sRGB source, apply a proper OCIO import profile. OCIO works differently. Defaults/roles for certain filetypes can be defined by the user and implementer can also expose seettings to change them. Adobe should implement this imo. (example from Nuke) On top of that you can also configure filename aliases. In 3D this is common to do. Think 'MyTexture_albedo.jpg' would be recognized as "Albedo" and get sRGB - Texture assigned if it was written to do that. PS. I specificaly wrote import profile not input profile because the proper sRGB profile in this place would actually be the Output - Output sRGB profile from the OCIO What I said above also explains why you wouldn't want sRGB files by default to be Output - sRGB per se. But still, most studios adjust the configs to suit their workflows and needs. Nothing is stopping you from changing your configuration to best fit your work. Very easy to create an extra entry to the list instead of custom too. Just add it to Adobe After Effects (Beta)\Support Files\OpenColorIO-Configs\ or use the environment variables method.

Shebbe · ‎Oct 20, 2022

Hey Niel, What do you mean exactly with "how the transforms are working"? They simply convert from said camera or display space to the sequence's timeline color space. The only difference it could have versus conversions in other software is the chromatic adaptation model used to convert the white point but I think all the color spaces they have at the moment are D65 so it never converts. Furthermore there is no tonemapping or rendering intent in the transforms but you know they added a very rudimentary tonemap option checkbox in the sequence settings which doesn't solve at all the goal of mapping camera scene referred to display. To me it sounds like they just wanted a quick band aid to 'fix' Rec.2100 HLG material from iPhones for SDR video distribution... This is what SGamut3.cine bright blue light capture looks like with tone map enabled. Not very pretty 🙂 At it's current state there is no point in using it. Even the most incorrect and inconvenient way of just creating your own curve and adding in saturation will probably yield better results.

Shebbe · ‎Oct 19, 2022

Thanks Christine! OCIO Env Vars: Yes gotcha, it wasn't clear to me that AE was already picking up the path set in the env vars. Would it be useful to have some kind of visual clue as to that it's reading the env var instead of a manual path? Output/Export: It looks like the Display color spaces on the beta configs don't get the RRT applied. The issue I described is not seen with the OCIOv1 config because the displays are only the combined RRT+ODT named Output - sRGB. I'm not sure if the config can be altered or how other software do this but we need to have an option to chose the full targets including the RRT ACES 1.0 - SDR Video. OCIOv1: Is there a reason why ACES 1.0.3 is used and not the latest 1.2? https://github.com/colour-science/OpenColorIO-Configs/tree/feature/aces-1.2-config

Shebbe · ‎Oct 18, 2022

Oh and one more note btw, dunno when the AE update was pushed but the Release Candidate 1 is currently the latest ACES OCIOv2 configs. Canon and ARRI were added amongst other updates.

Shebbe · ‎Oct 18, 2022

You folks deserve a million kisses for this one! It's finally coming and I've never been a excited as now for an Adobe software update. This will mean so much for the industry. Here's my initial feedback: Upon some quick tests I already ran into an issue with exporting with ODT applied. What would be the way to bake in SDR Rec.709/sRGB into ProRes? Both the gamma is off and values above 1.0 are clipping. (output was set to sRGB display, interpret footage + viewer set to Raw) Left exr through sRGB ODT, right ProRes with baked ODT Another thing that immediately stood out to me was that we aren't allowed to use the OCIO Color Space Transform without setting global management to it. What if we wan't to manually manage a project in some cases? I think it could be nice to still read from the project settings which config to use but have Adobe managed enabled instead. Or/and give the option to browse to a config on the plugin itself. May sound weird after all the craving for OCIO but for some setups it can be nice to only have some tools to convert between certain spaces via a config and not use the display/aces output side of things. And what about OCIO through environment variables? Can imagine many studios wanting to manage configs through that on their systems. Design: Now that we have a pretty full page on the Color tab the other 4 tab's settings look quite lonely.... Maybe group them up a bit? They could all fit within one tab now the window is this big by default. Workflow: Will be be able to define color spaces in the color picker so we can choose say Display sRGB colors instead of values that become the workingspace's color values. I think globally via color picking role makes sense but could be nice to have a setting for it in the colorpicking window so it can convert from there too? Like that for example. But again, great progress has been made already! Also really happy with other improvements lately with v23.0 release and now in current beta ARRIRAW on the GPU finally with proper processing for Anamorphic :D. Recently finished a project with that were it would have been incredibly helpful to have already but we managed in the end. Look forward to more features and improvements. OCIO Premiere next?...

Shebbe · ‎Oct 18, 2022

You seem to be working in 16bit. AE is only floating point if set to 32bit which ACES OCIO needs to process values above 1.0 linear. Maybe that helps.

Shebbe · ‎Sep 29, 2022

Late reply! But can confirm it works as expected now 🙂 thanks!

Shebbe · ‎Sep 05, 2022

Thanks Neil, I do understand the proces behind "glueing" the preview chunks together into a new ProRes or whatever chosen codec preview file. I just think that you can easily do the same but convert afterwards to the requested format. This would tremendously reduce export times on larger timelines or heavier footage. The problem (for us) is that you don't want the timeline render files to be as crappy as proxies/h264 for performance sake. You want a smooth timeline but equivalent to at least ProRes HQ. So when it's finally time to make a final export for heavier projects it's faster to go to the preview format and throw it in Media Encoder instead of waiting on a rerender of the entire thing. We can keep doing the AME workaround ofcourse but it's tedious and would be a big QoL improvement if implemented into "Use Previews".

Shebbe · ‎Sep 04, 2022

It's a lot better to apply grain in log space. While it's true that you can compress and expand values above 1.0 non destructively with HDR Compander the image state in between isn't really useful especially if you have high values. To preserve specular of 16.0 reduces the entire image immensley if the rest of the image sits around 1.0 and below on average. So grain values get applied on incredibily low values but get blown up afterwards by the reverse process making the image look worse and introduce negative values. Using a Color Profile Converter to go from an arbitrary known linear color space to the same space in log and back is much more robust. For example ARRI LogC/Linear. It doesn't matter what the source image is because we only care about temporarily converting the transfer function from lin to log and back. That said, it would be nice to have an updated 32bit Add Grain. In example below I reduce up to 16. The highlight on the big garlic midleft was around 13. HDR Compander produces redicoulus contrasted grain with negative values. Lin to Log behaves as expected. HDR Compander Lin to Log

Shebbe · ‎Sep 04, 2022

Nice addition. I do wonder though, why a new keyboard shortcut? Why not make just [J] and [K] general purpose. No selection means jumping to all next and previous keyframes. Layer selection jumps to layer's keyframes and markers. Property jumps to it's keyframes only. I personally don't see the point of having an extra modifier for that specifically and an extra entry in the keyboard shortcut list. I can change SHIFT+K to just K in the shortcuts and it literally fulfills my above statement so why not remove the other one. Alternatively a user could swap them around I guess because it's much more intuitive to use a single key for what you want to do most commonly which is likely jumping between stuff from the selected layer/property rather than everything.

Shebbe · ‎Sep 01, 2022

Thanks for this! There is a bug/oversight I found. When selecting multiple layers to pickwhip or dropdownmenu select which they layer they should track matte to, only the one from your selected position gets applied. This behavior is not seen with layer parenting. Please have it work the same.

Shebbe · ‎Sep 01, 2022

Thanks for thinking about these improvements. We have ours set to ProRes 4444 on our template. Our machines are plenty capable of handling it and it makes for fast exports to high quality format. What I don't get however is why we can't use "Use Previews" for rendering to other formats! If we can get ProRes4444 rendered timelines exported to H.264 (conversion) that's miles faster than having to rerender the entire timeline. On big timelines we tend to export to ProRes4444 and convert with Media Encoder afterwards because it takes 20seconds total instead of say 8 minutes. If I'm not mistaken this even used to be the case in earlier implementations but got removed afterwards?

Shebbe · ‎Aug 10, 2022

There are many wrongs to the otherwise good intentions of this. I share a bit of the frustration @R Neil Haugen has on it. The current direction to me feels like a band-aid fix to a much more complex subject. I can already see the youtube videos arise titled: "I Fixed My Footage With This Simple Click!" Is that the market Adobe is really catering to? Premiere needs to step up when it comes to managing color, that's for sure. But it needs to be done in a robust and most importantly, open system that allows full control over the pipeline by the user, accompanied by proper terminology. Preferably a framework that will allow potential other colormanage system to be added in the future. So no funny auto conversions and questionable tickboxes. How do I think Premiere should move forward? 1. Remove all forms of auto conversions from the entire program (by default). That includes you sRGB! I mean look at this. We don't have control over it. This is a 5x2 grid of identical color squares with same filetype vertically. The top row has no profile embedded and sRGB embedded bottom row. Only .jpg and .png get detected and auto converted whilst AE detects .psd .ai and I think .eps too. 2. Unlock all colorspace options for any filetype and even AE dynamic links. I get it. You want to make it as simple as possibe for endusers but stacking assumptions on assumptions on locked innerworkings of software only makes things more complicated even for the 'noob' to manage if things don't work as intended. By giving us acess to the full list for any file we can at least ourselves decide what gets converted and what not. By default this should all be set to none in my opinion. We can leave the automatic ones for when the proper full colormanagement system is in place to globally switch them for known media. It could look something like this: 3. Add all 'popular' spaces including working spaces. If we want to get into providing true options to manage colors we need all the options and not just a limited set of what Adobe might think the users need. This means all camera colorspaces and transferfunctions but also spaces like DaVinci Wide Gamut/Intermediate, ACES 2065-1, ACEScc, ACEScct, ACEScg, Adobe RGB, ProPhotoRGB, Display P3. 3. Dedicate an extra page in the project settings to Color Management. Time to move that small color management box on the bottom of general project settings to it's deserved dedicated tab. Here everything should be available. This is what I hope to see at some point. - Color Managent System dropdown menu. 1 - None (greying out or hiding the other settings) 2 - Adobe (Adobe DRT, Adobe Tone Map whatever name works) - Use auto color management for known media checkbox (switching all to 'from File' like it does now by default) - Use Tone Mapping (I don't see the point of having this per sequence so should live here. If neccesary a 'Bypass Tonemapping' checkbox sequence settings instead would make more sense but no one that I know of would need HDR->SDR conversion without it) - HDR Graphics White settings 3 - OCIO With option to use the 'Environment Variable', 'Same as Project' or 'Custom' config file path. Same as Project would require the folder to be named OCIO with the config inside and sit right next to the .pproj file. This would be a great option to include configs into projects for interchange and archive! An OCIO config should substitute the list of color spaces on the media with what the config holds. The sequence color space options should also reflect the configs Display/Views colorspaces. There's a lot more you could do with OCIO but I'll leave that for another discussion once it's relevant. 4 - future implementations....ACES 2.0, IPP2...etc.) Genral settings - 3D Lut Interpolation math 4. A proper full Adobe DRT Ultimately the current Tone Map implementation should be replaced with a DRT. From what I can tell in my short testing is that the current tone map solution is very rudimentary and feels like it's born soley out of necessity to do something about files that contain true HDR encodings like Rec.2100 like the iPhone of which people expect it to 'look normal' when they import it. Similar to the 'highlight burn fix' sliders you used to have in 3d renderers. For Sony material it's not effective enough to handle a medium bright blue display (Left: DaVinciDRT, Right: Adobe Tone Map) Sorry for lack of better example at the moment. This is not enough to serve as robust color managing pipeline which is a shame for the potential Premiere has going this direction. If we can get a pleasing true display rendering transform including the abilty to have an actual Working Color Space before the Output Color Space we can actually get work done. For example copying grades from REDWideGamut/Log3G10 to Sony SLog3/SGamut3.cine would perceptually look similar aside from sensor differences because the desicions were working color space based. The DRT should also have it's ways of dealing with bright saturated colors in whatever way Adobe sees fit. Most DRTs apply a certain amount of dechroma towards the highlights which we are familiar to with film and is also the easiest way to perceive colors as relatively more bright within the SDR domain. This may sound like a huge overhaul but to me it's the only way to truly become professional when it comes to managing color. The simple users can still enable "auto everything" if they want and professionals have the tools to adapt the sotware to their workflows. 5. More ideas... Premiere Pro is quite robust when it comes to playback and it natively operates in 32bit float if I'm not mistaken (or until such effects are applied). Having a clear proper manage system in place opens up doors for more advanced compositing tasks without having to resort to After Effects. Add Color Space Transform effect. This would provide the same list as the media color space list with the added option to linearize in or output just like the Color Profile Converter in AE. With this you could for example use blurs and glows or even exposure in true linear math for much more realistic results! It would also make working with a manual setup much nicer. You could even add the option to convert to display space with Adobe DRT/ToneMap. You could achive similar things with Adobes system this way as you would with OCIO. Add native OCIO effect We have a free OCIO plugin and BorisFX Sapphire offers one but they're slow. Perhaps if Adobe engineers get in on it they can make it run much faster with Mercury Engine. And native support is always better! In the end After Effects should also start following suit. It already has an 'okay' system in place but this icc profile based management where even your OS and monitor profiles are listed is just a disaster if you ask me. It also has Arri and Sony profiles but RED's profiles or any others were never added. There could be so much cleanup. Ideally it's fully in-line with how Premiere works for much better integration. For new users this is also a lot simpler to learn just one. I really hope this post will provide some solid ideas and help steer Premiere Pro in a direction that benefits both beginners and professionals in the industry. Now is the time to change and now is the time to do it right!

Shebbe · ‎Mar 18, 2022

Can we get rid of the auto conversion for known log types? I'm pretty sure nobody asked for this... I can't create proxies of my footage now because the resulting image doesn't match source. At the same time it's not even a display rendering transform just a straight conversion wihtout tonemapping so attrocious looking in SDR (clips too). What's the point? If you think it's worth having at least give an option to disable it or better yet make it an option to enable it!

Shebbe · ‎Mar 01, 2022

Thanks for this update! This is miles better than initial plans and the old way. Nice job. I don't know how I feel about the forced all caps eventhough I personally always do this for my custom layouts but maybe because that separated them from the defaults which you can't see anymore now. It reads better in general but maybe there are users that would prefer the inclusion of small caps.

Shebbe · ‎Jan 12, 2022

Sure thanks, but why a workaround when the actual issue can be fixed. The new Gaussian Blur is tagged as 32bit compliant when it's not.

Shebbe · ‎Jan 10, 2022

Hiding as an added option to me makes more sense than hiding it in the first place but I do like the idea of customizability. If space is really a concern why not implement a few toolbar options under a cog icon all the way left of everything. 1. Simple // compressed icons and most unused buttons away 2. Advanced // all buttons as expanded as possible (could even separate out the color channels e.g.) 3. Custom (Premiere Style, but keep current size ofcourse) Just thinking out loud here.

Shebbe · ‎Jan 10, 2022

And to be clear it doesn't just concern ACES it's the new Gaus Blur with GPU support that does this in 32b. The legacy gaus blur does work. Would also love to see this fixed! It's one of the most common needed blurs in compositing!

Shebbe · ‎Jan 10, 2022

I appericiate the efforts to make the Composition panel UI more streamlined, but needing extra clicks to change settings when there is plenty of space left is terrible design if you ask me. I don't see any reason to hide the value behind a dropdown menu!

Shebbe

Shebbe

Activity

Re: Welcome to native OCIO/ACES support in After E...

Re: OCIO - ACES - Add scroll bars to the list and ...

OCIO My Feedback On Current Implementation

Re: Welcome to native OCIO/ACES support in After E...

Re: The AE Beta blog shows OpenColoio being implem...

Re: Welcome to 3D Model Import in After Effects!

Re: OCIO - ACES - Info Panel should have option to...

Re: The AE Beta blog shows OpenColoio being implem...

Re: Canon Panny Sony log users: how are the CM tra...

Re: Canon Panny Sony log users: how are the CM tra...

Re: Canon Panny Sony log users: how are the CM tra...

Re: Welcome to native OCIO/ACES support in After E...

Re: Canon Panny Sony log users: how are the CM tra...

Re: Welcome to native OCIO/ACES support in After E...

Re: Welcome to native OCIO/ACES support in After E...

Re: Welcome to native OCIO/ACES support in After E...

Re: Welcome to native OCIO/ACES support in After E...

Re: Feature Focus: Selectable Track Matte Layers H...

Re: DISCUSS: Use ProRes as the default codec for s...

Re: Grain and Gaussiam Blut 32 bit

Re: Feature Focus: New Shift+J and Shift+K Keyboar...

Re: Feature Focus: Selectable Track Matte Layers H...

Re: DISCUSS: Use ProRes as the default codec for s...

Re: DISCUSS: Tone Mapping in Premiere Pro Beta

Re: Adobe Media Encoder v 22.2 is now available!

Re: DISCUSS: Workspace switcher improvements in th...

Re: Grain and Gaussiam Blut 32 bit

Re: Updated Exposure control in viewer panels

Re: Grain and Gaussiam Blut 32 bit

Re: Updated Exposure control in viewer panels