Thu, Dec 7
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.
@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.
@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.
Wed, Dec 6
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:
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.
Thu, Nov 30
Good find! Confirmed.
Here's a fix that seems to work:
Wed, Nov 29
True. I'd also consider this a bug. Not a dramatic one of course, but it is indeed an inconsistency...
Thu, Nov 23
See also "precision limitations on integer values" here:
Half floats can store maximum 65536, but definitely not all integers in between. I think we should always store ID passes with full float precision, regardless if the half float option is used.
Nov 1 2017
Oct 31 2017
More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.
(still missing pretty much all data, like testing actual current official release, latest master, specifying which version/OS/etc.........)
Oct 24 2017
I put ctrl-F11 in the title. Quick Viewer is what I think its officially known as? The playback does all of those things and more. It plays at 10x, it plays at 0x, it skips half the frames, goes seemingly backwards, all at once. Glitchy. Unusable. It has no concept of what time is. Its not the generated video file as it plays fine elsewhere.
Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files (e.g. sample video files) to do so, etc.
Oct 17 2017
Oct 16 2017
Oct 9 2017
I can confirm that there is a problem, here.
I had to open an Image Editor, modify Number of frames, Start Frame settings and enable autorefresh into Image Properties.
Sep 13 2017
Alright. My bad. Wasn’t aware. I’ll see if I can come up with a patch or two to address the issues, though, because this is pretty important to me.
Thanks for the report, but it doesn't sound as a bug at all, more like a feature request or an enhancement request which we do not accept in the bug tracker. There are lots of areas in Blender which can behave better, but with are behaving fully according to the design and hence not considered a bug.
Sep 11 2017
FYI: For now I’m preprocessing the input by converting to 24-bit RGB before importing into Blender, but that clearly isn’t enough most of the time. Even 8-bit (per channel) YUV can only be used with heavy dithering, and e. g. 10-bit input (which is getting increasingly common) loses way too much precision. Given FFmpeg’s rather awkward pixfmt support (owing to swscale legacy), it seems like using libzimg directly is the best option.
Sep 10 2017
Just confirmed that FFmpeg defaults to Rec. 601. Bad. This needs a selection on import (defaulting to “Auto”, which should apply the same resolution-based heuristics as video players for untagged files, i.e. use 709 with HD resolutions) and export (should autoselect based on render resolution and also mark the colorspace appropriately in the resulting file—no idea what the API is for that on lavf’s side).
Sep 6 2017
I think we can tweak the mapping to avoid this, even if it means break backwards compatibility a bit.
Sep 5 2017
Aug 3 2017
Before opening this task I talked to @Bastien Montagne (mont29) over IRC and we could not find a real good reason for this feature. So I created this task to get some deeper discussion.
I do not think that the bf-funboard has ever really been a good place where users actually get feed back from there ideas, so I would rather open the task here.
Design tasks are mainly for developers, who wants to present their design for a particular project and get feedback. It is not for functionality discussions. For such discussions please use bf-funboard mailing list.
Jul 26 2017
Hi brecht. Even in 2017 me and some others stumble over this behaviour and I want to try another solution myself. I am an experienced software developer, though never done anything in blender sourcecode so far.
Jul 6 2017
Jul 4 2017
Well, then, thanks for the report, but this is not something we can work on directly, issue could be reported to ffmpeg I guess (though this is primarily a playback library, so not sure how much they care about HDR type of data, on the other hand some HDR video formats are emerging these days, so maybe they'll have to consider the issue for those as well?).
Jun 26 2017
Jun 23 2017
This is sadly due to the swscale reliance in FFMPEG. Currently, all buffers loaded from codecs are converted to RGB at 8 bits per channel via the swscale library. This likely won't be changing any time in the near future unless the FFMPEG handling is overhauled to load raw YCbCr and let OCIO handle the colour transforms.
Thanks for the suggestion, but this tracker is not for feature requests, see here for other options: