Changing the Proxy Render Size of a movie clip used as background image for a camera doesn't affect the quality of the clip in the 3D viewport #78277

New Issue

Julien Blervaque · 2020-06-25T23:46:19+02:00

Julien Blervaque commented

2020-06-25 23:46:19 +02:00

Bug_CameraBGProxy.zip Bug_CameraBGProxy.zip

System Information
Operating system: windows 10
Graphics card: GeForce GTX 970

Blender Version
Broken: 2.83
Worked: Not found: 2.82a gives another wrong result (pink rectangle instead of image)

Short description of error
When a video clip is used as a background image for cameras, in the 3D scene, a property named Proxy Render Size appears in the Camera Background Images panel. It is supposed to allow the user to use a low resolution of the video. when changing the value of this parameter - From full or 100% (difference?) to 25% we should see in the viewport a degradation of the image quality (more pixelised). In practice nothing changes, whatever the value.

Exact steps for others to reproduce the error
Based on the default startup or an attached .blend file:

Create a camera and select it.
Go to the Data Properties panel, in the Background Images subpanel clic on the button Add Image, then on the button Movie Clip.
Clic on the button Open to open a file browser, get a video clip (I used a .mp4 of res 1280 x 720, provided in the zip file)
Set the camera as the active view in the 3D Viewport and display the background. It should appear at 100% quality.
Now change the proxy Render Setting value to 25%. Nothing changes in the scene, the quality of the video is the same. The experted behavior is to see a more pixelized image.
If you jog into the timeline the quality is still the high res one. If you save and reload the file then on other values than 100% you get flashing pink rectangles instead of the expected proxy.

Save System Info file is provided in the Zip file.

Thank you

