Pages: [1] 2   Go Down

Author Topic: Testings report  (Read 8930 times)

fredjeang

  • Guest
Testings report
« on: May 13, 2011, 08:51:24 am »

Hi,

I did some intensive testings and would like to report here the results. It might be usefull for some users. I warm you: it is a little or a lot boring.

We are (no surprise), in a singular situation. Apple ProRes codec has vastly become a standart, but if it is possible to read, import and transcode a ProRes file in windows, it is not possible to export a file in ProRes, this is Apple only. The problem of this Codec between the 2 platform is that it generates a gamma shift, known as the Apple bug.
A "bug" that can cost a lot of headaches, time and money and the company as often does not give a damn when it comes to their interests.

If Avid is known to be too slow to catch-up because they test everything a zillion time before, Apple has become master in reaching to impose good fancy stuff to the pros, even with bugs and only available in their systems. (that reminds the early Bill Gates days init?)

DNxHD is free, works on both platforms, can integrate alpha, compliant with SMPTE, works extremely well and is becomming step by step the prefered codec in the industry etc...but not as simple, to date Apple ProRes is still a prefered codec for a lot of applications.

Nota: not only the gamma shift can occurs with ProRes, it also does with H.264 in some particular cases.

I did some testings, importing, converting and exporting from windows and compared the results in both platforms. It's deplorable.

Original footage
- Avid: you need to take care of the way you import a file in the bin.
import in RGB, you tell Avid that the color space is not broadcast legal, so it will automatically recalculate the values, wich result in a different gamma, more washed. Curiously, this shift is more or less equal to the difference you will obtain with the ProRes codec.

It is important to precise that this shift could be obtain exactly manually (tried it) putting the gamma values to the legal extremes. So what really does Avid is that it simply consider the broadcast standart.

If you want your footage to not be affected by Avid, you have to tell him to import in 601-709, this basically is telling Avid that your file is fine and does not need any gamma correction.
That is very important.

After-effects-Autodesk etc...
If you import the original footage in After-effects or Autodesk in whatever bits, what those programs read is exactly the same as your original footage. 100% consistency in RGB.

But be carrefull.
If you apply a color correction in After Effects, then export from it in an Apple codec let's say H.264, the result will be absolutly correct to what you did in both platforms.
So as reimporting this footage in Avid in 601-709 mode (for the reasons explained above). 100% consistency there.
Not the same can be said with the use of importing ProRes and work with it or in a transcoding export. That simply does not work with accuracy.

But if you are using Autodesk, apply a correction and export with Apple codec(s), you'll have the gamma shift, except if you export in an uncompressed format wich then keeps the consistency (but then you don't use Apple codecs).
On the other hand, if you export in a Quicktime container using the DNxHD 10 bits codec, you do not have any shift, even reimporting in Avid and re-exporting, in Win or Mac etc...

In other words: DNxHD is the only codec so far in my testings that keeps the visual consistency in all the chain involved, regardless of the platform involved. Exporting any Apple codec from a DNxHD master for delivery also results in 100% accuracy. Or in other other words, Avid did the homeworks, Apple didn't and put the mess on the chain. They want people to buy their computers and softwares, Avid wants people to edit without issues. Big difference.

So, "Houston we have a problem": ProRes is very fashionable and can only be generated from a Mac and not free. This is the word of the gamma surprises from a platform to another.

How the hell do we solve that properly once for awhile??? Because if we could, we simply can ignore the ProRes, but the sad reality is that we can't ignore it. Thank you Apple to bring your fancy, wonderfull, brilliant and personal idea of standardization !

It's like the frenchs (I'm french), they can make the world beleive that they have the best wines so they can sell a very bad Bordeaux twice the price on the marquet and people are thinking they are drinking a top wine...the french label and the apple label are one and the same hoax. It's all about design and brand cool effect perception.

 
!!! I can't beleive I'm still loosing my time (and I'm not the only one for what I'm seeing on RedUsers, CreativeCow etc...) on those codec surprises while I should be editing and-or shooting.

Look at what kind of D.I.Y solution we have to deal with: http://blogs.adobe.com/toddkopriva/2009/12/prores-4444-colors-and-gamma-s.html or http://www.isophia.co.uk/prores-gamma-shift-fix/ etc...

