Signature_pad: Captura de datos biométricos con el letrero

Depende de qué datos tenga exactamente en mente, pero creo que sería posible. Existe ISO/IEC 19794-7:2014 que "_especifica formatos de intercambio de datos para datos de comportamiento de firmas/signos capturados en forma de una serie de tiempo multidimensional_", por lo que sería increíble usar este estándar en lugar de crear el nuestro propio. . Desafortunadamente, no tengo acceso a este documento y no sé cómo se ve realmente el formato :/

¡Muchas gracias por tu respuesta! Esperaré ese estándar y
Informaré aquí cualquier avance que pueda obtener para su uso posterior.

El 21/1/2017 10:21, "Szymon Nowak" [email protected] escribió:

Depende de qué datos tenga exactamente en mente, pero creo que sería
posible. Hay ISO/IEC 19794-7:2014
http://www.iso.org/iso/catalogue_detail.htm?csnumber=55938 que " especificaformatos de intercambio de datos para datos de comportamiento de firma/signo capturados enla forma de una serie de tiempo multidimensional ", por lo que sería increíble
usar este estándar en lugar de crear el nuestro. Desafortunadamente, no lo hago
tiene acceso a este documento y no sabe cómo se ve realmente el formato
me gusta :/

—
Usted está recibiendo esto porque usted fue el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274250329 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/APdPAIzn5SZW2nwNKDD3evH4ijb_1Mk7ks5rUc4wgaJpZM4LphIH
.

@kalihos También puede probar la última versión beta (1.6.0-beta.1), que tiene un método #toData que devuelve todos los puntos agrupados en líneas, pero actualmente solo devuelve las coordenadas de tiempo, x e y para cada punto. Sería bastante fácil agregarle velocidad y aceleración, pero no creo que podamos capturar nada más.

Puede probar esta versión beta en la página de demostración : simplemente dibuje cualquier cosa y luego llame a signaturePad.toData() en la consola de herramientas de desarrollo.

Por supuesto, capturar la velocidad y la aceleración sería genial, y suficiente
para garantizar legalmente que el firmante no puede rechazar la autoridad. De todos modos, el
El nuevo método #toData es un excelente aviso para mí. intentare y comentare
Uds.

¡Muchas gracias!

2017-01-22 14:35 GMT+01:00 Szymon Nowak [email protected] :

@kalihos https://github.com/kalihos También puedes probar lo último
versión beta (1.6.0-beta.1), que tiene el método #toData que devuelve todos
puntos agrupados en líneas, pero actualmente solo devuelve tiempo, x e y
coordenadas de cada punto. Sería bastante fácil sumar velocidad y
aceleración, pero no creo que podamos capturar nada más.

Puede probar esta versión beta en la página de demostración
https://szimek.github.io/signature_pad/ - simplemente dibuja cualquier cosa y luego
llame a signaturePad.toData() en la consola de herramientas de desarrollo.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274331306 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/APdPAH0oBwyertm7moGPS24Fubi33MKOks5rU1sJgaJpZM4LphIH
.

Supongo que la aceleración y la velocidad podrían deducirse de las marcas de tiempo, pero, por lo que vale, sería muy bueno tener una opción para incluir esos puntos de datos al llamar a toData , o tener un nuevo método para imputarlos. .

Por cierto, me encanta la versión beta. Lo he estado probando un poco y espero poder almacenar los datos sin procesar en la base de datos en el futuro. ¡Buena cosa! 👍

@JD-Robbs

Por cierto, me encanta la versión beta.

¡Gracias! :)

Lo he estado probando un poco y espero poder almacenar los datos sin procesar en la base de datos en el futuro.

Es exactamente por eso que preferiría usar algún estándar existente para almacenar estas cosas. Una vez que las personas comiencen a almacenarlo en su base de datos, será difícil modificarlo en las próximas versiones. Originalmente, estaba destinado a ser privado y solo se usaba para dibujar SVG y ayudar con las pruebas unitarias.

Me pregunto qué velocidad y aceleración deberían ser para el primer punto de cada línea: 0 o null/undefined .

¡He probado su excelente versión beta y funciona muy bien! Como dijiste, sería fantástico tener además velocidad y aceleración disponibles. En el punto legal, creo que no es relevante tener 0 o nulo/indefinido para el primer punto, porque solo se usaría para comparar un signo con otro previamente guardado, por lo que cualquiera puede verificar si es la misma persona que firmó las dos veces . Pero, técnicamente hablando, tal vez sería mejor establecer la aceleración para el primer punto en 0. Creo que sería más fácil almacenar la matriz completa, porque un 0 siempre es un formato más fácil de exportar a un archivo... de lo contrario, lo haríamos store "null-5-3-7-2...", y suena un poco confuso en mi opinión...

Respecto a la norma, como decía, estoy tratando de obtener información detallada sobre ella, pero las altas diferencias legales en complejidad entre los distintos países no ayudan en absoluto... Por ejemplo, en España no existe una certificación legal sobre este tipo de letrero "manuscrito digital", pero se acepta. Pero, a diferencia de la firma manuscrita tradicional o la firma digital certificada, aquí es usted quien debe demostrar que su proceso está bien y puede garantizar la autenticidad de la firma, pero en base a un ordenamiento jurídico español (http:// noticias.juridicas.com/base_datos/Admin/l59-2003.html - perdón, solo en español).

¡Hola de nuevo!

De todos modos, no puedo acceder al documento estándar, pero he estado mirando la ley española, y sus datos capturados actualmente están más que bien. Solo los datos como los puntos de presión y la inclinación son imposibles de capturar desde un dispositivo normal, pero no son completamente necesarios. De todos modos, la velocidad y la aceleración serían increíbles para garantizar que el usuario no rechace su propia señal. Estoy comenzando mi desarrollo integrando su componente. Si agrega tales datos adicionales en un futuro cercano, intentaré adaptar los datos en mi base de datos. Está funcionando muy bien...

¡Muchas gracias!

Supongo que si un punto ya tiene velocidad y aceleración, entonces ya no necesita tiempo. Intentaré actualizarlo, aunque puede llevar un tiempo. ¿Quizás alguien quiere crear un PR? 😉

@szimek

Es exactamente por eso que preferiría usar algún estándar existente para almacenar estas cosas. Una vez que las personas comiencen a almacenarlo en su base de datos, será difícil modificarlo en las próximas versiones. Originalmente, estaba destinado a ser privado y solo se usaba para dibujar SVG y ayudar con las pruebas unitarias.

Ese es un muy buen punto: ni siquiera he pensado tan lejos con toda mi emoción (aunque todavía estaré almacenando BLOB, también es bueno tener la información biométrica sin procesar). Supongo que cualquier versión futura aún se basará en la información básica sobre las coordenadas y el tiempo; por lo tanto, supongo que siempre podría haber una ruta de actualización/conversión si las cosas cambian (por ejemplo, medidas/escalas). Pero, de nuevo, no estoy realmente al tanto de cómo se implementa todo.

Me pregunto qué velocidad y aceleración deberían ser para el primer punto de cada línea: ¿0 o nulo/indefinido?

¿Supongo que la velocidad sería 0 y la aceleración el delta al segundo punto? Aunque, entonces, ¿cuál sería la aceleración del último punto? Tal vez, ambos deberían ser 0, no estoy seguro.

Supongo que si un punto ya tiene velocidad y aceleración, entonces ya no necesita tiempo. Intentaré actualizarlo, aunque puede llevar un tiempo. ¿Quizás alguien quiere crear un PR? 😉

Alternativamente, creo que el comportamiento de toData y fromData podría permanecer como está (solo para mantener los datos requeridos al mínimo).

En su lugar, quizás podría haber un método adicional en el prototipo que pueda convertir la salida de toData en {x: number, y: number, time: number, velocity: number, acceleration: number}[] .

Quizás estás en lo cierto. Podría inferir esa información a partir del tiempo,
Pensé que podría ser más fácil comparar dos signos. Pero sí, se sobrecargaría.
el objeto sin necesidad. Trabajaré con su versión beta actual.
¡Es perfecto como está!

El 24/1/2017 18:20, "Szymon Nowak" [email protected] escribió:

Supongo que si un punto ya tiene velocidad y aceleración, entonces no
realmente necesito tiempo más. Intentaré actualizarlo, aunque puede llevar un
mientras. ¿Quizás alguien quiere crear un PR? 😉

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274872842 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/APdPAG5bKRA4vv9_uqT563KiR1eqpZ_hks5rVjLCgaJpZM4LphIH
.

+1 en esto.
Esta es una buena información para cumplir con la norma ISO 19794-7.

@javenosa ¿Tiene alguna información sobre qué datos/formato ISO 19794-7 realmente especifica?

X coord de la pluma (incrementa cuando se mueve a la derecha)
Coord Y desde la pluma (incrementa cuando se mueve hacia arriba)
Coordenada Z de la pluma (aumento cuando se mueve el elevador entre el dispositivo y la pluma, esto no se aplica aquí)
Velocidad horizontal (diferencia entre velocidades)
Velocidad vertical (diferencia entre velocidades)
Aceleración horizontal
Aceleración vertical
Hora
Diferencia horaria
Presión
Ángulo (esto no se aplica aquí)

Con su complemento puede obtener la mayor cantidad de elementos de esta lista.

https://image.slidesharecdn.com/onlinesignaturerecognition-130201011136-phpapp02/95/online-signature-recognition-16-638.jpg?cb=1359681345

@javenosa Gracias! Si hay alguien que quiere hacer relaciones públicas para agregar velocidades horizontales y verticales, aceleración y diferencia de tiempo, sería increíble 😉 Como dijiste, realmente no podemos obtener la coordenada Z, la presión o el ángulo.

Una diferencia es que en el lienzo HTML, la coord Y aumenta cuando se mueve hacia abajo. No estoy seguro de si tiene sentido cambiarlo para cumplir con las especificaciones, porque será un poco molesto usar estos datos para dibujar en un lienzo y probablemente necesite saber la altura del lienzo para saber qué restar de...

También me pregunto si también deberíamos tener algún otro método (o una opción para #toData ) que devuelva el color del lápiz y los anchos máximo/mínimo por línea también. No es realmente necesario para los datos biométricos de la firma, por lo que tal vez se pueda agregar más tarde, si suficientes personas se quejan.

Creo que la presión se puede obtener en el dispositivo correcto (por supuesto, con soporte de presión, iPhone 6s, iPhone 6s Plus, iPhone 7, iPhone 7 Plus, etc.).

No tenía idea de que es posible obtener estos valores en JS, eso es bastante impresionante.

Aunque mirando el código fuente de https://pressionjs.com , no parece ser trivial de implementar y no estoy seguro de que valga la pena el código adicional, por lo que tal vez pueda posponerse por ahora y eventualmente agregarse en las próximas versiones.

Sí, pressurejs es una alternativa (simplemente copio la versión del iPhone de su sitio jaja).
Entiendo tu punto, lógica de sonido.

Probé pressurejs, y parece decir siempre que el dispositivo no es compatible (lo intenté con el trackpad normal de Macbook, iPhone...). De todos modos, mirando la información de especificaciones de @javenosa , creo que actualmente estamos almacenando toda la información necesaria en la base de datos con el método toData, excepto quizás la presión (difícil de obtener sin un dispositivo Wacom o similar) y el ángulo (similar al anterior) . Actualmente estoy usando su excelente complemento en mi aplicación y funciona bien. Y, si más tarde necesito analizar alguna firma, puedo leer información biométrica y obtener datos adicionales como velocidad o aceleración. Creo que no es necesario almacenar información redundante...

@kalihos Si decidimos omitir la presión por ahora, entonces tiene razón en que todos los demás datos (es decir, velocidades y aceleraciones) pueden derivarse del tiempo. Tal vez por ahora sería más fácil devolver solo el tiempo y proporcionar un script en el archivo README que pueda convertirlo en algo que tenga estos datos adicionales.

Me pregunto si también necesitamos devolver el tamaño del lienzo (o tal vez mejores coordenadas X e Y máx./mín.), para que sea posible invertir las coordenadas Y (0 en la parte inferior frente a 0 en la parte superior).

@szimek Es una buena idea proporcionar coordenadas X e Y máx./mín. Pero tenga en cuenta que, al guardar en SVG, dicha información podría resultar confusa debido a la posibilidad de cambiar el tamaño. ¿No cree que sería mejor almacenar la firma solo en formato PNG si desea almacenar un máximo de X/Y?

Respecto al script en el archivo README, sí, es otra buena idea. Solo sería necesario asegurar una comparación correcta a efectos legales (reclamación legal).

@kalihos Estaba pensando en almacenar max/min X e Y solo para que sea posible revertir Y para datos biométricos. Como @javenosa mencionó antes, en la especificación 0 está en la parte inferior, pero en un lienzo 0 está en la parte superior. Si quisiéramos seguir la especificación, necesitaría alguna forma de "revertir" las coordenadas Y. Por supuesto, max/min X e Y también se pueden derivar iterando sobre todos los puntos devueltos por el método #toData , por lo que no necesariamente tiene que ser devuelto por #toData en sí mismo.

@szimek Es una buena opción para almacenar max/min X e Y, para que pueda restaurar el lienzo completo y pueda cumplir con la especificación. De todos modos, no creo que sea completamente necesario tomar la especificación literalmente, si puede garantizar la autenticidad de la firma... pero es correcto almacenarla para que sea más "puro";)

¿Algún avance en esto?
La aceleración y la velocidad serían una característica sorprendente del método "toData".

Gracias

@javenosa Actualmente me estoy enfocando en lanzar 1.6 con soporte SVG, pero no tengo mucho tiempo libre, por lo que está progresando con bastante lentitud.

si quieres verlo en 1.6, los PR son bienvenidos ;) Además, debería ser bastante fácil escribir un script simple que tome la salida de toData y agregue velocidades y aceleración; todo lo que necesitas para calcular eso es el tiempo. diffs, que ya se han devuelto.

No se como seran las formulas para calcular la velocidad y la aceleracion, si me lo puedes decir te puedo hacer un PR.

velocity = change in distance / change in time
acceleration = change in velocity / change in time

Hay Point#velocityFrom(point) que te darán velocidad entre 2 puntos y una vez que lo tengas, puedes usar casi el mismo código para calcular la aceleración:

// This one already exists
Point.prototype.velocityFrom = function (start) {
  return (this.time !== start.time) ? this.distanceTo(start) / (this.time - start.time) : 1;
};

// This one should be added
Point.prototype.accelerationFrom = function (start) {
  return (this.time !== start.time) ? this.velocityFrom(start) / (this.time - start.time) : 1;
};

Ambos métodos probablemente deberían devolver 0 en lugar de 1 en caso de que los tiempos sean los mismos, porque la posición también debería ser la misma...

Interesante proyecto! El estándar de biometría ISO es un estándar binario codificado en ASN-1 que estábamos a punto de implementar. Afortunadamente para nosotros, se lanzó una versión XML en 2015, que es mucho más fácil de implementar.

Respecto al post de javenosa cabe mencionar que la mayoría de los canales (se llaman canales en la norma ISO) son opcionales. Solo se requieren x, y y t y el resto es opcional. Por lo tanto, puede ser bueno tener presión o coordenadas Z, ángulo, etc., pero no es obligatorio para un conjunto de datos biométricos totalmente compatible. Además, se pueden calcular muchos otros valores más tarde a partir de los valores existentes de x, y y t como (velocidad, aceleración, etc.). Entonces, comenzaría con un conjunto de datos más básico: x, y, t ...

