<p dir="ltr">I guess the scalability of some effects like glare could be overcome with the use of drivers attached to render percentage. But I find that drivers often aren't called until frame change, making many driver solutions fail (at least during testing period).</p>
<p dir="ltr">As for an active image area I can see the appeal of repurposing the backdrop, as screen real estate can be a challenge with lots of nodes spread across the compositor. Wouldn't it be more useful to enhance the uv image editor window as the one stop shop for all 2d image editing? </p>
<p dir="ltr">In addition I would argue that the viewer node should have a multi slot buffer like the render out window, so we could display alternate node outputs at reasonable resolutions. As the thumbnails in each node are only useful as signposts not comparative analysis. </p>
<p dir="ltr">Btw have a nice holiday. </p>
<p dir="ltr">Cheers<br>
David<br>
On 31 Jan 2014 08:13, "Jeroen Bakker" <<a href="mailto:j.bakker@atmind.nl">j.bakker@atmind.nl</a>> wrote:<br>
><br>
> Hi all, <br>
><br>
> We see that the users are discussing the technical solutions :). First of all we should be very clear about what you want.<br>
><br>
> The nodes that currently have the biggest (relative-resolution) issues are the buffered operations (glare, filter). They assume that the current pixel size is the actual pixel size, but that is not the case. Other popular compositors work on a 'project' resolution, and let the user downscale via a setting or dynamically too speed up the process. Biggest difference is that Blender is an integrated product.<br>
><br>
> From developer perspective we would better see other projects first like:<br>
> - make a decision on backdrop vs image viewer, usage of the viewer node, render node, as this could really have big impact on everything we do, especially when we know we want to have 'canvas-compositing' in the future. this is a project you users could really help with discussing; and we can help in structuring the discussion.<br>
><br>
> So the question would be:<br>
> 1. how does (from an artist point of view) the ideal compositor look like that fits in Blender [artists in lead, developer as consult]. This is also the reason why this list was set up.<br>
> 2. using this as input we (the developers) can break-down it into projects and make a logical order of these projects. [developer in lead, artists as consult]<br>
> 3. per project we can go into details [artists as in lead for the what, developer on lead for the how]<br>
><br>
> We are currently working on memory usage and performance, but have nothing to show yet. See the above as an invitation to discuss the future of the compositor. The next few weeks we won't be able to join the discussion (holiday), but after that it would be nice if there are some big topics we can discuss.<br>
><br>
> Jeroen & Monique<br>
> - At Mind -<br>
><br>
><br>
> On 01/29/2014 11:29 AM, Francesco Paglia wrote:<br>
>><br>
>> Hi all,<br>
>> As Sebastian pointed out in the wiki doc, the solution could be to have the size of the footage/renderlayer fixed to the final resolution and having the temp render files upsized to the proper value like the "proxy" solution other software adopt.<br>
>> We do have another information that we should not forget the "percentage scale for render resolution" so maybe the behavior has to be careffully taken.<br>
>> I imagine this sort of pipeline:<br>
>> doesn't matter which percentage of scale a render is done the renderlayer is always locked to the proper size set in the resolution panel and the test image is just blown up to that size.<br>
>> a "proxy render" can be introduced in the compositing preference so we can easily switch between how many pixel consider to render per time (1/1, 1/2, 1/4, 1/8) and if the rendered picture match one of those resolution just consider it "as is" to not add other extra level of filtering.<br>
>><br>
>><br>
>><br>
>><br>
>> 2014-01-29 Greg Zaal <<a href="mailto:gregzzmail@gmail.com">gregzzmail@gmail.com</a>><br>
>>><br>
>>> Hey folks :)<br>
>>><br>
>>> I agree, relative sizes would be very useful - however in some cases, absolute sizes are important (such as blurring a matte as a cheap form of anti-aliasing).<br>
>>><br>
>>> So an optional toggle (as with the blur node) would be good in my opinion, but it's not all that important either :)<br>
>>><br>
>>> -Greg<br>
>>><br>
>>> _______________________________________________<br>
>>> Bf-compositor mailing list<br>
>>> <a href="mailto:Bf-compositor@blender.org">Bf-compositor@blender.org</a><br>
>>> <a href="http://lists.blender.org/mailman/listinfo/bf-compositor">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
>>><br>
>><br>
>><br>
>><br>
>> -- <br>
>> Francesco Paglia<br>
>> Vfx and Production Supervisor<br>
>><br>
>> mobile +39 347.82.12.473<br>
>> e-mail <a href="mailto:f.paglia.80@gmail.com">f.paglia.80@gmail.com</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Bf-compositor mailing list<br>
>> <a href="mailto:Bf-compositor@blender.org">Bf-compositor@blender.org</a><br>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-compositor">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Bf-compositor mailing list<br>
> <a href="mailto:Bf-compositor@blender.org">Bf-compositor@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-compositor">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
><br>
</p>