[Bug_CameraBGProxy.zip](https://archive.blender.org/developer/F8644287/Bug_CameraBGProxy.zip) Bug_CameraBGProxy.zip **System Information** Operating system: windows 10 Graphics card: GeForce GTX 970 **Blender Version** Broken: 2.83 Worked: Not found: 2.82a gives another wrong result (pink rectangle instead of image) **Short description of error** When a video clip is used as a background image for cameras, in the 3D scene, a property named Proxy Render Size appears in the Camera Background Images panel. It is supposed to allow the user to use a low resolution of the video. when changing the value of this parameter - From full or 100% (difference?) to 25% we should see in the viewport a degradation of the image quality (more pixelised). In practice nothing changes, whatever the value. **Exact steps for others to reproduce the error** Based on the default startup or an attached .blend file: - Create a camera and select it. - Go to the Data Properties panel, in the Background Images subpanel clic on the button Add Image, then on the button Movie Clip. - Clic on the button Open to open a file browser, get a video clip (I used a .mp4 of res 1280 x 720, provided in the zip file) - Set the camera as the active view in the 3D Viewport and display the background. It should appear at 100% quality. - Now change the proxy Render Setting value to 25%. Nothing changes in the scene, the quality of the video is the same. The experted behavior is to see a more pixelized image. - If you jog into the timeline the quality is still the high res one. If you save and reload the file then on other values than 100% you get flashing pink rectangles instead of the expected proxy. Save System Info file is provided in the Zip file. Thank you

Julien Blervaque commented

2020-06-25 23:46:19 +02:00

Added subscriber: @Werwack

Richard Antalik commented

2020-06-29 17:13:37 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-06-29 17:13:37 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2020-06-29 17:13:37 +02:00

Did you enable and build proxies in clip editor? https://docs.blender.org/manual/en/latest/editors/clip/sidebar.html#proxy-timecode-panel

Julien Blervaque commented

2020-06-30 00:29:20 +02:00

I allow myself to add Julian Eisel here (@julianeisel) since I think there is here a UX/UI point.

So no, I didn't enabled nor build proxies in clip editor before changing the Proxy Render Size value. I followed your link and now I am able to make the proxy of the background images for the clip work. Kind of.
So I guess there is no "functional" bug here. But there are to me some UI and UX issues, plus some missing information in the documentation.

I explain myself:
I am not used to use the proxy system. So when I changed the clip proxy value in the Background Images of the camera and I faced this double strange behavior that either the resolution of my clip in teh viewport was not changing or in some cases it became pink I first thought at a wrong manipulation from my behalf.
I then went to the camera documentation: https://docs.blender.org/manual/en/latest/render/cameras.html?highlight=background%20images%20camera It was not mentionned anything about the clip proxy settings. At least a link to the Clip documentation page would have help to put me on the right path.
I then thought about a possible bug, but I wanted to be sure I did the right manipulation, so I went to the blender chat, in support, and asked for a confirmation: https://blender.chat/channel/support?msg=FqdoNWiTowFodDFNv
NiCapp answered me and advised me to report it as a bug.

So my point is that the use of proxies is apparently unclear not only for "newbies" but also for experienced users.

To me, if the feature is working in itself is cannot be considered as "usable" in its current state.

I then suggest the following improvements ((I'm UX/UI designer btw):

The user should be led to the activation of the proxy settings of the clip thanks to the interface: a popup message could appear when the proxy settings of the camera background clip are changed saying that the clip currently has no proxy associated and should indicate where to change it (namely at the other side of the application, in a workspace I just discovered tonight dedicated to clips - so far I thought it was for image tracking)).
The 2 strange behaviors of image quality not changing and pink images should only appear in case of an error: At the moment they are clearly misleading - or leading to think there is a bug. Either nothing changes and there is a popup message mentioned above or things are changed automatically (ie the proxies are generated transparently) and the images in the viewport then get the expected resolution. Pink color should be let for real error, such as proxy not generated for some reason that is not due to a missing user manipulation (an error in the cache path for example, or low memory).
As I experienced just now it also appears - as far as I see - that the user must generate a proxy for each resolution - manually - in order to use it. Why not generating only the one the user needs, this directly from the place where the clip is used and the proxy settings are accessible (in this case the camera background images panel)? That would save trickky manipulations for the user, save him time, save coders time (I will have to implement all thoses manipulations in my add-on to make the camera background proxies work? That is certainly a huge work and I already miss time to support my production) and it will be far more intuitive and predictable for all users, whatever their level of experience.
There is also a UI point that could be made a bit clearer: in the Proxy Render Size dropdown list there is at the same time 100% and Full Render. Well, if 25%...100% are refering to the proxy resolution then 100% is the same resolution than full, by definition. I guess Full then refers to "original footage, without additional compression". Maybe the item "100%" could be renamed to "100% - Compressed", if that's what is happening.

I got a better understanding of the use of the proxies in general in the application now thanks to all this and my point of view is that is it currently a pretty laborious and unclear workflow. There is very likely some room for improvement here.
Thank you very much for your attention to this.

I allow myself to add **Julian Eisel** here (@julianeisel) since I think **there is here a UX/UI point**. So no, I didn't enabled nor build proxies in clip editor before changing the Proxy Render Size value. I followed your link and now I am able to make the proxy of the background images for the clip work. Kind of. So I guess there is no "functional" bug here. But there are to me some UI and UX issues, plus some missing information in the documentation. I explain myself: I am not used to use the proxy system. So when I changed the clip proxy value in the Background Images of the camera and I faced this double strange behavior that either the resolution of my clip in teh viewport was not changing or in some cases it became pink I first thought at a wrong manipulation from my behalf. I then went to the camera documentation: https://docs.blender.org/manual/en/latest/render/cameras.html?highlight=background%20images%20camera It was not mentionned anything about the clip proxy settings. At least a link to the Clip documentation page would have help to put me on the right path. I then thought about a possible bug, but I wanted to be sure I did the right manipulation, so I went to the blender chat, in support, and asked for a confirmation: https://blender.chat/channel/support?msg=FqdoNWiTowFodDFNv NiCapp answered me and advised me to report it as a bug. **So my point is that the use of proxies is apparently unclear not only for "newbies" but also for experienced users.** To me, if the feature is working in itself is cannot be considered as "usable" in its current state. I then suggest the following improvements ((I'm UX/UI designer btw): - **The user should be led to the activation of the proxy settings of the clip thanks to the interface**: a popup message could appear when the proxy settings of the camera background clip are changed saying that the clip currently has no proxy associated and should indicate where to change it (namely at the other side of the application, in a workspace I just discovered tonight dedicated to clips - so far I thought it was for image tracking)). - **The 2 strange behaviors of image quality not changing and pink images should only appear in case of an error:** At the moment they are clearly misleading - or leading to think there is a bug. Either nothing changes and there is a popup message mentioned above or things are changed automatically (ie the proxies are generated transparently) and the images in the viewport then get the expected resolution. Pink color should be let for real error, such as proxy not generated for some reason that is not due to a missing user manipulation (an error in the cache path for example, or low memory). - As I experienced just now it also appears - as far as I see - that the user must generate a proxy for each resolution - manually - in order to use it. **Why not generating only the one the user needs, this directly from the place where the clip is used and the proxy settings are accessible** (in this case the camera background images panel)? That would save trickky manipulations for the user, save him time, save coders time (I will have to implement all thoses manipulations in my add-on to make the camera background proxies work? That is certainly a huge work and I already miss time to support my production) and it will be far more intuitive and predictable for all users, whatever their level of experience. - There is also a UI point that could be made a bit clearer: in the Proxy Render Size dropdown list there is at the same time 100% and Full Render. Well, if 25%...100% are refering to the proxy resolution then 100% is the same resolution than full, by definition. I guess Full then refers to "original footage, without additional compression". Maybe **the item "100%" could be renamed to "100% - Compressed",** if that's what is happening. I got a better understanding of the use of the proxies in general in the application now thanks to all this and my point of view is that is it currently a pretty laborious and unclear workflow. There is very likely some room for improvement here. Thank you very much for your attention to this.

