You can disable project color management and then create the proxies. They should match your source media and remain log. Connect them and then apply the color management again. ... View more

Hey @cody_cuellar , Glad it was useful!   After making my post with the suggested design I also thought it would be even better to make all sliders show their gradients already, much like Houdini's and many other pickers out there. It removes the need for the variable vertical slider too.   Regarding color appearance inside the color picker I always found it really odd that Adobe force manages this. It's true that you see a direct relation from picking color to resulting display color but this isn't always desired. I find it more problematic seeing a heavily skewed and unintuitive sat/brightness gradients over non managed appearance. Especially when working space is log where the numbers start to mean something totally different and the full 0-1 range is actually really large.   Mechanisms like the choice of color picking space are more efficient than always showing the converted display space color for the complete 0-1(or higher) rgb range of the working space. In Houdini's implementation they also give you the choice how to view the colors in the picker. Such mechanism could theoretically be deployed for both OCIO and ICC based workflows correct? And the view options would allow artists to apply their own preference how the picker shows the colors.   Hoping to see such functionality in an improved version of the new picker. ... View more

Thanks for this update.   1. The explanation is a bit confusing. - Why is it called HDR UI Limit in the picker window? What does the UI have to do with picking a color? - Why is it referred as "HDR Nit" in the post here? The nit limit slider seems to be a multiplier allowing for up to 2^4 higher than 1.0 values. Stating a 0-4 nit range is not accurate as we are seemingly talking about exposure stops normalized multiplication math.   2. The behavior is also a little bit weird because it's default value is set to 1.0 but is actually 0.0 before doing anything. If you touch the slider but keep it at 1.0 then the picker field switches to the first 2x multiplication range. Usability wise this is also a bit messy because if you altered the slider it becomes impossible to return the view to a max of 1.0 so you'd need to pick a color that is between 0-1, hit OK, open the picker again and then it's normalized to that range again.   - Changing the slider to 0-4 range rather than 1-4 with 'hidden' 0 as default is a sensible fix. - Perhaps useful to add a modifier key to limit the range to 0-1 while dragging could work?   3. The RGB sliders already have a range of 0-16 regardless of the limit slider and retroactively increase the limit slider as necessary. It would be more useful if the limit dictates the max ranges for the RGB sliders themselves. ie. Limit = 0 == RGB min/max 0-1. This would be much more artist friendly.   4. It would be nice if HSB boxes were also sliders so they could be dragged as well instead of only selecting them and then using the vertical box which is slow if you want to tweak more than 1 of them.   5. The new UI does not allow for RGB to be selected for the vertical slider. Would be nice if that was still the case.   6. It looks like OCIO documents have a different color picker that is still partially 8bit int. It's equivalent "HDR UI Limit" slider with more sensible definition also goes all the way to +/-20 stops which is perhaps overkill as 10stops is already 1024.0 which for scene-linear context is already way too extreme. This picker also seems a bit buggy, if you choose "white" then bump up the Intensity slider to say 4 stops and hit OK you have the correct value of 16.0 but if you open the picker again something else is shown. For some reason it converts the color to a darker base value with a higher multiplication but this isn't accurate. The result is 15.94. The most logical would be to depricate and replace this entire picker with the new one I guess...   7.. Hope to see more improvements to the color picker. Especially for OCIO based workflows the ability to color pick in a color space different from the working space is very important.   Houdini example:     Mockup example addressing all above:             ... View more

