If you’ve been using Blender for years, brushing through 2.x and 4.x versions and checking for that “next big thing”, here it is. The Blender Foundation today published Blender 5.0, marking not just a point-update but a clearly defined production ready milestone. Find the official announcement here: https://www.blender.org/press/blender-5-0-release/

Blender 5.0 introduces full support for the ACES workflow (Academy Colour Encoding System), enabling a more accurate and unified colour management system across pipelines. The release also brings HDR (High Dynamic Range) support, allowing for consistent high-fidelity colour reproduction on modern displays and rendering workflows.

Handling of large-scale geometry has been improved significantly. The software can now manage much larger .blend files and assets containing millions of vertices without becoming unstable or unresponsive. This directly benefits studios handling detailed scans, simulation caches, or complex game-ready environments.

Rendering also receives notable refinements. There are new passes such as the Render Time Pass and Portal Depth Light Pass, and the OptiX Denoiser (for NVIDIA GPUs) now produces cleaner and more stable results, improving overall render efficiency. The UI and workflow have been tightened up as well. Drag-and-drop now feels smoother, the Outliner behaves more predictably, and widget styles have been unified for better readability. The Video Sequencer gains a useful improvement: using Shift + A now places a new strip directly under the mouse cursor, a small but meaningful quality-of-life fix for editors.

One caveat: Blender 5.0 introduces breaking changes that affect file compatibility. Projects saved in version 5.0 may not open properly in earlier 4.x versions. This should be considered before committing ongoing production work to the new version.

Grease Pencil

In Blender 5.0 the Grease Pencil toolset receives a new “Pen” tool in Edit Mode, which behaves similarly to the legacy curves pen tool, allowing more direct stroke-editing of Grease Pencil generated geometry. In addition, changes such as improved cyclic-stroke handling (start and end segments now connect without overlaps or gaps) are documented, improving reliability for looped 2D/3D hybrid animations.

Compositing

The compositor in Blender 5.0 sees enhancements aimed at more efficient node-based workflows. For instance, new nodes like Chromatic Aberration (simulating lens fringing) and Sensor Noise have been added. Also worth noting: the addition of an Asset Shelf in the node editor enables reuse of node groups across files, facilitating more modular compositing setups.

Geometry Nodes

Blender 5.0 significantly expands the capabilities of the Geometry Nodes system. A new volume grid data type is supported, enabling volumetric workflows in procedural layouts (via OpenVDB grids) rather than converting to mesh forms. It also introduces SDF-Grid Laplacian and SDF-Grid Median nodes to process signed distance fields for curvature flow and noise reduction within SDF data sets.

Cycles

The rendering engine Cycles in Blender 5.0 receives updates such as a new default volume rendering algorithm based on “null scattering” which reduces artefacts in overlapping volumes and simplifies parameter tuning. cSupport for thin-film iridescence in the Metallic BSDF shader and improvements in subsurface scattering (SSS) via the Random Walk model are also included.

Video Editing (Sequencer)

In the Video Sequencer module of Blender 5.0 there is now the ability to apply compositing node trees directly inside the Sequencer via a ‘Compositor modifier’, allowing editors and motion-graphics artists to work within a unified timeline rather than switching contexts. General timeline behaviour improvements and UI refinements accompany this feature, though documentation of major new video-editing specific nodes remains minimal.

Production Tips & Caveats

For anyone planning to introduce Blender 5.0 into a studio or pipeline environment, caution and preparation remain essential. It is strongly recommended to first test 5.0 on non-critical projects to assess stability and compatibility with existing tools. Large pipelines have complex dependencies, and even minor version changes can lead to unexpected issues in rendering, scripting, or I/O.

Before migrating, verify that essential add-ons and Python scripts are compatible with the new version. Major releases often introduce API changes that can break automation tools or extensions. Keeping a parallel installation of the previous stable version (such as 4.5 LTS) ensures that ongoing projects remain safe while the team evaluates the upgrade. While the release notes provide strong technical documentation, it has not been independently verified at press time how stable every new feature performs under heavy production workloads. Testing before adoption in live projects is essential.

Final Thoughts

After years of steady iteration, Blender 5.0 feels like a landmark release. It brings the open-source 3D suite closer to the needs of real production environments, not through flashy gimmicks but through practical improvements: robust colour workflows, more reliable geometry handling, and thoughtful interface refinements.

For anyone who has been with Blender since the endless 2.x days, this version might be the moment it finally explodes. If your pipeline can handle a test migration, now is a good time to download, install, and see what Blender 5.0 can actually do for your studio.

Blender 5.0 Beta!

Blender 4.5 LTS lands

Blender 5.0 hits release candidate!

Blender user survey 2025 – time to tell the team what you really think

The post Blender 5.0 – it’s here! first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Node Mill profiles vintage cine and photo lenses by capturing their optical characteristics under controlled conditions, then encodes those traits—coma, bloom, distortion, chromatic aberration, bokeh shape, vignette, color cast, fringing—into pixel‑accurate OpenFX presets. This goes beyond generic film or diffusion emulation; it reproduces measured distortions and hue shifts, not just a soft blur.

Mix‑and‑Match and “Overdrive” Controls

LensNode provides standalone controls for each optical effect and allows users to combine traits from different lenses in one chain—like Canon FD geometry with Helios coma and Voigtländer color cast. A global “Overdrive” slider exaggerates effects for stylized looks, all animatable via DaVinci Resolve’s timeline.

Swirly Bokeh + Depth‑Aware Application

The plugin models individual lens bokeh and allows rotation before convolution. It supports swirly bokeh even for lenses without it originally. LensNode can also use depth maps as input, and includes a built-in lens profile blur map captured from focus chart measurements—addressing edge blur and focus fall‑off dynamically.

High‑Performance GPU + ACES‑Friendly

LensNode runs fully GPU‑accelerated with optimization options for high‑res footage. Reports indicate real‑time playback at 8K on an NVIDIA RTX 3080 with multiple nodes applied. Its linear‑space processing supports ACES pipelines, camera‑log inputs, and high‑bit‑depth deliverables.

Platform Support and Licensing

LensNode is currently available for DaVinci Resolve 18.6+ on macOS 14+ (Metal 3 support) and Windows 10/11 (CUDA GPU required). Linux and other editing platforms are not supported yet.

Early Access licenses cost USD 99—perpetual with two seats (macOS + Windows), free updates through version 1.0 (expected mid‑2025), plus one year of further updates. No trial exists during Early Access. Purchasing and license management is handled via LemonSqueezy.

Lens Library Today — and Roadmap

As of April 2025, the profile library includes lenses such as the Asahi Super Takumar 20 mm f/4.5, Voigtländer Nokton 40 mm f/1.4, Canon nFD 50 mm f/1.4, Helios 44‑2 58 mm f/2.0, and five focal lengths of LOMO Illumina MK1 S35 (with full‑frame variants). More cine glass, including Cooke S4, is planned soon.

Technical and Production Considerations

