Searching \ for '[PIC:] Watermarking video with a PIC or SX' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ubicom/lib/io/index.htm?key=video
Search entire site for: 'Watermarking video with a PIC or SX'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Watermarking video with a PIC or SX'
2004\02\03@180803 by Jinx

face picon face
I've been asked by a small production company whether it's
possible to watermark a video with their company logo. My
initial response was "probably", now I have to prove it !

I know a little about the format of TV scan lines (PAL in this case)

http://www.epanorama.net/documents/video/pal_timing.html

and woud like suggestions on how this could be accomplished.
The only signal available is composite, as in that link's picture

"Watermarking", as they describe it, is a shape on the picture
created by altering the brightness. The graphic is translucent,
rather than opaque super-imposed pixels. They also indicated
that the watermarking should have several levels of brightness
alteration to give it more depth. It'll be around 1" square in the
bottom right corner

As the graphic will be a known shape at a known position, I
wonder if a fast video ADC can be used to measure the original
pixels where the graphic needs to be and then use a look-up
table in the micro to alter the brightness. Then it gets written back
with a video DAC. As the whole line takes just 52us to scan and
the area of interest is maybe only ~3us of this, that suggests to me
that alterations will be seen one frame later. I can't see a micro
being able to implement ADC > change > DAC in real time. A 50
or 75MHz SX could easily do the pixel timing I'm sure, although
who knows what analogue conversion and switching problems
are likely to appear

But maybe someone has a better idea of how this could be done.
Links to anything relevant would be appreciated too. I've already
had a look at sites describing PIC- and SX-generated video signals,
but it's not really the same thing

TIA

==============================================
Research is what I'm doing when I don't know what I'm doing
- Wernher von Braun

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@183428 by Dmitriy Fitisov

flavicon
face
TIA,
first of all - what kind of watermark is supposed to be?
Color or b/w? B/W many times simpler. With color it is may be a pain
to synchronize with crystal phase to produse correct color.
2. Do everything on the fly -> Enter -> Your Device -> Exit
   Anything will be in the same frame.
3. Why do you need a DAC? I think 4-6 resistors may do the trick.
4. No need for 75 MHz whatsoever - changing faster then 6-8 MHz
   on conventional TV will be limited by filtr to that limit.
   So, you have to change your signal while in the place of
   watermark by values of "watermark". I'm trying to say, that
   you probably should have fast programmable operational amplifier,
   let the signal pass through. While in watermark zone - change
   the amplifier's coefficient by level of your "watermark" signal.


Dmitriy Fitisov.
http://www.radier.ca/pic/pictimer.php

{Original Message removed}

2004\02\03@184257 by Brent Brown

picon face
On 4 Feb 2004 at 12:08, Jinx wrote:
> As the graphic will be a known shape at a known position, I
> wonder if a fast video ADC can be used to measure the original
> pixels where the graphic needs to be and then use a look-up
> table in the micro to alter the brightness. Then it gets written back with
> a video DAC. As the whole line takes just 52us to scan and the area of
> interest is maybe only ~3us of this, that suggests to me that alterations
> will be seen one frame later. I can't see a micro being able to implement
> ADC > change > DAC in real time. A 50 or 75MHz SX could easily do the
> pixel timing I'm sure, although who knows what analogue conversion and
> switching problems are likely to appear

Just a fairly vague idea to consider: Instead of doing it digitally with ADC and
DAC, what if you switch in a resistive divider network to alter the signal level
(brightness). You may just get enough resolution using timer 2 and compare
registers to give you "on" and "off" times relative to each line sync pulse.
Adding another resistor gives you more levels of brightness but then
changing brightness at pixel clock speed becomes a problem.

Brent.

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  spam_OUTbrent.brownTakeThisOuTspamclear.net.nz

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@184504 by Mike Harrison

flavicon
face
On Wed, 4 Feb 2004 12:08:03 +1300, you wrote:

{Quote hidden}

You probably don't need  (or want) to convert the signal to digital and back - you can modulate the
intensity by applying a small voltage shift to the video signal - a crude 3 or 4 bit DAC made out of
a few resistors would do the trick.

There are a number of onscreen display (OSD) generation chips, which may be useable for this, if you
can sync them to the incoming video.
It might just be feasable to do it with a very fast PIC, but you would need to PLL-lock the clock to
get stable timing, and you may need an external shift-register to get a fast enough pixel clock.
A  PIC with a small GAL to do the fast timing ought to do the trick. You might be able to use the
sync. serial port as the shift register, but this would only give you one bit per pixel.

Quick back-f-an-envelope design....

Lets say you want 32 pixels in the 3us window, this gives a pixel rate of about 10MHz. Assuming a PIC18 running at 40MHz, this gives you a 10MHz instruction rate.
You could just manage a burst of 3-bit pixels at this rate with external latching - you can load a
byte into an output port in two instructions (or is it one on the 18F?). This byte would contain two
3-bit-pixels, and another bit which changes on each 8-bit load, which is used by external hardware
to get the pixel alignment right (the external hardware needs to know the relationship of the pic
clock to the load operations)
A GAL16v8 could probably do this.   Vertical position would be determined by counting line syncs

As for syncing to the video, you need to generate the PIC clock with a VCO, and phase-compare the
incoming sync with the PIC's sync. You may be able to be clever and do much of this in software - if
you used the PIC's input capture on the incoming sync, you could measure the difference between the
external sync and the PIC's sync, and output a VCO control voltage via the PWM - the external
hardware would then just be a VCO and a lowpass filter (probably just 2Rs and 2 Cs) to filter the
PWM signal into the VCO control voltage.

 
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@190006 by Herbert Graf

flavicon
face
{Quote hidden}

       I think you've got the right basic idea, however, I wouldn't sample the
video with an ADC. Just use an analog block that has a switchable "addition"
to a signal, depending on how you design it you could make it a variable
addition, controlled by a DAC perhaps? Aside from that you just need a chip
to separate out the sync signals and them simply some counters. TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@190210 by M. Adam Davis

flavicon
face
You may want to look at getting two complementary chips - one which
converts the composite to color channels and one which converts back to
composite.  (or YUV values, if you simply want to mess with the
brightness instead of the color)

Your chip simply listens to the sync pulses, and at the right time for
each scan line spits out a series of pulses that control a resistor
divider in the brightness line.

If you want to do anything more complex you'll either end up using a lot
of support circuitry with the PIC simply controlling the timing, or
using a different method/microcontroller altogether.

I don't think the PIC would be up to 'broadcast quality' though.

Good luck!

-Adam

Jinx wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@190623 by Mike Harrison

flavicon
face
>Lets say you want 32 pixels in the 3us window, this gives a pixel rate of about 10MHz. <snip>
Another thought - if you have a few bits of intensity control you can trade this off against pixel
resolution to some extent, possibly reducing the required pixel rate from not-possible to
possible,,!

I'd also suggest looking at AVRs, as their max clock rate may be a little higher, and their register
based architecture is more suitable for creating short bursts of very fast data :
out porta,r1
out port1,r2
etc...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@191911 by Jinx

face picon face
>  4. No need for 75 MHz whatsoever - changing faster then 6-8 MHz

I was think of the pixel timing, rather than the BW of the signal

> on conventional TV will be limited by filtr to that limit.
> So, you have to change your signal while in the place of
> watermark by values of "watermark". I'm trying to say, that
> you probably should have fast programmable operational amplifier,
> let the signal pass through. While in watermark zone - change
> the amplifier's coefficient by level of your "watermark" signal

I'll look into video-speed amps

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@194638 by Dmitriy Fitisov

flavicon
face
>  4. No need for 75 MHz whatsoever - changing faster then 6-8 MHz

I was think of the pixel timing, rather than the BW of the signal

---
?? I do not quite understand, sorry. I meant most speed which usable is 8
MHz for
  pixels - ok, may be 10 MHz. For example, good old Sinclair/Spectrum
computer
  20 years ago used this speed for on-screen letters.
  Of course, internal speed of the chip needs to be higher - no doubt.

> on conventional TV will be limited by filtr to that limit.
> So, you have to change your signal while in the place of
> watermark by values of "watermark". I'm trying to say, that
> you probably should have fast programmable operational amplifier,
> let the signal pass through. While in watermark zone - change
> the amplifier's coefficient by level of your "watermark" signal

I'll look into video-speed amps
--
http://www.njr.com have some video chips - I myself want to order
some for Macrovision remover. Regarding separation HSYNC, VSYNC - LM1881 is
most popular, I think.

LF398 probable is suitable for black level sample-and-hold.

Dmitriy Fitisov
----------------
http://www.radier.ca/pic/pictimer.php

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@195300 by Jinx

face picon face
> I'd also suggest looking at AVRs, as their max clock rate may be
> a little higher, and their register based architecture is more suitable
> for creating short bursts of very fast data

I have tools for all 3 - PIC, SX and AVR. SX are the fastest with a 1:1
MHz : MIPS ratio. Yet to determine whether full speed capabilities of
any of those mentioned are needed. I'm tempted to start with a high-
speed simple device like the SX, as the sorts of peripherals the PIC
and AVR has aren't necessary

Thanks for replies suggesting resistor networks. That makes sense
in hind-sight (doesn't everything ?). Level-shifting is all that's required,
and it would be a lot faster than ADC-DAC. Maybe at a later stage I
could try signal-splitting for colour changes

Synching the micro to the signal should be fairly straight-forward, but
we'll see.......

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@195534 by Jinx

face picon face
> >  4. No need for 75 MHz whatsoever - changing faster then 6-8 MHz
>
> I was think of the pixel timing, rather than the BW of the signal
> ---
> ?? I do not quite understand, sorry. I meant most speed which usable
> is 8 MHz for  pixels

We're talking about two different things. I'm talking about using a fast
micro so that there are plenty of instruction cycles available for timing
and processing, I think you're talking about the speed at which pixels
are displayed by the video

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\02\03@222929 by Bob Ammerman

picon face
Use a multiplying DAC. These take an analog input, multiply it by a digital
word and create an analog output.

You could use a prepackaged DAC, or since you really only need a few
multipliers (for brightness levels), you could cobble it together with
discrete parts.

Bob Ammerman
RAm Systems


{Original Message removed}

2004\02\04@033855 by Philip Pemberton

face picon face
In message <013d01c3eaaa$bf3705e0$7223fea9@jc2>
         Jinx <.....joecolquittKILLspamspam@spam@CLEAR.NET.NZ> wrote:

> As the graphic will be a known shape at a known position, I
> wonder if a fast video ADC can be used to measure the original
> pixels where the graphic needs to be and then use a look-up
> table in the micro to alter the brightness.
How about using an EPROM, a DAC and a mixer?
Basically, you have a counter that drives the EPROM, reset on every vsync,
started on a Hsync and reset after 56uS (or whatever). The output of the
EPROM is fed through a resistor-ladder DAC, which is then added to the video
signal. IOW, black becomes a slightly lighter mid-grey. OTOH, you could have
it darken the video (more fun!).
The timing stuff would be a pig to implement, but it's all doable in logic.

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
philpemspamKILLspamdsl.pipex.com              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.dsl.pipex.com/  | 48xCD, ARCINv6c IDE, SCSI

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@034308 by

picon face
Jinx wrote :

> I've been asked by a small production company whether it's
> possible to watermark a video with their company logo. My
> initial response was "probably", now I have to prove it !

> It'll be around 1" square in the bottom right corner

Independent on the total screen size ? Or maybe rather a
fixed % of the high/width of the screen ?

Jan-Erik.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@042459 by Alan B. Pearce

face picon face
>
>As the graphic will be a known shape at a known position, I
>wonder if a fast video ADC can be used to measure the original
>pixels where the graphic needs to be and then use a look-up
>table in the micro to alter the brightness. Then it gets written back
>with a video DAC. As the whole line takes just 52us to scan and
>the area of interest is maybe only ~3us of this, that suggests to me
>that alterations will be seen one frame later. I can't see a micro
>being able to implement ADC > change > DAC in real time. A 50
>or 75MHz SX could easily do the pixel timing I'm sure, although
>who knows what analogue conversion and switching problems
>are likely to appear
>
>But maybe someone has a better idea of how this could be done.
>Links to anything relevant would be appreciated too. I've already
>had a look at sites describing PIC- and SX-generated video signals,
>but it's not really the same thing

I would be tempted to do all the timing in some form of FPGA or other
programmable logic. The advantage of doing this would be that you may have
enough gates to set up 4 possible fixed positions (left, right, top, bottom
corners) and then select those using an outside micro, although 4 select
lines to switches may do.

In the FPGA run counters that are synchronized to the line and frame rates,
and then do compares. As others have suggested use several outputs from the
FPGA into an R/2R network to get the brightness boost. It should be possible
to build such a network using SIL or DIL resistor packs with a fast op-amp
to buffer and mix the output with the video signal (Maxim make video buffer
op-amps). My pick would be that you should be able to do all the brightness
levels you need with 3 binary lines (8 levels)

On thinking about it, you can probably do the line pulse count in the PIC,
having a bit map in the FPGA which is just the line count height of the
logo, probably +2 lines so you have a blank line above and below the logo in
the bitmap. Then the PIC does the line count to the insertion line of the
blank line above the bit map, and tells the FPGA to start insertion on the
next line. The FPGA then needs an input to signify is it needs left or right
insertion.

Note that to get a stable logo on the screen, you may have to clock the FPGA
quite fast. It is a while since I dealt with PAL signals, but remember going
through the theory when an apprentice, just as colour TV was being
introduced to NZ. I recall that the colour burst frequency is related to an
integer+0.25 of the line rate frequency. The extra quarter is related to the
way the phase of the subcarrier is switched +/-90 degrees between lines to
minimise the colour shifts that were a bane of NTSC signals due to path
phase shifts, and to get a stable logo on screen you may need to clock your
FPGA at something like 4x the colour burst frequency because of this. Some
experimentation should soon sort this out. Also consider the possibility
that you may need to have some sort of lock to the colour burst in the
signal being inserted into. This should be easily done using standard TV
chips to recover the sync signals which you will need anyway.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@045201 by Jinx

face picon face
Multi-answer reply

==============================================

> How about using an EPROM, a DAC and a mixer?
> Basically, you have a counter that drives the EPROM, reset
> on every vsync, started on a Hsync and reset after 56uS (or
> whatever). The output of the EPROM is fed through a resistor-
> ladder DAC

I think that's pretty much how it could be. The shapes can of
course be in the micro's memory. It's going to be there for
timing anyway

It's similar to the way those message wands work. A tilt switch
is the "synch" and a clock puts the EPROM's or RAM's data
onto a LED-driving buss

==============================================

> > It'll be around 1" square in the bottom right corner

> Independent on the total screen size ? Or maybe rather a
> fixed % of the high/width of the screen ?

Fixed %. 1" was just an estimate for an average screen, say
23". It's actually probably a little more than that

==============================================

> If you don't have a precise lock, your logo will 'swim' or jitter as
> the uP clock beats against the video line rate. If your video is
> coming from a tape source, the problem is compounded by
> mechanical jitter unless it's time base corrected

Understood. Then wouldn't that also be true for the original video ?
So the graphic I want to add would jitter as much as the pixels on
any scan line. Given that the spec I looked up shows some tolerance
for synch pulses, how would I know when there's been mechanical
jitter, and what could I do (if anything is really needed to be done) to
correct that ?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@050409 by Dmitriy Fitisov

flavicon
face
Counting lines is one part.
The biggest chalenge may come with brightness.
What would you do on totally black screen? On totally white?
May be you have to have some type of inversion - if the underlying
image is too bright - show inverse watermark.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@051032 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Dmitriy Fitisov [RemoveMEdmitriyTakeThisOuTspamRADIER.CA]
>Sent: 04 February 2004 10:03
>To: spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU
>Subject: Re: [PIC:] Watermarking video with a PIC or SX
>
>
>Counting lines is one part.
>The biggest chalenge may come with brightness.
>What would you do on totally black screen? On totally white?
>May be you have to have some type of inversion - if the
>underlying image is too bright - show inverse watermark.

The water mark could be shown by just inverting the video, no brightness
issues to worry about unless the whole area of the watermark happens to be
at exactly half video level brightness.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
TakeThisOuTpostmasterEraseMEspamspam_OUTbookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@051655 by Tim ODriscoll

flavicon
face
On Wed, 4 Feb 2004, Jinx wrote:
> But maybe someone has a better idea of how this could be done.
> Links to anything relevant would be appreciated too. I've already
> had a look at sites describing PIC- and SX-generated video signals,
> but it's not really the same thing

Jinx,

Ages ago I was messing around with something similar, but shelved it for a
rainy day. I managed to use an LM1881 to seperate out the sync signals,
then a 16F84 to count X horizontal pulses from each vertical pulse and
pull the video line high for a few instructions through a resistor
network. I managed to get a white bar in the middle of the picture, but
never finished it off. I got the feeling my '84 wasn't quick enough for
anything decent, so went onto something else.

I did find this chap's web site though:
http://www.rickard.gunee.com/projects/

He's well into his PIC and video stuff. I learnt a lot from his site.

Good luck,

Tim

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@051656 by Wouter van Ooijen

face picon face
> The water mark could be shown by just inverting the video, no
> brightness
> issues to worry about unless the whole area of the watermark
> happens to be
> at exactly half video level brightness.

IMHO not a very well-worked out idea. Showing in white is no problem
unless the whole area is white, idem for black. so this is no
improvement. Any method that says 'this will always work unless...' is
flawed. I did not follow this thread, but IMHO the only method that
always works is to have a watermark with a high-contrast contour, like
black letters with a white border.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@052316 by hael Rigby-Jones

picon face
{Quote hidden}

The chances of having a black screen at some stage are very high, chances of
having a full brightness white screen slightly less so, but the chances of
having a half video level screen must be remote to say the least.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmasterTakeThisOuTspamspambookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@052731 by

picon face
Why whatermark a screen with no valuable content
(100% black or 100% white) at all ? Does it realy
matter that the whatermark isn't visible in those
cases ?

Jan-Erik.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@052938 by Dmitriy Fitisov

flavicon
face
>The chances of having a black screen at some stage are very high, chances
of
>having a full brightness white screen slightly less so, but the chances of
>having a half video level screen must be remote to say the least.

>Regards

>Mike

------------------------------------------
No need to have whole screen white - enough to have it in the watermark
place.
2. The question is - if there is a requirement the watermark should be
visible
always - no chances should be taken.


Dmitriy



=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
postmasterSTOPspamspamspam_OUTbookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservSTOPspamspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@053805 by Alan B. Pearce

face picon face
>Why whatermark a screen with no valuable content
>(100% black or 100% white) at all ? Does it realy
>matter that the whatermark isn't visible in those
>cases ?

Ahh, a man who hasn't watched a Sky movie or sports broadcast :)) About the
only time there is no watermark on the screen is during the adverts.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@054013 by Jinx

face picon face
> Why whatermark a screen with no valuable content
> (100% black or 100% white) at all ? Does it realy
> matter that the whatermark isn't visible in those
> cases ?

No, not really. It's hard to imagine that an area of the
picture would be totally white or black for the whole
video. The only exception would be if the picture was
in letterbox format or had some other frame, but in
that case the watermark would be moved. Once the
system for putting it at one place is sorted out it would
simply be a matter of changing a few values to move it
to any position. Even with pots on AD pins

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@063911 by Mike Harrison

flavicon
face
>Note that to get a stable logo on the screen, you may have to clock the FPGA
>quite fast.

You have 2 options - either clock it so fast that a 1-clock jitter will not be noticeable, or
phase-lock a pixel-rate clock.

The high-rate clock will always have some jitter/crawl, and is also likely to introduce colour
artifacts.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@071309 by Alan B. Pearce

face picon face
>The high-rate clock will always have some jitter/crawl,
>and is also likely to introduce colour artifacts.

This is why I was suggesting clocking it at 4x the colour burst frequency,
which gives a clock rate of 17.734475MHz for PAL.

In looking for the colour burst frequency, Google gave me this site when
looking for "Pal colour burst"
esehttp://www.essex.ac.uk/~tim/DIG_PAL/

which gives the formula for the colour burst frequency, in relation to the
line frequency.

same search gives http://www.shootfirst.co.uk/standards.htm as a good guide
to the different standards, and where they are used (including having PAL
with a 3.58MHz colour burst!)
http://www.southgatearc.org/atv/black&burst.htm has a suitable discrete
amplifier/buffer, but I would personally use one of the Maxim/Dallas chips.

http://www.irl.cri.nz/msl/services/time/ is how the various standards,
including the TV standards, are monitored in NZ

http://www.serasidis.gr/circuits/colour_bar_gen/colour_bar_gen.htm someone
generating colour bar test signals using an AVR, possibly useful to Jinx's
original request.

http://www.howell1964.freeserve.co.uk/logic/colour_modulation.htm might have
some useful background info.

http://www.semiconductors.philips.com/acrobat/datasheets/TDA8310A_2.pdf is a
Picture in Picture processor from Philips, which may all you need for the
video side.

http://tallyho.bc.nu/~steve/palplus.html looks like a pretty good
description of PalPlus which gives you wide screen TV, while maintaining
compatibility with standard 4;3 aspect machines.

Hmm, that's gone rather off topic, but hopefully Jinx will pull some bits
out of there.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@072553 by Jinx

face picon face
Thanks for links Alan. That's tomorrow's reading sorted !

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv.....spamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@082729 by Mike Harrison

flavicon
face
On Wed, 4 Feb 2004 12:12:34 -0000, you wrote:

>>The high-rate clock will always have some jitter/crawl,
>>and is also likely to introduce colour artifacts.
>
>This is why I was suggesting clocking it at 4x the colour burst frequency,
>which gives a clock rate of 17.734475MHz for PAL.
But it will still need to be phase-locked to the incoming sognal, otherwise you will get
jitter/crawl.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservKILLspamspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@084013 by Alan B. Pearce

face picon face
>>This is why I was suggesting clocking it at 4x the colour burst frequency,
>>which gives a clock rate of 17.734475MHz for PAL.
>But it will still need to be phase-locked to the incoming sognal,
>otherwise you will get jitter/crawl.

But a certain amount of the phase locking circuit is already there, in that
you need to lock to the frame and line pulses. Provided those are locked to
suitable precision, then any +/-1 clock jitter at 17+MHz will be minimal, by
the time it has passed through a low pass filter that will cut off at around
1/3 to 1/2 clock frequency. It may be that to get the absolute minimum the
oscillator will need to have a divider that phase locks the oscillator to
the line pulse, but I suspect it will be minimal difference if the micro is
just locked to the line frequency. Jinx specifically stated in his first
post that it is in combined video, and even in a studio this will have
frequency limits at around 6-7MHz I would expect. after transmission it will
be filtered to around 1/4 clock frequency, so the edges will get reasonably
rounded, and the jitter be negligible to a viewer.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@090056 by Dave Tweed

face
flavicon
face
Jinx <RemoveMEjoecolquittspamspamBeGoneCLEAR.NET.NZ> wrote:
> "Watermarking", as they describe it, is a shape on the picture
> created by altering the brightness. The graphic is translucent,
> rather than opaque super-imposed pixels. They also indicated
> that the watermarking should have several levels of brightness
> alteration to give it more depth. It'll be around 1" square in the
> bottom right corner

I think that in order to have a unit that's really acceptable for
use in a broadcast production environment, you aren't going to be
able to cut corners at all in terms of video quality and interface
flexibility. The method outlined below would be top-notch in all
respects.

I happen to be working on a box right now that could do this in a
heartbeat, but it's way overkill for just doing a logo. You could
boil it down to just three chips, plus a microcontroller to provide
a user interface if required.

I use a Philips SAA7118E decoder chip, which takes broadcast standard
video signals in almost any imaginable format -- NTSC, PAL, SECAM and
all their variations -- and using almost any type of connection --
composite, Y/C (a.k.a. S-video), YUV components and RGB components.
The component inputs can either use sync-on-Y/G or separate composite
sync. This chip gives you a 27 MHz stream of bytes in ITU BT.656
format, perfectly line-locked to the input signal.

The second chip would be a small Xilinx FPGA that modifies the Y
component only to produce the logo, reading the logo data out from
internal memory. If the logo and its position are fixed on the screen,
then no user interface is required. However, if it needs to be turned
off/on, moved to different positions, or have its content changed
from time to time, I'd add a microcontroller to handle those details.

The third chip is a Philips SAA7129A encoder chip, which takes the
modified digital video data stream from the FPGA and converts it back
to any of the formats and connection types mentioned above.

This is probably very close to how the commercial units do it (I'm
told that these are the chips used in Tivo, for example), and as
someone else mentioned, that's probably the best option. But if
you feel up to building your own, that's where to start looking.

-- Dave Tweed

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@091516 by Bob Axtell

face picon face
Alan B. Pearce wrote:

> But a certain amount of the phase locking circuit is already there, in that
> you need to lock to the frame and line pulses. Provided those are locked to
> suitable precision, then any +/-1 clock jitter at 17+MHz will be minimal, by
> the time it has passed through a low pass filter that will cut off at around
> 1/3 to 1/2 clock frequency. It may be that to get the absolute minimum the
> oscillator will need to have a divider that phase locks the oscillator to
> the line pulse, but I suspect it will be minimal difference if the micro is
> just locked to the line frequency. Jinx specifically stated in his first
> post that it is in combined video, and even in a studio this will have
> frequency limits at around 6-7MHz I would expect. after transmission it will
> be filtered to around 1/4 clock frequency, so the edges will get reasonably
> rounded, and the jitter be negligible to a viewer.
>

I'm not sure what was originally needed. If the intention is to prove
that a piece of video is actually yours, that CAN be done with a PIC
operating as fast as possible, hopefully at 14.31818 x 2 (NTSC) or 17m x
2 (PAL). You use an LM1881 to count lines, then have the PIC write a bit
burst into a Vertical Interval line by using a Maxim video switch, i.e.
paint the line white at that spot. Each bit will cover several pixels,
but the idea is for it to be SEEN.

To see your "watermark" simply misadjust the vertical height of any
monitor and read the bit burst. You can fit about 32 bits into the
Vertical Interval.

--Bob

--

 Replies: NOTE-Script, EXE,BAT and COM
    files will be rejected by server
             --------------
               Bob Axtell
       PIC Hardware & Firmware Dev
         http://beam.to/baxtell
             1-520-219-2363

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@092344 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Bob Axtell [cr_axtellEraseMEspamYAHOO.COM]
>
>I'm not sure what was originally needed. If the intention is
>to prove that a piece of video is actually yours, that CAN be
>done with a PIC operating as fast as possible, hopefully at
>14.31818 x 2 (NTSC) or 17m x 2 (PAL). You use an LM1881 to
>count lines, then have the PIC write a bit burst into a
>Vertical Interval line by using a Maxim video switch, i.e.
>paint the line white at that spot. Each bit will cover several
>pixels, but the idea is for it to be SEEN.
>
>To see your "watermark" simply misadjust the vertical height
>of any monitor and read the bit burst. You can fit about 32
>bits into the Vertical Interval.
>

But as an identification, any information not in the picture is very easy to
strip.  Trying to restore the original picture from a water arked version
would be more difficult.

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmasterEraseMEspamspam_OUTbookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservRemoveMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@142048 by al smith

picon face
If the source of the video is in digital format, then you can overlay
digital content.  I've done this, but not with a PIC, but a pretty large
FPGA.  Essentially, you need to count lines and pixels and either sum or
modify the pixel data at the location you need it to be at.  Its all in the
digital domain and very easy to control at that level.  Then of course, you
need to send the data out and convert back to analog and in PAL standards.
In the world of visual simulation, thats how its done most the time for
HUD's and target overlays.

If your in the analog domain, then I suppose you could do some sort of video
summer, but it needs to be component video (RGB/H/V) to do it right and make
sure that the start of each field lines up with each other (easier said than
done...believe me. Its hard enough to do it in the digital domain, let alone
the analog domain).

But doing it with a PIC or SX....not sure I'd attempt it.  Sometimes you
can't fit a square peg in a round hole.

_________________________________________________________________
There are now three new levels of MSN Hotmail Extra Storage!  Learn more.
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\02\04@155118 by Jinx

face picon face
Thanks for all the excellent technical and common sense
replies fellas. With all that food for thought I'll be getting
a fat head ;-)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspam_OUTspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\02\06@041020 by Jinx

face picon face
I need some clarification please

I've had the video signal on the scope. Could see everything
I expected to, so no problems there and did the daydreaming
thing. Got an LM1881 around here somewhere too (old job,
someone got me looking into subliminal advertising). Then I
got to thinking about pixels. Some useful, for me, explanations
here

http://www.mtxindia.com/An1.htm

and this, which is more info but doesn't help blow the fog away

http://www.mir.com/DMG/aspect.html

Now, I'm assuming that the video signal isn't actually a series of
discrete identifiable pixels, but an analogue waveform. True ? And
if so, is it true then that it's the colour mask that "creates" pixels,
the quality and number of these dependent on the granularity of the
original image collector ? IOW (obviously) the picture can only be
as good as the stage with the poorest resolution, ie camera, trans-
mission or screen

So, for the purposes of positioning a brightness change, the micro
should be a sync detector and timer. There's no need, or even ability,
to actually count pixels ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\06@042302 by hael Rigby-Jones

picon face
{Quote hidden}

Analog transmission have no concept of pixels, the resolution in the
horizontal scan is purely limited by bandwidth as you say.  What you will
need to do, is to count lines after the vertical blank period to get get the
vertical positioning of the your logo.  Horizontal positioning will be
purely down to timing.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmaster@spam@spamspamBeGonebookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\06@042719 by

picon face
Jinx wrote :

> Now, I'm assuming that the video signal isn't actually a series of
> discrete identifiable pixels, but an analogue waveform. True ?

Yes, think about technology from the 50's, and you got
the "picture" clearer, not ? :-) :-)

Jan-Erik.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\06@044001 by Jinx

face picon face
> Analog transmission

Ah-ha, the penny just dropped

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\06@080343 by Olin Lathrop

face picon face
Jinx wrote:
> Now, I'm assuming that the video signal isn't actually a series of
> discrete identifiable pixels, but an analogue waveform. True ?

Yes.

> And
> if so, is it true then that it's the colour mask that "creates"
> pixels,

No.  The shadow mask of a CRT monitor is completely independent of any scan
line or pixel positioning.  It provides a means to display colors on the the
CRT face.  The spacing of the color mask triads, called the "dot pitch", is
intended to be small enough so that individual triads can't be seen under
normal viewing conditions.  The color CRT face therefore becomes continuous
for viewing purposes and the triads can be forgotten.  Note also that triads
are arranged in a hexagonal pattern, while pixels are in a rectangular
pattern.  Some Sony monitors use a different arrangement, but it's still not
a rectangular pattern.  Take a look at a your color CRT face with a jewler's
loupe and you'll see what I mean.

