Forum Replies Created

Page 1 of 5
  • Oh, I have left a bug report about this. I find it hard to believe that not one user would have left Adobe a bug report from a problem of this size, and so easily repeatable and affecting 100% o the users (it seems to have nothing to do with the hardware you have).

    I found something like 2-3 people/threads with this problem, and the workaround was not found as an answer in any of the threads. So it is hardly common knowledge, and hardly something poeple will keep using when/if the bug is solved.

    Lets say I have 126 50p files I need to downconvert to SD with Media Encoder. Oh, yeah, I will just create a Premiere project and create 126 timelines where I will import these 126 files… While it is a workaround it is a real timekiller. In these cases I tend to lean towards Compressor and use it instead.

    Using Media Encoder and the workaround is waaay too time consuming.

    But for Premiere Projects that already exist, it is useable. For converting files, not so useable (any other encoding software is preferrable if compared with the need to create 126 sequences and all).

  • Phew, thanks! It is a working workaround for the bug, at least for my footage. Do you know it it works for the problems in the thread I linked to, in the Adobe forum? One was even without speedchange at all:

    “AME does frame blend going from Canon 24P AVCHD to Apple TV 720 24P preset. Why?”

    Perhaps you could send a link to this old thread to someone at Adobe who has a account on their own forum. So the thread would get an answer and a temporary solution. If someone would have answered the thread already, telling everyone Adobe knows about this and has a temporary workaround, I wouldn´t have needed to post this thread at all.

    On second thought… I probably would, to let others know about the bug.

    The guys in the other thread are talking about Media Encoder 4.2. Is that from CS4? Then this bug has survived through CS4, CS5 and CS5.5. IT makes no sense to me. Do the guys at the development actually know about this bug? Or is it just left untouched on purpose, because there is a workaround for the bug?

  • Sure, the curves can be used. But it is not as fast as using the colorwheels for color corrections.

    Lets say you need to adjust the highlights, they are tinted towards magenta… On the hi-colorwheel this is easily and quick to adjust, compared to the curves that need more fiddling and you might need to adjust several of the curves for this correction.

    As I explained somewhere in this thread, we need to do sppedgrading, no time to fiddle with the curves for all corrections. Sometimes they are needed, sure, but we cannot use curves for all corrections. Fast grading with a control surface is what I wanted to achieve. If you´d use curves all the time, there would be no need for a control surface.

    And the way Resolve reacts now, if you d make this adjustment for the highlights you would change the whole image all the way to the blackpoint, changing the blackpoint too. Sure, I think the overlap should be pretty big to give good results, but not so big that you change the blackpoint of the footage with the highlight controls.

  • Ah, yeah, the “Brightness Regions” looks like exactly what I´m talking about.

    Luma key? Perhaps. But it adds yet another step that needs to be added and adjusted every time…

    For now, I think I will step back and wait for Resolve to evolve before I take it into our production line. Not having audio on exports is already a big disappointment, all fiddling with XML imports and stuff takes a bit time (batch import would save time), and now this. The brightness regions not being what suits us and not being adjustable.

  • Yeah, I am a bit surprised too, haven´t read anything about anyone with these “problems”. I just checked colorista and it affects almost along the whole range too, but not quite as far as Resolve does (and I think they start to “fade out” earlier along the brightness-scale). Adjusting the highlights will not affect the black point, the blacks stay black.

    So probably a quite small adjustment of the range would be enough.

    Perhaps it has to do with us handling old films with weird twisted colors, different parts of the image is twisted differently compared to new footage? And we don´t have the luxury of spending hours upon hours on a few minutes of footage. We need to chew through several hours of footage each day, for each colorist.

    So it is more of colorcorrection than grading, and a bit more “rough cut corrections” with mainly primaries. When transferring old family films from 8mm and 16mm film, the clients have hours upon hours of footage. And they are not prepared to take a huge bank loan just to get their films transferred… 😉

  • [Kevin Cannon] “I always liked this function on the Avid DS system (which also had a handy three-tone preview, black gray white to tell you what in your current image falls into which categories, roughly). “

    This is also available on Premiere Pro 3-way colorcorrector. Both the ability to adjust what should be considered as shadow/mid/high, and the ability to see a preview with black/gray/white to show what parts of the image are affected by the different controls.

    This is badly needed in Resolve… because at least according to me, they overlap way too much. I will add it to my wishlist, and send to it Blackmagic next week or something.

  • [Dan Moran] “Lift, Gamma and Gain can be different to Shadows Midtones And Highlight controls.”

    Yeah, yeah, but on Resolve they are labeled “Lift – Shadows” and “Gamma – Midtones” and “Gain – Highlights”. Right next to the colorwheels on the new “colorwheel tab”. At least on this tab, they seem to be the same. 😉

    And I can´t understand why the highlight control affects all the way down to the shadows… Weird. Makes it very hard to target either the highlihgts or the shadows specifically, and the midtones affect the whole image… Makes the tools very “indistinct”, if you ask me.

    Sliders that adjust how far each control will affect the image, and perhaps controls for how long the smooth overlap of the different controls should be… Definetly needed here. And make them permanent in a preferences page, and perhaps add the possibility to make custom adjustments on a lcip-basis or on a project basis. But it should definetly be a user-adjusteable permanent preference.

  • [Sascha Haber] “Ok, to illustrate what I meant…
    This is an image with a lot of light :
    The midtones will pick the roof and windows which are actually the darkest parts.”

    Yes, this image doesen´t have any real rak parts, so the “shadows-control” would obviously not be used here. You´d use the highlight and midtones to affect this image.

    ——————————————————————-

    [Sascha Haber] “and here we have a pretty dark one :
    The midtones will pick the highlights.

    Yes, this image doesen´t have any real highlights. so you´d use the shadow and midtones to adjust this image.

    ——————————————————————–

    [Sascha Haber] “My point was its kinda impossible to look at Gamma as midtones..it isnt.
    it just affects the light level around 50% most and not so much the 0 or 100 % range.

    Well they are labeled as “shadows”, “midtones” and “highlights” on colorista, so why not use these terms when we talk about the controls? But of course it is as you write, the midtones affect colors around 50% light level, highlights affect more around 100% light level, and so on.

    The problem is that the highlight control adjusts the image all the way from 100 down to 0 if we look at the image “as light measured from 0 to 100”. It would be better if it affected something like…

    Shadows affect 0 to 50
    Midtones affect 25 to 75
    Highlights affect 50-100

    (of course, shadows should affect mostly around 0 and smoothly less and less the closer to 50 you get. These numbers are very rough, but I hope you understand what I mean)

    With smooth minor overlapping between hightlight to midtones, midtones should slightly overlap both hightlights and shadows, and of course shadows should overlap up to midtones, but not all the way up to the highlights.

    We do very specific/special colorcorrections, we transfer old films and colorcorrect the footage. These old films sometimes have a slight colorcast, so the image is tinted towards red. Sometimes it is tinted towards blue. Sometimes the shadows are tinted one way and the highlights, or the rest of the footage, is tinted towards something else!

    Using colorista one would correct the shadows (if the image had any real shadows) would be corrected with the shadows and then when you adjust the rest of the footage, like highlight, the shadows would remain set. Of course, if you need to tweak the midtones a lot perhaps you needed to touch up the shadows again…

    But basically the three controls affected, mostly, different light-level-parts of the image. It was very easy to use.

    Now, in Resolve, the midtones affect the whole image, a lot. If you set the shadows so that the parts that are supposed to be black are black, the midtones will screw this adjustment almost immediately, because it affects the image all the way up and down from shadow to highlights. And even the highlight control affects the shadows almost immediately… Weird. Very weird.

  • [Dave Pickett] “They all interact with each other. That way you can stretch out the entire image by lifting the gain as opposed to pulling the brightest 33% of the picture up.”

    Yes… But I would prefer for the highlight adjustment to affect the highlights only (well, some streching down towards the midtones of course, but not all the way through the whole image down to the shadows). And I would prefer for the midtones to affect “mostly the midtones” with some stretch towards high/low, and the shadows would of course then affect the darker parts of the image mostly, with some stretch up to midtones, but not all the way up to the highlights.

    [Dave Pickett] “So the differences between Colorista and Resolve may be like that. “

    Yeah, but not only is it more difficult to get used to… I am not sure we can use it as it is now. It is very difficult to work with, when you have set the shadows (like taken out any colortint in the blacks) and then go on adjusting the highlights you mess up the blacks again, because the highlightcontrol affects the shadows too! Seems very weird…

  • [Sascha Haber] “lol, seriously ?

    Yes, lol, seriously.

    [Sascha Haber]Colorista is the new standard ?

    Is it? Who told you that?

    [Sascha Haber]mid of the image in question ?

    Well it is pretty obvious that “mid” in the “midtones” is referring to stuff not in the highlights nor in the shadows but… in the MIDtones. You know, not darker colortones nor brighter colortones?

    [Sascha Haber]one has to offset “midtones” to the footage.”

    Like in the secondaries? Isn´t that just when you want to affect certain colors, like turn a red car to a green car?

    Shadows are always shadows and highlights are always highlights. Then the question is what is to be considered as highlights, how far down should the highlight control affect the image? And that is what I want to find a adjustment for.

Page 1 of 5

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy