Thu, Aug 3
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.
Wed, Jul 26
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.
Apr 15 2017
If there were an issue, it would be a regression since 01fa4fb6 but I suspect the duplicated timebase is correct for paff-encoded video, see also tickets #3339 and #5378. In any case, there is most likely a bug in blender as FFmpeg always detects the correct length of the clip, no matter the timebase
Apr 13 2017
Mar 26 2017
It seems that @ronan ducluzeau (zeauro) clarified the issue, and that there is no bug here after all. Closing.
Mar 21 2017
Mar 10 2017
I appreciate your in depth response. I wasn't able to use an Image Sequence by baking paint but was able to use the Weight to bake something for an Animated Weight Group. I never knew that was possible and I'll keep experimenting and learning.
Mar 8 2017
Particles emission does not support animated weight groups, animated textures or image sequence textures.
It is a known limitation of current particle systems.
Mar 6 2017
Mar 5 2017
Mar 1 2017
Dec 20 2016
@ Jens verwiebe; would you mind describing the solution a little bit more in detail?
I'm trying to get DNG support within Blender VSE; but either blender shows a blank frame or crashes.
Dec 10 2016
Nov 26 2016
I can confirm @Sergey Sharybin (sergey) I think this one is for you?
Nov 12 2016
Fixed in the "a" version
Nov 10 2016
Nov 9 2016
I can have a closer look later if you like?
That would be great :)
Don't think it's that strange, every change anywhere in the code that somehow influences context can cause such issues. Typical bContext crap… Couldn't check code yet, but from backtrace it even looks a bit like something that only worked by accident before.
I can have a closer look later if you like?
That's so strange. The problem is because CTX_wm_space_image returns null (or rather, CTX_wm_area does it). I can't see what changed in 2.8 to justify that.
==31845==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x558ba55adbd8 bp 0x7ffcd34a2fa0 sp 0x7ffcd34a2f90 T0) #0 0x558ba55adbd7 in ED_space_image /home/guest/src/blender/blender/source/blender/editors/space_image/image_edit.c:60 #1 0x558ba55bc0f9 in save_image_doit /home/guest/src/blender/blender/source/blender/editors/space_image/image_ops.c:1784 #2 0x558ba55bdd66 in image_save_as_exec /home/guest/src/blender/blender/source/blender/editors/space_image/image_ops.c:2043 #3 0x558ba54a451e in wm_handler_fileselect_do /home/guest/src/blender/blender/source/blender/windowmanager/intern/wm_event_system.c:1856 #4 0x558ba54a4eae in wm_handler_fileselect_call /home/guest/src/blender/blender/source/blender/windowmanager/intern/wm_event_system.c:1940 #5 0x558ba54a5b04 in wm_handlers_do_intern /home/guest/src/blender/blender/source/blender/windowmanager/intern/wm_event_system.c:2064 #6 0x558ba54a67e9 in wm_handlers_do /home/guest/src/blender/blender/source/blender/windowmanager/intern/wm_event_system.c:2207 #7 0x558ba54a8027 in wm_event_do_handlers /home/guest/src/blender/blender/source/blender/windowmanager/intern/wm_event_system.c:2480 #8 0x558ba548b0ba in WM_main /home/guest/src/blender/blender/source/blender/windowmanager/intern/wm.c:489 #9 0x558ba54819f5 in main /home/guest/src/blender/blender/source/creator/creator.c:525 #10 0x7fc5088c72b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) #11 0x558ba5480e89 in _start (/home/guest/src/blender/release/blender2.8/bin/blender+0x158fe89)
Nov 8 2016
I also want to note that color management is messed up in 2.8.