LensNode may appear more subtle at 4K compared to 1080p, due to resolution scaling behavior. Its developers note optimal quality when applied at full 4K resolution and recommend adding LensNode at final stages. Occasional crashes have been reported—responsible GPU configuration (for example, macOS Metal mode) and early Access debugging are advised.

Final Assessment for Pros

LensNode offers a novel, data‑driven means of introducing vintage lens signatures into post, with granular control, GPU acceleration, and sophisticated optical profiling. It suits projects needing optical matching without vintage glass, stylized video work, VFX lens continuity, or experimental grading. But performance varies, and it is not a substitute for physical lens behavior in all cases. Production users should test LensNode under realistic timelines and processing environments before full integration. Its Early Access status calls for caution in critical pipeline deployment.

Node Mill LensNode

The post LensNode Evolving Vintage Lens Emulation in DaVinci Resolve first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

by Levin Müller-Holste

In the fourth semester of my bachelor’s degree in Media Design at Ostfalia University in Salzgitter, I was allowed to choose a specialisation subject and an associated project. The following project was to focus entirely on this area and be completed over two semesters. I quickly decided to create a homage to the Japanese film “Castle in the Sky”(is.gd/castle_in_the_sky). I wanted to experience the feeling of scrutinising such a great production. It was released in 1986 and, like many of the Studio Ghibli productions, is a 2D film. So I was tempted to convert this 2D film into a 3D version and bring my own style to it.

The story

Castle in the Sky is about a flying island called Laputa. According to legends, there are riches and technologies on this island. However, it has so far remained hidden from humans, which is why various parties have made it their goal to find it.

As I was of course aware that I wouldn’t be able to make the whole film in 3D, I first asked myself the following questions: What do I want to show? The island of Laputa is the most important part of the film and, in my opinion, also the most beautiful. The island initially has a peaceful, quiet and deserted atmosphere. Technology and nature live in harmony with each other, which is particularly evident in the robot that lives on the island. Among other things, it is there to look after nature. The longer you spend on Laputa in the film, the more mysterious it becomes and secrets are gradually uncovered that lie beneath the surface of the island. The focus of the project should therefore be specifically on the island.

The result is a journey through the different parts of the action, with the main focus being diverted away from the characters. I deliberately left them out because I only wanted to focus on the appearance of Laputa to convey the feeling of what it might be like to be there. I have emphasised individual elements, such as a plaque with an inscription or the aforementioned robot.

The process

In the fourth semester, I started by analysing the film. I took a close look at the important scenes on the island and picked out some favourites that I could imagine implementing. I used PureRef (pureref.com) for all the thoughts, images and information I collected. My first storyboard was created there. At the same time, I created an animatic in After Effects and added my first music. This gave me an idea of how long the various shots would be. This was changed again and again during the fourth semester, shots were shortened, lengthened or exchanged. A few of the shots were already firmly anchored in my storyboard after watching and analysing the film for the first time and I couldn’t imagine life without them. So as not to end up with scenes in 3D for nothing, I started with the realisation of the shots that were already certain. This meant that the process and working on the scenes was a bit of a mess, but I didn’t waste any time.

The realisation was done on my own setup – my PC is equipped with an RTX 3070, 32 GB RAM and an AMD Ryzen 7 3700X. This allowed me to edit and render all programmes and the wealth of geometry and textures well. I rendered the project in 1920 × 1080, with most frames taking an average of 12 minutes to render. The realisation was mainly done in Cinema4D. At the beginning of the fourth semester, I also set myself the goal of learning ZBrush and Substance Painter. I was able to integrate the two programmes very well into my workflow.

Modelling

In order to achieve a satisfactory result, I wanted to model all the objects myself. Apart from the plants and the grass, which I scattered, I modelled all the objects myself. The blockout for all objects was first created in Cinema4D, then I imported the models into ZBrush, where I always used the ZRemesher. Then the details were sculpted. For example, the robot was given lots of small dents and bumps.

It was important to me not to have a clean CG look, but to embellish the scenes with lots of small details. As soon as I was happy with the sculpting, I went to the dynameshen, created a high poly and a low poly version and added UVs to the low poly version. For this I used the tool RizomUV, which specialises in creating UVs, so it was much quicker for me than using Cinema4D. Here you can see the whole process, with the individual steps, up to the finished image. For some scenes, I even traced the original font from the film in Illustrator so that I could work close to the original.

With the UVs created, I then went to Substance Painter. There I loaded in the low poly version and baked the high poly version. This gave me the lowest number of polygons and still the high poly details. I used a mixture of smart materials, self-created procedural materials and hand-drawn masks. I wanted each model to have its own story.

Small cracks, wear and tear, dirt and dust decorate all objects that have been on Laputa for a long time. I mostly exported the textures in 4K, for close-up shots in 8K. They were imported into Cinema4D, where I used Redshift to set up the shaders and decorate all the objects. Of course, it wasn’t important to use Substance Painter for all objects in all scenes, so I also created some material using Redshift’s classic node system.

Lighting

The most exciting, fun and challenging part for me is the lighting. In my work, I specifically focus on the light and the mood it creates. My renderer of choice is Redshift. However, as Redshift is a biased renderer, unlike Octane, it is a little more difficult to create beautiful and realistic lighting settings. It’s always a challenge for me and I try to create a nice contrast between light and shadow and generate a focal point.

What stands out in the scenes and where is the focus? The look should be dreamy and take into account both the real scenes in the film and my own ideas. I try to get as close as possible to my idea of the final image in Cinema4D so that I don’t have to do a lot of compositing work. The scenes are mainly equipped with area lights, whereby the outdoor scenes were still equipped with dome lights together with an HDRI map and a sun & sky rig. With the area lights, I work with colour settings instead of temperature, as this makes it easier for me to get small colour accents in the light. An important point to achieve a realistic look is that I never set my lights to 100 per cent white, as nothing is 100 per cent white in reality either. These are the little details that make the difference for me in the end.

For the fourth shot, the panel between the trees, I also used an animated gobo texture to accommodate a tree moving in the wind in the shadow. Volumes were also an essential part of the lighting. This gave me a more realistic look in the exterior scenes and a mysterious mood for the underground scenes. This created the dramatic mood in the final shot, for example, where the robot’s red lights come on.

To really capture the mood, I kept creating different style frames until I got the result I wanted. By experimenting a lot with light, I gradually got a better idea of what my scenes were missing and how best to light them.

Rendering

For rendering, I gradually adjusted all the render settings in all the scenes individually in order to achieve a good result between images without noise, but also shorter render times. As all my scenes generated a lot of noise due to many lights, depth of field, motion blur and volumes, I decided in the end to use a denoiser built into Redshift. All frames were output as EXR files and, in addition to the AOV passes, I also used the ACES workflow, which was still new at the time.

This means that I output all frames as linear EXR images in order to assemble and grade them in After Effects. With the ACES colour spectrum, the highs didn’t burn out so quickly during post-processing and the lows didn’t turn the darkest black so quickly. With Puzzlematte Passes, I was also able to rework individual elements and place a special focus on them.

Compositing

In After Effects, I put all the EXR files together and was able to edit individual AOV passes. I often reworked and emphasised Volume, Specular Light and Reflection Passes in particular. All the scenes were given an adjustment layer on which I adjusted the curves a little to achieve even more contrast. I increased the bloom effect in individual scenes, such as the stone that keeps lighting up.

I added a chromatic aberration effect and a noise overlay to give it a slightly more cinematic look. That’s right, I rendered the scenes with a denoiser to add noise again later. But only because the added noise is more like the noise you get when shooting with a real camera. I also used small dust particles as an overlay so that I could get a bit closer to the retro images of the original.

I didn’t do much in the way of colour grading, mostly just adding a little more saturation. As 90 per cent of the result was already created in Cinema4D and Redshift, only minimal adjustments are necessary – but these are known to make a difference and ensure that the most beautiful image is achieved.

Sound design

As the sound is at least as important as the image, I teamed up with sound designer Jürgen Branz very early on in the process, who developed the entire sound for the project. We wanted to support the visual aspects with appropriate sounds. The individual shots needed to have harmonious and mysterious tones to convey the feeling of being on the island of Laputa and experiencing what was being shown. In my process, I kept sending Jürgen new animatics so that he could adapt the sound to the images and movements, and he kept sending me sound sketches until we were both happy with the result. It was a nice collaboration and I gave him as much freedom as possible because I knew it would be a great result anyway.

Iterations

At the beginning of my fourth semester in April 2022 the project started and at the end of the fifth semester in December 2022 I was finished. My professor Melanie Beisswenger actively supported me throughout the entire time. We talked about the status of the project at short intervals and she gave me tips in all areas.

From creating the first animatic to look development, lighting, texturing and animation. I received valuable help from her in every area and without this help the project would only have been half as good. I reworked some scenes five or six times, but it was worth it.

Conclusion

In conclusion, I really enjoyed the project and I am grateful to have been able to deal with it in such depth over two semesters. I learnt a lot as it was my first big 3D project. I realised how important organisation and a proper file structure are – although it is precisely these points that I would do differently if I had to start again
start again. Saving all the scenes, textures, models etc. properly and working with a proper naming system would probably have saved me a lot of time. I am grateful to have been able to work with Professor Melanie Beisswenger and sound designer Jürgen Branz. As professionals in their field, they helped me a lot.

As I also have my Bachelor’s thesis coming up very soon, I’m going to dedicate myself again to a somewhat larger animated film with its own story and use all the experience I’ve gained to achieve an even better result. I share my journey in the 3D world on Instagram (@levin.mh), Behance (@levinmh) and Vimeo (vimeo.com/levinmh) and you can watch my animation “A Tribute to Castle in the Sky” there. Jürgen Branz can be found at (@juergenbranz) on Instagram and on his website (juergenbranz.de).

Studying at the Ostfalia

With around 12,500 students, Ostfalia University is one of the largest universities of applied sciences in Lower Saxony. It offers more than 90 degree programmes in the fields of law, economics, social and health care as well as engineering and computer science at 4 locations. The Faculty of Transport, Sports, Tourism and Media in Salzgitter has around 2000 students. Ostfalia University is a state university, so there are no tuition fees (except for long-term tuition fees if the student account is exhausted). There is a re-registration fee of currently 330 euros per semester, which also includes the semester ticket for local public transport.

Media Design!
The Media Design degree programme is offered with a Bachelor’s (6 semesters) or Master’s degree (4 semesters). You can specialise in animation, VFX, games, interactive media, film or communication design. In the field of animation, students are taught to work with various techniques: from starting with stop motion, 2D animation, motion design, 3D animation and character animation. In addition to technical skills, the focus is on conception and visual development, as well as working on your own ideas and projects. Ostfalia is equipped with all kinds of state-of-the-art technology: Motion capture system from Rokoko, large film studio with blue and green screen, professional camera and lighting equipment, 3D printer, VR & AR headsets (Quest 2, Hololens, HTC Vive Pro), several computer pools that can also be used for rendering, photo studio, games club with appropriate equipment.

Who would like to take part
The application with the artistic portfolio and passing the aptitude test are the prerequisites for admission to the Media Design (BA) programme. Prospective Master’s students with a BA degree in design do not need a portfolio to apply.

More information: mediendesign-studium.ostfalia.de
Bachelor of Media Design: www.ostfalia.de/cms/de/k/mdba/
Master’s in Media Design: www.ostfalia.de/cms/de/k/mdma/

The post Castle In The Sky Hommage first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

This story, like so many others in recent times, starts at the beginning of the coronavirus crisis. You sit in lockdown and start to think about how you actually came to be a 3D artist. It definitely has something to do with the joy of technology and discovering it through play. So it’s not hard to take this thought further and think about the first computer that set you on this path. Of course, your neighbour’s Commodore 64 and your own 80386 computer with Windows 3.11 come to mind. But there was something else before all the big computers: the Gameboy. Even if it wasn’t powerful and purpose-built, it could undoubtedly be categorised as a computer. And so it’s fair to conclude that I learnt about my love of computers with the Gameboy.

A passion that ultimately led me to my profession. And so the ball started rolling on what was to become a 1 ½ month full-time project called “Loveletter” – namely to transform my old Gameboy Classic, purchased around 1994, into a digital asset to the best of my knowledge and belief and to use it to create both a series of photorealistic still images and a video animation in which the advertising aesthetics of today’s productions were to merge with the retro charm of the Gameboy in one animation. If you want to see the animation right away, you can find it here: https://youtu.be/b3QPdj1l_BQ.

The toolbox

Cinema 4D was used as the 3D hub for most of the tasks and Octane as the render engine. Perhaps somewhat unusually, I used Illustrator as a texturing tool, which was mainly used for the circuit boards and labelling in combination with Photoshop. After Effects was then used for compositing and the finishing touches – also for the stills. To render the finished 3D scenes, I used my own small render farm for Octane: a workstation with two RTX 3090 FEs and two additional clients with a total of five GTX 1080 TIs and two GTX 980 TIs.

And then it renders ..

Naturally, different render times were required for different stills in different resolutions. The rendering of the main still in 8K, which shows the disassembled Gameboy Classic and the Gameboy Clear, took around 2.5 hours on the hardware mentioned above (workstation and clients). Other still renderings in 4K and 6K varied from 15 minutes (single boards) to 1.5 hours (e.g. Clear Gameboy on blue cutting mat).

The situation was similar for video rendered in 4K. Render times here varied greatly depending on the distance and viewing angle of the Gameboy. This resulted in render times of 15 minutes for the wide shots and up to 90 minutes per frame for close-ups with a lot of depth and motion blur. Since 1,150 frames had to be rendered, a rendering service like Otoy’s RNDR came in handy. Otoy kindly sponsored the rendering in return for a promotion of the finished project on their site.

The render times may seem long overall, but almost all renderings include the transparent Gameboy, where all internal parts are visible through a milky transparent outer shell. These inner parts consist of multi-layered translucent materials of the circuit boards, coupled with an enormous beam depth of 32 bounces, which is necessary for a realistic representation of these nested translucent objects – the rendering time is quickly put into perspective.

Workflow!

The great thing about a private project like this is that you have to work your way through many disciplines of everyday 3D work to reach your goal, and there is always the potential to learn something new and push your limits. That’s why it’s also important for me to intersperse my own productions with commercial projects. Precisely because the learning potential is immense with these. For example, this was the first major project in the ACES colour space, which allowed me to test my pipeline for future productions in this colour space.

Production preparation

In preparation, the now almost 30-year-old Gameboy had to be dismantled into its individual parts in order to get an idea of the complexity of the inner workings and the shells. Equipped with a camera and macro lens, the individual parts were photographed frontally in all orientations. The Gameboy remained disassembled into its individual parts throughout the entire project. Even with good reference pictures, it is better to have the original at hand here and there to be able to check in detail in case of doubt. The calliper gauge was also always to hand so that I could take precise measurements of the parts, from gap dimensions to the thickness of the battery holder spring.

Modelling

Due to the many curves and the plan to make the Gameboy transparent later on, two different modelling techniques were used. Subdivision surface modelling was used for the shell of the Gameboy. This was done for two main reasons: Firstly, a (well-modelled) subdivision surface has a very clean edge flow that follows the topology and therefore provides a good basis for generating vertex maps that follow the surface structure. These vertex maps are required for the partially procedural texturing workflow later in the creation process.

On the other hand, the resolution of the mesh of SDS models can be increased to such an extent that super close-ups of the gameboy can also be rendered. This avoids render artefacts that tend to creep in with close-ups of (transparent) objects that are too small and kill realism.
For the circuit boards and their elements, a decision was made between box modelling and the SDS approach for each component. The advantage of box modelling as opposed to SDS is that it saves a lot of working time. However, once the modelling work has been completed, you are rather limited in terms of both resolution and the allocation of vertex maps. Equipped with everything necessary, the modelling could now begin.

The strategy was: “From the outside in”, which preceded the modelling of the shells.
The first impression “It’s just a cuboid, it’ll be quick” was shattered in the first few moments: even if you had wanted to model the Gameboy without the inner workings, parts such as the iconic bevelled speaker, the game slot opening, the numerous cut-outs for rotary controls and plugs as well as the ribbing on the back represent a not inconsiderable modelling effort. However, as the complete modelling of the product was being planned, the entire inner workings of the shells were added here, which included, for example, the holding devices for the total of 4 circuit boards, the loudspeaker and much more.

In addition to paying attention to the details, it quickly became clear how memorable the design language of the handheld computer was after many hours of play. So much so that the slightest mismeasurement of a few curves made the first shell model look like an imitation. You could certainly recognise the Gameboy, but it wasn’t quite “real”. As the focus was on the best possible representation, considerable parts of the shell had to be remodelled and merged with existing parts in order to get the shapes to fit exactly. In the end, the modelling time for the shells amounted to just over two weeks of daily work.

Luckily, the modelling of the circuit boards turned out to be somewhat easier – but only to cause a lot of work in the later texturing step. As the circuit boards are pure surfaces with a few holes, box modelling with some Boolean operations was used. These were later converted in order to avoid possible problems such as flickering during animations caused by an unstable bool.

For the board elements such as the capacitors, resistors, transistors etc., SDS modelling was mostly used again in order to be able to adapt them variably to the camera distance in the mesh subdivision, as with the shell.

Only more complex components such as the routing of the on/off switch and the Ext. connector, which is very similar in design to USB, were realised as box modelling in order to save time. If you were careful enough when modelling, you could use two bevel modifiers to round off sharp edges. As these are modifiers, it was also possible to subsequently intervene in the number of subdivisions and thus adapt them to the camera distance. Only the creation of (usable) vertex maps was not possible in this way, and so no shader control via vertex maps could be planned here, as with the shell. As the same components were used again and again, especially on the PCB, instancing was used here. This is a resource-saving method, as an object is referenced here and therefore only needs to be present once in the memory.

In the case of varying objects such as the capacitors, which differ in the flexibility of their legs, several versions were modelled, which were then instantiated as diversely as possible to avoid visible repetitions.

Texturing & shading

A semi-procedural workflow developed over the years was used for shading most of the components. The goal of the workflow is to create materials that can be assigned to an object without predominant UVs and look similar in quality to a texture created in a texture authoring programme such as Substance Designer specifically for a UV-unwrapped object. Why this workflow? Two words: resources and time saving.

Due to the often limited resources of a GPU, it makes sense to be as economical as possible, especially for larger productions. In addition to dense meshes, textures in particular eat up a lot of the precious VRAM (the memory of the graphics card). Texture authoring programmes usually rely on a PBR workflow (Physically Based Rendering), which describes the entire information of a shader in at least 4 bitmap textures. This results in at least one diffuse/albedo, roughness, metalness and normal map per material.

Depending on the material, further bitmaps such as Emission, Scattering, Reflectivity or Transparency are then added. If you want to get close to the shaded object with the camera without losing resolution, you have to create these bitmaps in 4K or 8K. The workflow also requires rolled-out UVs of all parts to be textured, which can be very time-consuming. In addition, the shaders with all linked textures can only be used for one object. Other objects require their own textures for their existing UV sets. This can very quickly degenerate into a large number of memory-gobbling 4K and 8K bitmaps that have to be juggled in a wide variety of materials.

The advantages of a partially procedural material are utilised here, which can be assigned object-independently and achieves the same fidelity as its resource-consuming PBR-based counterpart through more complex circuits in the node tree. To ensure this quality, two vertex maps are used per object to generate a modularity of the shader that is adapted to the object surface. A total of two vertex maps: one for convex areas of the surface, the other for concave areas. This makes it possible, for example, to generate worn areas on the convex areas, while light dirt deposits in the cracks are created by the concave map. These vertex maps were created manually for all SDS-modelled objects. This took some time. With the help of the edge and loop selection tools in C4D, however, this was rather easy. However, a selection option where you can select convex or concave edges using Phong Breaks would have significantly accelerated the process.

A little consultation with the programmer of C4D-Octane, the Cinema 4D Octane bridge, Ahmet Oktar, also simplified the workflow immensely by creating a new option for integrating vertex maps into a texture using a text string. This meant that only the vertex map name had to match the text field of the attribute text node in order to get the data into the shader.

This was much more flexible and quicker to handle than the previous method of linking specific vertex maps in the shader. Objects could now also be moved to other scenes without breaking any links. If the name could be found in a vertex map, it was automatically recognised in the shader and loaded for the respective object.

Of course, there would also be other variants such as Dirt to obtain convex and concave masks for the shaders. The advantage would have been that these dirt maps are generated completely procedurally without any manual intervention. The disadvantage, however, lies on the one hand in the increased rendering time that the additional ray tracing of the ambient occlusion entails, and on the other hand in the fact that the user has virtually no way of intervening if, for example, he wants to have an abrasion or dirt in a place where there is no curve and therefore no dirt mask. So one thing led to another and the working method and concept of the now frequently used semi-procedural workflow was born.
Tileable 2K dirt and scratch maps were used as textures, which could be mapped seamlessly onto the objects thanks to triplanar projection.

In order to give adjacent objects, such as the chips and capacitors, some variance in texturing, a specially written OSL script (Open Shading Language) was used, which can move, scale and rotate the texture projection per object in a user-defined way.

This prevents the same projection on frequently occurring objects. For the objects that were created with box modelling and bevel deformers, shaders without vertex map switching were used. Using these methods, a library of materials could be built up for many parts of the Gameboy.
The Random UV and many other small OSL helper scripts can be downloaded for free from my website.

A lot helps a lot – texturing the circuit boards

Anyone who has ever taken a closer look at a circuit board will have realised that it is a highly complex, multi-layered construction made up of a wide variety of materials. As a simple photo-to-texture approach would not be sufficient for the planned close-ups, a working method using Adobe Illustrator was used here. A trained eye revealed that it was possible to trace all the boards used in 4 layers or less. The Illustrator file was also structured according to this principle:

• Translucent PCB material
• Conductor tracks covered, conductor tracks open and contact points (mostly gold-plated)
• Printings
• Special layer for e.g. copper points or contact pads for the buttons

Each individual element on each side of each circuit board was then painstakingly traced by hand so that a circuit board design was available as a vector graphic of the respective circuit board. This lengthy process took up to one day per board side.

Since the textures, as mentioned above, have a major impact on the resources of the project, the various layers of the Illustrator file were written into the individual RGB channels of a TIFF file using Photoshop. This resulted in the lowest possible information density. In addition to each RGB bitmap of a circuit board, a displacement map was also created in order to reproduce the small height differences of the surface in detail, even with close-up settings. This meant that the tracks and contacts had slight elevations, and the somewhat bulging circuit boards of the buttons and the control pad could also be raised slightly.

Octane used the layered material for shading the boards, which, as the name suggests, allows different shaders to be layered on top of each other. As previously defined in the Illustrator layers, the different shaders were now created to correspond to the material properties of the different board layers.

• Subsurface scattering based base material
• Metallic trace material covered with a green dielectric layer
• Gold metal for the contact points and open conductors
• White dielectric material for the imprints
  

As with all other materials, a great deal of variance, such as irregularities due to dirt and scratch maps, was incorporated into the shaders of the circuit boards. Alongside the physical structure of the materials, these small but subtle details are responsible for a large part of the realism in a scene. Their task is to add imperfections to the perfect, clinically pure rendering and thus bring it more in line with our dirty reality.

Other maps such as the chip labelling and display/printing details of the Gameboy cover were also created in Illustrator and converted into bitmaps using Photoshop. The big advantage of vector-based texture handling is that it is not subject to any resolution limitations. So you can simply export a 16K map if you need to.

Thanks to the efficient instantiation during modelling / layout and the clever approach of separating texture data into RGB channels, the Gameboy asset with its approx. 1,200 components has a C4D file size of 17.8 Mbytes. The texture folder contains around 60 maps. Thanks to the procedural nature and triplanar mapping, the same dirt and scratch maps could be used again and again in the approx. 115 different materials in a resource-saving manner.

Still

Realism took centre stage for the still. The intention was to make the scene look like a photo of a retro hobbyist’s workplace. In the end, this was probably too successful, as the majority of the audience probably did not recognise the still image post as CGI, which was reflected in a much lower response – in contrast to the animation that followed later.

The additional objects in the still were both stolen from older works and newly created. The modelling and texturing of the game cartridge, for example, was done in the same way as the processing of the case. After digitally laying out the Gameboy components on the virtual cutting mat, small dust particles were distributed on the surfaces of the objects using Mograph Cloner, as in many earlier works, which further enhanced the realism of the final renderings.

Still lighting: less is more

The interior HDRI set from Maxime Roz was used to light the still scene(maximeroz.com/hdri). Since, as mentioned, the focus was on realism and not a studio look, only two other light sources were used in addition to the HDRI: one with a bluish light at the top left to simulate a window, and another from the front right to mimic a table lamp.

Before lighting, Octane was switched to its new ACES mode in the menu. The larger (huge) working colour space of ACES allows a much more nuanced and realistic colour representation. The images converted back to sRGB / Rec.709 by the Viewing Lut correspond much more to what the human eye or an analogue film camera perceives: less overexposure, naturally strong but not oversaturated colours.

If you had to explain it in a few words, you could say: What 32 bit is for the contrast range, ACES is for the colour representation. This switch to ACES allowed for a completely different kind of lighting, as the new colour handling gave the scene a much wider contrast and colour range. Lights could radiate onto the scene with more intensity and saturation without outshining and oversaturating everything.

Rendering Still

The in-house farm with nine GPUs was used for rendering. To ensure good quality prints, the image was rendered in 8,192 x 4,608 pixels. Thanks to the nature of octanes, no lengthy sampling settings for light and shaders are required. However, to be above reproach, 16K samples were used to render the still. For the best quality, the path tracing integrator was used with a higher ray depth of 32 specular and 16 diffuse bounces. Adaptive sampling comes into play in order to exclude areas of the rendering that are already free of noise from the active calculation and thus direct the computing power to the areas that are difficult to calculate.

Compositing: A few corrections with a lot of Open Colour IO for ACES

In order to take full advantage of 32 bit and ACES, the stills in After Effects were also composited in 32 bit. A practice that has long since become the standard here. To make After Effects compatible with ACES, the OpenColorIO plug-in, which is available for free download from the fnordware.com blog, was installed. The workflow consisted of creating an adjustment layer with the plug-in in the top level of the After Effects composition, linking the ACES profile, which you have to download separately, and then converting ACEScg to the sRGB / Rec. 709 screen profile.

At this point there was a slight misunderstanding between the plug-in and After Effects, as After Effects works in 32 bit and expects a linear output. However, the OCIO plug-in outputs the gamma-corrected Rec. 709 (as set). To linearise the output again, a colour space converter helped by converting from sRGB to sRGB and converting the result linearly by ticking the box. As Rec. 709 and sRGB are the same colour spaces, you get the same result with the sRGB setting. Only the tone mapping from ACES to Rec. 709 is slightly brighter in the lows and mids than the mapping to sRGB and was therefore selected for the project. This gave the same result as in the Octane Live Viewer with the ACES Rec. 709 setting.

In order to simulate a view output, it makes sense to define the above-mentioned adjustment layer as a guide layer except for the last output Comp, as otherwise the colour conversion will take place in each sub-composition, which of course will not produce the correct colours due to the multiple conversion. This ensures that you have the correct conversion from ACES to Rec. 709 in each sub-composition and therefore see the right thing, but do not shift it too early into the wrong colour space through subsequent steps. The compositing was carried out in a three-stage process, which was divided into different comp levels.

Level 1: Import, compositing of the
Layers, glow, colour correction
Level 2: Chromatic aberration, lens effects
Level 3: Fine-tuning of colours, contrast and conversion from ACES to Rec. 709