A normal video signal presented to a color monitor contains discrete scan
lines but is a continuous analog signal per scan line.  When a video signal
is processed or produced by a digital system, each scan line is represented
as a sequence of point samples.  This is where pixels come from.  Most CRT
monitors use an analog interface like SVGA, RGB, YUV, or various composite
types.  If the signal is produced by a digital system, the sequence of
pixels is converted back to analog produce the monitor signal.

Pixels, if any, just fall where they fall without regard to the size,
placement, or orientation of the monitor triads.  This works because the
triads are spaced closely enough for the screen to appear continuous, so the
pixels can end up wherever they want.

In the end, the size of the smallest resolvable detail depends on a
combination of factors, including the CRT dot pitch (triad spacing), the
beam or "spot" size, and the pixel spacing.  Of these, the dot pitch is
usually not the limiting factor.

If you want to see a more in depth information with photographs and
diagrams, see "The Way Computer Graphics Works", John Wiley and Sons, ISBN
0-471-13040-0, chapter 2 "Hardware Basics" pages 7-18.  This book is hard to
find, but well written in my humble opinion ;-)

> IOW (obviously) the picture can
> only be
> as good as the stage with the poorest resolution, ie camera, trans-
> mission or screen

Yes.

> So, for the purposes of positioning a brightness change, the micro
> should be a sync detector and timer. There's no need, or even ability,
> to actually count pixels ?

