Mini relatório – Camera Link
Projecto iVlab Data 12-06-06 Versão 1.0
Participantes Catarina Santiago Gabriel Silva Ricardo Cardoso Docente Américo Azevedo
1. Propósito do documento
Este documento visa a apresentação e descrição das arquitecturas desenvolvidas para implementar uma comunicação Camera Link entre câmara digital e frame grabber e o posterior processamento da imagem do corpo, em ambiente de desenvolvimento Kylix (Linux) ou Visual C++ (Windows).
2. Definições
• ROI: “Region of Interest”, área especifica de interesse de uma imagem. Pode ser quase qualquer rectângulo definido na frame total, através da sua altura e comprimento. A figura exemplifica algumas configurações possíveis para uma ROI.
• Tempo de exposição: período durante o qual o sensor da câmara integra a luz recebida pela lente.
3. Nota introdutória
3.1. Capacidade de aquisição
Partindo dos requisitos do equipamento industrial, em termos de velocidades nominais e número de rolhas processadas por segundo, é possível estabelecer as necessidades de capacidade de aquisição do sistema de captura de imagem.
Assim tendo como base uma taxa de processamento de 3 ou 4 rolhas por segundo, impõe-se um tempo de aquisição inferior a 250ms, desprezando tempos de processamento.
Para facilidade de cálculos defina-se:
• Tempo máximo de aquisição: 200ms.
• Número de linhas a adquirir para se obter uma imagem completa do corpo: 1000 linhas.
• Número de linhas por frame: 2 linhas.
fps
máximo
Tempo
frame
linhas
N
total
linhas
N
2500
2
.
0
2
/
1000
_
_
º
_
º
=
=
Com estes parâmetros constata-se a necessidade de taxas de aquisição na ordem das 2500fps, muito distantes da capacidade máxima da câmara Firewire utilizada (Ver anexo A), tornando-se clara a necessidade de utilização de uma tecnologia que permita altas taxas de transferência de informação (Ver anexo B), como Camera Link.
3.2. Número de linhas por frame
Duas das principais dificuldades, para uma boa captação de imagens do corpo nas condições apresentadas, estão intimamente ligadas à escolha do número de linhas a captar por frame. A saber:
• Distorção geométrica • Diferenças de luminosidade
Como o objecto em causa apresenta uma forma cilíndrica, à medida que se aumenta o número de linhas, tornam-se visíveis os limites com forma circular, o que impossibilita uma junção óptima para a formação da imagem total.
Por outro lado, a diminuição do número de linhas a captar por frame, permite ultrapassar eventuais lacunas no sistema de iluminação. Note-se que existem sempre diferenças de luminosidade entre as linhas iniciais e finais de cada frame, causando o aparecimento de manchas na imagem final.
Ao reduzir o número de linhas por frame (no limite 1 linha por frame), essa diferença de luminosidade é quase nula.
Outra condicionante a considerar é que, se por um lado, a definição de ROI’s com um número de linhas reduzido, permite o aumento do frame rate associado, por outro implica a captura de mais frames para perfazer o mesmo número total de linhas, tornando imperativo o uso de frame rate’s elevados.
Assim a proporcionalidade entre a diminuição da ROI e o aumento do frame rate, em termos de capacidade de cada câmara, é um factor de decisão na escolha da melhor tecnologia a utilizar.
Mais uma vez, pela análise da performance de cada equipamento (Ver anexo A e B), torna-se evidente a incapacidade da tecnologia Firewire com a câmara Marlin e a aptidão da tecnologia Camera Link com a câmara PhotonFocus.
3.3. Software de desenvolvimento
O desenvolvimento das aplicações de suporte ao funcionamento de Camera Link partiu de um conjunto de livrarias Sapera disponibilizadas pelo fabricante do frame grabber, tanto para Windows como para Linux.
No caso do sistema operativo Linux, foram disponibilizadas livrarias para C++, sendo impossível a sua utilização directa em Kylix, ambiente de desenvolvimento utilizado no projecto. No entanto foi estudada a hipótese de tradução dos ficheiros header (*.h), dessas livrarias, de C++ para Kylix, hipótese rejeitada devido à quantidade elevada de ficheiros a serem traduzidos, leia-se, dezenas de ficheiros. Note-se que mesmo para C++, para Linux, está disponível um número reduzido de funções, da totalidade presente em Windows.
Por todas estas condicionantes foi desenvolvida uma aplicação tendo como base uma demo fornecida para Linux, em C++, e foi implementado um processo de Shared Memory para transferência de informação entre a aplicação em C++ e a aplicação em Kylix.
Por sua vez, em Windows, a totalidade das funções Sapera estão disponíveis para Visual C++, enquanto que para Delphi e Visual Basic apenas está disponível uma parte dessas funções.
Depois de estudadas todas as linguagens referidas e constatando a inexistência de funções necessárias à implementação do sistema, em Delphi e Visual Basic, foi desenvolvida uma aplicação, para captação de imagens por Camera Link, em Visual C++.
4. Descrição
4.1. Linux
4.1.1. Shared Memory
O mecanismo de Shared Memory é um método eficiente de transferência de dados entre vários processos. Um processo aloca um bloco de memória (através de uma chamada ao sistema) que, se permitido, pode ser acedido por outros processos. A criação e a definição de permissões desta memória partilhada fica a cargo do sistema operativo, que retorna um apontador para a posição inicial do bloco de memória e um identificador do mesmo, comuns aos vários processos.
Este mecanismo permite ainda o controlo de acessos à memória, através de funções próprias. Neste caso, visto não existirem acessos simultâneos por parte das duas aplicações, não foi implementado nenhum sistema de controlo de acessos.
4.1.2. Aplicação em Kylix
A aplicação desenvolvida em Kylix, para recepção de imagens por Camera Link, permite o teste do sistema de transferência por Shared Memory e a verificação da taxa de aquisição da aplicação em C++.
Com esta finalidade a aplicação apresenta uma série de opções que definem o funcionamento normal do sistema total.
Depois de iniciada aplicação em Kylix o utilizador pode lançar ou terminar o programa de aquisição em C++, através do botão “Start grab” ou “Stop grab” e sincronizar com este, o pedido e a recepção de imagens. Para tal pode recorrer ao botão “Snap”.
A aplicação permite ainda a alteração de alguns parâmetros de captura através da página “Configurar”, entre os quais, o tamanho da ROI pretendida e o número de frames a captar.
O funcionamento interno da aplicação resume-se em quatro pontos fundamentais: 1. Lançamento da aplicação de aquisição e pedido de alocação da memória
partilhada:
O lançamento da aplicação de aquisição é efectuado com o recurso à função Libc.System da livraria Libc, que executa um script criado para o efeito.
O tamanho do bloco de memória pretendido deve ser igual em ambos os processos, aplicação em Kylix e C++, e as permissões devem ser atribuídas de modo a que as duas possam aceder ao bloco.
2. Pedido de aquisição de imagens:
As duas primeiras posições de memória do bloco alocado permitem uma troca de informações entre os dois processos, além da informação restante relativa à imagem capturada. Portanto o pedido de imagem baseia-se na escrita de um valor específico na primeira posição de memória.
3. Recepção, tratamento e apresentação de imagens:
Num funcionamento normal do sistema, na sequência de um pedido de imagem, a aplicação de aquisição deverá capturar o número de frames definido e colocar a informação no bloco de memória partilhado, assinalando o fim do processo de uma forma similar ao pedido, escrevendo um valor especifico na primeira posição de memória do bloco.
Note-se que a captura das diferentes frames e a formação da imagem final fica a cargo da aplicação de aquisição em C++ e que este sistema de transferência de dados está protegido por um esquema de time out, em que se a aplicação de aquisição, por alguma anomalia, não responder, a aplicação em Kylix ignora a informação e volta ao estado inicial.
Por outro lado, é necessário algum processamento de imagem antes de a poder disponibilizar, visto que, para minimizar os dados a transferir por Shared Memory, se optou por adquirir a imagem em formato Bayer, permitindo usar apenas um byte por pixel. Pela mesma razão é necessário então, passar a imagem de formato Bayer para RGB, tendo sido criada uma função para o efeito.
4. Alteração de parâmetros de configuração:
Todos os parâmetros de configuração apresentados na aplicação são especificados num ficheiro de configuração da câmara, extensão CCF, que além destes parâmetros contém todos os dados para o normal funcionamento da câmara e frame grabber.
Este ficheiro de configuração é ainda utilizado para enviar, à aplicação C++, o número de frames a captar.
Sendo assim a visualização dos valores de cada parâmetro e a sua alteração é efectuada através de funções de escrita e leitura de ficheiros.
4.1.3. Aplicação em C++
A aplicação de aquisição desenvolvida, tendo como base a demo “GrabCPP” disponibilizada, permite captar um número preestabelecido de frames aquando um pedido do utilizador. Neste caso o pedido é efectuado pela aplicação em Kylix, que interage, esta sim, com o utilizador. Note-se que a captura de frames pode ser associada a outro tipo de evento, como um trigger externo, neste caso sendo a aplicação em causa de teste, está implementado um sistema de pedido manual de imagens.
O esquema de funcionamento desta aplicação assenta na utilização de uma função de apresentação de frames, XferCallback, disponibilizada nas livrarias Sapera. Por defeito a função está associada ao evento fim de captura de frame e tem como finalidade a transferência de imagens para o objecto de visualização de vídeo em tempo real, neste caso o objecto final é uma janela do servidor X do Linux.
Por outro lado, a função XferCallback pode ser utilizada para algum processamento, logo que o tempo necessário não ultrapasse o tempo entre eventos recebidos. No caso, e visto que o processamento se resume a transferência de informação para a Shared Memory, o problema não se coloca.
Funcionamento geral da aplicação: 1. Inicializações:
Todos os parâmetros de funcionamento são obtidos através do ficheiro de configuração da câmara (*.ccf), assim como o número de frames a captar, por pedido.
São criados todos os objectos Sapera associados à captura de imagens. • SapAcquisition, objecto de aquisição de imagens;
• SapBuffer, buffers de armazenamento de informação;
• SapAcqToBuf, objecto de transferência de informação entre SapAcquisition e SapBuffer.
É criado o bloco de Shared Memory com o tamanho necessário, tendo em conta o número de frames e o tamanho de cada uma, e são definidas as permissões adequadas a atribuir ao bloco de memória.
2. Detecção de pedido de aquisição de imagens:
Depois de todas as inicializações efectuadas, a aplicação evolui para um estado de leitura cíclica da primeira posição do bloco de memória partilhado, não deixando de apresentar as imagens recebidas em formato vídeo ao vivo.
Quando a aplicação em Kylix coloca um valor específico na primeira posição do bloco de memória, sinal que o utilizador evocou a captação de uma imagem, a aplicação em C++ começa o ciclo de captura do número de frames definido e a formação da imagem final.
3. Recepção de imagens:
Depois de recebido o pedido de captura, sempre que é chamada a função XferCallback, a informação relativa a uma imagem é colocada no bloco de memória partilhado, formando-se a imagem final com o número de frames definido.
O fim do processo é assinalado com a escrita de um valor específico na posição de memória utilizada para sincronizar pedidos e recepção de imagens.
Diagrama de funcionamento da detecção de pedido de aquisição e da recepção de imagens:
4.1.4. Limitações da arquitectura em Linux
A arquitectura desenvolvida é afectada pela distribuição Linux utilizada (versão do kernel) e pelas livrarias de gestão de Threads associadas. A distribuição RedHat 9 faz uso da livraria NPTL (Native Posix Thread Library) ao passo que o Mandrake 9.2 utiliza a antiga livraria LinuxThreads.
A NPTL apresenta uma performance superior em relação à livraria LinuxThreads, suportando um número superior de notificação de eventos por segundo e tendo sido testada até 300 Hz.
Por sua vez os sistemas com LinuxThreads começam a perder eventos a taxas superiores a 50 Hz.
No entanto altas taxas de transferência podem ser atingidos com LinuxThreads, desde que sejam utilizados buffers em série e que as funções de resposta a eventos estejam associados a um número de buffers que permitam uma taxa de notificação abaixo dos 50 Hz.
Note-se que o objectivo da utilização de Camera Link prende-se com a obtenção de taxas de transferência da ordem das 2500fps e que a escolha da distribuição Linux está limitada pela utilização do ambiente de desenvolvimento Kylix e pela compatibilidade com os drivers disponibilizados para o frame grabber.
4.2. Windows
Como referido na nota introdutória, foi utilizado o software Visual C++, para o desenvolvimento da aplicação de teste de capturas de imagens por Camera Link, em Windows.
Visto todas as funções Sapera estarem disponibilizadas para esta linguagem de programação, não se recorreu a nenhum sistema de transferência de informação, nem mesmo de software específico de processamento de imagem.
Assim todas as opções de aquisição, armazenamento e apresentação de imagens são efectuadas recorrendo a classes, e aos seus atributos, disponibilizados pela livraria, sendo por sua vez utilizada a descodificação Bayer por hardware, se seleccionada.
São criados os mesmos objectos presentes para Linux: • SapAcquisition, objecto de aquisição de imagens; • SapBuffer, buffers de armazenamento de informação;
• SapAcqToBuf, objecto de transferência de informação entre SapAcquisition e SapBuffer.
Complementados por outras classes apenas presentes em Windows:
• SapView, em conjunto com a classe CImageWnd do próprio Visual C++, permite a apresentação de imagens em vídeo ao vivo ou directamente de uma imagem em buffer;
• SapBayer, classe de configuração da descodificação Bayer: por hardware, software ou ausente; utiliza a classe Sapera SapMyProcessing caso necessite de processamento por software.
Mais uma vez o funcionamento da aplicação centra-se na utilização da função XferCallback, que mantém os mesmos atributos anteriores: é chamada sempre que ocorre o evento fim de captura de frame e permite a apresentação das imagens capturadas.
Desta feita, sempre que o utilizador ou um evento do tipo trigger externo invoca a captura de uma imagem, a aplicação guarda o número de frames pretendido para um buffer auxiliar, associado a uma segunda janela de visualização.
A transferência de informação entre o buffer principal de captura e o buffer de armazenamento da imagem total é efectuada dentro da função XferCallback.
Por outro lado a aplicação permite, de um modo gráfico, definir o número de frames a capturar e visualização a cores ou a preto e branco, conforme está seleccionada ou não a opção de descodificação Bayer.
Todas as configurações da câmara e do frame grabber, das quais se destacam, o tamanho da ROI a utilizar e o uso ou não de trigger externo, são especificadas no ficheiro de configuração CCF, que é carregado através uma janela inicial de diálogo, com o seguinte aspecto.
Anexo A – Cálculo do frame rate da câmara Marlin F064C
Utilizando a resolução máxima da câmara (780x580) o frame rate máximo está limitado aos 60fps, no entanto com a definição de ROI’s o frame rate pode ser superior, sendo calculado pela seguinte expressão:
Graficamente:
Alguns valores genéricos da relação entre número de linhas a adquirir e a taxa de transferência:
Anexo B – Cálculo do frame rate da câmara PhotonFocus
MV-D640C-66-CL-10
O máximo frame rate desta câmara depende directamente do tempo de exposição e do tamanho da ROI, assim ao diminuir o tamanho da ROI e do tempo de exposição (ver anexo C), o frame rate pode crescer drasticamente. Note-se que só a diminuição na altura da imagem resulta num frame rate superior.
O próximo quadro mostra o aumento do frame rate com a diminuição do número de linhas a adquirir. Os números apresentados são valores arredondados, podendo ser na realidade um pouco superiores.
ROI texp = 50 µs D640-66-CL-10 MV-D640C-66-CL-10 MV-D640-33-CL-10 MV-D640C-33-CL-10 640 x 480 200 fps 100 fps 640 x 240 390 fps 200 fps 640 x 120 770 fps 390 fps 640 x 60 1490 fps 760 fps 640 x 30 2660 fps 1420 fps
Estes valores são calculados recorrendo à expressão:
treadout = tu * [CPRE + (Py + 2) * (Rx + HB) + RESET] * MODE if texp < treadout,
tframe = texp + treadout else
tframe = texp + tu * (CPRE + RESET) * MODE end
Anexo C – Software PFRemote
PFRemote é um software de configuração gráfica para as câmaras PhotonFocus. Este software permite alterar vários parâmetros de funcionamento da câmara, sendo apresentados neste documento os mais relevantes para o caso específico. Tempo de exposição: valor entre 0.042ms e 1300ms.
Frame Rate: frame rate da câmara em fps.
Região de interesse: ROI definida pelo rectângulo (X, Y), (W, H). X – coordenada do canto superior esquerdo;
Y – coordenada do canto superior esquerdo; W – comprimento da ROI;
O software permite ainda controlar outros parâmetros, dos quais se destacam o Output Mode, os ganhos de cor e o clock de funcionamento.
Output Mode: 8 Bit
Modo normal, resolução de 8 bit na escala de cinzentos; 10 Bit
Resolução de 10 bit na escala de cinzentos; 8 Bit, Gain 2x
Resolução de 8 bit na escala de cinzentos e ganho 2; 8 Bit Gain 4x
Resolução de 8 bit na escala de cinzentos e ganho 4; Ganhos de cor:
Red: controlo do ganho da cor vermelho; Green1: controlo do ganho da cor verde 1; Green2: controlo do ganho da cor verde 2; Blue: controlo do ganho da cor azul; Clock de funcionamento:
Disabled: 33MHz; Enabled: 66MHz;
