Page MenuHome

Use OIIO for DPX loading.
Needs RevisionPublic

Authored by Jeroen Bakker (jbakker) on Dec 6 2017, 11:33 AM.

Details

Summary

This patch will allow better loading of DPX files.

Log stored files where not loaded correctly. As OIIO converts DPX to sRGB blender loads them correctly.
Note that still the workflow has flaws as saving DPX, and loading back again gives strange results (Loaded sRGB as Linear), and not allowed to change the Color profile to match.

When CINEON and OIIO are selected OIIO will be used for loading and CINEON for saving. As OIIO does not store the color space in DPX files...
I don't think this patch is stable for master, but would like a review on what we can do about it.
As it is not compatible with the master behavior I made the patch on Blender2.8.

Sorry I don't have supported files that I can share. See below the details about the image

Image: test.dpx

Format: DPX (SMPTE 268M-2003 (DPX 2.0))
Class: DirectClass
Geometry: 1920x1080+0+0
Units: Undefined
Type: TrueColor
Base type: TrueColor
Endianess: MSB
Colorspace: Log
Depth: 10-bit
Channel depth:
  red: 10-bit
  green: 10-bit
  blue: 10-bit
Channel statistics:
  Pixels: 2073600
  Red:
    min: 83 (0.0811322)
    max: 942 (0.920821)
    mean: 261.243 (0.25537)
    standard deviation: 115.968 (0.113361)
    kurtosis: 12.5679
    skewness: 2.78015
    entropy: 0.829626
  Green:
    min: 96 (0.093843)
    max: 941 (0.919844)
    mean: 264.318 (0.258375)
    standard deviation: 118.85 (0.116178)
    kurtosis: 12.818
    skewness: 2.9001
    entropy: 0.834292
  Blue:
    min: 84 (0.0821088)
    max: 943 (0.921798)
    mean: 216.404 (0.211538)
    standard deviation: 114.029 (0.111465)
    kurtosis: 16.5328
    skewness: 3.56177
    entropy: 0.821986
Image statistics:
  Overall:
    min: 83 (0.0811322)
    max: 943 (0.921798)
    mean: 247.322 (0.241761)
    standard deviation: 116.299 (0.113684)
    kurtosis: 13.9623
    skewness: 3.08104
    entropy: 0.828635
Rendering intent: Perceptual
Gamma: 0.454545
Chromaticity:
  red primary: (0.64,0.33)
  green primary: (0.3,0.6)
  blue primary: (0.15,0.06)
  white point: (0.3127,0.329)
Background color: log(255,255,255)
Border color: log(223,223,223)
Matte color: log(189,189,189)
Transparent color: log(0,0,0)
Interlace: None
Intensity: Undefined
Compose: Over
Page geometry: 1920x1080+0+0
Dispose: Undefined
Iterations: 0
Compression: Undefined
Orientation: TopLeft
Properties:
  date:create: 2017-11-07T09:24:39+01:00
  date:modify: 2017-10-31T12:26:52+01:00
  document: 
  dpx:file.creator: LIBFORMAT
  dpx:file.ditto.key: 1
  dpx:file.filename: 
  dpx:file.version: V1.0
  dpx:film.frame_position: 0
  dpx:film.frame_rate: 23.976
  dpx:film.held_count: 0
  dpx:film.sequence_extent: 0
  dpx:image.element[0].transfer-characteristic: PrintingDensity
  dpx:image.element[1].transfer-characteristic: UserDefined
  dpx:image.element[2].transfer-characteristic: UserDefined
  dpx:image.element[3].transfer-characteristic: UserDefined
  dpx:image.element[4].transfer-characteristic: UserDefined
  dpx:image.element[5].transfer-characteristic: UserDefined
  dpx:image.element[6].transfer-characteristic: UserDefined
  dpx:image.element[7].transfer-characteristic: UserDefined
  dpx:image.orientation: 0
  dpx:orientation.aspect_ratio: 0x0
  dpx:orientation.border: 0x0+0+0
  dpx:orientation.device: A335C009_171013_R0T6
  dpx:orientation.x_center: -1
  dpx:orientation.y_center: -1
  dpx:television.frame_rate: 23.976
  dpx:television.time.code: 12:29:11:23
  dpx:television.user.bits: 00:00:00:00
  signature: fee4dc038d5c6d26a681e07fc75f7e4de210263796f2ab85489f2812bb0dd31c
  software: LIBFORMAT
Artifacts:
  filename: test.dpx
  verbose: true
Tainted: False
Filesize: 8.303MB
Number pixels: 2.074M
Pixels per second: 34.56MB
User time: 0.050u
Elapsed time: 0:01.060
Version: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org

Diff Detail

Repository
rB Blender

Event Timeline

Sergey Sharybin (sergey) requested changes to this revision.Dec 6 2017, 2:40 PM

We do need to have files to justify whether this change really fixes anything or not. I am fully unhappy even considering applying such a non-trivial patch without knowing what is broken. It also makes it more difficult to do regression tests if we don't know what is broken.

Big downside of this, is that this will mean we can not pack DPX files after this patch.

Personally, i don't think we should be using OIIO at all in ImBuf, it's only adding problems.

I don't think this patch is stable for master, but would like a review on what we can do about it.
As it is not compatible with the master behavior I made the patch on Blender2.8.

Please do not consider Blender2.8 a playground for unstable/dangerous/unknown features.

This revision now requires changes to proceed.Dec 6 2017, 2:40 PM

What a pleasant coincidence! I just had the problem a few days ago that I could not load a DPX file into Blender which I got from some other application. I used EXR instead as workaround. But I tried the patch and that actually works (even though the frame itself is flipped)! Here's a frame from the sequence that did not work:

@Sebastian Koenig (sebastian_k) , please try this patch P572. The image is indeed flipped upside-down, but it's same as OIIO opens it as well. In any case, please open a report with a file attached, so we can reference it from commit message.

@Jeroen Bakker (jbakker), proper way to move forward with this is to use libdpx [1] instead of our legacy DPX code. This way you don't create wrapper around a wrapper which wraps a wrapper, but use things morte direct, without going to a maintenance issues

[1] https://github.com/PatrickPalmer/dpx

@Sergey Sharybin (sergey) Thanks! I tried the patch, but it did not work. Neither the MCE nor the IE can open the image. If I try, it gives me an error: IMB_ibImageFromMemory: unknown fileformat (/home/sebastian/1-38_A002.0000811.dpx)
I'll open a report.

The patch is now committed to master, and in fact solved the issue for Sebastian. The image is still flipped, but all tools here shows it like that. The header also suggests this is a correct orientation... Needs more investigation, but is unrelated to this patch.

@Jeroen Bakker (jbakker), if there are files which still opens incorrect for you, it is essential to have them. Without investigating those i am not processing further reviewing this patch.