Right, assuming you are working with an analog video signal.  There are
digital video signals that do explicitly have pixels.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\06@101511 by Herbert Graf

flavicon
face
> So, for the purposes of positioning a brightness change, the micro
> should be a sync detector and timer. There's no need, or even ability,
> to actually count pixels ?

       Correct. TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\07@074608 by Peter L. Peres

picon face
>Now, I'm assuming that the video signal isn't actually a series of
>discrete identifiable pixels, but an analogue waveform. True ? And if so,

It's an analog signal with limited bandwidth and defined dynamic range
that is undistinguishable from a digital signal with twice the bandwidth
(at the D/A) and the same dynamic range.

>is it true then that it's the colour mask that "creates" pixels, the
>quality and number of these dependent on the granularity of the original
>image collector ? IOW (obviously) the picture can only be as good as the
>stage with the poorest resolution, ie camera, trans- mission or screen

Yes but the limitation appears as a bandwidth limitation, although it is
often expressed in lines of resolution.

>So, for the purposes of positioning a brightness change, the micro should
>be a sync detector and timer. There's no need, or even ability, to
>actually count pixels ?

Yes and no. Counting time accurately from the line start and V sync is
indistinguishable from counting pixels and and lines. The problem is
interlacing and top and bottom line flicker. These are solvable but not
easily. Also if your watermark is not a square with edges parallel to the
screen edges the flicker will be bad and you will have to use a mask and
at least two watermark pictures to get rid of it.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...