@Lonzak Si alguien puede proporcionar información sobre cómo debería verse exactamente la estructura de datos en comparación con cómo se ve ahora, sería genial. Debido a que actualmente el método #toData devuelve las coordenadas x, y y el tiempo, supongo que solo se trata de transformar la estructura actual a lo que espera el estándar ISO.

Sí, no hay problema: echa un vistazo al esquema y al ejemplo proporcionado. Para la conversión XML<->JS, puede usar jsonix . Pero como ya se mencionó, este es el estándar basado en XML más nuevo, la versión anterior basada en ASN-1 es mucho más compleja de crear en mi humilde opinión (codificador DER, BER con soporte para instrucciones de codificación. No encontramos ningún codificador / decodificador de código abierto que admita ese)...

¡La increíble biblioteca de @szimek , usándola en un proyecto nativo de reacción y es suave como la mantequilla!
@kalihos , ¿conoce un buen SDK de reconocimiento/coincidencia de firmas?

Lo siento, pero no tengo nada. Solo lo uso para documentos de bajo riesgo, así que
No espero que nadie rechace su propio cartel.

El 21/9/2017 23:21, "Mark Vayngrib" [email protected] escribió:

@szimek https://github.com/szimek impresionante biblioteca, usándola en una reacción
proyecto nativo y es suave como la mantequilla!
@kalihos https://github.com/kalihos ¿Conoces una buena firma?
SDK de reconocimiento/coincidencia?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-331285500 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/APdPANXnge-rnI2TRuV9w-uqdp8kn_nbks5sktNEgaJpZM4LphIH
.

