Summary: When using image paint on motion picture files, the entire frame will sometimes go much darker. This looks to be a linear to log conversion issue. It is erratic.
Reproduction: 1) Load a motion picture file. 2) In the UV image editor, turn on paint mode. 3) Flip and paint frames at will. Eventually, an entire video frame will go darker. It appears impossible to regain the proper image frame look except via a full reloading of the image file.
Platform: Linux amd64 (Ubuntu 11.04)
Version: SVN 36550
Description
Event Timeline
Sorry troy, but this is insufficient info for a bug report. There's too many unknowns here.
It's essential for you to carefully check on which reproducable case an error happens. You also should always check official releases. And explain what a "motion picture file" is.
The bug tracker is half the work for artists, half for devs :) it's not a support system!
Grr. Apparently my follow up vanished. Sorry for insufficient data, I'll try to rectify it with this post.
Reproduction:
1) Flip to Compositing default workspace.
2) Toggle on Use Nodes.
3) Delete the default Render Layer node.
4) Add an input Image node and load the MVI_2266.MOV motion picture file attached.
5) Set the total frames on the Image Node to 78 to match the length.
6) Add an output Viewer node.
7) Attach the Image node to the Composite and Viewer nodes.
8) In a UV Image pane, select the MVI_2266.MOV from the list box.
9) Turn on Image Painting.
10) In properties, toggle Auto Refresh and click Match Movie Length.
11) Begin painting, flipping frames and painting with the default brush.
Eventually you will see the dark frame. Sometimes zooming in and out will help to induce it while painting.
ADDITIONAL NOTES:
This bug appears extremely difficult to induce when only loading motion picture files in a UV pane. Seems to be occur in conjunction with an active Compositor pane and a Viewer node.
https://s3.amazonaws.com/sample-images/MVI_2266.AVI
Sample motion picture file located here. Uploads are failing to the tracker with no error.
Oh dear, painting on avi files was not meant to work even!
What we get here is a conflict between the compositor - which moves data first to linear color and then back - and the cache for painted frames.
Blender's image system doesn't support our multithreaded approach in 2.5 well yet. These are known todos.
I've added a clear description of the case in our todo tracker to notify a developer when colormanagement or threaded-image code is being worked on.
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Editors#Image_Editor
Thanks!