Julian Eisel commented

2020-06-30 17:07:58 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2020-06-30 17:07:58 +02:00

Updated the manual to have some more info on this, rBM6834: https://docs.blender.org/manual/en/dev/render/cameras.html#background-images.

One thing we could do in Blender is grey the proxy settings out if there is no proxy data and adding a disabled-hint in the tooltip (which we want to do more often). However, looking into this, it's actually not so easy (tm)... I don't see a decent way to mark the item as non-editable in RNA, which is the way we have to do it for the disabled hint. Maybe it's time to add disabled-hint support for UILayout.enabled (we should have that anyway).
Another issue is that we can't tell if the proxy is available without testing for the available proxy sizes on disk - which we'd have to do on every redraw for the check. That's too expensive to be an option.

What I think we should do is, store in the clip if proxies were built for a certain size. If the files can not be found on disk, we can show the pink image, possibly with some other hint.

Of course adding a button to build the proxies in-place could also work, but there are a number of settings we should expose for that. How would that look like?

Anyway, these are my two cents. I don't really have further time to work on this myself.

Updated the manual to have some more info on this, rBM6834: https://docs.blender.org/manual/en/dev/render/cameras.html#background-images. One thing we could do in Blender is grey the proxy settings out if there is no proxy data and adding a disabled-hint in the tooltip (which we want to do more often). However, looking into this, it's actually not so easy (tm)... I don't see a decent way to mark the item as non-editable in RNA, which is the way we have to do it for the disabled hint. Maybe it's time to add disabled-hint support for `UILayout.enabled` (we should have that anyway). Another issue is that we can't tell if the proxy is available without testing for the available proxy sizes on disk - which we'd have to do on every redraw for the check. That's too expensive to be an option. What I think we should do is, store in the clip if proxies were built for a certain size. If the files can not be found on disk, we can show the pink image, possibly with some other hint. Of course adding a button to build the proxies in-place could also work, but there are a number of settings we should expose for that. How would that look like? Anyway, these are my two cents. I don't really have further time to work on this myself.

