Signature_pad: Capturando dados biométricos com o sinal

Depende de quais dados você tem exatamente em mente, mas acho que seria possível. Existe a ISO/IEC 19794-7:2014 que "_especifica formatos de intercâmbio de dados para dados comportamentais de assinatura/sinal capturados na forma de uma série temporal multidimensional_", então seria incrível usar esse padrão em vez de criar nosso próprio . Infelizmente, não tenho acesso a este documento e não sei como o formato realmente se parece :/

Muito obrigado pela sua resposta! Aguardo com expectativa esse padrão e
Vou relatar aqui qualquer avanço que conseguir para uso posterior.

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

Depende de quais dados você tem exatamente em mente, mas acho que seria
possível. Existe ISO/IEC 19794-7:2014
http://www.iso.org/iso/catalogue_detail.htm?csnumber=55938 que " especificaformatos de intercâmbio de dados para dados comportamentais de assinatura/sinal capturados ema forma de uma série temporal multidimensional ", então seria incrível
usar esse padrão em vez de criar o nosso próprio. Infelizmente, eu não
tem acesso a este documento e não sabe como o formato realmente se parece
Como :/

—
Você está recebendo isso porque foi o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274250329 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/APdPAIzn5SZW2nwNKDD3evH4ijb_1Mk7ks5rUc4wgaJpZM4LphIH
.

@kalihos Você também pode experimentar a versão beta mais recente (1.6.0-beta.1), que possui o método #toData que retorna todos os pontos agrupados em linhas, mas atualmente retorna apenas as coordenadas de tempo, x e y para cada ponto. Seria bastante fácil adicionar velocidade e aceleração a ele, mas não acho que possamos capturar mais nada.

Você pode experimentar esta versão beta na página de demonstração - basta desenhar qualquer coisa e chamar signaturePad.toData() no console de ferramentas de desenvolvimento.

Claro, capturar velocidade e aceleração seria ótimo, e o suficiente
para garantir legalmente que o signatário não pode rejeitar a autoridade. De qualquer forma, o
novo método #toData é um excelente aviso para mim. vou tentar e comentar
vocês.

Muito obrigado!

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

@kalihos https://github.com/kalihos Você também pode experimentar as últimas
versão beta (1.6.0-beta.1), que tem o método #toData que retorna todos
pontos agrupados em linhas, mas atualmente retorna apenas tempo, x e y
coordenadas de cada ponto. Seria bastante fácil adicionar velocidade e
aceleração para isso, mas acho que não podemos capturar mais nada.

Você pode experimentar esta versão beta na página de demonstração
https://szimek.github.io/signature_pad/ - apenas desenhe qualquer coisa e depois
chame signaturePad.toData() no console de ferramentas de desenvolvimento.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274331306 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/APdPAH0oBwyertm7moGPS24Fubi33MKOks5rU1sJgaJpZM4LphIH
.

Suponho que a aceleração e a velocidade possam ser inferidas a partir dos timestamps - mas, pelo que vale, seria muito bom ter uma opção para incluir esses pontos de dados ao chamar toData , ou ter um novo método para imputá-los .

By the way - eu estou amando o beta. Tenho testado um pouco e estou ansioso para poder armazenar os dados brutos no banco de dados no futuro. Coisas boas! 👍

@JD-Robbs

By the way - eu estou amando o beta.

Obrigado! :)

Tenho testado um pouco e estou ansioso para poder armazenar os dados brutos no banco de dados no futuro.

É exatamente por isso que eu prefiro usar algum padrão existente para armazenar essas coisas. Uma vez que as pessoas comecem a armazená-lo em seu banco de dados, será difícil modificá-lo nas próximas versões. Originalmente, era para ser privado e usado apenas para desenhar SVG e ajudar nos testes de unidade.

Eu só estou querendo saber qual velocidade e aceleração devem ser para o primeiro ponto em cada linha - 0 ou null/undefined ?

Eu tentei sua excelente versão beta e funciona muito bem! Como você disse, seria fantástico ter velocidade e aceleração adicionais disponíveis. No ponto legal, acho que não é relevante ter 0 ou null/undefined para o primeiro ponto, pois seria usado apenas para comparar um sinal com outro salvo anteriormente, para que qualquer pessoa possa verificar se é a mesma pessoa que assinou as duas vezes . Mas, tecnicamente falando, talvez seja melhor definir a aceleração do primeiro ponto para 0. Acho que seria mais fácil armazenar o array completo, porque 0 é sempre um formato mais fácil de exportar para um arquivo... store "null-5-3-7-2...", e soa um pouco confuso na minha opinião...

