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 :)

4K for the finish...

Hello Axel,

Reading the above post make me ask a question...

What people say: the bigger the picture, the better wavelet compression works.

4k DCP @ 250MBit/sec projected on a 2k server should "VISUALLY" not be equal to a 4 times more compressed 2k DCP (like 67.5 MBit/s) due to the nature of wavelet compression scheme?

Do you really think it's VISUALLY equal to a "roughly 67.5 MBit/s" 2k DCP?

Pat

Hi Patrick,

I think that would need some deeper research to give a really precise answer.
However, if you container is 125 MBit/s or 250 MBit/s for "just" 2K there is likely more detail in it than in a 2K strip of a 4K resolution image at the same bit depth.
None of the DCI player I am aware of will actually decode a 4K and then downscale to 2K. Instead they will detect that only 2K is supported and therefor decode only the 2K level, so leaving out in a worsed case about 3/4th of the entire information.

What needs research here is how much the quantisation will affect the bit reduction in which levels of the image. But I would wonder if a 250 MBit/s 4K will really contain a 125 MBit/s 2K as down strip resolution...

If we find time we can give it a try and report the results. But that will take some time.

Cheers,
Axel
 
Hello Axel,

Reading the above post make me ask a question...

What people say: the bigger the picture, the better wavelet compression works.

4k DCP @ 250MBit/sec projected on a 2k server should "VISUALLY" not be equal to a 4 times more compressed 2k DCP (like 67.5 MBit/s) due to the nature of wavelet compression scheme?

Do you really think it's VISUALLY equal to a "roughly 67.5 MBit/s" 2k DCP?

Pat

Wavelet compression is not linear. So the more pixels per frame, the more efficient the compression because you can increase the AVERAGE bit rate over more similar pixels. So the same 250Mbs goes a lot further with 4K than with 2K, which is why a 4k DCP looks so good, even when encoded at 250Mbs (same as 2k). So if you make a 2K DCP at 67.5Mbs, it doesn't look as good because less pixels are used to average over the raster.
 
I think I take some small time and explain it in more understandable words than the link provided:
This was extremely helpful Axel. Much appreciated. Read it through 3 times, drew some diagrams for myself and I think those basics have stuck :)

Has raised a few questions for me though that I would love it if you could answer.

1. It seems that wavelet compression should provide a perfect downscale when ignoring rounding errors. However this seems to go against what I have seen in real life. For example, when comparing a full resolution image in RedCine-X with a 1/8 image, noise characteristics in particular look different. Actual pixels of noise seem bigger than expected if they truly are an averaged result of multiple wavelets. If they were an average, I would have expected the low res extraction to look very similar to a downscale from a full res image where pixels of noise almost disappear because they are averaged out by the time the image is that small.

Am I missing something or am I just having the placebo effect trick me?


2. The intro you have given to wavelet compression here applies in a lossless kind of fashion I am guessing? How does lossy compression (such as J2K and R3D) come into play with this? The answer to this may be more complicated than I am able to process (or you are willing to explain) but if you could point me in the right direction to learn, it would be most appreciated :D

Thanks again for your help :)
 
I think I take some small time and explain it in more understandable words than the link provided:

Many of you may know the principle of mip-mapping in 3D graphic cards to provide smaller resolution levels for textures when a 3d object is more far away. To do this, a mip-map is being created by placing the R, G and B layers as three quadrants of a four quadrant image plane. The 4th quadrant is then split again into 4 sub quadrants. One sub quadrant is filled with a perfect downscale of R -> R' to 1/2 width and 1/2 height, and so on for G -> G' and B -> B' channels. The then again empty 4th sub quadrant is again split into 4 sub-sub quadrants and the game is repeated, usually until you reach some very minimal size or actually a single pixel (single pixels would require mip maps to be powers of 2, though).

This example should explain that the sub channels are of perfect downscale quality. However, mip-mapping needs 1/4th more storage, which is not desireable in the context of distribution formats for video content.

So how do wavelets solve the problem?

Very simple:

You take the highest resolution level (say 4096x2160y) and then you create a first level of wavelet from it. This is being done by making a perfect quality downscale to say 2048x2160y resolution, actually mixing every 2 pixels into 1 horizontally. The resulting image will fill say the left side of your 4096x2160y frame buffer. As you stored always the medium value of the former original 2 pixels, all you need to know is how much this stored value is different from the original 2 pixels. As its the middle value, the distance to both values is identical, but with different signs. So we can say:

