page 1 de 4

ppt2.png  nuage de points à partir de photos

26 04 2015

ppt2.png

tutorial sur la génération d'objets 3d à partir d'une série de photographies :
http://combiencaporte.blogspot.fr/2012/07/la-photogrammetrie-visualsfm-et-meshlab.html

Queques liens :
http://wedidstuff.heavyimage.com/index.php/2013/07/12/open-source-photogrammetry-workflow/
http://makezine.com/2013/08/21/diy-photogrammetry-open-source-alternatives-to-123d-catch/

 


linux-debian.jpg  sensibilité de l'oreille humaine

24 04 2015

Sur la pd-list, Cyrille Henry et Miller Puckette nours parlent de la résolution (plage dynamique) de l'oreille humaine,

 

Le 23/04/2015 17:25, Miller Puckette a écrit :
I get 1 000 000 = 2^19.9 so a 20 bit dynamic range.

yes, your right, thanks for the correction c

I don't think A/D/A hardware ever gets better than about 110 dB dtnamic range though. cheers Miller On Thu, Apr 23, 2015 at 05:20:51PM +0200, Cyrille Henry wrote:
Le 23/04/2015 16:41, Alexandre Torres Porres a écrit :
Yep, nice indeed, I guess I learned - in short and in layman's undetailed terms - that audio output is ~24bits (a bit higher, but much higher for smaller numbers). Moreover, digital audio cards won't likely have more than 24 bit precision for many years to come, so it's just way more than enough.
The human ear is usually consider to be sensible from 0dB to 120dB, so a range of 10^(12/2) between the smallest and biggest amplitude. i.e from 1 to 1 000 000, or from 1 to 2^13.8 so, the human ear sensitivity can be considered to be about 14 bits. 16 bits diffusion should be enough. 24 bits diffusion is already overkill. cheers c
thanks 2015-04-23 6:43 GMT-03:00 Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>>: Nice. Thanks Chuck, I learnt something. On 22 April 2015 at 23:45, Charles Z Henry <czhenry@gmail.com <mailto:czhenry@gmail.com>> wrote: On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: > So I start with this idea that the audio (values from -1 to 1) can't be in > full 32 bit float resolution, it's less. I don't see why that is "wrong". > And then, from it, my first question here was: "what is the audio resolution > then?". I'm still clueless here about this answer. > > Moreover, is it more or less than what 24 bit audio cards handle? Let me try: 32-bit floating point numbers have 24 bits of precision. Always. The remaining 8 bits are just for the sign and exponent. When the amplitude of the signals decrease, you don't lose any precision in floating-point. The value of the least significant bit (LSB) gets proportionally smaller. However, the output of a 24-bit soundcard always has a fixed quantization. The LSB is always the same size. Smaller numbers have less precision. The mismatch occurs when converting from the 32-bit floats to the 24-bit fixed point numbers. Now, the smaller numbers aren't as precise anymore. They get rounded to the nearest number in the 24-bit fixed point system. So, yes, the resolution (of small numbers) in floating point (internal to Pd) is finer than the resolution of those numbers when output (driver/DAC). Also, the 24-bit fixed point format is for values between -1 and 1. That means that numbers between 0 and 1 have just 23 bits. In 32-bit math, the numbers between 0.5 and 1 still have 24 bits of precision (the sign is held elsewhere). That means that Pd's internal resolution is finer than the soundcard resolution for all numbers between -1 and 1. Chuck

 source : http://lists.puredata.info/pipermail/pd-list/2015-04/109900.html


linux-debian.jpg  La transformée de Fourier rapide

24 04 2015

 

f(x)=a(0) + ∑ a(n)*cosine(nωx) +b(n)*sine(nωx)

Jean Debord nours parle de la FFT :

Par exemple, si vous utilisez un taux d'échantillonnage (samplingRate)de 44100 échantillons / seconde, et que la longueur de votre enregistrement (N) est de 1024 échantillons, la durée représentée par l'enregistrement est 1024 / 44100 = 0.02322 seconde, de sorte que la fréquence de base f0 sera 1 / 0.02322 = 43.07 Hz. Si vous soumettez ces 1024 échantillons à la FFT, vous obtiendrez les coefficients ak et bk des sinus et cosinus pour les fréquences 43.07Hz, 2*43.07Hz, 3*43.07Hz, etc. Pour vérifier que la transformée fonctionne correctement, vous pourriez générer tous les sinus et cosinus correspondant à ces fréquences, les multiplier par leur coefficients ak et bk respectifs, tout additionner, et vous retrouveriez votre enregistrement d'origine ! Il est un peu étrange que tout cela fonctionne !

source :

https://www.unilim.fr/pages_perso/jean.debord/math/fourier/fft.htm

 

 

