> -----Mensaje original-----
> De: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]
> Enviado el: mi�rcoles 28 de julio de 1999 16:28
> Para: Tejada Lacaci, Antonio
> Asunto: RE: Free Software en Espa�a [Era: Re: Perdonar pero no me
> aclaro]
>
Por cierto, esta tanda de mensajes (no s�lo el tuyo) me ha llegado
sin la cabecera
Content-Transfer-Encoding: quoted-printable
de manera que se ve todo fatal (bueno, todo, todo no, s�lo las cosas
con acentos y dem�s ;) )
�S�lo me ha pasado a m� o le ha pasado tambi�n a alguien m�s?
�alguien ha estado hurgando con el soft de la lista?
> ::::: El d=EDa Wed, 28 Jul 1999 08:27:41 +0200, "Tejada Lacaci, Antonio=
> "
> <[EMAIL PROTECTED]> contaba:
>
>
> :: Si te das cuenta, todo esto no alude a algoritmos o formatos,
> :: sino a procedimientos (que s=ED son patentables, del mismo modo
> :: que lo son los dispositivos f=EDsicos de decodificaci=F3n de mp3=
> ).
>
> Tejada:: =09%-# =BFy la diferencia entre un algoritmo y un
> Tejada:: procedimiento es? :-?
>
>
> Toma lo que sigue con cierta reserva, al menos hasta que compruebe si
> existe jurisprudencia o doctrina sobre el tema. (Por cierto, que la
> pregunta es muy, muy interesante :)
.. seguro que no tanto como tus respuestas ;D
> Hasta donde yo s=E9, el algoritmo es un procedimiento matem=E1tico. La=
> Ley de Patentes no utiliza de hecho el t=E9rmino `algoritmo' (mea culpa=
> :), sino que dice ``m=E9todo matem=E1tico''. En mi opini=F3n, de lo qu=
> e se trata es de que sea un m=E9todo _intr=EDnsecamente matem=E1tico_.
>
> En el caso del mp3, los algoritmos sirven para implementar un
> procedimiento que se basa en la manipulaci=F3n no matem=E1tica de los
> datos. Quiero decir que no se trata de que hayan encontrado una forma
> de guardar los mismos datos en menos espacio con la aplicaci=F3n de una=
> f=F3rmula de transformaci=F3n, o de que hayan encontrado una forma nuev=
> a de codificar sonido y en eso consista todo, sino que parten de un
> principio f=EDsico (para el o=EDdo humano una buena parte del sonido es=
... espera, que me voy a patentar la "compresi�n por diccionario"
(aquella en la que se traducen los datos a codificar por entradas o �ndices
a un diccionario o tabla, que puede ir o no inclu�do en los datos finales) y
voy a hacerme rico (el LZW, el bzip y gzip son "algoritmos" que emplean el
"procedimiento" "compresi�n por diccionario").
�Pero eso no es una locura? ... es decir, ser�a mucho m�s sensato
patentar el algoritmo concreto, no la "idea" sobre el algoritmo. �Quieres
decir que la patente sobre la "idea" rige sobre todos los algoritmos que se
desarrollen y empleen esa idea como base? :-?
Bajo mi punto de vista, eso se contradice bastante con que s� se
pueda patentar el dispositivo f�sico (que es la "implementaci�n" f�sica de
"una idea" o procedimiento). El dispositivo f�sico ser�a an�logo a una
implementaci�n software concreta.
O mejor a�n, voy a patentar un procedimiento por el cual un
"engendro se comunica v�a impulsos el�ctricos y permite la ejecuci�n de
patrones de �rdenes".
Ya supongo que habr� un l�mite a lo abstracto que pueda ser la
definici�n de lo que patentes, pero eso implica que est� sujeto a
valoraciones subjetivas, por lo que a saber qu� te dejan patentar y qu� no!
.... �por probar que no quede!.
[...]
> No estoy seguro de estarme explicando con claridad (no porque no se
> pueda, sino porque posiblemente a m=ED me falta habilidad para ello; si=
> tienes problemas lo intentar=E9 de nuevo, h=E1zmelo saber :).
... creo que s� que lo entiendo, pero me parece bastante peligroso
lo que entiendo. Eso de que se pueda patentar la idea ... pffff .... es una
locura. Ya te digo que comprendo m�s que se pueda patentar el algoritmo
concreto antes que la idea gen�rica :-m ... claro, que entonces lo de
patentar el algoritmo ser�a muy espec�fico y quiz�s ese mismo algoritmo con
un peque�o cambio ya no ser�a afectado por la patente original :-m
> La pregunta siguiente (al menos eso me parece) es la de si los dem=E1s
> m=E9todos de compresi=F3n no podr=EDan considerarse tambi=E9n como
> procedimientos f=EDsicos con expresi=F3n matem=E1tica. Creo que no, au=
> nque seguramente t=FA puedes decidirlo con mucho m=E1s conocimiento de
> causa=
> :)
Pues ya te digo, parece que eso que t� explicas como procedimiento
no es m�s que la idea gen�rica de la que luego parten algoritmos
espec�ficos.
[...]
> Otra cosa ser=EDa jpeg, aunque no estoy seguro en=
> lo m=E1s m=EDnimo (por indicaciones creo que suprime datos en una
> transacci=F3n calidad-tama=F1o de fichero, pero no lo s=E9 de cierto y
> habr=EDa que comprobar si es una simple p=E9rdida de calidad que result=
> a aceptable al ojo humano o se ha tenido en cuenta el funcionamiento de
> =E9ste a la hora de dise=F1ar el procedimiento y la p=E9rdida).
Ya que estoy, te suelto el rollo ;_) : El jpeg se basa en que el ojo
de los seres humanos es m�s sensible a la luminancia que al resto de valores
de la escala luminancia/crominancia (o saturaci�n)/contraste y en la
relaci�n de "continuidad lum�nica" que tiene una imagen fotorrealista (por
eso no funciona bien con dibujos animados, p.ej.).
Lo primero tiene que ver con la relaci�n entre bastoncillos y conos
que tiene el ojo humano (los dos tipos de "sensores" de color o de luz, por
eso a los gatos no les gustan las im�genes comprimidas con jpeg ;D). Ello
implica que los colores con menor luminancia (azules....) son "maltratados"
por el algoritmo de compresi�n jpeg, que se basa tambi�n en cuantizaci�n,
an�lisis de Fourier (FFT):
El mapa de bits se divide en regiones de 8x8 (de ah� el "mosaico"
que sale si te pasas con el factor de p�rdida) se toman esas regiones de 8x8
como una se�al de 64 valores a lo largo del tiempo, se pasa esa se�al al
"dominio frecuencial" (t� una se�al o funci�n puedes verla "en funci�n del
tiempo" o si se repite con el tiempo, puedes verla en funci�n de la
frecuencia con que se repite) y se emplea un m�todo para poder extraer de
esa se�al sus componentes fundamentales (la transformada de Fourier y los
coeficientes de Fourier), despreciando as� componentes no fundamentales
(aqu� es donde entra la p�rdida de calidad, seg�n cu�ntos componentes
desprecies). Luego adem�s hay una ponderaci�n de componentes seg�n una
matriz, y una postcompresi�n de la lista de componentes definitiva seg�n
Huffmann, pero massomenos es como te he contado (que ya me sab�a mal que t�
me contases tantas cosas y yo nada a ti ;D).
> Espero que esto aclare algo. Si encuentro jurisprudencia, te lo har=E9=
> saber.
gracias! :)
> Un saludo.
>
> -- =20
>
> RESET
>
>
Antonio Tejada Lacaci [EMAIL PROTECTED]
Depto. An�lisis y Programaci�n
Banca March S.A.