Respeito ao padrão, como eu disse, estou tentando obter informações detalhadas sobre ele, mas as grandes diferenças legais de complexidade entre diferentes países não ajudam em nada... Por exemplo, na Espanha não há certificação legal sobre esse tipo de sinal "manuscrita digital", mas é aceito. Mas, ao contrário do tradicional sinal manuscrito ou certificado digital, aqui é você quem precisa demonstrar que seu processo está correto e pode garantir a autenticidade do sinal, mas com base em um ordenamento jurídico espanhol (http:// noticias.juridicas.com/base_datos/Admin/l59-2003.html - desculpe, apenas espanhol).

Oi de novo!

De qualquer forma, não consigo acessar o documento padrão, mas estive analisando a lei espanhola e seus dados atualmente capturados estão mais do que corretos. Apenas dados como pontos de pressão e inclinação são impossíveis de capturar de um dispositivo normal, mas não são totalmente necessários. De qualquer forma, velocidade e aceleração seriam incríveis para garantir que o usuário não rejeitasse seu próprio sinal. Estou iniciando meu desenvolvimento integrando seu componente. Se você adicionar esses dados adicionais em um futuro próximo, tentarei adaptar os dados em meu banco de dados. Está funcionando muito bem...

Muito obrigado!

Eu acho que se um ponto já tem velocidade e aceleração, então ele não precisa mais de tempo. Vou tentar atualizá-lo, embora possa demorar um pouco. Talvez alguém queira criar um PR? 😉

@szimek

É exatamente por isso que eu prefiro usar algum padrão existente para armazenar essas coisas. Uma vez que as pessoas comecem a armazená-lo em seu banco de dados, será difícil modificá-lo nas próximas versões. Originalmente, era para ser privado e usado apenas para desenhar SVG e ajudar nos testes de unidade.

Esse é um ponto muito bom - eu nem pensei tão longe com toda a minha empolgação (embora eu ainda esteja armazenando BLOBs, é bom ter as informações biométricas brutas também). Suponho que qualquer versão futura ainda será baseada nas informações básicas sobre coordenadas e tempo - portanto, acho que sempre pode haver um caminho de atualização/conversão caso as coisas mudem (por exemplo, medidas/escalas). Mas, novamente, não estou realmente atualizado sobre como tudo é implementado.

Eu só estou querendo saber qual velocidade e aceleração devem ser para o primeiro ponto em cada linha - 0 ou nulo/indefinido?

Eu acho que a velocidade seria 0, e a aceleração do delta até o segundo ponto? Embora, então, qual seria a aceleração do último ponto? Talvez, ambos devam ser 0 - não tenho certeza.

Eu acho que se um ponto já tem velocidade e aceleração, então ele não precisa mais de tempo. Vou tentar atualizá-lo, embora possa demorar um pouco. Talvez alguém queira criar um PR? 😉

Como alternativa, acho que o comportamento toData e fromData poderia permanecer como está (apenas para manter os dados necessários no mínimo).

Em vez disso, talvez possa haver um método adicional no protótipo que possa transformar a saída de toData em {x: number, y: number, time: number, velocity: number, acceleration: number}[] .

Talvez você esteja certo. Eu poderia inferir essa informação a partir do tempo,
pensei que poderia ser mais fácil comparar dois sinais. Mas sim, isso sobrecarregaria
o objeto sem precisar. Eu trabalharei com sua versão beta atual.
Está perfeito como está!

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

Acho que se um ponto já tem velocidade e aceleração, então não
realmente precisa de mais tempo. Vou tentar atualizá-lo, embora possa demorar um
enquanto. Talvez alguém queira criar um PR? 😉

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274872842 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/APdPAG5bKRA4vv9_uqT563KiR1eqpZ_hks5rVjLCgaJpZM4LphIH
.

+1 nisso.
Esta é uma boa informação para cumprir a ISO 19794-7.

@javenosa Você tem alguma informação sobre quais dados/formato ISO 19794-7 realmente especifica?

Coord X da caneta (incrementa quando se move para a direita)
Coord Y da caneta (incrementa quando se move para o topo)
Coord Z da caneta (incrementa quando move o elevador entre o dispositivo e a caneta, isso não se aplica aqui)
Velocidade horizontal (diferença entre velocidades)
Velocidade vertical (diferença entre velocidades)
Aceleração horizontal
Aceleração vertical
Tempo
Diferença de tempo
Pressão
Ângulo (isso não se aplica aqui)

Com o seu plugin, você pode obter a maioria dos itens desta lista.

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

@javenosa Obrigado! Se houver alguém que queira fazer PR para adicionar velocidades horizontais e verticais e aceleração e diferença de tempo, seria incrível 😉 Como você disse, não podemos realmente obter coord Z, pressão ou ângulo.

Uma diferença é que na tela HTML a coord Y aumenta quando se move para a parte inferior. Não tenho certeza se faz sentido alterá-lo para cumprir as especificações, porque será um pouco chato usar esses dados para desenhar em uma tela e você provavelmente precisará saber a altura da tela para saber o que para subtrair...

Também estou querendo saber se também devemos ter algum outro método (ou uma opção para #toData ) que retorne a cor da caneta e as larguras máximas / mínimas por linha também. Não é realmente necessário para dados biométricos de assinatura, então talvez possa ser adicionado mais tarde, se um número suficiente de pessoas reclamarem sobre isso.

Acho que pode haver pressão no dispositivo correto (é claro, com suporte de pressão, iPhone 6s, iPhone 6s Plus, iPhone 7, iPhone 7 Plus, etc).

Eu não tinha ideia de que é possível obter esses valores em JS, isso é muito legal.

Embora olhando para o código-fonte https://pressurejs.com , não parece ser trivial de implementar e não tenho certeza se vale a pena o código adicional, então talvez possa ser adiado por enquanto e eventualmente adicionado nas próximas versões.

Sim, o pressurejs é uma alternativa (acabei de copiar a versão do iphone do site deles hahah).
Eu entendo seu ponto, lógica de som.

Eu testei o pressurejs e parece sempre dizer que o dispositivo não é suportado (tentei com o trackpad normal do Macbook, iPhone ...). De qualquer forma, olhando para as informações de especificação de @javenosa , acho que estamos armazenando todas as informações necessárias no banco de dados com o método toData, exceto talvez pressão (difícil de obter sem um dispositivo Wacom ou similar) e ângulo (semelhante ao anterior) . Atualmente, estou usando seu excelente plugin em meu aplicativo e funciona bem. E, se mais tarde eu precisar analisar alguma assinatura, posso ler informações biométricas e obter dados adicionais, como velocidade ou aceleração. Acho que não é necessário armazenar informações redundantes...

@kalihos Se decidirmos ignorar a pressão por enquanto, você está certo de que todos os outros dados (ou seja, velocidades e acelerações) podem ser derivados do tempo. Talvez por enquanto seja mais fácil apenas retornar apenas o tempo e fornecer um script no arquivo README que possa convertê-lo em algo que tenha esses dados adicionais.

Eu só estou querendo saber se também precisamos retornar o tamanho da tela (ou talvez melhores coordenadas X e Y max/min), para que seja possível reverter as coordenadas Y (0 na parte inferior vs 0 na parte superior).

@szimek É uma boa ideia fornecer as coordenadas X e Y max/min. Mas leve em consideração que, ao salvar em SVG, essas informações podem ser confusas devido à possibilidade de redimensionamento. Você não acha que seria melhor armazenar a assinatura apenas no formato PNG se você deseja armazenar no máximo X/Y?

Respeito ao script no arquivo README, sim, é outra boa ideia. Seria apenas necessário garantir uma comparação correta para fins legais (reivindicação legal).

@kalihos Eu estava pensando em armazenar max/min X e Y apenas para que seja possível reverter Y para dados biométricos. Como @javenosa mencionou antes, na especificação 0 está na parte inferior, mas em uma tela 0 está na parte superior. Se quisermos seguir a especificação, eu precisaria de alguma maneira de "inverter" as coordenadas Y. Claro que max/min X e Y também podem ser derivados iterando sobre todos os pontos retornados pelo método #toData , então não precisa necessariamente ser retornado pelo próprio #toData .

@szimek É uma boa opção para armazenar max/min X e Y, para que você possa restaurar a tela completa e cumprir a especificação. De qualquer forma, não acho que seja totalmente necessário levar a especificação ao pé da letra, se você puder garantir a autenticidade da assinatura...

alguma atualização disso?
Aceleração e velocidade seriam um recurso incrível para o método "toData".

Obrigado

@javenosa Atualmente estou focando no lançamento do 1.6 com suporte a SVG, mas não tenho muito tempo livre, então está progredindo bastante lentamente.

se você quiser vê-lo em 1.6, PRs são bem-vindos ;) Além disso, deve ser muito fácil escrever um script simples que receba a saída de toData e adicione velocidades e aceleração - tudo o que você precisa para calcular isso é o tempo diffs, que já são retornados.

Eu não sei como são as fórmulas para calcular a velocidade e a aceleração, se você puder me dizer isso, eu posso fazer um PR.

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

Há Point#velocityFrom(point) que lhe dará velocidade entre 2 pontos e uma vez que você conseguir isso você pode usar quase o mesmo código para calcular a aceleração:

// 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 os métodos provavelmente devem retornar 0 em vez de 1 caso os tempos sejam os mesmos, porque a posição também deve ser a mesma...

Projeto interessante! O padrão de biometria ISO é um padrão binário codificado em ASN-1 que estávamos prestes a implementar. Felizmente para nós, uma versão XML foi lançada em 2015, que é muito mais fácil de implementar.

Em relação ao post de javenosa vale ressaltar que a maioria dos canais (chamados de canais no padrão ISO) são opcionais. Apenas x, y e t são obrigatórios e o resto é opcional. Portanto, pode ser bom ter pressão ou coordenadas Z, ângulo etc., mas não é obrigatório para um conjunto de dados biométricos totalmente compatível. Além disso, muitos outros valores podem ser calculados posteriormente a partir dos valores x, y e t existentes, como (velocidade, aceleração, etc.). Então eu começaria com um conjunto de dados mais básico: x,y,t ...

@Lonzak Se alguém puder fornecer informações sobre como exatamente a estrutura de dados deve ser em comparação com a aparência agora, seria ótimo. Porque atualmente o método #toData retorna x, y coords e tempo, então acho que é apenas uma questão de transformar a estrutura atual para o que for esperado pelo padrão ISO.

Sim, sem problemas: dê uma olhada no esquema e no exemplo fornecido. Para conversão de XML<->JS, você pode usar jsonix . Mas como já mencionado este é o padrão mais recente baseado em XML, a versão mais antiga baseada em ASN-1 é muito mais complexa para criar imho (codificador DER, BER com suporte para instruções de codificação. Não encontramos nenhum codificador/decodificador de código aberto que suportasse naquela)...

Biblioteca incrível do @szimek , usando-a em um projeto nativo de reação e é suave como manteiga!
@kalihos você conhece um bom SDK de reconhecimento/correspondência de assinatura?

Desculpe, mas não tenho nada. Eu só uso para documentos de baixo risco, então
Não espero que ninguém rejeite seu próprio signo.

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

@szimek https://github.com/szimek biblioteca incrível, usando-a em um react
projeto nativo e é suave como manteiga!
@kalihos https://github.com/kalihos você conhece uma boa assinatura
SDK de reconhecimento/correspondência?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-331285500 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/APdPANXnge-rnI2TRuV9w-uqdp8kn_nbks5sktNEgaJpZM4LphIH
.

@szimek eu encontrei algo assim:
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 Obrigado! No entanto, agora que existe SignaturePad#toData , pode-se (provavelmente) escrever um pequeno script que receba a saída dessa função e a converta para o formato esperado por esse padrão. Nem precisaria fazer parte desta biblioteca.

Algo como:

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

Se alguém aparecer com essa biblioteca, eu adicionaria informações sobre ela ao arquivo README.

Oi,
essa conversa é muito interessante!
alguém tentou implementar o padrão ISO?
Eu gostaria de ajudar

Alguma novidade sobre isso?

Como você estava falando sobre velocidade e aceleração, e a força? Existe uma biblioteca chamada pressurejs, que permite medir a força do toque em dispositivos que o suportam. Não estou neste tópico, então não sei nada sobre a parte legal.

@Springrbua v3 desta biblioteca suporta eventos de ponteiro, que podem fornecer essas informações se um dispositivo as fornecer. Portanto, deve ser possível, mas não o planejo para o primeiro lançamento 3.0.0, devido à falta de tempo e dispositivos para testá-lo.

Obrigado pela resposta rápida. Acabei de descobrir o pressurejs recentemente, então fiquei curioso, se ele poderia ser usado para assinaturas digitais também.

Biblioteca incrível do @szimek , usando-a em um projeto nativo de reação e é suave como manteiga!

@mvayngrib Como exatamente você conseguiu fazê-lo funcionar com o RN?

@ntelkedzhiev Estou usando react -native-signature-pad que é um wrapper em torno desta biblioteca. Ou melhor, estou usando um fork desse wrapper, pois queria obter largura/altura de volta junto com o URL de dados (https://github.com/tradle/react-native-signature-pad)

@mvayngrib Obrigado por me avisar! Estou fazendo a mesma coisa. Também tentei atualizar https://github.com/kevinstumpf/react-native-signature-pad para usar a nova versão atualizada deste repositório, mas levará mais tempo do que tenho agora. Acho que todos os módulos devem ser colocados dentro de um arquivo e devem estar no formato CJS/UMD.

alguma atualização sobre este tópico?

Oi, eu encontrei um padrão de implementação biométrica.
https://github.com/biosignin/bsi-core
É um pouco antigo, mas pode valer a pena como ponto de partida

Oi! Isso seria uma grande adição ao projeto. Alguma notícia sobre isso?

você quer dizer como pulso, pressão arterial, dilatação da pupila, temperatura corporal?

Em terça-feira, 15 de setembro de 2020 às 01:24 corrrso [email protected] escreveu:

Oi! Isso seria uma grande adição ao projeto. Alguma notícia sobre isso?

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-692553010 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ
.

--
aqui está minha assinatura

você quer dizer como pulso, pressão arterial, dilatação da pupila, temperatura corporal?
…
Em ter, 15 de setembro de 2020 às 01:24 corrrso @ . * > escreveu: Olá! Isso seria uma grande adição ao projeto. Alguma notícia sobre isso? — Você está recebendo isso porque está inscrito neste tópico. Responda a este e-mail diretamente, visualize-o no GitHub < #213 (comentário) > ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ .
-- aqui está minha assinatura

Ele quer dizer pressão do curso, aceleração, velocidade, etc. conforme definido nas especificações ISO 19794-7.
Estes são considerados dados biométricos úteis para validar legalmente uma assinatura, a imagem da assinatura por si só é insuficiente em alguns países como Itália e talvez Espanha.

você quer dizer como pulso, pressão arterial, dilatação da pupila, temperatura corporal?
…
Em ter, 15 de setembro de 2020 às 01:24 corrrso _ @ _. * > escreveu: Olá! Isso seria uma grande adição ao projeto. Alguma notícia sobre isso? — Você está recebendo isso porque está inscrito neste tópico. Responda a este e-mail diretamente, visualize-o no GitHub < #213 (comentário) > ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ .
-- aqui está minha assinatura

Ele quer dizer pressão do curso, aceleração, velocidade, etc. conforme definido nas especificações ISO 19794-7.
Estes são considerados dados biométricos úteis para validar legalmente uma assinatura, a imagem da assinatura por si só é insuficiente em alguns países como Itália e talvez Espanha.

Sim. É verdade que na Espanha é um requisito para assinatura digital avançada.

Eu tento fazer em https://github.com/javyxx/signature_pad é uma modificação simples para economizar pressão

https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/pressure

Oi...

Caso alguém tenha interesse, fiz no meu fork uma implementação básica para capturar pressão quando disponível e também implementei uma função para converter os dados capturados para a especificação ISO 19794-7.

Quaisquer comentários, testes, correções ou melhorias são bem-vindos.

Pode ser muito interessante fundir-se com este projeto de qualquer maneira

Eu bifurquei seu repositório para atualizar com as últimas alterações no repositório original szimek.
Acho interessante somar as acelerações AX e AY, que podem calcular como a velocidade. (Incremento da velocidade / tempo de incremento)
qual e sua OPINIAO?

qual e sua OPINIAO?

Olá Certifirm...

Tentei adicionar as acelerações também, mas estava tendo problemas com a validação dos resultados dos dados xml. A ISO especifica um valor máximo e às vezes eu estava tendo valores maiores que esse máximo. Existe uma maneira na ISO que permite aumentar e diminuir os valores, mas não ficou muito claro para mim e não tive mais tempo para investigar. Desculpe.