Interesting update. After some quick testing...   1. The search seems to not be performed live, meaning changing some data doesn't auto update the search results (ie. change label color of a clip so it should pass the filter)   2. It looks like default assigned labels (from media import) are not passing the filter, only when assigned manually.   3. Not sure if "overview" vs "view all" is an efficient way to set it up. I don't see the point of only 3 results per category as a default because searching isn't necissarily intended to find only a single file. A user would always need to switch to the full view after the querry which can be annoying. Why not remove the 'full view' and show all results in the category mode with categories being foldable or something?   4. The fact that you can click an existing filter to change it's params is a neat touch. It could be useful to be able to change the search component there as well for faster adjustments.   Example idea:   5. Needing to click the filter button -> popup window opens -> + new filter -> define params. Feels slightly cumbersome. Perhaps a + button next to the active filters works better and keeps mouse action close to the relevant area if the search panel is wide. It's popup should only contain a single row intended for the creation of that string only. I don't really see the necessity of a full filter 'manage' window as currently implemented because adding and removing could be done via clicking the tags themselves and be a faster approach.   Example idea (should probably only have an "add" button and clicking outside the popup just cancels it):   6. I initially thought that the filters would be saveable. I can see a use for that, saving a set of filters as preset. (saved along with project instead of program wide so it's project specific and travels accross users/systems)   7. This expanded search functionality is going to be useful for search bins too which is now still fairly limited.   side note: upon testing the labels thingy, I realized that changing label colors for multiple files from the project panel is stored as separate steps in history despite stating "Change Project Item(s)...." Not sure if this is a bug or beta specific but it should be addressed and match behavior with clips in a sequence, being a single consolidated operation.       ... View more

https://community.adobe.com/t5/premiere-pro-beta-discussions/now-in-beta-introducing-live-waveform-editing-feedback-in-premiere-pro/td-p/15280709 ... View more

@Chetan Nanda , @Alexis Van Hurkman I'd like to comment again on this topic. While I hope there will be at least a way to change tone mapping method in batch for multiple clips, even more ideal would be that this is also something that can be modified for the whole sequence at once.  You have to understand, since I'm a colorist I'm perfectly capable of understanding what is going on, but having to explain this to 'more basic editors' and making them responsible for keeping track of this next to the already 'complex' task of tagging the media properly is imo already too much. This is bound to go wrong especially since barely anything can be set project level wide.   I hope that you'll consider moving sequence management to project management whilst keeping the option for the user to deviate if necessary per sequence and that this project wide management also includes tone mapping method choice for scene to display referred conversions regardless of the working space. Realistically speaking, most users will only need 1 kind of color management and 1 target display for the entire project anyway. In earlier feedback I gave an example what that could look like.   It means a media manager can set up the entire project once, and then the editor shouldn't have to bother with anything color management related unless new media comes in that only needs to be tagged with the correct input space.   This is how Resolve handles it too and is much more efficient than always dealing with unique management per sequence which can easily go wrong if not paying attention. And if the user does alter it's sequence management against the project this warning is what you see on project level management.   Some food for thought. ... View more

I agree that there could be more clever ways to set it up. But from the Lumetri color managed perspective the order actually makes sense it's just that the overal layout is really long and perhaps too complicated in the way it's designed imo. But the sections are in order of 'large to small' or 'most global to most local' if you will. Preferences -> entire Premiere Pro (mercury settings etc) Project -> affects project only (using colorspace aware fx and LUT interpolation settings) Source Clip -> manages the media interpretation for the entire project (tagging with proper input space for sake of conversions etc) Sequence -> Determines the kind of color managed workflow you want to use and only applies to that sequence. Sequence Clip -> Uniquely applies settings to only that instance of the source clip in only that sequence.   In my earlier feedback I advocated for an option to make Sequence project management global for the project unless deviated on purpose on a single sequence. This could heavily reduce the complexity in the way project color management is set up. Most people will not have multiple deliverables for different target displays inside a single project anyway. The same is the case for what kind of tone mapping is used per clip when non-wide gamut color management is chosen. Right now it needs to be defined per sequence clip which is not effective by any strech. But this is said to be worked on. ... View more

If you're talking about exposure in using Direc Rec.709 color management there already is in the Sequence Clip section at the bottom of Lumetri color settings. It's not 'log style' offset but gain in linear light so shadows will be more 'sticky' if exposing up but exposing down typically is better that way.   If you meant through Lumetri, you cannot use the exposure slider in Lumetri in non-managed or Direct Rec.709 management and get the same quality/result. The best approach in manual management is to use Brightness & Contrast effect before your conversion LUT because brightness slider there is also offest ('log exposure').   There is no simple operator to do the same for white balance in log unfortunately.   For colormanaged context they could easily add Lumetri's existing balance and tint sliders to the Sequence Clip section as well with the same math also to be applied in linear. This would greatly assist in accurately balancing out log footage in a color workflow that outside of those aspects is somewhat more simplified. ... View more

Maybe an obvious question but did you make sure your sequence track targets were set correctly? i.e. disabling all source/target patching, or making sure the audio source is enabled. ... View more

Hey @Chetan Nanda , Thanks for the suggestion. Working in wide gamut would for us actually be the ideal but sadly this is unusable to anyone needing to mix display and scene-referred data in the same sequence (which is what you do 99.99% of the time). The lack of inverse display transforms causes display referred data to not be presented in the intended manner. I flagged that particular problem, amongst many others regarding 'wide gamut' workflows, several times in the main thread on color management from the beta.   I hope we can see solutions to both problems soon and until then we will not utilize Premiere's CM. ... View more

I believe Baselight is also layer-based, and is considered an even "higher" grading app than Resolve by many. So layers/nodes/whatever ...   Baselight is indeed layer-based but has the flexibility of referencing or even mixing with other layers in the stack. So pulling a key can for example be done on the source while it's operation is a couple layers further down. (Baselight works top to bottom). This mechanism makes layers more than flexible enough to do proper grading. Without it layes would indeed be completely inferior to node based approaches but Premiere could make their layers work in a similar way if properly implemented. ... View more

Sorry no, this sounds like a different issue. I actually have the same issue with Photoshop even if I choose "open with" on Windows and select Photoshop non-beta it opens the beta instead. Too lazy to make a new post about it but that's probably the best thing to do in your case. ... View more

Hello devs,   Are there any plans for improving the zoom? It's still unusable via the zoom tool because it is not smooth. The biggest problem is that the axis of zoom in/out detection feels to be sort of at a 45 degree angle instead of horizontal or vertical. You can see in my video example the redicolous difference in stability between AE zoom and Mocha plugin zoom. I would expect the quality to be on par. ... View more

Hey there,   I believe what you may be experiencing is video and full levels mismatches. I forgot the exact details on where which goes wrong but Resolve definitely has issues. Inside Resolve you can actually correct any mismatches by going into the clip attributes and setting it to Video or Full instead of Auto. Adobe will only detect from file and scale accordingly, the user does not have any control over interpretation. When you write APR444 from Adobe I believe it always writes Video levels eventhough the expected formatting for writing RGB instead of YUV is full levels.   Anyways, try a manual export out of Mac Resolve and Windows Resolve with data levels set to Full and another to Video and see what happens in both Premier and Resole on both Mac and Win to see where it goes wrong. ... View more

Love these ideas. ... View more

I don't think it's a good idea to just copy other software and I don't think Premiere needs a node based workflow. But I do agree that a good move forward would be to step away from Lumetri's forced operation order and here's the whole set of controls in a single effect style. Many basic math operators aren't even available in Lumetri and some of it's controls actually change in math depending on your colormanagement settings.   A new workspace/UI where you can have some form of layer based color grading with advanced masking and tracking that all still lives inside a single effect rather than real layers in your timeline could be a possiblity. ... View more

Hey Fergus,   Thanks for chiming in. I have to say, normally all our projects are graded outside of Premiere for plenty reasons but coincidentally, last Friday we actually had a mega quick turnaround project to deal with where the typical roundtrip session would take up way too much time. (perhaps not if Premiere ever gets robust conform tools? :)) But anyway, the decision was made to do basic grading in Premiere. It was a mix of DJI / Sony log and 709 phone footage. I used the Direct 709 workflow already present in 25.1 which worked well enough for the most part since exposure sliders are available as a pre DRT trim. Then used lumetri for basic contrast leveling and a bit of a lut on top.   It's exactly projects like this that would be sweet if you can work in ACEScct because that allows you to do all your effects still before display conversion. Especially addressing white balance issues is near impossible to fix accurately on display referred image states. We had a lot of unbalanced shots for the project as it was reality/quick shooting.   Will look forward to continued efforts in improving managment and grading tools. I would love to be able to confidently say that some projects can be mastered within Premiere because if the math is right, there is no difference in quality really. Being able to stay in Premiere for some projects can save much time. ... View more