My solution (and some others too): exporting ProRes from Mac if you have to send it to other editing platforms with YUV settings,  
This is because ProRes has a double nature: YUV and RGB
re-imported the clip into Avid with the DNxHD 10 bit codec
(watch out the import setting, anyway Avid is transparent and you'll immediatly notice if you are right)
export to Quicktime with RGB setting. It works!

You need to know absolutly each one of your applications encoding. If I send a ProRes file to Autodesk in YUV, I'm doing things wrong.

or, if possible, always go uncompressed.

or...go to the bar and forget about that mess! That's what I'll do right now.
 
« Last Edit: May 13, 2011, 02:52:13 pm by fredjeang »
Logged

smthopr

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 612
    • Bruce Alan Greene Cinematography
Re: Testings report
« Reply #1 on: May 14, 2011, 11:04:17 pm »

I think you've explained it!

It drives me nuts.  A client required a ProRes version of their movie.   Converted from DPX to ProRes on my Mac using Apple Color, but there was a gamma shift.  Had to correct for the shift and re-render in FCP.  The render took 30 hours...

But if you start in ProRes and stay in ProRes, everything stays ok :)
Logged
Bruce Alan Greene
www.brucealangreene.com

AvidVisionary

  • Guest
Re: Testings report
« Reply #2 on: May 15, 2011, 05:41:25 pm »

Are window user affected by this or any other problems with Adobe CS5?
Logged

Sareesh Sudhakaran

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 546
    • The Indie Farm
Re: Testings report
« Reply #3 on: May 16, 2011, 09:31:32 am »

These are not software issues but hardware issues. The best place to start learning about these things is the manual that comes with the grading software.
Logged
Get the Free Comprehensive Guide to Rigging ANY Camera - one guide to rig them all - DSLRs to the Arri Alexa.

AvidVisionary

  • Guest
Re: Testings report
« Reply #4 on: May 16, 2011, 05:36:37 pm »

He is speaking about codecs. How is this a hardware issue?
Logged

fredjeang

  • Guest
Re: Testings report
« Reply #5 on: May 16, 2011, 05:50:43 pm »

It is kind of both.

There are no issues if you stay in Mac from beginning to the end (although I'd like to see it with Adobe suite on Mac...let's see if it works on Adobe as it works on FCP, both on Mac of course)

but this is not possible always and even not desirable.

The problem is that there is a 444 codec that has not been developped to be 100% reliable on both platforms and that can only be generated from FCP. The codec is good, the politics behind sucks.

Commercially, yes, it was a masterpeice...
Logged

AvidVisionary

  • Guest
Re: Testings report
« Reply #6 on: May 16, 2011, 06:57:07 pm »

Codecs are software issues not hardware. So it's not kind of both.
Logged

fredjeang

  • Guest
Re: Testings report
« Reply #7 on: May 16, 2011, 07:32:21 pm »

Codecs are software issues not hardware. So it's not kind of both.
In absolute, I think you are right.
Those are software issues.

But there have always been certain difficulties for manufacturers to acheive total accuracy and compatibility between both systems.

The fact that DNxHD is very consistent regardless of the platform indicates that indeed we are talking about software issue.
But I'm an image guy and going deapper in computer engineering is not in my knowledge. I can't really infirm that there could not be also an hardware reason. I simply do not know.
Logged

AvidVisionary

  • Guest
Re: Testings report
« Reply #8 on: May 16, 2011, 08:36:37 pm »

I am computer engineer trying to learn images. Perhaps we can help each other.

From my experience regarding codecs;

Best editing format for both systems is no longer a format issue. Anything that is native to the editing programme will be supported without any problems. Video editing programmes do not like anything compressed. They are supported but you will have to render each time you modify the clip.
Logged

Sareesh Sudhakaran

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 546
    • The Indie Farm
Re: Testings report
« Reply #9 on: May 16, 2011, 11:59:39 pm »

My response was in regards to color only.

Every codec can maintain constant color because LUTs and gammas are already inbuilt into their coding. Transcoding for one to another does not affect color unless it has explicitly been changed by somebody who does not know what he/she is doing. You must understand and master LUTs, gamma and profiling inside out to control the color workflow.

The errors always take place on mis-calibrated hardware devices, especially when using monitors that are not meant for color grading - as in expensive consumer grade monitors from apple, dell, hp, etc. These monitors can be stretched to display the color space you want it to show, but the technologies are inherently not capable of reproducing the entire color gamut of various spaces.

Most minor post houses make do with these issues since the practical client/consumer cannot tell the difference. But for critical color grading, the codec is the last thing on anybody's mind. Color management is an art form unto itself. Keeping color consistent between Apple and PC systems spread across the world (different color spaces multiplied by different gamma settings) is the greatest challenge faced by a Post Production Supervisor. One must plan prior to shooting anything.

Regarding color shifts in ProRes - Apple never intends for a customer to switch between platforms. They make it as hard as possible. If I know I'll be dealing with data from different vendors, I'll stay clear of FCS completely. However, ProRes is a very able codec that can go toe to toe with anybody. But it's not the marrying type.
Logged
Get the Free Comprehensive Guide to Rigging ANY Camera - one guide to rig them all - DSLRs to the Arri Alexa.