@szimek he encontrado algo así:
http://stg.jsm.gov.my/documents/372014/372056/MS+ISOIEC+19794-7+2008+-+INFORMATION+TECHNOLOGY+BIOMETRIC+DATA+INTERCHANGE+FORMATS+PART+7+SIGNATURE+SIGN+ TIME+SERIES+DATA-712359.pdf/25a168da-0654-4907-b527-ad808005fe78?version=1.0&previewFileIndex=

@mgierw ¡Gracias! Sin embargo, ahora que hay SignaturePad#toData , uno podría (probablemente) escribir un pequeño script que tome la salida de esta función y la convierta al formato esperado por este estándar. Ni siquiera tendría que ser parte de esta biblioteca.

Algo como:

const data = convertToISO(signaturePad.toData());

Si a alguien se le ocurre una biblioteca de este tipo, agregaría información al respecto en el archivo README.

Hola,
esta conversación es muy interesante!
¿Alguien trató de implementar el estándar ISO?
Me gustaría ayudar

¿Alguna noticia sobre esto?

Como estabas hablando de velocidad y aceleración, ¿qué pasa con la fuerza? Hay una biblioteca llamada pressurejs, que le permite medir la fuerza del toque en los dispositivos que lo admiten. No estoy en este tema, así que no sé nada de la parte legal.

@Springrbua v3 de esta biblioteca admite eventos de puntero, que pueden proporcionar dicha información si un dispositivo la proporciona. Por lo tanto, debería ser posible, pero no lo planeo para la primera versión 3.0.0, debido a la falta de tiempo y de dispositivos para probarlo.

Gracias por la rápida respuesta. Acabo de descubrir pressurejs últimamente, así que tenía curiosidad, si también podría usarse para firmas digitales.

¡La increíble biblioteca de @szimek , usándola en un proyecto nativo de reacción y es suave como la mantequilla!

@mvayngrib ¿Cómo logró exactamente que funcionara con RN?