I think this is really an issue that Adobe should address.   Due to other silly reasons we are forced to edit 9x16 videos in a 16x9 equivalent because otherwise we don't have a proper clean feed to external monitor for creative/client sessions. When we prep for final online and export we swap back to the real 1080x1920 resolution to make sure things are absolute, which for the most part works okay but slight shifts are still observed here and there.   There is something not properly structured in the way Premiere's coördinate system works. If you change a composition's resolution in After Effects you do not suffer from these shifts at all.   Additionally Premiere could really use much needed advanced control over object behavior like persistent dynamic aligning of a clip to x% or x-px top-left or bottom or other smart alignments of the canvas. As a result when changing the sequence resolution these elements would stick to their relative defined positions. This would greatly reduce manual labor and the need for pre-made designs in multiple ratios. ... View more

Hey @kazuyaf88705976 , Perhaps because you're a new user but we don't see any images in the post. Could you try sharing them again?   Furthermore, did you bring the prores file back into Premiere Pro to compare? Or were you using an external video player. Also to help the developers reading this thread better understand the issue could you share your system info and Premiere Pro version?   Is the problem only present when exporting to ProRes 4444? Or is it in ProRes 422 flavors as well. What about other formats like H.264/5.   Lastly, what happens if you grab a still frame of a Canon MXF clip, put it back in the timeline and export that to ProRes in both Premiere and Resolve. Does that present the same data? This could help track down where the issue happens further. ... View more