fredjeang

  • Guest
Re: Testings report
« Reply #10 on: May 17, 2011, 06:43:27 am »

Thanks for your contributions guys.
Writing the OP I was hoping this thread could take this direction.

Some meditations on that matter.

I've been working in the last 2 years in a big pro photography structure surrownded by very high skilled professionals in all the chain.

In the past they had few videos assignments and of course delegated the all work to movie-video structures and the costs where huge.
Recently, the budgets stopped to allow this while there was a clear demand from clients, and not specially to make some videos on the fly as an extra, and we all did have to start to make videos without really knowing anything.

What was a highly trained stills structure, suddenly we appearted to be a complete amateur video mess. As TMARK pointed in another thread, Recuenco is a sort of exception in Madrid.

I understand that the video gurus, and specially the one used to work in high-end teams with heavy and expensive softwares and gear are looking at us with a mix of disdain an really thing that we can't or won't make it.
But in fact we do.

It is a lot of work, and almost everyday new chalenges, problems etc...are springing up, like this codec gamma shift for ex. That is the reason why I tend to write questions and questions in this forum part, and probably the video gurus who read them will thing, oh well...

But some are working seriously and I can tell you this: photographers will be very good at making videos. I've seen it. We had a producer mounths ago and they did not want to take any risks with us because they are perfectly aware that we are not mastering yet enough, so they charged a professional video team (very friendly guys by the way) to shoot with us and do the post-prod. Very expensive.

What I've seen is that they do not move and place cameras the same way, they tend to not understand the light and space as well as stills photographers or cinema guys. We compared the results and in terms of imagery itself understanding, grading, our team did a way better job, faster and cheaper. They did a more consistent job than us in the cutting and I understood why. Actually I learn a lot. They are very good at understanding How to match the cutting with the client need. They are more familiar on telling a story.
But they where completly amazed about what for ex, the boss and I could do with a Canon 5D2 and even APS in low-light and the resulting grading, just that they are some ways and tricks to acheive even a great raw footage that those video guys don't really understand either. In fact the collaboration between the 2 worlds is very profitable for everybody.

It is true that we are, I completly recognise it, in the middle of the learning, but I'm convinced that we are catching-up step by step and will probaly outperform in many ways with smaller structures.

Just a question of time, commitment and seriousness in the learning process.


  



« Last Edit: May 17, 2011, 07:40:53 am by fredjeang »
Logged

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
Re: Testings report
« Reply #11 on: May 19, 2011, 10:52:05 am »

Every codec can maintain constant color because LUTs and gammas are already inbuilt into their coding.
(...)
The errors always take place on mis-calibrated hardware devices
when exactly the same file on exactly the same monitor looks different when played back by different softwares ... then we have to deal with software issues (QT for instance) and/or codec issues.
Actually I'm with Fred here... DNxHD provides color consitancy in most applications while ProRes is more prone to show gamma shift or color shift or both ... depending on the application used for playback (or used for transcoding).
You sure should avoid to use QT for playback or for transcoding from/to different formats...
 
Logged

Sareesh Sudhakaran

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 546
    • The Indie Farm
Re: Testings report
« Reply #12 on: May 19, 2011, 11:06:23 pm »

If it looks different, it's not the same color space or gamma, is it?
Logged
Get the Free Comprehensive Guide to Rigging ANY Camera - one guide to rig them all - DSLRs to the Arri Alexa.

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
Re: Testings report
« Reply #13 on: May 20, 2011, 05:38:32 am »

If it looks different, it's not the same color space or gamma, is it?
no, the very same file, just viewed in different players.

See for instance a testchart (source: http://www.belle-nuit.com/testchart.html ) viewed in Avid, Nice Player, MPEG Streamclip and Quicktime.
Compare the values of TV white (RGB 235/235/235), TV black (RGB 16/16/16) and the bold color bars based on the the standard EBU testimage (varying RGB triples of 180 + 16).
Please note that some color values in these screenshots suffer from quantization errors due to JPG conversion… for instance you will see RGB 16/180/179 for Cyan but originally it was 16/180/180).
Also note: if you view the screenshots in Firefox with color management enabled sRGB will be assigned to the files… so all RGB values will be wrong. Better download the files, view them in Photoshop and check the color values in the info platte.

First the testchart based on a DNxHD movie clip:
viewed in Avid: all correct
viewed in Nice Player: all correct
viewed in MPEG STreamclip: all correct
viewed in Quicktime: all incorrect (too bright - this shows the infamous Quicktime Gamma shift)




