Forums > Jitter

jit.dx.grab : how to deinterleave DV input ?


February 7, 2006 | 10:23 am

When I use my PAL DV cam with jit.dx.grab @dim > 320 240 (for ex : 640×480 or 720×576) I get an interleaved video.
(example : http://mathieu.chamagne.free.fr/max/dx.grab_720-576-interlea ved.jpg )

If I use jit.demultiplex, I get 2 matrixs of 720×288…
of course, I searched in the mail archive, but found nothing about "deinterleave, demultiplex, deinterlace…"
(what’s the difference between interleave, interlace, multiplex?…)

So, my question is : how can I get a "normal" image in PAL DV with my camera & jit.dx.grab ?

(MaxMSP 4.5.6 Jitter 1.5.2 for windows / P4 3Ghz / Sony HDR-HC1E PAL camera)

Thanks in advance

Mathieu Chamagne
http://www.maxobjects.com

February 7, 2006 | 6:54 pm

On Feb 7, 2006, at 2:23 AM, Mathieu Chamagne wrote:

> (what’s the difference between interleave, interlace, multiplex?…)

Nothing. Just different words for the same thing. Multiplex is a more
generally used term, which since Jitter is not video specific, the
reason it was chosen.

> So, my question is : how can I get a "normal" image in PAL DV with
> my camera & jit.dx.grab ?

Typically for deinterlacing you either throw away every other scan
line and upsample, or use computer vision techniques (which can be
slow for realtime operation). We don’t support the latter in the
JItter standard distribution, but you might be able to use the cv.jit
objects to accomplish this, though it might be cumbersome. There is
also at least one freeframe deinterlace object which might do
something more than just lose every other scanline and upsample with
interpolation, but I haven’t checked it out.

You can accomplish this with [jit.dx.grab 720 576]->[jit.matrix 4
char 720 288]->[jit.matrix 4 char 720 576 @interp 1] for CPU based
interpolation, or replace the final jit.matrix with jit.gl.videoplane
or jit.gl.texture to use HW accelerated interpolation. You can also
make use of colormode uyvy for added speed benefits, and the
interpolation will work fine (poses problems with the chromatic
downsampling if resizing about the downsampled horizontal axis).

Of course the *best* way to avoid this problem is to use a
progressive scan camera in progressive scan mode.

-Joshua

February 8, 2006 | 10:34 am

Thanks for your help, Joshua.

I tried the "deinterlace" Freeframe plugin (PetesPlugins_FreeFrame1.15 pack) wich works great with others freeframe hosts (foe ex vvvv Toolkit), but with jit.freeframe, i get very strange results : white parts of image becomes yellow !
http://mathieu.chamagne.free.fr/max/freeframe_deinterlace_ar gb.jpg
http://mathieu.chamagne.free.fr/max/freeframe_deinterlace_uy vy.jpg

too bad, it seems to be the cheaper and easier solution to really deinterlace (not just interpolate 720*288 -> 720*576).

Would it be possible to make a .jxs for jit.gl.slab to make this job in the GPU ?

It’s the first time I’m trying to work with a DV cam in full resolution with Jitter, and I would find it very anoying to use half of my CPU power just to get a "clean" deinterlaced video input…
I’m sure that I’m not the only one to use a non-progressive scan camera with jitter ; I would be very curious to know how people usualy deal with this problem…

Mathieu Chamagne
http://www.maxobjects.com

February 9, 2006 | 10:20 am

For jit.qt.grab, we were able to implement an internal "singlefield"
filter. I will need to do a little research to see if this would also
be possible for jit.dx.grab. It would probably be the cheapest
option, CPU-wise.

Thanks for the freeframe report. I will check it out.

jb

February 9, 2006 | 11:00 am

an internal filter in jit.dx.grab would be very useful, I think…

and what about doing it in the GPU (jit.gl.slab) ?

Mathieu

February 9, 2006 | 9:18 pm

On Feb 9, 2006, at 3:00 AM, Mathieu Chamagne wrote:

> an internal filter in jit.dx.grab would be very useful, I think…
> and what about doing it in the GPU (jit.gl.slab) ?

Just drop every scanline before sending to GPU as a texture. It will
interpolatedly upsample, which is all the singe scanline filter
inside jit.qt.grab does.

-Joshua

April 14, 2008 | 10:28 am

Hi Jeremy,

I’m trying jit.qt.grab.help at 720×576 with a DFG/1394 1e but the singlefield attribute doesn’t visually change the output; it still looks interlaced with the attribute set to 1.

Joshua’s solution with two jit.matrix’s works well but is slow, the solution with one jit.matrix and jit.gl.videoplane works well and is not slow.

Btw I assume that nobody happened to make a ‘proper’ deinterlacing shader in the mean time?

Mattijs

Mac OS X.4.11, Max 4.6.3, Jitter 1.6.3, Sony DCR-VX2000E

Quote: Jeremy Bernstein wrote on Thu, 09 February 2006 11:20
—————————————————-
> For jit.qt.grab, we were able to implement an internal "singlefield"
> filter. I will need to do a little research to see if this would also
> be possible for jit.dx.grab. It would probably be the cheapest
> option, CPU-wise.
>
> Thanks for the freeframe report. I will check it out.
>
> jb
>
—————————————————-

April 18, 2008 | 3:21 pm

Update (for the archives): I found out that the DFG/1394 1e has a built-in setting to leave out odd or even frames.

No need for any additional matrix or shader operations there (although simply leaving out half of the data is still a relatively crude way to de-interlace).

Mattijs

Quote: Mattijs wrote on Mon, 14 April 2008 12:28
—————————————————-
> Hi Jeremy,
>
> I’m trying jit.qt.grab.help at 720×576 with a DFG/1394 1e but the singlefield attribute doesn’t visually change the output; it still looks interlaced with the attribute set to 1.
>
> Joshua’s solution with two jit.matrix’s works well but is slow, the solution with one jit.matrix and jit.gl.videoplane works well and is not slow.
>
> Btw I assume that nobody happened to make a ‘proper’ deinterlacing shader in the mean time?
>
> Mattijs
>

Viewing 8 posts - 1 through 8 (of 8 total)

Forums > Jitter