Hey Alexis,   I appreciate you explaining the move behind it and the plans of continuing development around this topic. But I can't help but be concerned about it. Many times features are released and then left as is. Even if improvements are made, depending on the differences between the 'fixed mechanism' and the legacy 'broken state' present high chances of forcing backwards compatiblity to such states for sake of peoples projects not breaking.   It would've been more efficient to keep things that aren't fully finished out of the way until then. I wouldn't have minded at all if the improved colormanagement features would've been released without 'wide gamut tone mapped' ACEScct working space yet. ... View more

Hey Adobe,   So after radio silence followed up by the release of 25.2  almost none of the issues I repeatedly mentioned have been adressed...   Is this your solution to the obvious problem? If you need to add a client logo it needs to be spot on accurate not "close enough". The only workaround is to nest the scene referred data but with more complex edits this is impossible and just not desirable overall to always deal with nested edits as it f*cks your timeline versioning if the actual edits aren't existing in the output timeline.   DRT inverses are not something new, this could've been on the radar before even starting the implementation of this. If the existing DRTs aren't written well enough that an inverse is possible an alternative DRT should've been made. If that's not the goal then why still add this?   Nobody is going to benefit from this until it's properly addressed. ... View more

A welcome feature to those that need it.   I don't think I've ever had to hunt folders or remember the location. It's already pretty clear in several places like the window bar or on the home screen mouse-over tooltip. 🙂     ... View more

The ideal setup would be that media/diskcache has it's own drive so it never has to interfere with read or write speeds of the disk where data is read and written to.    It is also best to have a very fast disk for cache. What kind of SSD are you talking about. SATA or NVMe? And how is it connecting to the Macbook?   If you have plenty of internal storage it would be best to reserve a bit of that for cache because that's definitely fast. I would split the drive in two partitions that have their own disk size so you always know how much you have for normal data on your machine and prevent filling up the entire drive.   Depending on the kind of media you work with I'd say about 300GB for cache is enough so that could be set as limit inside AE prefs. But how much you want to allocate may depend on how much you can spare on your macbook. ... View more

Sounds great.   Regarding the range issues, I'll just sneak in this old feature request I once posted that Premiere could highly benefit from. With the upcoming color management finally opening up and maturing a bit, bringing data range management to users for project media and exports is also an aspect that could recieve much needed love. ... View more

I also dislike the " Copy" suffix on duplication but in our workflow we also rarely deal with it. There are two 'workarounds' I know of that you can use.   You can do a copy into a paste command which will duplicate your sequence without any name change at all. Just requires 2 shortcuts instead of 1...   What we do for editing however is never have any old sequence version at all present in the offline/online edit folders. We always move them immedeatly to an __OLD folder. You can CTLR/CMD drag a sequence to some other place and it will also make a non-renamed copy of it. So whenever we start the day with new version we copy drag the current ones to __OLD and rename the now 'new' current ones to the new version. It works especially well because it allows you to keep your sequences opened rather than having to open your newly created onens which you sometimes accidentally forget and work in an old version instead. ... View more