I guess he is talking of algorithm where the entire buffer needs to be
evaluated before processing the pixels. Like knowing which is going to be
the Max Luma value in your buffer to divide all your pixels by this value.
(very simple example, but just for the case) or something like Retinex
algorith
Hi,
I missed some IRC chats on this subject and there are some definition
problems. Like what are tiles in the perspective of a user/artist and
what are tiles in perspective of parallelization.
Both definitions are right, but developers and users mix the definition
and the meaning. Sorry for th
Hi Jeron,
> Please help me to determine the case when a whole output image is
> needed. IMO input is readonly and output is writeonly. I don't see the
> need atm to support whole output images in a 'per output pixel'
> approach. And every 'per input pixel' approach can be written by a 'per
> outpu
On Sat, Jan 22, 2011 at 8:11 PM, Aurel W. wrote:
> I also realize that the argument "it would work with the current
> compositor" is a strong argument. But I got some problems with that.
> First of all I think that a compositor should be in principal be able
> to support all image processing opera
> On the contrary, I think the compositor should be designed and
> optimised for its purpose, compositing CGI/vfx imagery. It doesn't
> need to be a completely generalised image processing system, it just
> needs to do what it's intended for, well. So far I've seen a mostly
> theoretical objections
>
> Jeron : Like what are tiles in the perspective of a user/artist and
what are tiles in perspective of parallelization.
Both definitions are right, but developers and users mix the definition
and the meaning. Sorry for that.
Thats what I thought :)
Aurel : Again, just examples for operati
> some gradiant base algorithm & very fast blur are in needs of full buffer
> for sure, but I don't understand why some nodes cannot says "I need full
> buffer, so I'll wait all my parents to compute and give me a FB as input"
> and other nodes (by default) based on tiles. So only a few would be s
Hi,
To be honest, long winded discussions on ways how to implement stuff
should not take away the freedom for a developer to find out him/
herself the optimal cases. I'm confident that Jeroen is aware of
boundary cases here, and he will try to find a good balance for
practical usage.
For a
Hi Martin,
Not capable of grasping your discussions with Campbell on this topic,
I proposed to ask arbitration by a third person who knows this well.
We're all equally stubborn fallible humans you know, and who's "right"
or "wrong" then is less relevant than just moving forward. :)
If you t
Hi Ton,
I'll try to explain this as simply as possible.
Registering python classes with the RNA system has to be done in a specific
order to solve dependency issues.
Unregistering (when unloading) also has to be done in a specific order (not the
same, maybe not just reverse order).
There are
Hi,
Yes that sounds clean and clear. But apparently there's more ways to
solve the problem, and either way has pros and cons. When visions on
such problems don't align, then how to decide? The maintainers and
main contributors to the code then can have a final word.
-Ton-
-
Hi,
The problem I have with taking a decision now is that we haven't solved the
order problem.
If it turns out to require very complex rules, it might be easier to solve
automatically than manually (or vice versa).
What I mean is that I don't think we have all the data to take a good decision
Hi,
I don't really see the order problem as a problem we have to solve. If
you're registering multiple things, then it seems logical to me that
if A references B, you register B first and then A. It's not clear to
me where these potential complex rules would show up?
Brecht.
On Sat, Jan 22, 2011
a small comment if the core developers/ designers of the api can't
decide which way is 'right':
Don't change what's there. If there is controversy, it probably means
there are pros and cons both ways; any change comes with a cost- every
script has to be modified to work. In he case of stuff that sh
--- On Sat, 1/22/11, Brecht Van Lommel wrote:
> I don't really see the order problem as a problem we have
> to solve. If
> you're registering multiple things, then it seems logical
> to me that
> if A references B, you register B first and then A. It's
> not clear to
> me where these potential
On Sat, Jan 22, 2011 at 9:28 PM, Martin Poirier wrote:
>
>
> --- On Sat, 1/22/11, Brecht Van Lommel wrote:
>
>> I don't really see the order problem as a problem we have
>> to solve. If
>> you're registering multiple things, then it seems logical
>> to me that
>> if A references B, you register B
Hi,
I'm sorry, as actually I would need to dig into details to understand all
the subtleties,
but few sparse thoughts
order:
is it possible to have a two step registration? such that first - there map
is created ( or graph
http://www.boost.org/doc/libs/1_45_0/libs/graph/doc/index.html ) like it
Hi,
j.bak...@atmind.nl (2011-01-22 at 0952.44 +0100):
> image. The highest/lowest value is calculated once (not parallelized)
> the pixel processor is parallelized.
Not very good example ;] as this searching problem is near as much
parallelizable as the pixel processor would be. Split the work in
18 matches
Mail list logo
