<div dir="ltr">From my point of view there are at least 2 separate (although related) issues:<div><br></div><div>1) Use relative sizes by default. This requires defining an abstract &quot;canvas space&quot; to which all nodes relate. The render output would usually span across the 0..1 width range and its aspect ratio defines the visible canvas (optionally render output could be set to &quot;portrait mode&quot; to use height instead).</div>

<div>In some cases you may actually want to use pixels (like the pseudo-aliasing mentioned by Greg), but even for blurring etc. a relative size is a better default to ensure the result is largely independent from final resolution.<br>

</div><div><br></div><div>2) Associate offset/size/rotation with things like image input nodes, to avoid having to always add translate/scale (usability feature). By default an image rect can be the full canvas width (this also ensures backward compatibility).</div>

<div>These transforms can be made accessible intuitively with boxes and handles in the compositor backdrop perhaps. We just have to be careful not to add too much noise in the node editor. With such widgets and drawing elements it would do two very different things, which may necessitate some kind of edit mode (nodes mode vs. compo canvas mode).<br>

</div><div><br></div><div>Internally the compositor could still use pixels on the lowest level (operations), but it should have a general mechanism to convert from canvas space into final pixel space reliably. Currently nodes like Translate still access the RenderData from context to convert relative values into pixels, we&#39;d need a few functions to make this a common procedure and independent from render settings (see 1)</div>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 11:29 AM, Francesco Paglia <span dir="ltr">&lt;<a href="mailto:f.paglia.80@gmail.com" target="_blank">f.paglia.80@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div>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 &quot;proxy&quot; solution other software adopt.</div>


<div>We do have another information that we should not forget the &quot;percentage scale for render resolution&quot;  so maybe the behavior has to be careffully taken.</div><div>I imagine this sort of pipeline:</div><div>


doesn&#39;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></div><div>a &quot;proxy render&quot; 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 &quot;as is&quot; to not add other extra level of filtering.</div>


<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-01-29 Greg Zaal <span dir="ltr">&lt;<a href="mailto:gregzzmail@gmail.com" target="_blank">gregzzmail@gmail.com</a>&gt;</span><br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hey folks :)<div><br></div><div>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).</div>


<div><br></div>

<div>So an optional toggle (as with the blur node) would be good in my opinion, but it&#39;s not all that important either :)</div><span><font color="#888888"><div><br></div><div>-Greg</div></font></span></div>


<br></div></div><div class="im">_______________________________________________<br>
Bf-compositor mailing list<br>
<a href="mailto:Bf-compositor@blender.org" target="_blank">Bf-compositor@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-compositor" target="_blank">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
<br></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Francesco Paglia<div>Vfx and Production Supervisor</div><div><br></div><div>mobile  <a href="tel:%2B39%20347.82.12.473" value="+393478212473" target="_blank">+39 347.82.12.473</a></div>
<div><div>e-mail   <a href="mailto:f.paglia.80@gmail.com" target="_blank">f.paglia.80@gmail.com</a></div>

</div><div><br></div>
</font></span></div>
<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" target="_blank">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
<br></blockquote></div><br></div>