@ntelkedzhiev Estoy usando react-native-signature-pad, que es un contenedor de esta biblioteca. O más bien, estoy usando una bifurcación de ese contenedor, ya que quería recuperar el ancho/alto junto con la URL de datos (https://github.com/tradle/react-native-signature-pad)

@mvayngrib ¡ Gracias por avisarme! Estoy haciendo lo mismo. También intenté actualizar https://github.com/kevinstumpf/react-native-signature-pad para usar la nueva versión actualizada de este repositorio, pero tomará más tiempo del que tengo ahora. Creo que todos los módulos deben colocarse dentro de un archivo y deben estar en formato CJS/UMD.

alguna actualización sobre este tema?

Hola, encontré un estándar de implementación biométrica.
https://github.com/biosignin/bsi-core
Es un poco antiguo pero puede valer como punto de partida.

¡Hola! Esta sería una gran adición al proyecto. ¿Alguna noticia al respecto?

¿Te refieres al pulso, la presión arterial, la pupila dilatada, la temperatura corporal?

El martes 15 de septiembre de 2020 a la 1:24 a. m. corrrso [email protected] escribió:

¡Hola! Esta sería una gran adición al proyecto. ¿Alguna noticia al respecto?

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-692553010 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ
.

--
aquí está mi firma

¿Te refieres al pulso, la presión arterial, la pupila dilatada, la temperatura corporal?
…
el martes 15 sep 2020 a las 1:24 corrrso @ . * > escribió: Hola! Esta sería una gran adición al proyecto. ¿Alguna noticia al respecto? — Estás recibiendo esto porque estás suscrito a este hilo. Responda a este correo electrónico directamente, véalo en GitHub < #213 (comentario) > o cancele la suscripción https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ .
-- aquí está mi firma

Quiere decir presión de carrera, aceleración, velocidad, etc., tal como se define en las especificaciones ISO 19794-7.
Estos se consideran datos biométricos útiles para validar legalmente una firma, la imagen de la firma por sí sola es insuficiente en algunos países como Italia y quizás España.

¿Te refieres al pulso, la presión arterial, la pupila dilatada, la temperatura corporal?
…
el martes 15 sep 2020 a las 1:24 corrrso _ @ _. * > escribió: Hola! Esta sería una gran adición al proyecto. ¿Alguna noticia al respecto? — Estás recibiendo esto porque estás suscrito a este hilo. Responda a este correo electrónico directamente, véalo en GitHub < #213 (comentario) > o cancele la suscripción https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ .
-- aquí está mi firma

Quiere decir presión de carrera, aceleración, velocidad, etc., tal como se define en las especificaciones ISO 19794-7.
Estos se consideran datos biométricos útiles para validar legalmente una firma, la imagen de la firma por sí sola es insuficiente en algunos países como Italia y quizás España.

Sí. Es cierto que en España es un requisito para la firma digital avanzada.

Lo que trato de hacer en https://github.com/javyxx/signature_pad es una modificación simple para ahorrar presión

https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/presión

Hola...

Si alguien está interesado, hice en mi fork una implementación básica para capturar la presión cuando estaba disponible y también implementé una función para convertir los datos capturados a la especificación ISO 19794-7.

Cualquier comentario, prueba, arreglo o mejora es bienvenido.

Puede ser muy interesante fusionarse con este proyecto de todos modos.

Bifurqué su repositorio para actualizarlo con los últimos cambios en el repositorio original de szimek.
Creo que es interesante agregar las aceleraciones AX y AY, que se pueden calcular como la velocidad. (Incremento de la velocidad / tiempo de incremento)
¿Cuál es tu opinión?

¿Cuál es tu opinión?

Hola Certifirm...

Traté de agregar también las aceleraciones, pero estaba teniendo problemas con la validación de los resultados de los datos xml. La ISO especifica un valor máximo y, a veces, tenía valores más grandes que ese máximo. Hay una forma en el ISO que te permite escalar hacia arriba y hacia abajo los valores, pero no estaba muy claro para mí y no tuve más tiempo para investigar. Lo siento.