Julien Blervaque commented

2020-07-01 10:15:18 +02:00

These are very good and valuable possible answers :)

Regarding the pink image feedback there may also have something to do here:

Currently when something (anything in fact) is going wrong with the images to display then the image (or clip, or texture...) is replaced by a pink filled rectangle. This has the good side to tell the user something went wrong, but the downside that there is absolutely no clue on what. Plus the fact that it may modify the original media behavior: for example when we use a clip background for the cameras and the proxy is not generated then we get:
* a pink rectangle that is lasting forever (ie longuer that the original media), which is quite disturbing. The expected behavior would probably be that the pink gets transparent after the end of the media (as the media itself)(and in case of course that the media end is not on "hold" state)
* in the specific case of the camera images background the pink rectangle is fully opaque. It then completely occludes the scene and that's a real issue to manipulate the scene. The expected behavior here is clearly that it should respect the Alpha value set for the camera background.

I think we are at a point where there something really cool to do with this pink rectangle. In the 2D/3D prod application I was in charge of we changed this same filled color we had to more contextual and self-explainatory images. Most of the cases were covered and the user was able to spot the origin of the issue at a single glace without having us to develop specific complex stuff for the UI. Here there are (the Media Cache was used for missing proxy, and the green one was used for textures, allowing us to quickly open a 3D scene while the texture proxies were assynchroneouly being generated):

So let's imagine how helpful these contextual error images would be in Blender, for all users in any editor, and for a development cost that is really reduced !

These are very good and valuable possible answers :) Regarding the pink image feedback there may also have something to do here: * **Currently when something (anything in fact) is going wrong with the images to display then the image (or clip, or texture...) is replaced by a pink filled rectangle**. This has the good side to tell the user something went wrong, but the downside that there is absolutely no clue on what. Plus the fact that it may modify the original media behavior: for example when we use a clip background for the cameras and the proxy is not generated then we get: * a pink rectangle that is lasting forever (ie longuer that the original media), which is quite disturbing. **The expected behavior would probably be that the pink gets transparent after the end of the media (as the media itself)**(and in case of course that the media end is not on "hold" state) * in the specific case of the camera images background the pink rectangle is fully opaque. It then completely occludes the scene and that's a real issue to manipulate the scene. **The expected behavior here is clearly that it should respect the Alpha value set for the camera background.** I think we are at a point where there something really cool to do with this pink rectangle. In the 2D/3D prod application I was in charge of we changed this same filled color we had to more contextual and self-explainatory images. Most of the cases were covered and the user was able to spot the origin of the issue at a single glace without having us to develop specific complex stuff for the UI. Here there are (the Media Cache was used for missing proxy, and the green one was used for textures, allowing us to quickly open a 3D scene while the texture proxies were assynchroneouly being generated): ![ImagesFeedback.jpg](https://archive.blender.org/developer/F8656509/ImagesFeedback.jpg) So let's imagine how helpful these contextual error images would be in Blender, for all users in any editor, and for a development cost that is really reduced !

Richard Antalik commented

2020-07-30 20:21:24 +02:00

Changed status from 'Needs User Info' to: 'Archived'

Richard Antalik closed this issue

2020-07-30 20:21:24 +02:00

Richard Antalik self-assigned this 2020-07-30 20:21:24 +02:00

Richard Antalik commented

2020-07-30 20:21:24 +02:00

I will close this report as it is mostly a feature request and there were some steps taken.

Thanks for the report, but please use other channels for user feedback and feature requests: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

I will close this report as it is mostly a feature request and there were some steps taken. Thanks for the report, but please use other channels for user feedback and feature requests: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Changing the Proxy Render Size of a movie clip used as background image for a camera doesn't affect the quality of the clip in the 3D viewport #78277