left original pixel = middle value - difference

and

right original pixel = middle value + difference


A simple monochrome example (for understanding the principle):

Left pixel is 50 and right pixel is 70.
The middle value downscale pixel will be (50+70)/2= 120/2 = 60
The difference to the original pixels is 60-50 = 10 or also true 70-60 = 10 and is always 10.
You can now reconstruct the left pixel by using the medium pixel 60 +/- 10:
Left pixel = 60-10 = 50
Right pixel = 60+10 = 70

A simple RGB example (and X'Y'Z' would be just a different naming on channels):

Left pixel is RGB(50, 100, 200) and right pixel is RGB(70, 180, 200).
The middle value downscale pixel will be RGB((50+70)/2, (100+180)/2, (200+200)/2) which results in RGB(120/2, 280/2, 400/2) = RGB(60, 140, 200).
The difference to the original pixels is RGB(60-50, 140-100, 200-200) or also true RGB(70-60, 180-140, 200-200) and is always RGB(10, 40, 0).
You can now reconstruct the left pixel by using the medium pixel RGB(60, 140, 200) +/- RGB(10, 40, 0):
Left RGB = RGB(60, 140, 200) - RGB(10, 40, 0) = RGB(50, 100, 200)
Right RGB = RGB(60, 140, 200) + RGB(10, 40, 0) = RGB(70, 180, 200)

So as you can see all you need to do is to store the middle average value of two pixels in the first half of your framebuffer and the difference value in the second half. That uses exact the same amount of space as the original bitmap and allows (almost) perfect reconstruction. Important to understand: You need a signed value range for the difference level, as they can be negative. And there is a round error of 1/2 bit in a worsed case.

When you now iterate that step once more on the left 2048x2160y perfect downscaled image to scale it down vertically to 2048x1080y doing the same steps, but vertically, you have the top left corner being a perfect downscaled 2K image, the down left quarter being the difference level to reconstruct 2048x2160y resolution and the two right quadrants the difference to reconstruct the 4096x2160y full resolution image.

However, JPEG2000 for DCI specs goes well beyond that and includes typically 5 wavelet levels for 2K content and 7 wavelet levels for 4K content, whih means the downscaled image part is iteratively dowscaled by 1/2 alternating vertically and horziontally (and ONLY the image part, not the difference part). So the lowest resolution is much smaller than the original content. To reconstruct the image, you have to process all resolution levels until the desired resolution is reached.

Its definetly NOT line skipping.

Btw, CineForm uses wavelets too. The BIG point here is that you can reconstruct a lower resolution wavelet with far less computing resources, as you need to read and process dramatically less data. In fact you can view and work with a smaller (but perfect quality) resolution. Something that you can NEVER do with ProRes, DNxHD, BMD or AJA codecs, nor DPX or TIFF files. Its time that poeple start understanding this important difference for their workflows.

Cheers,
Axel

Posts like these are what I absolutely love about reducer.

Axel, thank you, and am looking forward to get to the point where I start playing with FinalDCP. Still stuck in the post quagmire unfortunately to worry about delivery process yet. :(
 
This was extremely helpful Axel. Much appreciated. Read it through 3 times, drew some diagrams for myself and I think those basics have stuck :)

Has raised a few questions for me though that I would love it if you could answer.

1. It seems that wavelet compression should provide a perfect downscale when ignoring rounding errors. However this seems to go against what I have seen in real life. For example, when comparing a full resolution image in RedCine-X with a 1/8 image, noise characteristics in particular look different. Actual pixels of noise seem bigger than expected if they truly are an averaged result of multiple wavelets. If they were an average, I would have expected the low res extraction to look very similar to a downscale from a full res image where pixels of noise almost disappear because they are averaged out by the time the image is that small.

Am I missing something or am I just having the placebo effect trick me?


2. The intro you have given to wavelet compression here applies in a lossless kind of fashion I am guessing? How does lossy compression (such as J2K and R3D) come into play with this? The answer to this may be more complicated than I am able to process (or you are willing to explain) but if you could point me in the right direction to learn, it would be most appreciated :D

Thanks again for your help :)

Hi Brad,

warning, you are mixing apples and pies here!

While RED R3D are based on JPEG2000 as far as we know, requesting a lower resolution from a RED RAW R3D file within REDCINE-X, such as 1/8 will potentially cause the following:
The quadrants per color channel are restored at a lower resolution. Then those quadrants will be combined into a RGB image, maybe using some small pixel shifting to compensate for the small offset those color channels have (due to the Bayer pattern they represent). But only RED knows the answer, so we are speculating here. I doubt that they even try do a deBayer process from a lower resolution color channel. IMHO that would be total nonsense, as the pixel shift is completely different, because it scales as well. It would entirely new algorithms to do something "good" here.

However, when looking at a DCP we are talking about smaller resolutions of a true full pixel RGB image (or X'Y'Z' image). So there is a BIG difference between the two things.

RAW is a completely different beast than an RGB image, even when the compression method used may be partially the same.


Regarding how does JPEG2000 wavelet compression work, its actually a bit more complex than I described, because the filters in action already filter the image in diverse sub bands of information, from which some can be discarded to gain compression efficiency.

Here is a good link to this:
http://faculty.gvsu.edu/aboufade/web/wavelets/student_work/EF/how-works.html

or very detailed here:
http://www.google.de/imgres?hl=de&safe=off&sa=X&rlz=1I7ADFA_de&biw=1920&bih=1099&tbm=isch&tbnid=A8CKzJCOjCKUoM:&imgrefurl=http://research.microsoft.com/~jinl/paper_2002/msri_jpeg.htm&docid=h-KqtmaBzO-GOM&imgurl=http://research.microsoft.com/en-us/um/people/jinl/paper_2002/msri_jpeg_files/image022.gif&w=436&h=224&ei=zhdHUc_YEdTY4QT17IC4CA&zoom=1&ved=0CGgQrQMwCA&iact=hc&vpx=1566&vpy=146&dur=3689&hovh=161&hovw=313&tx=156&ty=78&page=1&tbnh=145&tbnw=281&start=0&ndsp=56

1. The image is being wavelet transformed at 12 bits per pixel depth. Thats the steps I explained before. You get kind of a reorganized framebuffer.
2. Quantization is applied. This means important informations is being kept, unimportant information is being dropped (lost).
3. The resulting data package will be compressed using a method quite similar to e.g. ZIP files, but using an advanced compression scheme called Ebcot (entropy coding).
4. The final compressed package is written to a file, including a header with some basic metadata.

The description I gave is the basic prinicple behind wavelets. The algorithms in use are a bit more advanced, but still follow these principles.

Cheers,
Axel
 
Wavelet compression is not linear. So the more pixels per frame, the more efficient the compression because you can increase the AVERAGE bit rate over more similar pixels. So the same 250Mbs goes a lot further with 4K than with 2K, which is why a 4k DCP looks so good, even when encoded at 250Mbs (same as 2k). So if you make a 2K DCP at 67.5Mbs, it doesn't look as good because less pixels are used to average over the raster.


Yes, I think you are right with that thought. However, it would need some specific research to check the details.
We might at some point have the tools to do these tests. Right now it would require us some coding to do so, but we have a lot of other things on our lists, so I have to wait a bit until we find time to look into the details here.

I wonder as many are curious about 250 MBit being or not being good enough for 4K, how well RED RAY will compare to this, given its like ten times smaller than this?
OK, its possibly applying a GOP like compression scheme, and may still have a RAW approach inside. But only at the point we can compare the results side by side we will be able to understand how good or bad this will really be.

One might think: "OK, high bit rate stuff is for the theater, low bit rate stuff is for the home." But RED RAY is announced to be a theatrical solution too. And on the other hand we see tons of theaters showing content off from BluRays as well.
Future will tell us.

Cheers,
Axel
 
I'm just glad we made 2K and 4K DCP.

I think it was the right way to go after my initial research.

The film is screening again here in FLorence (from the 2K DCP) next month!

David
 
Just to throw this out there. My last film a 26 minute micro budget documentary was finished as:

4k dcp
2k dcp
4k prores
2k prores
1920x1080 prores
david

Question about the 4K ProRes version: what is it being played out from? Mac with a 4K video card? Which card? AMD 7970 flash hacked for Mac? QuickTime (or ffmpeg) read of ProRes on Windows over AMD 7970 or similar? BM Decklink 4K Extreme on MacOSX?

Thanks in advance David.

Cheers - #19
 
I use the 4K prores version to edit with FCP X. It gives me a high res master to create promo materials from, but it is not really designed to playout in a theater, untitil the hookup a KONA 3G card or a deckling in most theaters (which we are not going to see) The 2K and 1920 x1080 versions can be sent to certain festivals that accept Quicktime.

I wanted high res, CC'd editable copies of the film so that is why the 4K and 2K prores, the 4K is internal, the 2K and 1920 could be put on a drive for festival submissions.

David




Question about the 4K ProRes version: what is it being played out from? Mac with a 4K video card? Which card? AMD 7970 flash hacked for Mac? QuickTime (or ffmpeg) read of ProRes on Windows over AMD 7970 or similar? BM Decklink 4K Extreme on MacOSX?

Thanks in advance David.

Cheers - #19
 
Thanks David. I have a vision of a hard drive based media player that could source 4K material over HDMI using an embedded player app. WD and others have been cranking out these combo HDD/Media server units at a very attractive price point and I can't help but wonder what the potential is to create a 4K capable version. Just looking for cost effective alternatives to the RedRay player and for options that aren't tied to the .RED format.

AFAIK the lowest cost 4K player one can create is a low end PC with a 4K capable video card like the AMD 7970. This can be done for a little under $1,000 today. Even off a single 7200rpm HDD one should be able to handle a 4K DCP encoded at 250mb/s (32MB/s) for instance, as well as other compressed formats.

Cheers - #19
 
ON the mac side.

A mac mini with a 1TB internal SSD sending 4K QT over HDMI via QT (not sure if there are limitations here). I think less hardware and more Low bitrate data streams that can arrive anywhere in the world at a moments notice.

I don't like seeing hardware attached to anything when we have the internet.

There has to be a way to leverage the computing power of someone's PC to playout 4K files.

David




Thanks David. I have a vision of a hard drive based media player that could source 4K material over HDMI using an embedded player app. WD and others have been cranking out these combo HDD/Media server units at a very attractive price point and I can't help but wonder what the potential is to create a 4K capable version. Just looking for cost effective alternatives to the RedRay player and for options that aren't tied to the .RED format.

AFAIK the lowest cost 4K player one can create is a low end PC with a 4K capable video card like the AMD 7970. This can be done for a little under $1,000 today. Even off a single 7200rpm HDD one should be able to handle a 4K DCP encoded at 250mb/s (32MB/s) for instance, as well as other compressed formats.

Cheers - #19
 
Thanks David. I have a vision of a hard drive based media player that could source 4K material over HDMI using an embedded player app. WD and others have been cranking out these combo HDD/Media server units at a very attractive price point and I can't help but wonder what the potential is to create a 4K capable version. Just looking for cost effective alternatives to the RedRay player and for options that aren't tied to the .RED format.

Agree Blair - I'm sure they are coming!

Also: how about a PS4?

Or your cellphone in 2015?

Did you see the rumor about the LG's next Google Nexus phone which is supposed to record 30fps 4K and will be out at the end of this year? Seems plausible to me.

I'm realistic about the issues with mastering 4K in the present day but I'm not a skeptic about the future.

Of course... whether average folks will notice much of a difference is another thing, but I agree 4K playback will definitely be possible on commodity devices soon. Probably a long time BEFORE you can walk into the average movie theater and see a film in 4K!

Of course you'll probably have to carry your 4K TV or projector around with you because a lot of folks won't have 4K display possibility for a while!

I do think that audiences will be way more excited about the idea of "laser projection" in terms of perceptions of "crisp, bright, colorful" than just "4K" on its own. "4K laser" might do it!

Of course, to take advantage of a laser projector's full color range... you'd need to master using a laser projector and design your film for that wide color space.

So yeah, folks might just have to re-do their "future proof" 4K masters made at great expense today anyway :)

