Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

"Tattoo" project notes...

@ Erich

This allways makes me curious...
I'd have loved to see some visual examples of what you're saying, not being into maths at all...

I do see compression artifacts in prores files. But that may well be due to me learning to recognize them.

On the RED side of things, I have started to realise that a lot of the issues (pre Build 30) were actually more de-compression/( and possibly de-bayering) related.

So... If you (or anyone else) could point me to some examples of typical wavelet compression issues, I'd love to take a look.

Cheers

Gunleik
 
Sounds all very theoretical to me.
If there are any artifacts at all, I like those from Wavelet better. Humans are very sensitive to blockimess in organic images, while a minor softness is looking organical in itself. I've even heard from DPs who use a higher compression in REDCode just to soften the image a bit (personally, I'd rather use diffusion filters).

I've never seen ringing in RED footage, and I've seen quite a bit by now.
 
I know we love wavelets around here, but they also suffer from a wonderful artifact known as "ringing." A more annoying artifact (at least to me) is the loss of subtle details (tiny divergences from the ideal wavelet curves); removing these is one of the main things that allows for there to be "compression" at all. When you hear "lossy", this is what is being lost. I personally can't wait for RED to deliver an uncompressed or lossless compression mode so we can A/B stuff. :-)

Of course, it's possible that RED has overcome some or all of this; RedRay (I'm told) has pretty amazing quality for the bit rates.

One of the x264 developers has a nice writeup on the tradeoffs between wavelets and DCT-based compression here: http://x264dev.multimedia.cx/archives/317

Final caveat: I am not a compression expert, but I do work with wavelets directly on another project of mine (3D rendering) and have a pretty solid understanding of how they can impact an image.

I am a fan of the "Diary of an x264 Developer" blog and while it is a very interesting article, it deals with delivery codecs at "sane" bitrates in the 2 MB/s range. REDCODE at 200 MB/s is by no means a sane delivery codec - it is a high bitrate acquisition codec. So while wavelets might lack the efficiency, at insane bitrates much of the its problems are eliminated and it also avoids artifacts associated DCT based codecs such as macroblock and banding artifacts. REDCODE 2.5:1 is mathematically lossless. Even the 42 MB/s 4K RED One footage performs excellently. There are some high frequency blurring artifacts in wide, detailed shots, but that's about it. I have not yet seen instances of ringing or banding. I am sure the Epic REDCODE is flawless.

On the other hand, you have the RedRay codec which seems to perform excellently at moderate bitrates - but we don't know much about that. There's obviously much more to a codec, which is why x264 Very Slow preset is a 100 times more efficient than the DSLR H.264 implementation.

Gunleik, ringing is basically artifacts ("rings") around edges and to me looks a lot like poorly done edge sharpening. Neither DCT nor wavelets are free from the ringing artifact - though wavelets do seem to be more affected at very low bitrates. I am sure you have seen the artifact before, there are several examples on the internet.
 
One of the x264 developers has a nice writeup on the tradeoffs between wavelets and DCT-based compression here: http://x264dev.multimedia.cx/archives/317

Final caveat: I am not a compression expert, but I do work with wavelets directly on another project of mine (3D rendering) and have a pretty solid understanding of how they can impact an image.

His perspective is heavily h.264 biased and the comparison isn't taking to account that each compression technology has it's sweet spot. There's alot to disagree with in that article...
 
All Ian is doing is using his own personal "1D Cineon to Video LUT", rather than an off-the-shelf one. It's interesting that you think that curve grades can be "very, very destructive unless you really know what you're doing", whereas what I'd say is "unless you really know what you're doing you can destroy an image in grading". If it's the user ability that's the issue, then that's the issue, not what grading methods are used. I don't think 1D curves, if properly implemented (in the software / hardware), are inherently destructive. What I do think is necessary though is that all transforms applied to an image be simple enough to understand, without unnecessary complexity, and have sufficient precision and respect to the underlying data.

Graeme
 
It's an interesting enough article (if h264 biassed) about very low bit-rate applications, but REDCODE, for instance is a high bit-rate application. I like your comment about "sweet spot" Deanan - that's exactly right. Each type of compression technology has it's sweet spot in terms of compression amount, content, and other features.

The readers comments about REDRAY are highly amusing though - some seem to be in a state of utter dis-belief, as I would also be if I'd not been instrumental in making the darn thing work in the first place!

Graeme
 
I've seen REDCODE 28 completely break down on a couple of shots. Usually as you give it more and more detail to compress it just gets softer, but beyond a certain point the detail seems to completely overwhelm it and it degrades into a not only soft but also pixellated mush. One scene was a dolly-push down a path lines with trees, with thousands of leaves and tall grasses blowing in the wind, and the other was underwater, cruising over a wreck that was rusted and teaming with reef life, with a lot of particles floating around in the water. Both shots were high framerate, and the lesson we learned was simple - when you have tons of detail and want to shoot slowmo, don't use CF cards that limit you to RC28, get a RED Drive or RED RAM and shoot RC36.
 
