|
|
| Author |
Message |
Luhan
electronics forum Guru
Joined: 10 Dec 2005
Posts: 365
|
 Posted: Fri Jul 14, 2006 7:46 pm Post subject:
Video Motion Detection
|
|
|
Hi,
I got this idea on video motion detection and built it. It works.
http://members.cox.net/berniekm/vax.html
My question is: has anybody done it this way before? (Referring to
figures 1,2, and 3)
Lemme know.
Luhan |
|
| Back to top |
|
 |
Rich Grise
electronics forum Guru
Joined: 24 Mar 2005
Posts: 3971
|
| Posted: Fri Jul 14, 2006 8:27 pm Post subject:
Re: Video Motion Detection
|
|
|
On Fri, 14 Jul 2006 12:46:50 -0700, Luhan wrote:
| Quote: | Hi,
I got this idea on video motion detection and built it. It works.
http://members.cox.net/berniekm/vax.html
My question is: has anybody done it this way before? (Referring to
figures 1,2, and 3)
Lemme know.
|
I like it a lot.  It somehow reminds me philosophically, of an idea
I had for a speakwrite, but the spectral pattern recognition was beyond
my expertise. )-;
Thanks,
Rich |
|
| Back to top |
|
|
Joel Kolstad
electronics forum Guru
Joined: 03 May 2005
Posts: 695
|
| Posted: Fri Jul 14, 2006 9:01 pm Post subject:
Re: Video Motion Detection
|
|
|
"Luhan" <luhanis@yahoo.com> wrote in message
news:1152906410.476486.314010@m73g2000cwd.googlegroups.com...
Clever design, Luhan... well done! |
|
| Back to top |
|
|
Jim Thompson
electronics forum Guru
Joined: 06 May 2005
Posts: 5440
|
| Posted: Fri Jul 14, 2006 9:06 pm Post subject:
Re: Video Motion Detection
|
|
|
On Fri, 14 Jul 2006 14:01:18 -0700, "Joel Kolstad"
<JKolstad71HatesSpam@yahoo.com> wrote:
| Quote: | "Luhan" <luhanis@yahoo.com> wrote in message
news:1152906410.476486.314010@m73g2000cwd.googlegroups.com...
I got this idea on video motion detection and built it. It works.
http://members.cox.net/berniekm/vax.html
Clever design, Luhan... well done!
|
Indeed!!
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food. |
|
| Back to top |
|
|
Mochuelo
electronics forum Guru Wannabe
Joined: 10 May 2005
Posts: 128
|
| Posted: Fri Jul 14, 2006 9:27 pm Post subject:
Re: Video Motion Detection
|
|
|
On 14 Jul 2006 12:46:50 -0700, "Luhan" <luhanis@yahoo.com> wrote:
| Quote: | Hi,
I got this idea on video motion detection and built it. It works.
http://members.cox.net/berniekm/vax.html
My question is: has anybody done it this way before? (Referring to
figures 1,2, and 3)
Lemme know.
Luhan
|
If an object the size of one cell moves diagonally one position
(vector=(+1,+1)) along certain diagonals, none of your three sums will
detect it.
You can use cyclic redundancy codes (CRC) to detect almost any kind of
change in the picture. Just feed the 64 samples serially, and keep the
remainder of the polynomial division. 8-bit CRC should probably be
enough, but 16-bit would be safer, and it is quite easy to compute it.
There are many C and assembly CRC libraries on the internet.
Best, |
|
| Back to top |
|
|
Joerg
electronics forum Guru
Joined: 05 May 2005
Posts: 3533
|
| Posted: Fri Jul 14, 2006 9:27 pm Post subject:
Re: Video Motion Detection
|
|
|
Hello Luhan,
| Quote: |
I got this idea on video motion detection and built it. It works.
http://members.cox.net/berniekm/vax.html
My question is: has anybody done it this way before? (Referring to
figures 1,2, and 3)
Lemme know.
|
Very clever. Haven't seen anything like it. In filter design or
ultrasound, yes, but not with video.
Hey, maybe you could patent that? Oh wait, I don't know but a usenet
post would probably constitute a publication.
--
Regards, Joerg
http://www.analogconsultants.com |
|
| Back to top |
|
|
Luhan
electronics forum Guru
Joined: 10 Dec 2005
Posts: 365
|
| Posted: Fri Jul 14, 2006 10:35 pm Post subject:
Re: Video Motion Detection
|
|
|
Mochuelo wrote:
| Quote: | On 14 Jul 2006 12:46:50 -0700, "Luhan" <luhanis@yahoo.com> wrote:
Hi,
I got this idea on video motion detection and built it. It works.
http://members.cox.net/berniekm/vax.html
My question is: has anybody done it this way before? (Referring to
figures 1,2, and 3)
Lemme know.
Luhan
If an object the size of one cell moves diagonally one position
(vector=(+1,+1)) along certain diagonals, none of your three sums will
detect it.
You can use cyclic redundancy codes (CRC) to detect almost any kind of
change in the picture. Just feed the 64 samples serially, and keep the
remainder of the polynomial division. 8-bit CRC should probably be
enough, but 16-bit would be safer, and it is quite easy to compute it.
There are many C and assembly CRC libraries on the internet.
Best,
|
Its true that there are some cases where the object is not detected,
but a moving object is unlikely to contantly move in such specific
directions.
Using a simple checksum makes the system overly sensitive to ambient
light variations. This is just the opposite of detecting objects. The
+/- operations cancel out much of the ambient variations.
I'm not sure how a more complex CRC would react, but that is an idea.
Luhan |
|
| Back to top |
|
|
Luhan
electronics forum Guru
Joined: 10 Dec 2005
Posts: 365
|
| Posted: Fri Jul 14, 2006 10:48 pm Post subject:
Re: Video Motion Detection
|
|
|
Luhan wrote:
| Quote: | Mochuelo wrote:
On 14 Jul 2006 12:46:50 -0700, "Luhan" <luhanis@yahoo.com> wrote:
Hi,
I got this idea on video motion detection and built it. It works.
http://members.cox.net/berniekm/vax.html
My question is: has anybody done it this way before? (Referring to
figures 1,2, and 3)
Lemme know.
Luhan
If an object the size of one cell moves diagonally one position
(vector=(+1,+1)) along certain diagonals, none of your three sums will
detect it.
You can use cyclic redundancy codes (CRC) to detect almost any kind of
change in the picture. Just feed the 64 samples serially, and keep the
remainder of the polynomial division. 8-bit CRC should probably be
enough, but 16-bit would be safer, and it is quite easy to compute it.
There are many C and assembly CRC libraries on the internet.
Best,
Its true that there are some cases where the object is not detected,
but a moving object is unlikely to contantly move in such specific
directions.
Using a simple checksum makes the system overly sensitive to ambient
light variations. This is just the opposite of detecting objects. The
+/- operations cancel out much of the ambient variations.
I'm not sure how a more complex CRC would react, but that is an idea.
Luhan
|
Yikes! A CRC will not work at all. There is no way to set a
'threshhold' level for detecting significant changes vs random
variations.
Luhan |
|
| Back to top |
|
|
Mochuelo
electronics forum Guru Wannabe
Joined: 10 May 2005
Posts: 128
|
| Posted: Sat Jul 15, 2006 8:35 am Post subject:
Re: Video Motion Detection
|
|
|
On 14 Jul 2006 15:35:05 -0700, "Luhan" <luhanis@yahoo.com> wrote:
| Quote: | Its true that there are some cases where the object is not detected,
but a moving object is unlikely to contantly move in such specific
directions.
Using a simple checksum makes the system overly sensitive to ambient
light variations. This is just the opposite of detecting objects. The
+/- operations cancel out much of the ambient variations.
|
Just remove the dc offset from the 64 samples, and then send them to
the CRC.
Best,
| Quote: |
I'm not sure how a more complex CRC would react, but that is an idea.
Luhan |
|
|
| Back to top |
|
|
Luhan
electronics forum Guru
Joined: 10 Dec 2005
Posts: 365
|
| Posted: Sat Jul 15, 2006 1:16 pm Post subject:
Re: Video Motion Detection
|
|
|
Mochuelo wrote:
| Quote: | On 14 Jul 2006 15:35:05 -0700, "Luhan" <luhanis@yahoo.com> wrote:
Its true that there are some cases where the object is not detected,
but a moving object is unlikely to contantly move in such specific
directions.
Using a simple checksum makes the system overly sensitive to ambient
light variations. This is just the opposite of detecting objects. The
+/- operations cancel out much of the ambient variations.
Just remove the dc offset from the 64 samples, and then send them to
the CRC.
|
CRC's cannot be used. They respond wildly to even a singe bit change.
Since there is always some variation in the video data, the CRC would
change with every video frame regardless of whether motion was present.
Luhan |
|
| Back to top |
|
|
Mochuelo
electronics forum Guru Wannabe
Joined: 10 May 2005
Posts: 128
|
| Posted: Sat Jul 15, 2006 2:02 pm Post subject:
Re: Video Motion Detection
|
|
|
On 14 Jul 2006 15:48:05 -0700, "Luhan" <luhanis@yahoo.com> wrote:
| Quote: | Yikes! A CRC will not work at all. There is no way to set a
'threshhold' level for detecting significant changes vs random
variations.
[...]
CRC's cannot be used. They respond wildly to even a singe bit change.
Since there is always some variation in the video data, the CRC would
change with every video frame regardless of whether motion was present.
|
What do you mean by "will not work at all," "there is no way" and
"cannot be used"? You mean:
a) Nobody can come up with a way to use CRCs in this application, and
end up with better performance than with your proposed scheme.
b) You can't.
a or b? |
|
| Back to top |
|
|
Ken Smith
electronics forum Guru
Joined: 06 May 2005
Posts: 1727
|
| Posted: Sat Jul 15, 2006 4:03 pm Post subject:
Re: Video Motion Detection
|
|
|
In article <1152969365.167712.66680@h48g2000cwc.googlegroups.com>,
Luhan <luhanis@yahoo.com> wrote:
| Quote: |
Mochuelo wrote:
On 14 Jul 2006 15:35:05 -0700, "Luhan" <luhanis@yahoo.com> wrote:
Its true that there are some cases where the object is not detected,
but a moving object is unlikely to contantly move in such specific
directions.
Using a simple checksum makes the system overly sensitive to ambient
light variations. This is just the opposite of detecting objects. The
+/- operations cancel out much of the ambient variations.
Just remove the dc offset from the 64 samples, and then send them to
the CRC.
CRC's cannot be used. They respond wildly to even a singe bit change.
Since there is always some variation in the video data, the CRC would
change with every video frame regardless of whether motion was present.
|
If you reduce the number of values and the number of bits in each sample,
you reduce the odds of a change of one bit. If backlash is built into the
digitizer, a further reduction in the odds can be had. If we are looking
for a change in the picture that is large enough, the CRC will work.
The way I would attack doing it with a CRC (assuming I had to) would be to
do the following.
(1) Run the video signal into a "log(x)" circuit so that (roughly), the
same change in value always means that the brightness changed by the same
percentage. The bottom end of the curve will not be a true log function
so that we don't amplify the noise too much in very dark areas.
(2) Digitize with a, lets say, 12 bit ADC that is well synced to the
video. and feed that into a FPGA that does the following steps.
(3) Only clock samples through while we are in the scan area of the video
image.
(4) Implement a IIR bandpass filter in the column direction with about 3
memories.
(5) Using, lets say, 256*3 memory locations sellected according to the
column number, implement an IIR filter in the row direction.
(6) Perhaps snip off the LSBs and decimate the data a bit to reduce the
need for the next bit of memory.
(7) Arrange a chunk of memory such that we get a, lets say, 12 bit value
for the previous scan at this location and then overwrite it with a new 12
bit value.
( Impement the following function between the read and write of the
memory from step (7):
if abs(New - Old) > BackLash
then Y = New
else Y = Old
(9) Make a CRC from, lets say, the top 8 bits of the results from 8.
My reasoning is like this:
A reflective object reflects a constant percentage of the light falling
on it regardless of the absolute brightness. This is way I take the
log(x).
The bandpass filter in the row direction implements a homomorphic
amplitude compression. This mostly removes the effects of over all
dimming and brightening of the scene. Cutting out the high frequencies
removes much of the noise and jitter and rejects small objects such as
flies in the scene.
The bandpas filter in the column direction removes the variations in
brightness from left to right and again rejects small objects.
After the filtering, the signal, more or less, contains only information
about the locations of the objects in the scene plus some remaining noise.
If the backlash in step ( is much more than this noise, the Y=Old case
will happen every time unless something in the scene changes.
A CRC can easily be arranged so that it has its repeat values widely
spaced on the scene.
--
--
kensmith@rahul.net forging knowledge |
|
| Back to top |
|
|
Luhan
electronics forum Guru
Joined: 10 Dec 2005
Posts: 365
|
| Posted: Sat Jul 15, 2006 6:34 pm Post subject:
Re: Video Motion Detection
|
|
|
Ken Smith wrote:
| Quote: | In article <1152969365.167712.66680@h48g2000cwc.googlegroups.com>,
Luhan <luhanis@yahoo.com> wrote:
Mochuelo wrote:
On 14 Jul 2006 15:35:05 -0700, "Luhan" <luhanis@yahoo.com> wrote:
Its true that there are some cases where the object is not detected,
but a moving object is unlikely to contantly move in such specific
directions.
Using a simple checksum makes the system overly sensitive to ambient
light variations. This is just the opposite of detecting objects. The
+/- operations cancel out much of the ambient variations.
Just remove the dc offset from the 64 samples, and then send them to
the CRC.
CRC's cannot be used. They respond wildly to even a singe bit change.
Since there is always some variation in the video data, the CRC would
change with every video frame regardless of whether motion was present.
If you reduce the number of values and the number of bits in each sample,
you reduce the odds of a change of one bit. If backlash is built into the
digitizer, a further reduction in the odds can be had.
|
The digitizer would have to remember the previous data at exactly that
location.
If we are looking
| Quote: | for a change in the picture that is large enough, the CRC will work.
|
No, all of the CRC's I have seen react to single bit changes.
| Quote: |
The way I would attack doing it with a CRC (assuming I had to) would be to
do the following.
(1) Run the video signal into a "log(x)" circuit so that (roughly), the
same change in value always means that the brightness changed by the same
percentage. The bottom end of the curve will not be a true log function
so that we don't amplify the noise too much in very dark areas.
|
I prefer my one resistor and one capacitor.
| Quote: |
(2) Digitize with a, lets say, 12 bit ADC that is well synced to the
video. and feed that into a FPGA that does the following steps.
|
The PIC has 10 bits, using 12 contradicts your comment above about
reducing the number of bits. I use 8 bits for 'easy handling'.
| Quote: |
(3) Only clock samples through while we are in the scan area of the video
image.
|
Check the website, thats always done.
| Quote: |
(4) Implement a IIR bandpass filter in the column direction with about 3
memories.
(5) Using, lets say, 256*3 memory locations sellected according to the
column number, implement an IIR filter in the row direction.
|
The PIC has only about 100 memory locations.
| Quote: | (6) Perhaps snip off the LSBs and decimate the data a bit to reduce the
need for the next bit of memory.
|
Conflicts with your #2.
| Quote: | (7) Arrange a chunk of memory such that we get a, lets say, 12 bit value
for the previous scan at this location and then overwrite it with a new 12
bit value.
( Impement the following function between the read and write of the
memory from step (7):
if abs(New - Old) > BackLash
then Y = New
else Y = Old
(9) Make a CRC from, lets say, the top 8 bits of the results from 8.
My reasoning is like this:
A reflective object reflects a constant percentage of the light falling
on it regardless of the absolute brightness. This is way I take the
log(x).
|
Yes.
| Quote: |
The bandpass filter in the row direction implements a homomorphic
amplitude compression. This mostly removes the effects of over all
dimming and brightening of the scene. Cutting out the high frequencies
removes much of the noise and jitter and rejects small objects such as
flies in the scene.
The bandpas filter in the column direction removes the variations in
brightness from left to right and again rejects small objects.
After the filtering, the signal, more or less, contains only information
about the locations of the objects in the scene plus some remaining noise.
If the backlash in step ( is much more than this noise, the Y=Old case
will happen every time unless something in the scene changes.
A CRC can easily be arranged so that it has its repeat values widely
spaced on the scene.
|
Build it and show us the design. Let us all know how it works. You
are going in the opposite direction from my design - better
recoginition with much greater complexity.
My design is a compromise on recognition with greatly reduced
complexity.
You may have some very good ideas here on an implementation using maybe
a PC to do the processing. This may have its uses depending on design
constraints.
Good luck,
Luhan |
|
| Back to top |
|
|
Ken Smith
electronics forum Guru
Joined: 06 May 2005
Posts: 1727
|
| Posted: Sat Jul 15, 2006 11:28 pm Post subject:
Re: Video Motion Detection
|
|
|
In article <1152988446.349332.132950@m79g2000cwm.googlegroups.com>,
Luhan <luhanis@yahoo.com> wrote:
| Quote: |
Ken Smith wrote:
[....]
If you reduce the number of values and the number of bits in each sample,
you reduce the odds of a change of one bit. If backlash is built into the
digitizer, a further reduction in the odds can be had.
The digitizer would have to remember the previous data at exactly that
location.
|
No, it would not.
I think you will agree that, if the digitizer was lets say 1 bit and the
backlash was greater than the video signal, the output would always be either
high or low depending on which way it started.
I think you would also agree that if the entire video frame was reduced to
a single pixel, a low resolution multibit digitizer would produce the same
result assuming the overall lighting did not change.
With some filtering before it, the one bit digitizer could be replaced
with a window comparitor. When you go to multiple pixels, the required
backlash circuit would become a majority logic circuit in the simple case.
| Quote: |
If we are looking
for a change in the picture that is large enough, the CRC will work.
No, all of the CRC's I have seen react to single bit changes.
|
.... and if the change in picture does not cause a change on the input to
the CRC, the CRC's output does not change. So all that is required is a
circuit that doesn't change the digital input if the picture doesn't have
some huge change in it.
| Quote: | The way I would attack doing it with a CRC (assuming I had to) would be to
do the following.
(1) Run the video signal into a "log(x)" circuit so that (roughly), the
same change in value always means that the brightness changed by the same
percentage. The bottom end of the curve will not be a true log function
so that we don't amplify the noise too much in very dark areas.
I prefer my one resistor and one capacitor.
|
To each his own, I guess but it sounds quite primative to me. With my
version, changes in overall brightness don't produce a changed output.
| Quote: | (2) Digitize with a, lets say, 12 bit ADC that is well synced to the
video. and feed that into a FPGA that does the following steps.
The PIC has 10 bits, using 12 contradicts your comment above about
reducing the number of bits. I use 8 bits for 'easy handling'.
|
This was about "using a CRC" so the details of the hardware doesn't matter
it is just getting it to involve a CRC that was the goal.
| Quote: | (3) Only clock samples through while we are in the scan area of the video
image.
Check the website, thats always done.
|
It still needs to be stated for the description to be complete.
| Quote: | The PIC has only about 100 memory locations.
|
Then don't use a PIC!
| Quote: |
(6) Perhaps snip off the LSBs and decimate the data a bit to reduce the
need for the next bit of memory.
Conflicts with your #2.
|
How does that conflict. I sure don't see any way that it does.
| Quote: | amplitude compression. This mostly removes the effects of over all
dimming and brightening of the scene. Cutting out the high frequencies
removes much of the noise and jitter and rejects small objects such as
flies in the scene.
The bandpas filter in the column direction removes the variations in
brightness from left to right and again rejects small objects.
After the filtering, the signal, more or less, contains only information
about the locations of the objects in the scene plus some remaining noise.
If the backlash in step ( is much more than this noise, the Y=Old case
will happen every time unless something in the scene changes.
A CRC can easily be arranged so that it has its repeat values widely
spaced on the scene.
Build it and show us the design.
|
Why? Do you think it won't work or that it doesn't use a CRC?
| Quote: | Let us all know how it works. You
are going in the opposite direction from my design - better
recoginition with much greater complexity.
My design is a compromise on recognition with greatly reduced
complexity.
You may have some very good ideas here on an implementation using maybe
a PC to do the processing. This may have its uses depending on design
constraints.
|
No, like I suggested, an FPGA is the way to go. All of the logic will fit
into a not very large one. The memory pushes you up in size a bit but not
all that much these days. The amount of electronics to make the FPGA go
would not be much.
--
--
kensmith@rahul.net forging knowledge |
|
| Back to top |
|
|
Luhan
electronics forum Guru
Joined: 10 Dec 2005
Posts: 365
|
| Posted: Sun Jul 16, 2006 1:15 am Post subject:
Re: Video Motion Detection
|
|
|
Ken Smith wrote:
| Quote: | In article <1152988446.349332.132950@m79g2000cwm.googlegroups.com>,
Luhan <luhanis@yahoo.com> wrote:
Ken Smith wrote:
[....]
If you reduce the number of values and the number of bits in each sample,
you reduce the odds of a change of one bit. If backlash is built into the
digitizer, a further reduction in the odds can be had.
The digitizer would have to remember the previous data at exactly that
location.
No, it would not.
I think you will agree that, if the digitizer was lets say 1 bit and the
backlash was greater than the video signal, the output would always be either
high or low depending on which way it started.
I think you would also agree that if the entire video frame was reduced to
a single pixel, a low resolution multibit digitizer would produce the same
result assuming the overall lighting did not change.
With some filtering before it, the one bit digitizer could be replaced
with a window comparitor. When you go to multiple pixels, the required
backlash circuit would become a majority logic circuit in the simple case.
If we are looking
for a change in the picture that is large enough, the CRC will work.
No, all of the CRC's I have seen react to single bit changes.
... and if the change in picture does not cause a change on the input to
the CRC, the CRC's output does not change. So all that is required is a
circuit that doesn't change the digital input if the picture doesn't have
some huge change in it.
The way I would attack doing it with a CRC (assuming I had to) would be to
do the following.
(1) Run the video signal into a "log(x)" circuit so that (roughly), the
same change in value always means that the brightness changed by the same
percentage. The bottom end of the curve will not be a true log function
so that we don't amplify the noise too much in very dark areas.
I prefer my one resistor and one capacitor.
To each his own, I guess but it sounds quite primative to me. With my
version, changes in overall brightness don't produce a changed output.
(2) Digitize with a, lets say, 12 bit ADC that is well synced to the
video. and feed that into a FPGA that does the following steps.
The PIC has 10 bits, using 12 contradicts your comment above about
reducing the number of bits. I use 8 bits for 'easy handling'.
This was about "using a CRC" so the details of the hardware doesn't matter
it is just getting it to involve a CRC that was the goal.
(3) Only clock samples through while we are in the scan area of the video
image.
Check the website, thats always done.
It still needs to be stated for the description to be complete.
The PIC has only about 100 memory locations.
Then don't use a PIC!
(6) Perhaps snip off the LSBs and decimate the data a bit to reduce the
need for the next bit of memory.
Conflicts with your #2.
How does that conflict. I sure don't see any way that it does.
amplitude compression. This mostly removes the effects of over all
dimming and brightening of the scene. Cutting out the high frequencies
removes much of the noise and jitter and rejects small objects such as
flies in the scene.
The bandpas filter in the column direction removes the variations in
brightness from left to right and again rejects small objects.
After the filtering, the signal, more or less, contains only information
about the locations of the objects in the scene plus some remaining noise.
If the backlash in step ( is much more than this noise, the Y=Old case
will happen every time unless something in the scene changes.
A CRC can easily be arranged so that it has its repeat values widely
spaced on the scene.
Build it and show us the design.
Why? Do you think it won't work or that it doesn't use a CRC?
Let us all know how it works. You
are going in the opposite direction from my design - better
recoginition with much greater complexity.
My design is a compromise on recognition with greatly reduced
complexity.
You may have some very good ideas here on an implementation using maybe
a PC to do the processing. This may have its uses depending on design
constraints.
No, like I suggested, an FPGA is the way to go. All of the logic will fit
into a not very large one. The memory pushes you up in size a bit but not
all that much these days. The amount of electronics to make the FPGA go
would not be much.
--
--
kensmith@rahul.net forging knowledge
|
I'll leave it to others decide if what you propose makes sense.
Luhan |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Jan 09, 2009 10:14 pm | All times are GMT
|
|
Debt Consolidation | Mortgage Calculator | Loans | Internet Advertising | Debt Consolidation
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
Unix/Linux documentation |
Unix/Linux forums |
Medicine forum |
Science forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Electronix
»
design