et la : http://www.developpez.net...matiques/mathematiques/demonstration-i-1-a/#post2499924
Zavonen nous parle des nombres complexes  :

Il n'y a pas de DEMONSTRATION au sens où tu l'entends.
C est construit comme une extension de R, pour résoudre les équations algébriques de degré 2 à discriminant négatif comme x^2+1=0.
Or on avait remarqué que si on était placé dans un corps ou CETTE équation pouvait être résolu, alors TOUTES les autres du même type pouvaient l'être aussi.
Remarque que :
R lui-même est construit par extension de Q pour résoudre x^2-2=0,
Q est construit à partir de Z pour résoudre 2x=1,
Z est construit à partir de N pour résoudre x+1=0, etc.. etc...
Donc dès lors qu'on suppose le pb résolu il doit exister un élément i de C et non de R bien entendu tel que i^2=-1, de là on trouve toutes les règles de calcul usuelles avec les complexes pour assurer la conservation des propriétés algébriques (notion d'anneau de corps etc...).
Cela étant fait on CONSTRUIT formellement C à partir des couples de R^2, en prenant les règles de calcul sur les coules déterminées ci-avant.
On DEFINIT ensuite le complexe i comme étant le couple (0,1).
Donc i^2 =-1 par CONSTRUCTION.


linux-debian.jpg  Ross Bencina nous parle du temps réel

26 03 2015

In summary

Boiling down the above discussion into a few rules of thumb for code that executes in a real-time audio callback:

  • Don’t allocate or deallocate memory
  • Don’t lock a mutex
  • Don’t read or write to the filesystem or otherwise perform i/o. (In case there’s any doubt, this includes things like calling printf or NSLog, or GUI APIs.)
  • Don’t call OS functions that may block waiting for something
  • Don’t execute any code that has unpredictable or poor worst-case timing behavior
  • Don’t call any code that does or may do any of the above
  • Don’t call any code that you don’t trust to follow these rules
  • On Apple operating systems follow Apple’s guidelines

There are a few things you should do where possible:

  • Do use algorithms with good worst-case time complexity (ideally O(1) wost-case)
  • Do amortize computation across many audio samples to smooth out CPU usage rather than using “bursty” algorithms that occasionally have long processing times
  • Do pre-allocate or pre-compute data in a non-time-critical thread
  • Do employ non-shared, audio-callback-only data structures so you don’t need to think about sharing, concurrency and locks

Just remember: time waits for nothing and you don’t want to glitch.

 


source :
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing


linux-debian.jpg  Synthesis ToolKit

23 03 2015

rep@reep:~/Projets/STK/stk-4.5.0/projects/examples$ ./audioprobe

Compiled APIs:
  Linux ALSA

Current API: Linux ALSA

Found 7 device(s) ...

Device Name = hw:HDA Intel MID,0
Probe Status = Successful
Output Channels = 4
Input Channels = 2
Duplex Channels = 2
This is the default output device.
This is the default input device.
Natively supported data formats:
  16-bit int
  32-bit int
Supported sample rates = 44100 48000 96000 192000

Device Name = hw:HDA Intel MID,1
Probe Status = Successful
Output Channels = 2
Input Channels = 0
Duplex Channels = 0
This is NOT the default output device.
This is NOT the default input device.
Natively supported data formats:
  16-bit int
  32-bit int
Supported sample rates = 44100 48000 88200 96000 192000

Device Name = hw:HDA NVidia,3
Probe Status = Successful
Output Channels = 8
Input Channels = 0
Duplex Channels = 0
This is NOT the default output device.
This is NOT the default input device.
Natively supported data formats:
  16-bit int
  32-bit int
Supported sample rates = 32000 44100 48000 88200 96000 176400 192000

Device Name = hw:HDA NVidia,7
Probe Status = Successful
Output Channels = 8
Input Channels = 0
Duplex Channels = 0
This is NOT the default output device.
This is NOT the default input device.
Natively supported data formats:
  16-bit int
  32-bit int
Supported sample rates = 32000 44100 48000 88200 96000 176400 192000

Device Name = hw:HDA NVidia,8
Probe Status = Successful
Output Channels = 8
Input Channels = 0
Duplex Channels = 0
This is NOT the default output device.
This is NOT the default input device.
Natively supported data formats:
  16-bit int
  32-bit int
Supported sample rates = 32000 44100 48000 88200 96000 176400 192000

Device Name = hw:HDA NVidia,9
Probe Status = Successful
Output Channels = 8
Input Channels = 0
Duplex Channels = 0
This is NOT the default output device.
This is NOT the default input device.
Natively supported data formats:
  16-bit int
  32-bit int
