On 23/09/2011, at 11:37 AM, Steven Boswell II wrote:
If that's how you expect to use mutexes, an atomic integer would be
a LOT more efficient, e.g. the g_atomic_int functions in glib.
Those are implemented with processor instructions instead of OS
system calls.
I assume I'd need to use
On 23/09/2011, at 1:52 PM, E Chalaron wrote:
>
> The files are in a quicktime container as raw RGB data from cinelerra.
> But ... I suppose I can always denoise before rendering in X264 which
> will be in YUV anyway.
I was just thinking that if you were to implement yuvdenoise for RGB,
how wou
The files are in a quicktime container as raw RGB data from cinelerra.
But ... I suppose I can always denoise before rendering in X264 which
will be in YUV anyway.
>
> Sorry I mean, what file format (or library) would you be reading this
> in as?
>
> yuv4mpeg is in yuv format. I'm not aware of
On 23/09/2011, at 12:20 PM, E Chalaron wrote:
> Cine scan films such as 8, 9.5, super 8 , 16 mm etc ...
> Either in 8 or 16 bits.
Sorry I mean, what file format (or library) would you be reading this
in as?
yuv4mpeg is in yuv format. I'm not aware of an rgb stream format.
Or would you be usi
Cine scan films such as 8, 9.5, super 8 , 16 mm etc ...
Either in 8 or 16 bits.
Cheers
E
On 09/23/2011 02:07 PM, Mark Heath wrote:
>
> What format is using RGB?
>
> Mark
>
--
All of the data generated in your IT infrastr
Hi Steven
Thanks for that. I will have a look, (already printed), but not knowing
anything about writing code, it's unlikely I will achieve the goal.
Cheers
E
On 09/23/2011 01:42 PM, Steven Boswell II wrote:
y4mdenoise's internal engine is written to be VERY flexible. One
could easily modify
y4mdenoise's internal engine is written to be VERY flexible. One could easily
modify it to accept any type of pixel format. Look at the definitions of
MotionSearcherY and MotionSearcherCbCr in newdenoise.cc to see how it's
configured for yuv420p. An RGB-based denoiser would be no big deal.
I
If that's how you expect to use mutexes, an atomic integer would be a LOT more
efficient, e.g. the g_atomic_int functions in glib. Those are implemented with
processor instructions instead of OS system calls.
I've struggled mightily to make y4mdenoise more multiprocessor friendly, and
one of
Thanks for the input.
I did read up about the Thread Pool (Boss/worker) Pattern and
implemented something along these lines.
I was thinking about the most likely places to divide a file.
* time range based
* Frame based
* Slice based (range of lines)
* line based
* pixel based
Time range i
Hi Steven
Can y4mdenoise accept a sequence of TIFF RGB files ? or just YUV colorspace?
To my (limited) knowledge a temporal full RGB denoiser does not exist
for Linux ... Or am I wrong :-) ?
Cheers
E
On 09/23/2011 12:00 PM, Steven Boswell II wrote:
y4mdenoise does that sort of threading intern
y4mdenoise does that sort of threading internally. It'll denoise the intensity
plane and color plane separately, plus it has reader threads and writer
threads. I wrote a small thread-related class hierarchy that should be
reusable. If nothing else, it should be inspirational.
BTW, you probab
Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).
So now this
12 matches
Mail list logo
