News

News

Adobe Creative Cloud and U.S. Navy


We had the chance to work with the U.S. Navy as a media consultant. During the project we tested many applications and workflows. Our challenge was to decide which base frameworks and tools to start integrating behind the Navy firewall so that eventually they can scale up and build larger enterprise grade solutions for their productions. Be it small apps, hooks, API’s, content sharing archiving etc. We decided Adobe was a good fit. We tested some projects from end to end working as much as we could with Adobe Creative Cloud tools. What we liked was the flexibility. If Adobe made the best tool for the job we used it. If we had a more custom solution Adobe allowed us to work around it well enough to make a workflow seem integrated as one solution rather than a tool box of disjointed applications.

What’s in an app?

It was only a few years ago when a developer friend of mine stood over my desk and yelled out “why do people keep using this word app”. My friend was simply perplexed by the idea that people where just realizing that “apps” exist. After all we had been writing software applications and managing content via a client/server relationship since we could remember. We had grown up in a world where our parents had set us up on terminals and given us books of code to copy over with the promise that in the end we would have a game to play. By the time we where in middle school it was clear to us that an “app” was just a piece of software. We did not even call it an “app" then. I think we just called it software or a program.
So when apple products like the iPhone became so popular and they opened development to third parties, all of a sudden the whole world was walking around talking about apps. My pal was literally confused as to why clients would come in and ask for “this new thing called and app”. What new thing? You mean the same thing we had been doing for 10 years but for a different OS?
It was at this point I instinctively tried to rationalize out what an “app” was so I could help define what the client was really asking for. I told him “I think they simply want software and that apple pretty much branded the word “app” to be the universal word for lightweight software that could make using our devices easier to end users. Nobody would want to say that long sentence out loud so they just say app”. I don’t think he got it and we just went on with the day.
Fast forwarded years and of course this same pal that was so perplexed is using multiple devices and downloading “apps” like a maniac. It’s become “normal” now and he even uses the word “app”.
I remembered this little convo while looking over the requirements for current “app” project I am reviewing. It made me realize how far we have come and how fast. Looking down at my desk I realized what where creating was much bigger then what the word “app” started out as. I think “app” started out as meaning lightweight software that allowed the end users to access the features of their devices in a user-friendly way. A way for non-technical people to use technical hardware and software. Really it was a brilliant idea. But by no means a new idea and not something apple invented. “Apps” have always been made with the above-mentioned intent. This was just and instance of doing it on these new smaller computers/devices. However once the consumer market caught on to using these “apps" they brought it into their office with them. So slowly the consumers are walking into their corporate jobs with iPhones and showing everyone how wonderful they are. Then it was just a matter of time before “management” realized that in order to keep their job they probably get their business on the app train. So they did. Now what these clients ask for as an “app” could mean much more than a lightweight software. It could be complex management systems that include tons of data relationships, storage pools, load balancing, real-time communications, event triggering etc. These clients are asking for full-blown system development yet they still ask us how the “app” is coming along like they are ordering it up from the menu.
So we take away from this that it’s important when clients ask for product that they are aware of what they are asking for. Sometimes we have to push to get this into words. At Splice we are going to ask a lot of questions to our end -users and clients about what they are doing and why they want this “app”. This is to try and push out of them their bigger thoughts and ideas. We want them to make bigger “apps”, but sometimes we have to push the end-user’s imagination to make the ideas bigger. Bigger ideas and bigger “apps”.

The ProRes Issue

It’s no surprise to anyone working in post these last few years that ProRes has become a standard working codec in the process. That being said I still demand 10 bit uncompressed files or image sequences as masters. The issues with ProRes and its famous “gamma shift” magic is just way too much of a liability to overlook. The issue is that ProRes is just not stable in terms of knowing for sure that the file you send or receive is in fact the file you intend to send or receive. After much review of this color shift it seems that not only is it annoying but no method to this madness exists. Even after several years of working with it I still find issues even today with new applications. If you are not familiar with this issue let me give an example of how this can become a real problem. Let’s say I have a an editor who has a section of an edit and wants to start some color grading test (yes we do test stuff). They want to start setting a look for a part of the edit as they are about to enter the picture lock phase and we are getting ready for grading. So the editor encodes a section of the timeline as ProRes and sends the file over. Now the colorist picks up that file and brings it into DaVinci, sends to scene cut detection and starts applying a look. Saves some LUT’s/ setting for when it gets time to online and grade this for real. Everyone is happy so far. Then the editor send that treated file out to the vfx folks who are about to apply some effects. The vfx guys use the color graded version to get a sense of where the shot is going. So said VFX folks do their thing. Everyone loves how this project is coming along.

Well the editor goes back to editing for a few weeks and the rest of the team hear nothing as they approach picture lock (directors can never stop cutting). Finally they lock and bring the xmls, Edl’s whatever back to the grade. We start applying the color setting we went over in the past. But wait nothing is looking like our test? The VFX guys are calling and they are saying that the comps they made are not looking correct with the final locked files. What the heck is going on? We already did all this testing earlier to make sure we would not be rushed on deadlines in the finish. But nothing is looking as it did during our test? What happened?

You see the editor was working on clips transcoded from whatever to ProRes when they started editing and they want to do a ProRes workflow thru color grading (not my thing but eh ok). The ProRes files that where transcoded for edit looked one way but when the editor made that export of a section of the edit, the gamma actually shifted. Since the VFX and colorist just thought this was shot poorly and had not seen the actual raw footage they just went ahead setting looks on what they were given. However the editor exported the files in an incorrect manner (and it’s more Quicktimes fault then the editor). So now all that work the colorist and VFX did is all wasted time and they essentially have to start that process all over. Wasting time, wasting money, and making everyone nervous about hitting the output deadline.

I test every workflow from top to bottom twice before putting it into play. However I have seen the issue in testing phases. I have seen this kind of stuff happening around me on an almost regular basis. Way to regular to even consider ProRes as a mastering codec. In fact when I hear ProRes my brow usually raises. My rant is simply to restate my belief that you must test workflows A LOT. Find out what platforms, software and pipeline the team is going to use from start to finish and test moving the files down the pipe. Do it twice. And when a situation occurs outside the scope of the initial testing, test again. ProRes is inconsistent. Some applications shift it, Some do not. Some even shift the color on simple transcoding. Thing is that it may look ok on one platform but not on another. It’s all over the place. Lately I have been using DNxHD as my middle ground file over ProRes and I find a lot less issues. Even better DPX, but for smaller projects sometimes that can cause a world of hurt for the offline editor. For TV mastering I’m still into 10 bit uncompressed or DNx these days.

I test every workflow from top to bottom twice before putting it into play. However I have seen the issue in testing phases. I have seen this kind of stuff happening around me on an almost regular basis. Way to regular to even consider ProRes as a mastering codec. In fact when I hear ProRes my brow usually raises. My rant is simply to restate my belief that you must test workflows A LOT. Find out what platforms, software and pipeline the team is going to use from start to finish and test moving the files down the pipe. Do it twice. And when a situation occurs outside the scope of the initial testing, test again. ProRes is inconsistent. Some applications shift it, Some do not. Some even shift the color on simple transcoding. Thing is that it may look ok on one platform but not on another. It’s all over the place. Lately I have been using DNxHD as my middle ground file over ProRes and I find a lot less issues. Even better DPX, but for smaller projects sometimes that can cause a world of hurt for the offline editor. For TV mastering I’m still into 10 bit uncompressed or DNx these days.

Pages