Bruce Allen
www.boacinema.com
 
I couldn't find definitive info on Apple's site but I don't believe the Intel 4000 graphics board or the HDMI port can deliver UHD or 4K out of the MacMini. The Thunderbolt port supports DisplayPort implementations but the graphics card has to be up to the task and other than the dual DisplayPort input option on the Sony VPL GT100 I am unaware of any other current devices using DP for 4K.

Thanks to all those gamers spurring GPU development, I am hoping that the next generation of mid priced graphics cards will support 3,840 by 2,160 (and maybe even 4,096 by 2,160) at refresh rates up to 60Hz. While 4K mavens such as many of us will spend $400 for a 4K capable GPU like the Radeon 7970, most folks won't. When all but the most stripped down systems include a graphics board that can handle UHD/4K it will dramatically increase the number of potential viewers of 4K content.

Cheers - #19
 
Thanks David. I have a vision of a hard drive based media player that could source 4K material over HDMI using an embedded player app. WD and others have been cranking out these combo HDD/Media server units at a very attractive price point and I can't help but wonder what the potential is to create a 4K capable version. Just looking for cost effective alternatives to the RedRay player and for options that aren't tied to the .RED format.

AFAIK the lowest cost 4K player one can create is a low end PC with a 4K capable video card like the AMD 7970. This can be done for a little under $1,000 today. Even off a single 7200rpm HDD one should be able to handle a 4K DCP encoded at 250mb/s (32MB/s) for instance, as well as other compressed formats.

