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.
Wed, Nov 1
Tue, Oct 31
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:
May 16 2017
From quick around seems we can not solve it from our side, just need to wait for the new OpenEXR to be released.
This seems to be a bug in OpenEXR itself, which was fixed by . Unfortunately, this commit is in none of the branches except from development one (it is not in the 2.2fixes branch).
May 15 2017
May 12 2017
Apr 18 2017
@Aaron Carlisle (Blendify) ffmpeg gets the length right because the duration (in frames) has doubled as well as the tbr. If you let Blender change the scene rate to whatever ffmpeg tells it, the length in elapsed time is correct.
Apr 17 2017
I've done some digging, and the loading of multilayer EXR files seems a bit indirect. load_image_single() loads the image with its metadata, then calls IMB_freeImBuf(ibuf); to immediately free the image buffer. A later call to BKE_image_acquire_ibuf() fetches the image buffer from some cache using image_get_cached_ibuf(), which then returns an ImBuf without metadata.