In the first step, all passes were loaded. As these were the light passes of the three light sources, they were simply added together and their strength adjusted using the exposure correction effect. In the next steps, Red Giant Optical Glow was used to create a realistic overexposure effect in very bright areas and the good old curve filter for slight corrections in the colouring and contrast. As the ACES Rec. 709 tone mapping tends to blur the shadows, these were brightened again with an extra gradation curve.

For the next step, the previous steps were summarised in a new composition. The chromatic aberration of a photo lens is best simulated by splitting the colour channels of an image into their RGB components and then upscaling these minimally by different factors. To achieve the splitting into the individual RGB channels, the main composition was duplicated twice so that three layers of the same sub-composition were present in the composition.

Now the “Offset channels” effect came into play, which was set so that only the red channel was used in the first layer, only the green channel in the second layer and only the blue channel in the bottom layer. After adding the layers, the colours could be separated by scaling them differently. The great thing about this way of working is that you retain a clean representation of the content in the centre of the image, while the colours diverge more and more towards the edges depending on the strength of the different scaling. This result exactly mirrors the behaviour of lenses, which usually produce a perfect image in the centre but, due to their design, produce increasingly unclean images towards the edges.

In the final step, the result was fine-tuned once again by adjusting both saturation and contrast. After the final conversion to sRGB using the OCIO adjustment layer, a fine grain was applied to the image in the last step and the white and black points were defined. This is very difficult to do before the conversion to sRGB, as this step involves complex tone mapping, which is the whole reason for this rather complex ACES workflow.
This type of compositing was repeated in a very similar way for all the images created for the project, of course with small modifications to all the settings in order to get the best out of the renderings.

Animation: Preparation and a little rigging

Once the stills had been finalised, it was straight on to the planned animation, which was to be prepared in the style of a commercial. It was clear early on that the animation should be a one-shot without editing, in which the camera circles around the product and takes a closer look at various details. In a short concept phase, the planned animations were written down in keywords. With a little imagination, it was possible to visualise the animation in the head using the keyword list and, if necessary, make changes to the sequence without much effort. A mental previs, so to speak.

After that, it was straight on to scene construction and rigging. To make the timing of the animations easier later on, some elements of the Gameboy were rigged so that the animation could be completed with fewer clicks. For example, all cable harnesses were soldered to their respective boards using Xpresso circuits so that they moved realistically when the boards were moved independently of each other.

User data was also created that allowed the Gameboy to switch between the Classic colour scheme (white with pink buttons) and Clear, to operate the On/Off switch, which also caused the control LED to switch on, and to change the instance IDs of the coloured shell parts. The latter was established in order to be able to switch between the different colour versions of the Gameboy. Using a shader circuit, it would have been possible to change the asset between the Classic, Red, Black, Green, Yellow and Blue colour schemes with the instance IDs from 0 to 5. In addition to the colour scheme of the cover, this shader circuit also takes into account other details such as the screen frame, labelling and buttons, which are different for the various versions. However, the idea of switching between the different colours during the animation was discarded in the animation phase because it already captivated the viewer with enough other details, and in the end was only used for the packshot.

In order to create beautiful concentric movement curves for the camera, it was nested in two zero objects, with the first zero centred in the middle of the Gameboy. A second null, in which the camera was zeroed out, was used to ensure more complex rotations without getting into a gimble lock. The dynamic animations of the project were created from the rotational movement of this first zero in relation to the distance animation of the second zero and camera.

Animation: Camera keyframes

The animation was started with a rough-pass setting of keyframes according to the previously defined keyword list. In the animation, apart from the explosion, the camera moves almost exclusively. This was particularly useful because motion blur of the camera is easier to calculate in most renderers. As the rendering of motion blur of complex objects such as our Gameboy asset often leads to rendering errors such as incorrectly calculated blur, this can be avoided.

After the first rough animation, the timing was first adjusted to get the right mix between quick position changes and overview shots. This result was passed on to the composer Lukas Guziel(soundcloud.com/lukas-guziel) as a hardware rendering (Playblast) to create an audio composition, as the timing was fixed from this point on. Then it was time for fine-tuning, in which the tangents of almost all keyframes were touched in order to precisely define the acceleration and deceleration behaviour of the individual movements. Last but not least, the focus and aperture of the camera were animated to give the image aesthetics the right amount of sharpness and bokeh.

Animation: Light

For the lighting, the setup of the still with HDRI, cold and warm light source was largely adopted, as the cold-warm contrast had worked well there. However, as this was a camera that shows the object from many sides, the light could not remain static. So, similar to the camera, the area lights were placed in null objects, which were placed in the centre of the Gameboy to allow easy rotation around the Gameboy.

With the help of the fast preview rendering in the Live Viewer, rotations and positions for HDRI and light sources were found for each slower passage that provided beautiful lighting. The light sources were then keyframed so that they could change position during the fast passages of the camera without the viewer noticing. Sometimes this transition proved to be problematic because it could happen that a light source flashed in front of the camera during the change and thus created unsightly reflections.

This could be partially remedied by setting new keyframes. However, there were still two places where this was not possible. However, as nothing had changed in the post-workflow and the animation was also planned with individual light source passes, it was decided to compensate for any image crossings by temporarily fading out the respective light pass.

Animation: Nintendo logo

Shortly before the pack shot, a position was planned in which the Nintendo logo scrolls down from the top, as is usual when switching on the Gameboy, and then stops with the iconic “bling”.
The logo was to be transferred to the monochrome pixel matrix of the Gameboy screen as realistically as possible. The smartphone’s super slow motion function shed some light on this. This made it possible to determine the refresh rate of the display (60 Hz) and the approximate pixel response time from the video.
Together with a logo exactly replicated in Illustrator Pixel, an animation was created in After Effects that very accurately reflects this nostalgic experience. The resulting image sequence was then linked into the Octane material’s display shader to appear on screen at the correct time.

Animation: Rendering

As the rendering was kindly sponsored by RNDR, the cloud render farm operated by Otoy, it was possible to render in 4K despite the sometimes long render times (90 min / frame on two RTX 3090). Unfortunately, the export to the ORBX format required for cloud rendering turned out to be more complex than expected, as this is still under development.

The first hurdle here was that the C4D ORBX exporter had quite long export times because it does not work as a background process in C4D and displays every step in the viewport. However, a remedy was quickly found: with a script from 3D colleague Dino Muhic (dinomuhic.com/orbx-commandline-export), which allows the export via command line and thus speeds it up more than tenfold.

However, this did not solve all the problems. For example, the frequent fading in and out of geometries put a strain on the exporter and there were discrepancies between the rendering in C4D and the farm. Fortunately, this can be checked quite easily by opening the exported ORBX in the Octane standalone and rendering it there. This means you don’t have to wait for a farm rendering to know whether the export worked.

Unfortunately, the solution here was somewhat more complex, and after some testing it became clear that an individual export had to be created for each part of the animation between which an object was faded in or out. This resulted in some effort to divide the animation into 10 files, each of which then had to be exported.

After this hurdle, everything went according to plan. The online rendering went quickly and smoothly, and hardly anything had to be re-rendered. Smaller parts of the animation were also rendered locally in order to keep the render farm running. Places where transitions such as from classic colours to clear take place were rendered overlapping and then blended in post.

To save resources when downloading and storing the approx. 7,500 image files on the hard drive, all ACES-EXRs were saved using DWAB compression. If a 4K 32-bit EXR file limited to one level with frequently used ZIP compression requires approx. 30 Mbytes of memory, the same file with DWAB compression (16-bit float) has only approx. 7.5 Mbytes with imperceptibly changed quality. This meant that the memory consumption of the rendered files could be reduced from an estimated 280 Gbyte to 72 Gbyte.

Animation: Compositing / Finalisation

Here too, almost the same comp workflow was used as for editing the stills. No wonder, because apart from the movement, nothing had changed in the workflow. The structure of the passes, which mainly contained the various light sources, was identical. Neat Video was used to eliminate any remaining slight noise from the sequences rendered with 8,192 SPP. Only to apply a global grain with the grain filter to the animation again at the end to make it look a little more cinematic and, above all, to reduce banding and block artefact formation on streaming platforms.

Last but not least, the animation was accompanied by the finished soundtrack by Lukas Guziel, which gave it even more life and presence, and exported to the final formats via the Media Encoder and uploaded to online platforms such as Vimeo and YouTube.

Conclusion: the fulfilment is in the detail

After almost one and a half months of work, the time had finally come and “Loveletter” could be published. Long hours and many days were spent creating this work. Overall, this resulted in a varied journey across many areas of the 3D landscape that had a lot to offer. The intensive approach to themes such as looking closely at shapes and materials refined my view. The release from a deadline led to trying out new things such as the ACES workflow and RNDR and to further training in many areas, which resulted in refined knowledge and an even better eye for the essentials.

One of the best things, however, is the overwhelming response that this project has generated far beyond the boundaries of the 3D community among PCB engineers, electronic hobbyists and, of course, retrogamers in particular. Many thanks for the attention! So the next project, the 80386 computer mentioned at the beginning, is already in the starting blocks to be realised.

The post Loveletter first appeared on DIGITAL PRODUCTION and was written by Raphael Rau.

In the beginning there was a problem – and in fact it was already there at the very start of international distribution: Because international distribution goes hand in hand with a thousand different versions of a film being needed. So why did our industry need another complex format? That’s why.
Different final formats, different language versions, edited versions, subtitles, output devices – in short, an almost unmanageable number of tapes and/or file formats, including chaotic content and metadata management and high storage space requirements.

IMF is now supposed to solve all these problems: a format that contains all the required versions, is easier to handle and also saves storage space. The discussion about what such a format should look like began back in 2007, and in February 2011 the USC Entertainment Technology Center finally adopted the IMF Specification 1.0 – one month later the SMPTE Working Group 35PM50 was launched, from which the various IMF applications later emerged (more on this in a moment).

The following points were clear from the outset: IMF was to replace tapes as a storage medium – a fact that had already taken place even without IMF. Next, it was to contain all variants and versions of the content – in other words, in addition to the original version of the film, all available language versions, sound mixes, subtitles, edited versions, etc..

The required storage space should be minimised by two mechanisms: Firstly, video compression should be available. Secondly, content should not be stored twice. Until now, this was inevitably the case: If a master was created for the American market – let’s say as ProRes 444 incl. stereo and 5.1 mix – a second master was created alongside it, for example for the German market, which took up the same amount of storage space. Both masters were approximately the same size, as the video takes up the lion’s share of the storage space – and this is predominantly the same for both masters – apart from the few places where localised titles can be seen. Added to this are the different cut versions.

IMF also solves this problem elegantly: only one master video track is saved in the IMP (Interoperable Mastering Package) and all versions reference this master track and only save any modifications (e.g. localised title sequence) as actual video data.

In all of this, IMF should utilise existing standards – such as the MXF container, the XML format, or JPEG 2000 compression. The bottom line is that IMF is not an acquisition or live production format – no camera in the world will spit out IMF. It is also not an intermediate format like ProRes, which can be used for editing and colour correction. IMF is something like a final “Grand Master”, which is primarily intended to facilitate distribution (business-to-business).

Applications – the flavours of an IMP

Before we look at the inner workings of an IMP, let’s first talk about what are known as IMF applications. IMF applications (apps for short) describe different variants of an IMP for different areas of use, but they all use the same basic structure. Different features of the various apps are, for example, compression, colour space, quantisation and resolution (see info image below). So before you start creating an IMP, you first need to find out which app is specified in the customer’s delivery specifications. App 2e (e for “extended”, for “even more extended”) is currently the most commonly used, as it essentially describes the features for today’s network distribution à la Netflix: AS-02 MXF container, lossy and lossless JPEG 2000 compression, 12/16-bit RGB colour depth, Rec. 709 or Rec. 2020 colour space, max. 4Kx3K resolution, HDR and uncompressed PCM audio in an MXF container.

App1 is the unicorn among the applications – actually, it is not an application as such, but rather a deceptive package for archives that have something against video compression and container formats everywhere and therefore prefer to save their content in uncompressed DPX or TIFF sequences.

App3 is Sony’s more or less failed attempt to establish its own IMF standard based on HDCAMSR – presumably nobody except Sony uses this standard.

App4 is aimed at distribution from film archives. App4 supports resolutions of up to 8K and archival frame rates (such as 12 fps), but is only permitted in the XYZ colour space in 16-bit JPEG 2000.

Two more apps are currently in the works: OpenEXR- and ProRes-based IMF. Both are to be adopted as standards within the next few months (they appear in the info box as App5 and App6 – these names are likely, but have not yet been finalised). The EXR IMF is intended to facilitate the exchange of VFX in the ACES colour space, while ProRes is mainly of interest for the broadcast sector – in both cases, an MXF container is again used for the video data. The reason for the introduction of the two formats is simply that existing content does not have to be re-encoded, but simply re-wrapped, which is much faster and requires less processing power when creating IMPs.

What’s in the box

But now to the insides: On the outside, an IMP has taken over quite a lot from a DCP. Similar to a DCP, an IMP is a folder with a series of files – audio and video are stored separately in the form of MXF files (with the exception of App1, which is not an app). There is also a series of XML files. What does not exist is DCP-like encryption using KDM.
Firstly, the MXFs: As already mentioned, video and audio (and subtitles) are stored in separate MXF files so that they can be combined flexibly. Specifically, all video segments are each stored in their own MXF: i.e. the 90 minutes of the original film are in one MXF. The 2 minutes of the German title for the German version are in a separate MXF and so on.
There are various options for saving the sound in MXF files. Normally there is one MXF per soundfield. A soundfield is a compilation of various related audio channels. For example, the 6 audio channels for the German 5.1 mix represent a soundfield (German 5.1), the two stereo channels for the original English dubbing represent another soundfield and so on.

The XMLs perform various tasks: Firstly, there is ASSETMAP.xml – in both a DCP and an IMP, everything and everyone is referenced by its own UUID (Universally Unique Identifier) in the file header. The ASSETMAP.xml assigns the appropriate file name to each UUID within the IMP.