I've transcoded the movie to ProRes (from Avid -> send to Quicktime -> ProRes HQ) and re-imported it into Avid.
Here's the result viewed in Avid (re-import on the left, original testchart on the right for reference).
On re-import the luminance range is still correct but colors are off:




How does the exported ProRes file looks like without re-import into Avid… i.e. directly viewed in other applications?
See here… all incorrect (except of the re-imported movie viewed in Avid top left with correct luminance range but incorrect colors):




« Last Edit: May 20, 2011, 06:05:06 am by tho_mas »
Logged

Sareesh Sudhakaran

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 546
    • The Indie Farm
Re: Testings report
« Reply #14 on: May 20, 2011, 10:08:34 am »

Couldn't see any of the pics due to some error. QT is known to change gamma within...one of the reasons I avoid it like the plague.
Logged
Get the Free Comprehensive Guide to Rigging ANY Camera - one guide to rig them all - DSLRs to the Arri Alexa.

fredjeang

  • Guest
Re: Testings report
« Reply #15 on: May 20, 2011, 12:24:02 pm »

I downloaded the chart and also did quick testings with the Autodesk and Avid on one and the same computer.

The first thing I see is never use QT for rendering between platforms!
Yes, to be avoided like the plague.

Incorrect colors
Incorrect Gamma unless corrected

The popular delivery codec H.264 generated from Avid is consistant, the same generated from QT pro with exactly the same settings is uncorrect to an extreme and even loose a lot of color range. Concretely it looses 3 stops DR just to start with that. This is not recuperable in Avid neither Autodesk, it is lost.

The testing tho-mas did with ProRes speaks by itself.

Some are saying all over the internet that the QT displays a wrong gamma, but that is not what I'm seeing and my question is, why it does not display ALSO a wrong gamma with DnxHD? Is it possible that it displays a wrong gamma on the proper Apple products?

tho-mas played a DNxHD in QT and experienced the gamma shift as his pics are showing. I exported a DNxHD in a QT container in 10bits mode and viwed on QT did not experienced the shift...it was 100% accurate from any viewer. This is mad!


I give-up. Those are things for engineers, not for me.
« Last Edit: May 20, 2011, 04:34:22 pm by fredjeang »
Logged

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
Re: Testings report
« Reply #16 on: May 20, 2011, 04:57:43 pm »

Some are saying all over the internet that the QT displays a wrong gamma, but that is not what I'm seeing and my question is, why it does not display ALSO a wrong gamma with DnxHD? Is it possible that it displays a wrong gamma on the proper Apple products?

tho-mas played a DNxHD in QT and experienced the gamma shift as his pics are showing. I exported a DNxHD in a QT container in 10bits mode and viwed on QT did not experienced the shift...it was 100% accurate from any viewer
when your display is calibrated to Gamma 1.8 Quicktime will show the correct Colors and Liminance Range (with DNxHD). But Gamma 1.8 is a bit uncommon for video production...
« Last Edit: May 20, 2011, 05:05:33 pm by tho_mas »
Logged

fredjeang

  • Guest
Re: Testings report
« Reply #17 on: May 20, 2011, 05:13:20 pm »

when your display is calibrated to Gamma 1.8 Quicktime will show the correct Colors and Liminance Range (with DNxHD). But Gamma 1.8 is a bit uncommon for video production...

Yes, but it results that my display is calibrated at 2.2.

Could it be then that the fact that it is a 10bits DNxHD has a consequence?

Normally Gamma should not affect the black and white levels but the greys. So if your black point is 6 it should stays at 6.

This is why I find this Apple bug extremely strange and annoying. Not surprise that it does even put the mess on the prod gurus.
« Last Edit: May 20, 2011, 05:17:47 pm by fredjeang »
Logged

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
Re: Testings report
« Reply #18 on: May 20, 2011, 05:16:56 pm »

Yes, but it results that my display is calibrated at 2.2.

Could it be then that the fact that it is a 10bits DNxHD has a consequence?
no, my files were 10bit too.
Maybe you have the extension in Quicktime's preferences enabling a Gamma 2.2 switch (AFAIK it comes with FC Studio, but am not sure).
Logged

fredjeang

  • Guest
Re: Testings report
« Reply #19 on: May 20, 2011, 05:24:30 pm »

no, my files were 10bit too.
Maybe you have the extension in Quicktime's preferences enabling a Gamma 2.2 switch (AFAIK it comes with FC Studio, but am not sure).

Oh, I forgot to mentionned, I exported in 709, not rgb from Avid.
Logged
Pages: [1] 2   Go Up