Supported sample rates = 32000 44100 48000 88200 96000 176400 192000

Device Name = default
Probe Status = Successful
Output Channels = 32
Input Channels = 32
Duplex Channels = 32
This is NOT the default output device.
This is NOT the default input device.
Natively supported data formats:
  16-bit int
  32-bit int
  32-bit float
Supported sample rates = 4000 5512 8000 9600 11025 16000 22050 32000 44100 48000 88200 96000 176400 192000

 


tl09.jpg  LE (en capitale) tutorial OpenGL

23 03 2015

A lire absolument si vous débutez (comme moi) :

https://open.gl/

c'est le meilleur tutorial à ce jour que je n'ai jamais lu, parce qu'il y a l'essentiel, parce que la code fourni marche, parce que le gars qui l'a écrit l'a bien fait (images, illustrations et tout), parce qu'il n'y a pas de conneries ou de trucs obsolètes, parce que les exemples sont simples et néanmoins très efficaces.


linux-debian.jpg  VDPAU (échange de mémoire vidéo)

23 03 2015

VDPAU :

$apt-get install vdpauinfo

 

rep@barbouille:~/$ vdpauinfo
display: :0   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  340.65  Tue Dec  2 09:13:46 PST 2014

Video surface:

name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12
422     4096  4096  UYVY YUYV

Decoder capabilities:

name               level macbs width height
-------------------------------------------
MPEG1                 0  8192  2048  2048
MPEG2_SIMPLE          3  8192  2048  2048
MPEG2_MAIN            3  8192  2048  2048
H264_MAIN            41  8192  2048  2048
H264_HIGH            41  8192  2048  2048
VC1_SIMPLE            1  8190  2048  2048
VC1_MAIN              2  8190  2048  2048
VC1_ADVANCED          4  8190  2048  2048
MPEG4_PART2_SP        3  8192  2048  2048
MPEG4_PART2_ASP       5  8192  2048  2048
DIVX4_QMOBILE         0  8192  2048  2048
DIVX4_MOBILE          0  8192  2048  2048
DIVX4_HOME_THEATER    0  8192  2048  2048
DIVX4_HD_1080P        0  8192  2048  2048
DIVX5_QMOBILE         0  8192  2048  2048
DIVX5_MOBILE          0  8192  2048  2048
DIVX5_HOME_THEATER    0  8192  2048  2048
DIVX5_HD_1080P        0  8192  2048  2048

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  Y8U8V8A8 V8U8Y8A8
R10G10B10A2      16384 16384    y  Y8U8V8A8 V8U8Y8A8

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     y
INVERSE_TELECINE                 y
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y         1     4096
VIDEO_SURFACE_HEIGHT             y         1     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y  

 

 

 

https://www.opengl.org/registry/specs/NV/vdpau_interop.txt
http://fr.wikipedia.org/wiki/VDPAU
https://packages.debian.org/search?keywords=libvdpau

 

codecs VDPAU :

rep@barbouille:~/Projets/$ mplayer -vc help | grep --color vdpa
ffmpeg12vdpau ffmpeg    working   FFmpeg MPEG-1/2 (VDPAU)  [mpegvideo_vdpau]
ffwmv3vdpau ffmpeg    problems  FFmpeg WMV3/WMV9 (VDPAU)  [wmv3_vdpau]
ffvc1vdpau  ffmpeg    problems  FFmpeg WVC1 (VDPAU)  [vc1_vdpau]
ffh264vdpau ffmpeg    working   FFmpeg H.264 (VDPAU)  [h264_vdpau]
ffodivxvdpau ffmpeg    working   FFmpeg MPEG-4,DIVX-4/5 (VDPAU)  [mpeg4_vdpau]

 

 


47903653.jpg  screencast ffmpeg et x11grab, ou libvlc

02 03 2015

Meilleure solution :

soluce a) ffmpeg :

modprobe v4l2loopback && ffmpeg -f x11grab -r 25 -s 256x256 -follow_mouse centered -show_region 1 -i :0.0+0,0 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video1

puis dans puredata ouvrir une webcam virtuelle avec [pix_video] et V4L2

 

soluce b) libVLC (faut avoir compilé Gem avec la libvlc) :

[device screen://<
|
[pix_video]


47903653.jpg  linux framebuffer

28 02 2015

http://www.ummon.eu/Linux/API/Devices/framebuffer.html

en résumé :
Open the device using the open() call. reading the device means reading the screen memory. Try $ cat /dev/fb0 >screenshot to dump the screen memory to a file. To restore the screenshot do the opposite: $ cat screenshot >/dev/fb0.


  oeil 3

29 01 2015



page 1 de 4


Pierre Mersadier - 2014 - license cc by-nc-sa 3.0 fr