Great article! Thank you for sharing it. Reading a bit about the back story and processes really hits how integrated and efficient a RED workflow can be. We all know how quickly it can fall of the rails.

The discussion about it has been very informative too.

The 4K viewing of Tattoo at NAB has spoiled a recent movie theatre experience I had. The movie was shot digital but distributed on film. It didn't look as good as it could have and only highlighted some of the issues brought up on this thread.

David
 
All Ian is doing is using his own personal "1D Cineon to Video LUT", rather than an off-the-shelf one. It's interesting that you think that curve grades can be "very, very destructive unless you really know what you're doing", whereas what I'd say is "unless you really know what you're doing you can destroy an image in grading". If it's the user ability that's the issue, then that's the issue, not what grading methods are used. I don't think 1D curves, if properly implemented (in the software / hardware), are inherently destructive. What I do think is necessary though is that all transforms applied to an image be simple enough to understand, without unnecessary complexity, and have sufficient precision and respect to the underlying data.

Graeme

It is, of course, the users ability that is the key factor. But there are an awful lot of colorists - as well as those who call themselves one - that don't understand what a log encoded image is, let alone how to handle it. Using a curve control rather than LUT is fine if you know what the log curve was and how to properly interpret it. But if you don't, the chances are rather good that you'll try to crush the lower end too much, and you'll push the upper midrange too much, thus creating an unnatural greyscale as your starting point but not knowing why, or how to fix it. The problem with home grown curve corrections done by less than experienced colorists is they are basically doing something they happen to personally like, rather than what the image should be. Image quality always suffers when one does this without a good creative purpose. Much better to use a proper, mathematically derived transform in the form of a LUT to yield a proper starting point for creative grading and ensure that the transform is logical and correct. Curve grades can always be applied as well to yield better control if needed. But doing it right is a much better starting point than guessing, which is what many, if not most, inexperienced colorists - and even some experienced ones - would be doing.
 
"doing something they happen to personally like, rather than what the image should be" - I thought the image "should be" what is "liked", because there is no absolute what an image "should be".

A LUT is just a representation of a curve, and there is no "correct" transform from a Cineon to a "video" image, only many equally valid ones, all with their own creative intent. Quite frankly if we take this hypothetical colourist who bodges up creating a 1D Cineon to video curve, I'd also expect them to bodge picking the "right" LUT Perhaps they even don't know that they need some curve transform in there at all....

Graeme
 
Sorry if this has been posted again (couldn't read all the thread) but where can someone see this "Tattoo" video that this discussion is based on?

I read the article at http://michaelcioni.tumblr.com/ but there was no link to the video either.

I believe that unless we can see the video for ourselves the article doesn't really make the intended impact, does it? Unless of course it's only meant to make sense for the lucky people that could attend NAB.

I am sure the video is great though! Didn't mean anything disrespectful for the people involved in making it!

:-)
 
"doing something they happen to personally like, rather than what the image should be" - I thought the image "should be" what is "liked", because there is no absolute what an image "should be".

A LUT is just a representation of a curve, and there is no "correct" transform from a Cineon to a "video" image, only many equally valid ones, all with their own creative intent. Quite frankly if we take this hypothetical colourist who bodges up creating a 1D Cineon to video curve, I'd also expect them to bodge picking the "right" LUT Perhaps they even don't know that they need some curve transform in there at all....

Graeme

I really don't know why you're apparently trying to start some sort of debate about this. There's great value in simplicity sometimes, something that you always seemed to recognize before. Giving people files that are not like files they've previously dealt with, and a greyscale interpretation that is not meant to be either looked at or used directly, can and has created a situation where a number of your users are looking at images that are less than optimal. I hate to tell you how many DIT's I've run into who don't have any clue as to what a "de-log" step is or why they need one, all they know is they pull the blacks down on a logarithmically coded image and it looks better. THAT's why simplicity is often called for, and why I suggested a much simpler approach than rolling your own curve correction to get to a sensible starting point without compromising the photography. Not only that, but the fact is that while grading, you have a lot more fine control if you work directly with the non-transformed data and use the transform as the last step in a processing pipeline than you do if you apply the "de-log" step earlier in the chain, something many people also don't completely understand unless they happen to have done DI work. Like Jim, I'm trying to suggest a series of rather simple steps (steps that I often use myself, because they're very efficient for television work when time is of the essence) to achieve a much better end product. I would think that you of all people would recognize that.
 
"doing something they happen to personally like, rather than what the image should be" - I thought the image "should be" what is "liked", because there is no absolute what an image "should be".

A LUT is just a representation of a curve, and there is no "correct" transform from a Cineon to a "video" image, only many equally valid ones, all with their own creative intent. Quite frankly if we take this hypothetical colourist who bodges up creating a 1D Cineon to video curve, I'd also expect them to bodge picking the "right" LUT Perhaps they even don't know that they need some curve transform in there at all....

Graeme

Makes me think...

Here are 3 images from the first real world test i did when received my R1...a few years ago...old M sensor... :)

