<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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>
On 01/29/2014 11:29 AM, Francesco Paglia wrote:<br>
</div>
<blockquote
cite="mid:CAJ8L8Fw_7rBvD=rkxeiBpFkuKUdDUmqmixd4Kz_UzR2xqcfw-Q@mail.gmail.com"
type="cite">
<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 "proxy" solution other software
adopt.</div>
<div>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.</div>
<div>I imagine this sort of pipeline:</div>
<div>
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>
</div>
<div>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.</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"><<a
moz-do-not-send="true" href="mailto:gregzzmail@gmail.com"
target="_blank">gregzzmail@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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's not all that important
either :)</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-Greg</div>
</font></span></div>
<br>
_______________________________________________<br>
Bf-compositor mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bf-compositor@blender.org">Bf-compositor@blender.org</a><br>
<a moz-do-not-send="true"
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>
<br clear="all">
<div><br>
</div>
-- <br>
Francesco Paglia
<div>Vfx and Production Supervisor</div>
<div><br>
</div>
<div>mobile +39 347.82.12.473</div>
<div>
<div>e-mail <a moz-do-not-send="true"
href="mailto:f.paglia.80@gmail.com" target="_blank">f.paglia.80@gmail.com</a></div>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-compositor mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-compositor@blender.org">Bf-compositor@blender.org</a>
<a class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-compositor">http://lists.blender.org/mailman/listinfo/bf-compositor</a>
</pre>
</blockquote>
<br>
</body>
</html>