Cheers - #19

H265. Look for it inside every TV made after this year.
 
Mark, are you suggesting that the displays themselves will have the H.265 decoder chips embedded so all you have to do is get the bitstream into the display? Possibly over next gen WiFi... Or will we be stuck with external boxes for a while longer.

Cheers - #19
 
I'm skeptical that Peter Jackson will redo all the visual effects in The Hobbit in 4K.

http://www.postmagazine.com/Publica...1-2012/Edit-This-The-Hobbit.aspx#.UUfohFs__Wo

My comment was more that indies who make a Rec.709 4K file to be "future proof" might be a little sad when they finally come to show their file on a 4K laser or OLED display... because those displays will probably have a much wider color gamut and to really take advantage of that, maybe you'd want to master and view in a wider-gamut color space to avoid clipping and losing extreme colors?

RE: The Hobbit being re-made in 4K... I don't know! Folks with boatloads of money and craziness like Jackson and Jim Jannard are unpredictable so I wouldn't bet either way! Since Jackson controls the post houses who did his VFX... yeah maybe he is secretly rendering away as we speak? Although if I were him, I'd just put the cash into the next two movies first instead. There won't be a whole lot of 4K home video sales for the next year!

BTW am I the only one who felt that the 2K finish on Hobbit was more noticeable than usual? Usually a 2K finish doesn't bug me much at all - but at 48fps, I felt that I noticed the slight lack of resolution more. It was getting in the way of the "window into real life" thing a bit for me and contributed to the video feel a little.

Mark, are you suggesting that the displays themselves will have the H.265 decoder chips embedded so all you have to do is get the bitstream into the display? Possibly over next gen WiFi... Or will we be stuck with external boxes for a while longer.

Seems logical! Heck, they'll probably even do it using current-gen WiFi! Although I agree that the compression wouldn't exactly be lossless :)

Bruce Allen
www.boacinema.com
 
My comment was more that indies who make a Rec.709 4K file to be "future proof" might be a little sad when they finally come to show their file on a 4K laser or OLED display... because those displays will probably have a much wider color gamut and to really take advantage of that, maybe you'd want to master and view in a wider-gamut color space to avoid clipping and losing extreme colors?

RE: The Hobbit being re-made in 4K... I don't know! Folks with boatloads of money and craziness like Jackson and Jim Jannard are unpredictable so I wouldn't bet either way! Since Jackson controls the post houses who did his VFX... yeah maybe he is secretly rendering away as we speak? Although if I were him, I'd just put the cash into the next two movies first instead. There won't be a whole lot of 4K home video sales for the next year!
...

Bruce Allen
www.boacinema.com

I agree, on going for a "next" movie rather then reshowing a 2k movie at 4k. I think all the industry needs at this point is one tent pole 4k - from the root up 4k movie - fully shot for 4k rather then just showing a 2k movie at 4k. For example, a movie that really needs 4k could be a organic setting in the tropics with two intimate lovers talking - sand/fabric/skin/water/flowers/fish/garden.
 
Back
Top