I thought RedLog looked great for dynamic range, highlights smoothness and absence of banding...

Didn't have a clue on what was happening as far as math processing... LUTs etc... (I read about it since then...although :)

But if the image looks great on a calibrated monitor (the same color and gamma space as the intended delivery standard), chances are it will look what you actually see.

A few years ago, i had a 30 sec commercial that had to be blown up to 35mm film for theaters.

The transfer house told me, "send us a TIFF images sequence that look OK on a calibrated computer monitor, and we'll do the conversion, and it will look the same".

It looked EXACTLY the same when projected, no color shift, no gamma difference, no banding :)

Also...Having different color spaces and gamma spaces, as a starting points for grading, ...i like a lot :)

Antoine
 

Attachments

  • 11.jpg
    11.jpg
    36.3 KB · Views: 0
  • 16.jpg
    16.jpg
    45 KB · Views: 0
  • 19.jpg
    19.jpg
    52.2 KB · Views: 0
Ouch, What happened to my images... :( heh heh...

I'll try to upload them without that mushy compression

Antoine
 
Makes me think...

Here are 3 images from the first real world test i did when received my R1...a few years ago...old M sensor... :)

I thought RedLog looked great for dynamic range, highlights smoothness and absence of banding...

RedLog was designed, at least in part, to accommodate "video gamma" style grading, as it is a "mild" log curve that is mostly intended to retain highlight information, albeit at a slightly reduced precision. RedlogFilm is not. It is a Cineon based log curve, which normally requires a "de-log" step to obtain a proper greyscale representation on a video type system.
 
Regarding the "Look"

Throughout my career, I have been appalled at the number of people who were put in charge of color timing (film terminology for grading) that were either partially or totally color blind.
I have known people who readily admitted that they were at least partially color blind, and did not want to even come close to being put in a position of grading, but there are people out there who are faking their way through it.
It is actually not hard to spot this. They just simply are unable to get the color correct.

I bring this up because once spotted, it can, and has, solved a lot of problems with matching, and the look of the project once a person who is not color blind starts grades the project.

Really! One person's look can be the result of partial or even total color blindness.
 
Mike, I'm trying to find out what you're getting at. If we were in person, it would be a lot quicker for sure. I guess I took objection to a curve being "very, very destructive unless you really know what you're doing", and I want to know why.

Graeme
 
Mike, I'm trying to find out what you're getting at. If we were in person, it would be a lot quicker for sure. I guess I took objection to a curve being "very, very destructive unless you really know what you're doing", and I want to know why.

Graeme

Well, here's a good example. A, shall we say, "inexperienced" colorist takes a RedlogFilm image and applies a curve correction. He lowers the "near blacks" (by eye) and lifts the "near whites" (also by eye). Then he does some "lift, gamma, gain" type grading. Now he decides he wants it to be a bit "poppier", so he goes back to his curve correction and pulls up the "near near whites." The faces are then a lot harsher. So he then brings down the "near near blacks" and he gets apparently better contrast but less black detail. He also notices that the face now has better contrast, but harsher highlights, so he pulls down the "near near white" curve point. Now he has grey highlights in the faces. So he pulls up the "near whites" and gets hot halos around the grey highlights. He also starts getting artifacts at the crossover point between the "near near whites" and the now too high "near whites." This kind of thing happens all the time because when an inexperienced colorist uses a curve control as their primary contrast tool, it's all too easy to think you're doing something good to the image when in fact you've walked yourself into no man's land and don't really know it. Using a predetermined, mathematically correct transform (in the form of a LUT) yields a starting point based on the original photography's inherent contrast and enforces a bit of discipline for those that are not that familiar with log curves, and ultimately avoids the "weird extremes" that often seem to result from inappropriate curve corrections.

Now, in some software (Scratch comes to mind) there is the ability to apply a "default" Cineon to video curve based on proper values but implemented as a curve rather than a LUT. That's a good alternative, but it isn't available in most software that I know of, so the rather non-scientific "roll your own" approach takes over, and is often done at the beginning of the processing chain. That's when the trouble starts...
 
Ok Mike, I have a better idea of what you're on about now. Are you thinking that instead of the nice smooth continuous monotonic curve with no flat sections, the inexperienced colourist would come with a curve looking somewhat like a camel's back?

Graeme
 
Back
Top