Next comes the packing list (PKL_name_of_pkl.xml). Related files are listed here based on their UUID – this allows a server to quickly find out whether all assets for playing a specific version are actually available. An IMP that contains an English and a German version could have two PKLs: One PKL that contains all the UUIDs needed for the English version and another PKL that lists the UUIDs (and therefore files) for the German version.
Finally, there is the composition playlist (CPL_name_der_cpl.xml). As the name suggests: a playlist. A CPL is similar to an EDL (Edit Decision List). Here, the various assets (video, audio and subtitle files) are referenced using their UUIDs and a kind of timeline is built from them (e.g. German video track, but shortened cut version, together with German 5.1 mix). The nice thing about CPLs is that they do not use timecode for the “cut”, but edit units, which are much more precise and flexible.

Edit units depend on the format used: for video, edit units are simply frames, for audio they are samples. The CPL then works like this: Source clips are so-called “resources” and are referenced using their UUID. Each resource has a so-called entry point and a duration (both in edit units), which are used to set the counterparts to source in and out of an EDL. A sequence is then built from several resources, which in turn represents a segment within the playlist.
This basically provides all the ingredients for a simple IMP. Optionally, two more things can be added: Subtitles and OPLs. OPL stands for “Output Profile List” and describes a series of macros that are used for automated transcoding, for example. Here, a transcoding software is given instructions on how to create a German HD version with a 5.1 mix from multilingual 4K content, for example. The OPL is also saved as an XML file in the IMP (OPL_name_of_opl.xml.). However, OPLs are currently hardly ever created, requested or required, as there is currently a lack of support, market and development resources.

Subtitles must be in TTML format (Timed Text Markup Language) and are also wrapped in an MXF container. TTML enables high-quality rendering of subtitles for cinema, TV and OTT (over-the-top) content and is also fully compatible with non-linear content (i.e. can also be “cut up” by a CPL together with video and audio). Metadata from older subtitle formats such as CEA 708 (mainly used by US broadcasters) or EBU STL are also supported by TTML.

As future-proof as TTML is, it is also difficult to implement – support for this format is unfortunately not yet so advanced, as it is a fairly comprehensive format – IMF therefore uses a slightly slimmed-down version: IMSC1 (Internet Media Subtitles and Captions 1.0). But all in good time.

Full, Version and Supplemental IMPs

Not all IMPs are the same. Like any complex format, IMF also has various variations and subtypes. A full IMP contains various, if not all, versions of a film in picture, sound and subtitles – it is the “grand master” IMP, so to speak. If you now take a look at broadcast distribution, it quickly becomes clear that there is little interest in distributing full IMPs across the globe. What is an Austrian TV station supposed to do with the Israeli language version and Lithuanian subtitles? So what do you do? You create a so-called “Version IMP” from the “Grand Master”, which only contains the picture and sound version for the Austrian market – perhaps with optional subtitles in German and English.

That leaves the Supplemental IMP. Let’s assume that an IMP with a German picture and language version has already been distributed to broadcasters in Germany. Unfortunately, the subtitles were not yet ready at the time of distribution. A supplemental IMP is therefore created, which only contains the subtitles and a CPL, but which references the original IMP with the picture and sound data. This means that the supplemental IMP requires the previously delivered version IMP in order to be played. A similar scenario is a newly released director’s cut, new or additional language versions or modified opening and closing credits. Of course, it is also possible to add a Supplemental Package to a Version or Full IMP at a later date and send it as a single package.

Version and Supplemental IMPs therefore offer the greatest possible flexibility – the disadvantage of the story, however, is that IMF is not necessarily suitable for archiving. Not only because everything gets out of hand above a certain amount of Supplemental and Version IMPs, but also because
Archives do not like video compression and container formats such as MXF. Compressed data can hardly be recovered from defective data carriers in an emergency – that’s why archives usually fall back on something IMF-like, which comes uncompressed in the form of TIFF or DPX sequences and otherwise also looks like an IMF – but isn’t really one (there it is again, our hated chip child App1).

What it takes to create an IMP

So, enough about the inner workings of an IMP – what do you need to create one? First of all, the right hardware. No matter which software you use, they all use GPUs to decode and encode the JPEG-2000 video – so powerful graphics cards are an advantage. An Nvidia GP100 can achieve approx. 100 fps 4K JPEG 2000 encoding – but similar figures can also be achieved more cheaply with a few Geforce cards. However, the storage should not be ignored, as the source material is usually uncompressed and therefore bandwidth-hungry – so if the storage is not fast enough, it cannot deliver the data as quickly as the GPU could encode it and becomes a bottleneck. The CPUs are currently not given quite as much weight as the graphics cards, but the CPUs have to shovel the data from the storage to the GPU fast enough – 24 physical CPU cores should be enough for 4K content. However, the upcoming ProRes application should be kept in mind: ProRes is decoded and encoded entirely on the CPU. There is no upper limit for everything, GPU, CPU and storage – depending on how fast you want to decode and encode, you can increase as far as the machine allows. On the software side, you don’t have too many options these days.

The entry into the IMF world is made with Fraunhofer’s EasyDCP (cost: 6,545 euros incl. VAT) or Innovative Pixel’s FinalDCP (3,569 euros incl. VAT). This gives you a software solution for DCPs and IMPs – but both lack certain mastering functions such as the creation of cut versions, validation, soundfield creation and the like. DVS Clipster also has DCP and IMF mastering functions: If you have one, you can of course make use of them. The disadvantage of Clipster, however, is its outdated architecture, which makes it difficult to keep up with the rapid pace of development. Whilst the competition is already fully committed to GPUs, Clipster owners still have to deal with the slower, less flexible, proprietary and not exactly cheap hardware. This brings us to the two main players in the field of IMF mastering: Marquise Technologies MIST and Colorfront Transkoder. Both are a comparable burden on the wallet in the 5-digit range. Transcoder is mainly sold as a turnkey system, but is also available as software-only.

The situation is similar with MIST, but there is a basic software version to which you can add various optional add-ons, e.g. DCP mastering, IMF mastering and HEVC rendering, whereas Transkoder comes with everything from the start. MIST is available as a Windows-only package, while there is also a Mac OS X version of Transkoder in addition to the Windows version, although this does not have the same range of functions as the Windows version due to the OS and is largely unusable for IMF workflows. Both systems decode and encode JPEG 2000 on one or more GPUs. In addition, both offer a DCP and IMF validation function, which subjects an existing IMP to a series of tests to ensure that the respective IMP is also standard-compliant.

Both Transkoder and MIST also have a range of colour grading, editing and HDR management tools as well as colour management and SDI output. There is also a player-only version of both manufacturers (also including validation functions), which are designed to carry out quality checks of IMPs. If you would like more information or a trial of either system, please contact the respective reseller here in Germany (DVE-AS for Colorfront, DVE-X for Marquise Technologies) for advice. Many thanks at this point to Dan Tatut from Marquise Technologies for his help in obtaining information for this article.

The post IMF – and what it’s all about first appeared on DIGITAL PRODUCTION and was written by Mazze Aderhold.