BR112013007146B1

BR112013007146B1 - Método, sistema de processamento de sinal de imagem e dispositivo eletrônico para sincronização de flash com o uso de sinal de temporização de interface de sensor de imagem

Info

Publication number: BR112013007146B1
Application number: BR112013007146-0A
Authority: BR
Inventors: Guy Cote; Jeffrey E. Frederiksen
Original assignee: Apple Inc.
Priority date: 2010-09-30
Filing date: 2011-08-31
Publication date: 2021-09-28

Abstract

SINCRONIZAÇÃO DE FLASH COM O USO DE SINAL DE TEMPORIZAÇÃO DE INTERFACE DE SENSOR DE IMAGEM. Certos aspectos desta descrição referem-se a um sistema de processamento de sinal de imagem 32 que inclui um controlador de flash 550 que é configurado para ativar um dispositivo de flash antes do início de um quadro de imagem-alvo com o uso de um sinal de temporização de sensor. Em uma modalidade, o controlador de flash 550 recebe um sinal de temporização de sensor atrasado e determina um tempo de início de ativação de flash com o uso do sinal de temporização de sensor atrasado para identificar um tempo correspondente ao final do quadro anterior, aumentar aquele tempo em um tempo de supressão vertical e, então, subtrair um primeiro desvio para compensar o atraso entre o sinal de temporização de sensor e o sinal de temporização de sensor atrasado. Então, o controlador de flash 550 substrai um segundo desvio para determinar o tempo de ativação de flash, garantindo, desse modo, que o flash seja ativado antes de receber o primeiro pixel do quadro-alvo.

Description

Antecedentes

[0001] A presente descrição refere-se, em geral, a dispositivos de imageamento digitais e, mais particularmente, a sistemas e métodos para processar dados de imagem obtidos com o uso de um sensor de imagem de um dispositivo de imageamento digital.

[0002] Essa seção é destinada a introduzir o leitor a vários aspectos da técnica que podem ser relacionados a vários aspectos das presentes técnicas, que são descritos abaixo. Acredita-se que essa discussão é útil para fornecer ao leitor informações de antecedentes para facilitar uma melhor compreensão dos vários aspectos da presente descrição. Em conformidade, deve-se compreender que essas declarações devem ser interpretadas a essa luz, e não como admissões da técnica anterior.

[0003] Recentemente, os dispositivos de imageamento digitais se tornaram cada vez mais populares devido, pelo menos parcialmente, ao fato de tais dispositivos se tornarem mais e mais acessíveis para o consumidor médio. Ademais, além de um número de câmeras digitais autônomas disponíveis atualmente no mercado, não é incomum dispositivos de imageamento digitais serem integrados como parte de outro dispositivo eletrônico, como um computador de mesa ou do tipo notebook, um telefone celular ou um tocador de mídia portátil.

[0004] Para obter dados de imagem, a maioria dos dispositivos de imageamento digitais inclui um sensor de imagem que fornece vários elementos detectores de luz (por exemplo, fotodetectores) configurados para converter luz detectada pelo sensor de imagem em um sinal elétrico. Um sensor de imagem também pode incluir uma matriz de filtro de cor que filtra a luz capturada pelo sensor de imagem para capturar informações de cor. Os dados de imagem capturados pelo sensor de imagem podem, então, ser processados por uma pipeline de processamento de imagem, que pode aplicar várias operações de processamento de imagem aos dados de imagem para gerar uma imagem colorida completa que pode ser exibida para a visualização em um dispositivo de exibição, como um monitor.

[0005] Embora técnicas de processamento de imagem convencionais busquem, em geral, produzir uma imagem visualizável que é ambas objetiva e subjetivamente agradável ao espectador, tais técnicas convencionais podem são tratar adequadamente de erros e/ou distorções nos dados de imagem introduzidos pelo dispositivo de imageamento e/ou o sensor de imagem. Por exemplo, pixels defectivos no sensor de imagem, que podem ser devido a defeitos de fabricação ou falha operacional, podem falhar em captar níveis de luz com precisão e, se não corrigidos, podem se manifestar como aparecendo na imagem processada resultante. Adicionalmente, a queda de intensidade de luz nas bordas do sensor de imagem, que pode ser devido às imperfeições da fabricação da lente, pode afetar adversamente as medições de caracterização e pode resultar em uma imagem na qual a intensidade geral de luz não é uniforme. A pipeline de processamento de imagem também pode realizar um ou mais processos para ajustar a nitidez da imagem. Técnicas de ajuste de nitidez da imagem convencionais, entretanto, podem não dar conta adequadamente de ruído existente no sinal de imagem, ou pode ser incapaz de distinguir o ruído das bordas e as áreas com textura na imagem. Em tais casos, técnicas de ajuste de nitidez convencionais podem de fato aumentar o surgimento de ruído na imagem, o que é, em geral, indesejável. Ademais, várias etapas de processamento de imagem adicionais, algumas das quais podem contar com estatísticas de imagem coletadas por um mecanismo de coleta de estatísticas, também podem ser realizadas.

[0006] Outra operação de processamento de imagem que pode ser aplicada aos dados de imagem capturada pelo sensor de imagem é uma operação de interpolação. Porque a matriz de filtro de cor fornece, em geral, dados de cor em um comprimento de onda por pixel de sensor, um conjunto de dados de cor completo é, em geral, interpolado para cada canal de cor para reproduzir uma imagem de cor completa (por exemplo, imagem de RGB). Técnicas de interpolação convencionais interpolam, em geral, valores para dados de cor ausentes em uma direção horizontal ou vertical, dependendo, em geral, de algum tipo de limite fixo. Entretanto, tais técnicas de interpolação convencionais podem não dar conta de modo adequado dos locais e direção das bordas na imagem, o que pode resultar em artefatos de borda, como aliasing, artefatos de xadrez ou artefatos de arco-íris sendo introduzidos na imagem de cor completa, particularmente ao longo das bordas diagonais na imagem.

[0007] Em conformidade, várias considerações deveriam ser tratadas ao processar uma imagem digital obtida com uma câmera digital ou outro dispositivo de imageamento para melhorar a aparência da imagem resultante. Em particular, certos aspectos da descrição abaixo podem tratar de uma ou mais das desvantagens brevemente mencionadas acima.

SUMÁRIO

[0008] Um sumário de certas modalidades apresentadas no presente documento fé apresentado abaixo. Deve-se compreender que esses aspectos são apresentados meramente para fornecer ao leitor um breve sumário dessas certas modalidades e que esses aspectos não são destinados a limitar o escopo dessa descrição. De fato, essa descrição pode abranger uma variedade de aspectos que podem não ser apresentados abaixo.

[0009] A presente descrição fornece e ilustra várias modalidades de técnicas de processamento de sinal. Particularmente, modalidades apresentadas dessa descrição podem se referir ao processamento de dados de imagem com o uso de um back-end de unidade de processamento de imagem, à disposição e configuração de armazenamento temporário em linha para implantar a lógica de processamento de pixel bruto, uma técnica para gerenciar o movimento de dados de pixel na presença de condições de sobrefluxo (também chamado de saturação), técnicas para sincronizar dados de vídeo e áudio, assim como técnicas relacionadas ao uso de vários formatos de memória de pixel que podem ser suados para armazenar dados de pixel na memória e para ler dados de pixel da memória.

[00010] Em relação ao processamento de back-end, modalidades apresentadas fornecem um sistema de processamento de sinal de imagem que inclui uma unidade de processamento de pixel de back-end que recebe dados de pixel após serem processados por pelo menos uma dentre uma unidade de processamento de pixel de front-end e uma pipeline de processamento de pixel. Em certas modalidades, a unidade de processamento de back-end recebe dados de imagem e pode ser configurada para aplicar operações de detecção de face, mapeamento de tom local, ajustes de claridade, contraste, cor, assim como de escala. Ademais, a unidade de processamento de back-end também pode incluir uma unidade de estatísticas de back-end que pode coletar estatísticas de frequência. As estatísticas de frequência podem ser fornecidas a um encodificador e podem ser usadas para determinar parâmetros de quantização que devem ser aplicados a um quadro de imagem.

[00011] Um aspecto adicional da descrição se refere à implantação de uma unidade de processamento de pixel bruto com o uso de um conjunto de armazenamento temporário em linha. Em uma modalidade, o conjunto de armazenamento temporário em linha pode incluir um primeiro subconjunto e segundo subconjunto. Várias unidades lógicas da unidade de processamento de pixel bruto podem ser implantadas com o uso dos primeiro e segundo subconjuntos de armazenamento temporário em linha de maneira compartilhada. Por exemplo, em uma modalidade, a correção de pixel defectivo e a lógica de detecção podem ser implantadas com o uso do primeiro subconjunto de armazenamento temporário em linha. O segundo subconjunto de armazenamento temporário em linha pode ser usado para implantar lógica de correção de sombreamento de lente, lógica de ganho, compensação e fixação e lógica de interpolação. Ademais, a redução de ruído também pode ser implantada com o uso de pelo menos uma porção de cada um dentre os primeiro e segundo subconjuntos de armazenamento temporário em linha.

[00012] Outro aspecto da descrição pode ser referir a um sistema de processamento de sinal de imagem inclui a lógica de controle de sobrefluxo que detecta uma condição de sobrefluxo quando uma unidade de destino quando uma fila de entrada de sensor e/ou unidade de processamento de front-end recebe pressão posterior a partir de uma unidade de destino a jusante. O sistema de processamento de sinal de imagem também pode incluir um controlador de flash que é configurado para ativar um dispositivo de flash anteriormente ao início de um quadro de imagem-alvo ao usar um sinal de temporização de sensor. Em uma modalidade, o controlador de flash recebe um sinal de temporização de sensor atrasado e determina um tempo de início de ativação de flash ao usar o sinal de temporização atrasado de sensor para identificar um tempo correspondente ao final do quadro anterior, aumentando aquele tempo em um tempo de supressão vertical e, então, subtraindo um primeiro desvio para compensar o atrasado do sinal de temporização de sensor e o sinal de temporização de sensor atrasado. Então, o controlador de flash subtrai um segundo desvio para determinar o tempo de ativação de flash, garantindo, assim, que o flash seja ativado anteriormente ao recebimento do primeiro pixel do quadro-alvo. Aspectos adicionais da descrição fornecem técnicas relacionadas à sincronização de áudio-vídeo. Em uma modalidade, um registro de código de tempo fornece um carimbo de tempo atual quando amostrado. O valor do registro de código de tempo pode ser aumentado em intervalos regulares com base em um relógio do sistema de processamento de sinal de imagem. No início de um quadro atual adquirido por um sensor de imagem, o registro de código de tempo é amostrado e um carimbo de tempo é armazenado em um registro de carimbo de tempo associado ao sensor de imagem. O carimbo de tempo é, então, lido a partir do registro de carimbo de tempo e registrado em um conjunto de metadados associado a um quadro atual. O carimbo de tempo armazenado nos metadados de quadro pode, então, ser usados para sincronizar o quadro atual a um conjunto de dados de áudio correspondente.

[00013] Um aspecto adicional da presente descrição fornece um controlador de entrada/saída de memória flexível que é configurado para armazenar e ler os múltiplos tipos de pixels e formatos de memória de pixel. Por exemplo, o controlador de I/O de memória pode apoiar o armazenamento e a leitura de pixels de imagem brutos em vários bits de precisão, como 8 bits, 10 bits, 12 bits, 14 bits e 16 bits. Os formatos de pixel que estão desalinhados dos bytes de memória (por exemplo, não sendo um múltiplo de 8 bits) podem ser armazenados de maneira em pacote. O controlador de I/O de memória também pode suportar vários formatos de conjuntos de pixel de RGB e conjuntos de pixel de YCC.

[00014] Vários refinamentos das características indicadas acima podem existir em relação a vários aspectos da presente descrição. Características adicionais também podem ser incorporadas nesses vários aspectos. Esses refinamentos e características adicionais podem existir individualmente ou em qualquer combinação. Por exemplo, várias características discutidas abaixo em relação a uma ou mais modalidades ilustradas podem ser incorporadas em qualquer um dos aspectos descritos acima da presente descrição sozinhas ou em qualquer combinação. Novamente, o breve sumário apresentado acima é destinado apenas a familiarizar o leitor com certos aspectos e contextos de modalidades da presente descrição sem limitação à matéria reivindicada.

BREVE DESCRIÇÃO DOS DESENHOS

[00015] O depósito de patenteou pedido de patente contém pelo menos um desenho executado em cor. As cópias dessa publicação de patente ou de pedido de patente com desenhos coloridos serão fornecidas pelo Escritório mediante a solicitação e pagamento da taxa necessária.

[00016] Vários aspectos dessa descrição podem ser mais bem compreendidos mediante a leitura da seguinte descrição detalhada e mediante referência aos desenhos, nos quais:

[00017] A Figura 1 é um diagrama de bloco simplificado que mostra componentes de um exemplo de um dispositivo eletrônico que inclui um dispositivo de imageamento e conjunto de circuitos de processamento de imagem configurado para implantar uma ou mais técnica de processamento de imagem apresentado na presente descrição;

[00018] A Figura 2 mostra uma representação gráfica de um bloco de pixel 2x2 de uma matriz de filtro de cor Bayer que pode ser implantada no dispositivo de imageamento da Figura 1;

[00019] A Figura 3 é uma vista em perspectiva do dispositivo eletrônico da Figura 1 na forma de um dispositivo de computação do tipo laptop, de acordo com os aspectos da presente descrição;

[00020] A Figura 4 é uma vista frontal do dispositivo eletrônico da Figura 1 na forma de um dispositivo de computação de mesa, de acordo com aspectos da presente descrição;

[00021] A Figura 5 é uma vista frontal do dispositivo eletrônico da Figura 1 na forma de um dispositivo eletrônico portátil de mão, de acordo com aspectos da presente descrição;

[00022] A Figura 6 é uma vista posterior do dispositivo eletrônico mostrado na Figura 5;

[00023] A Figura 7 é um diagrama de bloco que ilustra uma modalidade do conjunto de circuitos de processamento de imagem da Figura 1 que inclui uma lógica de sinal de imagem processamento de front-end (ISP) e lógica de processamento de pipe de ISP, de acordo com aspectos da presente descrição;

[00024] A Figura 8 é um diagrama de bloco que ilustra outra modalidade do conjunto de circuitos de processamento de imagem da Figura 1 que inclui lógica de sinal de imagem processamento de frontend (ISP), lógica de processamento de pipe (pipeline) de ISP e lógica de processamento de back-end ISP, de acordo com aspectos da presente descrição;

[00025] A Figura 9 é um fluxograma que mostra métodos para o processamento dados de imagem com o uso ou do conjunto de circuitos de processamento de imagem da Figura 7 ou Figura 8, de acordo com aspectos da presente descrição;

[00026] A Figura 10 é um diagrama de bloco mais detalhado que mostra uma modalidade da lógica de front-end de ISP que pode ser implantada na Figura 7 ou Figura 8, de acordo com aspectos da presente descrição;

[00027] A Figura 11 é um fluxograma que mostra um método para o processamento dados de imagem na lógica de front-end de ISP da Figura 10, de acordo com uma modalidade;

[00028] A Figura 12 é um diagrama de bloco que ilustra uma configuração de registros de armazenamento temporário duplo e registros de controle que podem ser utilizados para o processamento dados de imagem na lógica de front-end de ISP, de acordo com uma modalidade;

[00029] As Figuras 13 a 15 são diagramas de temporização que mostram modos diferentes para acionar o processamento de um quadro de imagem, de acordo com modalidades das presentes técnicas;

[00030] A Figura 16 é um diagrama que mostra um registro de controle com mais detalhes, de acordo com uma modalidade s;

[00031] A Figura 17 é um fluxograma que mostra um método para uso de uma unidade de processamento de pixel de front-end para processar quadros de imagem quando a lógica de front-end de ISP da Figura 10 está operando em um modo de sensor único;

[00032] A Figura 18 é um fluxograma que mostra um método para uso de uma unidade de processamento de pixel de front-end para processar quadros de imagem quando a lógica de front-end de ISP da Figura 10 está operando em um modo de sensor duplo;

[00033] A Figura 19 é um fluxograma que mostra um método para o uso de uma unidade de processamento de pixel de front-end para processar quadros de imagem quando a lógica de front-end de ISP da Figura 10 está operando em um modo de sensor duplo;

[00034] A Figura 20 é um fluxograma que mostra um método no qual ambos os sensores de imagem estão ativos, mas em que um primeiro sensor de imagem está enviando quadros de imagem para uma unidade de processamento de pixel de front-end, enquanto o segundo sensor de imagem está enviando quadros de imagem para uma unidades de processamento de estatística de modo que as estatísticas de imageamento para o segundo sensor estejam imediatamente disponíveis quando o segundo sensor de imagem continuar enviando quadros de imagem para a unidade de processamento de pixel de frontend em um momento posterior, de acordo com uma modalidade.

[00035] A Figura 21 é uma representação gráfica de um formato de acesso de memória linear que pode ser aplicado a formatos de pixel armazenados em uma memória do dispositivo eletrônico da Figura 1, de acordo com aspectos da presente descrição;

[00036] A Figura 22 é uma representação gráfica de um formato de acesso de memória lado a lado que pode ser aplicado a formatos de pixel armazenados em uma memória do dispositivo eletrônico da Figura 1, de acordo com aspectos da presente descrição;

[00037] A Figura 23 é uma representação gráfica de várias regiões de imageamento que podem ser definidas em um quadro de imagem capturada de fonte por um sensor de imagem, de acordo com aspectos da presente descrição;

[00038] A Figura 24 é uma representação gráfica de uma técnica para uso da unidade de processamento de front-end de ISP para processar tiras verticais sobrepostas de um quadro de imagem;

[00039] A Figura 25 é um diagrama que mostra como a troca de byte pode ser aplicada a dados de pixel de imagem de recebimento a partir da memória com o uso de um código de swap, de acordo com aspectos da presente descrição;

[00040] As Figuras 26 a 29 mostram exemplos de formatos de memória para dados de imagem brutos que foram suportados pelo conjunto de circuitos de processamento de imagem da Figura 7 ou Figura 8, de acordo com modalidades da presente descrição;

[00041] As Figuras 30 a 34 mostram exemplos de formatos de memória para dados de imagem de RGB de cor completa que podem ser suportados pelo conjunto de circuitos de processamento de imagem da Figura 7 ou Figura 8, de acordo com modalidades da presente descrição;

[00042] As Figuras 35 e 36 mostram exemplos de formatos de memória para dados de imagem de luma/croma (YUV/YC1C2) que podem ser suportados pelo conjunto de circuitos de processamento de imagem da Figura 7 ou da Figura 8, de acordo com modalidades da presente descrição;

[00043] A Figura 37 mostra um exemplo de como determinar um local de quadro na memória em um formato de acesso linear, de acordo com aspectos da presente descrição;

[00044] A Figura 38 mostra um exemplo de como determinar um local de quadro em memória em um formato de acesso lado a lado, de acordo com aspectos da presente descrição.

[00045] A Figura 39 é um diagrama de bloco do conjunto de circuitos de ISP da Figura 8 que mostra como o manejo de sobrefluxo pode ser realizado, de acordo com uma modalidade da presente descrição;

[00046] A Figura 40 é um fluxograma que mostra um método para o manejo de sobrefluxo quando uma condição de sobrefluxo ocorre enquanto dados de pixel de imagem estão sendo lidos a partir de memória de figura, de acordo com aspectos da presente descrição;

[00047] A Figura 41 é um fluxograma que mostra um método para o manejo de sobrefluxo quando uma condição de sobrefluxo ocorre enquanto os dados de pixel de imagem estão sendo lidos a partir de uma interface de sensor de imagem, de acordo com uma modalidade da presente descrição;

[00048] A Figura 42 é um fluxograma que mostra outro método para o manejo de sobrefluxo quando uma condição de sobrefluxo ocorre, enquanto os dados de pixel de imagem estão sendo lidos a partir de uma interface de sensor de imagem, de acordo com uma modalidade adicional da presente descrição;

[00049] A Figura 43 fornece uma representação gráfica de dados de imagem (por exemplo, vídeo) e áudio correspondentes que podem ser capturados e armazenados pelo dispositivo eletrônico da Figura1;

[00050] A Figura 44 ilustra um conjunto de registros que pode ser usado para fornecer carimbos de data e hora para a sincronização dos dados de vídeo e áudio da Figura 43, de acordo com uma modalidade;

[00051] A Figura 45 é uma representação simplificada de um quadro de imagem que pode ser capturado como parte dos dados de vídeo da Figura 43 e que mostra como as informações de carimbo de data e hora podem ser armazenadas como parte dos metadados de quadro de imagem, de acordo com aspectos da presente descrição;

[00052] A Figura 46 é um fluxograma que mostra um método para uso de carimbos de data e hora com base em um sinal de VSYNC para sincronizar dados de imagem com dados de áudio, de acordo com uma modalidade;

[00053] A Figura 47 é um diagrama de bloco do conjunto de circuitos de ISP da Figura 8 que mostra como o controle de temporização flash pode ser realizado, de acordo com uma modalidade da presente descrição;

[00054] A Figura 48 mostra uma técnica para a determinação dos tempos de ativação e desativação flash, de acordo com uma modalidade da presente descrição;

[00055] A Figura 49 é um fluxograma que mostra um método para determinar os tempos de ativação de flash com base na técnica mostrada na Figura 48;

[00056] A Figura 50 é um fluxograma que mostra um método para uso de um pré-flash para atualizar estatísticas de imagem anteriormente à aquisição de uma cena de imagem com o uso de um flash, de acordo com aspectos da presente descrição;

[00057] A Figura 51 é um diagrama de bloco que fornece uma vista mais detalhada de uma modalidade da unidade de processamento de pixel de front-end de ISP, conforme mostrado na lógica de front-end de ISP da Figura 10, de acordo com aspectos da presente descrição;

[00058] A Figura 52 é um diagrama de processo que ilustra como a filtragem temporal pode ser aplicada aos dados de pixel de imagem recebidos pela unidade de processamento de pixel de front-end de ISP mostrada na Figura 51, de acordo com uma modalidade;

[00059] A Figura 53 ilustra um conjunto de pixels de imagem de referência e pixels de imagem atuais de conjunto de correspondente que podem ser usados para determinar um ou mais parâmetros para o processo de filtragem temporal mostrado na Figura 52;

[00060] A Figura 54 é um fluxograma que ilustra um processo para aplicar a filtragem temporal a um pixel de imagem atual de um conjunto de dados de imagem, de acordo com uma modalidade;

[00061] A Figura 55 é um fluxograma que mostra uma técnica para calcular um valor delta de movimento para uso com a filtragem temporal do pixel de imagem atual da Figura 54, de acordo com uma modalidade;

[00062] A Figura 56 é um fluxograma que ilustra outro processo para a aplicação de filtragem temporal a um pixel de imagem atual de um conjunto de dados de imagem que inclui o uso de ganhos diferentes para cada componente de cor dos dados de imagem, de acordo com outra modalidade;

[00063] A Figura 57 é um diagrama de processo que ilustra como uma técnica de filtragem temporal que utiliza tabelas de movimento e luma separadas para cada componente de cor dos dados de pixel recebidos de imagem pela unidade de processamento de pixel de frontend de ISP mostrada na Figura 51, de acordo com uma modalidade adicional;

[00064] A Figura 58 é um fluxograma que ilustra um processo para aplicar filtragem temporal a um pixel de imagem atual de um conjunto de dados de imagem com o uso das tabelas de movimento e luma mostradas na Figura 57, de acordo com uma modalidade adicional;

[00065] A Figura 59 mostra uma amostra de dados de imagem de resolução completa brutos que podem ser capturados por um sensor de imagem, de acordo com aspectos da presente descrição;

[00066] A Figura 60 ilustra um sensor de imagem que pode ser configurado para aplicar compartimentalização aos dados de imagem brutos de resolução completa da Figura 59 para emitir uma amostra de dados de imagem brutos compartimentalizados, de acordo com uma modalidade da presente descrição;

[00067] A Figura 61 mostra uma amostra de dados de imagem brutos compartimentalizados que podem ser fornecidos pelo sensor de imagem da Figura 60, de acordo com aspectos da presente descrição;

[00068] A Figura 62 mostra os dados de imagem brutos compartimentalizados a partir da Figura 61 após serem reamostrados por um filtro de compensação de compartimentalização a ser fornecido, de acordo com aspectos da presente descrição;

[00069] A Figura 63 mostra um filtro de compensação de compartimentalização que pode ser implantado na unidade de processamento de pixel de front-end de ISP da Figura 51, de acordo com uma modalidade;

[00070] A Figura 64 é uma representação gráfica de vários tamanhos de etapa que podem ser aplicados a um analisador diferencial para selecionar pixels de entrada de centro e índice/fases para a compartimentalização de filtro de compensação, de acordo com aspectos da presente descrição;

[00071] A Figura 65 é um fluxograma que ilustra um processo para colocar em escala dados de imagem com o uso do filtro de compensação de compartimentalização da Figura 63, de acordo com uma modalidade;

[00072] A Figura 66 é um fluxograma que ilustra um processo para determinar um pixel central de fonte de entrada atual para a filtragem horizontal e vertical pelo filtro de compensação de compartimentalização da Figura 63, de acordo com uma modalidade;

[00073] A Figura 67 é um fluxograma que ilustra um processo para determinar um índice para selecionar os coeficientes de filtragem para a filtragem horizontal e vertical pelo filtro de compensação de compartimentalização da Figura 63, de acordo com uma modalidade.

[00074] A Figura 68 é um diagrama de bloco mais detalhado que mostra uma modalidade de uma unidades de processamento de estatística que pode ser implantada na lógica de processamento de front-end de ISP, conforme mostrado na Figura 10, de acordo com aspectos da presente descrição;

[00075] A Figura 69 mostra vários casos de limite de quadro de imagem que podem ser considerados ao aplicar técnicas para detectar e corrigir pixels defectivos durante processamentos de estatística pela unidades de processamento de estatística da Figura 68, de acordo com aspectos da presente descrição;

[00076] A Figura 70 é um fluxograma que ilustra um processo para realizar a detecção e correção de pixel defectivo durante o processamento de estatísticas, de acordo com uma modalidade;

[00077] A Figura 71 mostra um perfil tridimensional que mostra a intensidade de luz versus a posição de pixel para uma lente convencional de um dispositivo de imageamento;

[00078] A Figura 72 é um desenho colorido que exibe intensidade de luz não uniforme através da imagem, que pode ser o resultado de irregularidades de sombreamento de lente;

[00079] A Figura 73 é uma ilustração gráfica de um quadro de imageamento bruto que inclui uma região de correção de sombreamento de lente e uma grade de ganho, de acordo com aspectos da presente descrição;

[00080] A Figura 74 ilustra a interpolação de um valor de ganho para um pixel de imagem abrangido por quatro ponto de ganho de grade de limítrofes, de acordo com aspectos da presente descrição;

[00081] A Figura 75 é um fluxograma que ilustra um processo para determinar valores de ganho interpolados que podem ser aplicados a pixels de imageamento durante uma operação de correção de sombreamento de lente, de acordo com uma modalidade da presente técnica;

[00082] A Figura 76 é um perfil tridimensional que mostra valores de ganho interpolados que podem ser aplicados a uma imagem que exibe as características de intensidade de luz mostradas na Figura 71 ao realizar a correção de sombreamento de lente, de acordo com aspectos da presente descrição;

[00083] A Figura 77 mostra o desenho colorido da Figura 72 que exibe uniformidade melhorada na intensidade de luz após uma operação de correção de sombreamento de lente ser aplicada, de acordo com aspectos da presente descrição;

[00084] A Figura 78 ilustra graficamente como uma distância radial entre um pixel atual e o centro de uma imagem podem ser calculados e usados para determinar um componente de ganho radial para correção de sombreamento de lente, de acordo com uma modalidade;

[00085] A Figura 79 é um fluxograma que ilustra um processo através do qual os ganhos radiais e os ganhos interpolados de uma grade de ganho são usados para determinar um ganho total que pode ser aplicado aos pixels de imageamento durante uma operação de correção de sombreamento de lente, de acordo com uma modalidade da presente técnica;

[00086] A Figura 80 é um gráfico que mostra áreas brancas e eixos de temperatura de cor alta e baixa em um espaço de cor;

[00087] A Figura 81 é uma tabela que mostra como os ganhos de equilíbrio branco podem ser configurados para várias condições iluminantes de referência, de acordo com uma modalidade;

[00088] A Figura 82 é um diagrama de bloco que mostra um mecanismo de coleta de estatísticas que pode ser implantado na lógica de processamento de front-end de ISP, de acordo com uma modalidade da presente descrição;

[00089] A Figura 83 ilustra uma amostragem descendente de dados de RGB de Bayer brutos, de acordo com aspectos da presente descrição;

[00090] A Figura 84 mostra um histograma de cor bidimensional que pode ser coletado pelo mecanismo de coleta de estatísticas da Figura 82, de acordo com uma modalidade;

[00091] A Figura 85 mostra a ampliação e panorâmica em um histograma de cor bidimensional;

[00092] A Figura 86 é uma vista mais detalhada que mostra a lógica para implantar um filtro de pixel do mecanismo de coleta de estatísticas, de acordo com uma modalidade;

[00093] A Figura 87 é uma representação gráfica de como o local de um pixel em um espaço de cor C1-C2 pode ser avaliado com base em uma condição de pixel definida para um filtro de pixel, de acordo com uma modalidade;

[00094] A Figura 88 é uma representação gráfica de como o local de um pixel em um espaço de cor de C1-C2 pode ser avaliado com base em uma condição de pixel definida para um filtro de pixel, de acordo com outra modalidade;

[00095] A Figura 89 é uma representação gráfica de como o local de um pixel em um espaço de cor de C1-C2 pode ser avaliado com base em uma condição de pixel definida para um filtro de pixel, de acordo com ainda outra modalidade;

[00096] A Figura 90 é um gráfico que mostra como os tempos de integração de sensor de imagem podem ser determinados para compensarem por tremores, de acordo com uma modalidade;

[00097] A Figura 91 é um diagrama de bloco detalhado que mostra a lógica que pode ser implantada no mecanismo de coleta de estatísticas da Figura 82 e configurada para coletar as estatísticas de autofoco, de acordo com uma modalidade;

[00098] A Figura 92 é um gráfico que mostra uma técnica para realizar o autofoco com o uso de valores de classificação de autofoco fino e grosso, de acordo com uma modalidade;

[00099] A Figura 93 é um fluxograma que mostra um processo para realizar o autofoco om o uso de valores de classificação de autofoco grosso e fino, de acordo com uma modalidade;

[000100] As Figuras 94 e 95 mostram a decimação de dados de Bayer brutos para obter um valor de luma de equilíbrio de branco;

[000101] A Figura 96 mostra uma técnica para realizar o autofoco com o uso de valores de classificação de autofoco relativos para cada componente de cor, de acordo com uma modalidade;

[000102] A Figura 97 é uma vista mais detalhada da unidades de processamento de estatística da Figura 68, que mostra como os dados de histograma de RGB de Bayer podem ser usados para auxiliar a compensação de nível de preto, de acordo com uma modalidade;

[000103] A Figura 98 é um diagrama de bloco que mostra uma modalidade da lógica de processamento de pipe de ISP da Figura 7, de acordo com aspectos da presente descrição;

[000104] A Figura 99 é uma vista mais detalhada que mostra uma modalidade de um bloco de processamento de pixel bruto que pode ser implantado na lógica de processamento de pipe de ISP da Figura 98, de acordo com aspectos da presente descrição;

[000105] A Figura 100 mostra vários casos de limite de quadro de imagem que podem ser considerados ao aplicar técnicas para detectar e corrigir pixels defectivos durante o processamento pelo bloco de processamento de pixel bruto mostrado na Figura 99, de acordo com aspectos da presente descrição;

[000106] As Figuras 101 a 103 são fluxogramas que mostram vários processos para detectar e corrigir pixels defectivos que podem ser realizados no bloco de processamento de pixel bruto da Figura 99, de acordo com uma modalidade;

[000107] A Figura 104 mostra o local de dois pixels verdes em um bloco de pixel 2x2 de um sensor de imagem Bayer que pode ser interpolado ao aplicar técnicas de correção de não uniformidade verde durante processamento pela lógica de processamento de pixel bruto da Figura 99, de acordo com aspectos da presente descrição;

[000108] A Figura 105 ilustra um conjunto de pixels que inclui um pixel central e pixels vizinhos horizontais associados que podem ser usados como parte de um processo de filtragem horizontal para a redução de ruído, de acordo com aspectos da presente descrição;

[000109] A Figura 106 ilustra um conjunto de pixels que inclui um pixel central e pixels vizinhos verticais associados que podem ser usados como parte de um processo de filtro vertical para a redução de ruído, de acordo com aspectos da presente descrição;

[000110] A Figura 107 é um fluxograma simplificado que mostra como a interpolação pode ser aplicada a um padrão de imagem de Bayer bruto para produzir uma imagem de em RGB de cor completa;

[000111] A Figura 108 mostra um conjunto de pixels de um padrão de imagem de Bayer a partir do qual os componentes de energia horizontal e vertical podem ser derivados para interpolar os valores de cor verde durante a interpolação do padrão de imagem de Bayer, de acordo com uma modalidade;

[000112] A Figura 109 mostra um conjunto de pixels horizontais aos qual a filtragem pode ser aplicada para determinar um componente horizontal de um valor de cor verde interpolado durante a interpolação de um padrão de imagem de Bayer, de acordo com aspectos da presente técnica;

[000113] A Figura 110 mostra um conjunto de pixels verticais aos quais a filtragem pode ser aplicada para determinar um componente vertical de um valor de cor verde interpolado durante interpolação de um padrão de imagem de Bayer, de acordo com aspectos da presente técnica;

[000114] A Figura 111 mostra vários blocos de pixel 3x3 aos quais a filtragem pode ser aplicada para determinar valores de vermelho e azul interpolados durante a interpolação de um padrão de imagem Bayer, de acordo com aspectos da presente técnica;

[000115] As Figuras 112 a 115 fornecem fluxogramas que mostram vários processos para interpolar valores de cor verde, vermelho e azul durante interpolação de um padrão de imagem de Bayer, de acordo com uma modalidade;

[000116] A Figura 116 mostra um desenho colorido de uma cena de imagem original que pode ser capturada por um sensor de imagem e processada de acordo com aspectos de técnicas de interpolação apresentadas no presente documento;

[000117] A Figura 117 mostra um desenho colorido de padrão de imagem de Bayer da cena de imagem mostrada na Figura 116;

[000118] A Figura 118 mostra um desenho colorido de uma imagem de RGB reconstruída com o uso de uma técnica de interpolação convencional com base no padrão de imagem de Bayer da Figura 117;

[000119] A Figura 119 mostra um desenho colorido de uma imagem de RGB reconstruída a partir do padrão de imagem de Bayer da Figura 117 de acordo com aspectos das técnicas de interpolação apresentadas no presente documento;

[000120] As Figuras 120 a 123 mostram uma configuração e disposição de armazenamento temporário em linha que pode ser usada na implantação do bloco de processamento de pixel bruto da Figura 99, de acordo com uma modalidade;

[000121] A Figura 124 é um fluxograma que mostra um método para o processamento de dados de pixel bruto com o uso da configuração de armazenamento temporário em linha mostrada nas Figuras 120 a 123, de acordo com uma modalidade;

[000122] A Figura 125 é uma vista mais detalhada que mostra uma modalidade de um bloco de processamento em RGB que pode ser implantada na lógica de processamento de pipe de ISP da Figura 98, de acordo com aspectos da presente descrição;

[000123] A Figura 126 é uma vista mais detalhada que mostra uma modalidade de um bloco de processamento de YCbCr que pode ser implantado na lógica de processamento de pipe de ISP da Figura 98, de acordo com aspectos da presente descrição;

[000124] A Figura 127 é uma representação gráfica de regiões de fonte ativa para luma e croma, conforme definido em um armazenamento temporário de fonte com o uso de um formato 1-plano, de acordo com aspectos da presente descrição;

[000125] A Figura 128 é uma representação gráfica de regiões de fonte ativa para luma e croma, conforme definido em um armazenamento temporário de fonte com o uso de um formato de 2- plano, de acordo com aspectos da presente descrição;

[000126] A Figura 129 é um diagrama de bloco que ilustra o ajuste de imagem de lógica de nitidez que pode ser implantada no bloco de processamento de YCbCr, conforme mostrado na Figura 126, de acordo com uma modalidade;

[000127] A Figura 130 é um diagrama de bloco que ilustra a lógica de acentuação de borda que pode ser implantada no bloco de processamento de YCbCr, conforme mostrado na Figura 126, de acordo com uma modalidade;

[000128] A Figura 131 é um gráfico que mostra a relação de fatores de atenuação de croma para ajustar valores de luma nítidos, de acordo com aspectos da presente descrição;

[000129] A Figura 132 é um diagrama de bloco que ilustra a lógica de ajuste de claridade, contraste e cor de imagem (BCC) que pode ser implantada no bloco de processamento de YCbCr, conforme mostrado na Figura 126, de acordo com uma modalidade;

[000130] A Figura 133 mostram um roda de tom e saturação no espaço de cor de YCbCr que define vários ângulos e tom e valores de saturação que podem ser aplicados durante o ajuste de cor na lógica de ajuste de BCC mostrada na Figura 132;

[000131] A Figura 134 é um diagrama de bloco que mostra uma modalidade da lógica de processamento de back-end de ISP da Figura 8 que pode ser configurada para realizar várias etapas de pós- processamento a jusante da pipeline de ISP, de acordo com aspectos da presente descrição;

[000132] A Figura 135 é uma ilustração gráfica que mostra uma técnica de mapeamento de tom global convencional;

[000133] A Figura 136 é uma ilustração gráfica que mostra outra técnica de mapeamento de tom global convencional;

[000134] A Figura 137 mostra como as regiões de uma imagem podem ser segmentadas para a aplicação de técnicas de aplicação de tom local, de acordo com aspectos da presente descrição;

[000135] A Figura 138 ilustra graficamente como o mapeamento de tom local convencional pode resultar na utilização limitada de uma faixa de tom de saída;

[000136] A Figura 139 ilustra graficamente uma técnica para o mapeamento de tom local, de acordo com modalidades da presente descrição;

[000137] A Figura 140 é um diagrama de bloco mais detalhado que mostra uma modalidade de lógica de mapeamento de tom local LTM que pode ser configurada para implantar processos de mapeamento de tom na lógica de back0end de ISP da Figura 134, de acordo com aspectos da presente descrição;

[000138] A Figura 141 é um fluxograma que mostra um método para o processamento dados de imagem com o uso de lógica de processamento de back-end de ISP da Figura 134, de acordo com uma modalidade; e

[000139] A Figura 142 é um fluxograma que mostra um método para aplicar o mapeamento de tom com o uso da lógica de LTM mostrada na Figura 140, de acordo com uma modalidade.

DESCRIÇÃO DETALHADA DE MODALIDADES ESPECÍFICAS

[000140] Uma ou mais modalidades específicas da presente descrição serão descritas abaixo. Essas modalidades descritas são apenas exemplos das técnicas aqui apresentadas. Adicionalmente, em um esforço para fornecer uma descrição concisa dessas modalidades, todas as características de uma implantação real podem não ser descritas no relatório descritivo. Deve-se constatar que no desenvolvimento de qualquer tal implantação, como em qualquer projeto de engenharia ou design, várias decisões específicas de implantação podem ser realizadas para alcançar os objetivos específicos dos criadores, como conformidade com restrições relacionadas ao sistema e a empresas, que podem variar de uma implantação para a outra. Ademais, deve-se apreciar que tal esforço de desenvolvimento pode ser complexo e dispendioso, mas seria, ainda assim, uma obrigação de rotina de design, fabricação e fabricação para aqueles de habilidade comum na técnica que têm o benefício dessa descrição.

[000141] Ao introduzir elementos de várias modalidades da presente descrição, os artigos "um", "uma", e "o", "a" são destinados a significarem que há um ou mais dos elementos. Os termos "que compreende", "que inclui" e "que tem"são destinados a serem inclusivos e significam que pode haver elementos adicionais diferentes dos elementos listados. Adicionalmente, deve-se compreender que as referências a "uma (1) modalidade" ou "uma modalidade" da presente descrição não são destinadas a serem interpretadas como excludentes da existência de modalidades adicionais que também incorporam as características citadas.

[000142] Conforme será discutido abaixo, a presente descrição refere- se, em geral, a técnicas para o processamento dados de imagem adquirido através de um ou mais dispositivos de captação de imagem. Em particular, certos aspectos da presente descrição pode se referir a técnicas para detectar e corrigir pixels defectivos, técnicas para a interpolação de um padrão de imagem bruto, técnicas para ajustar uma nitidez de uma imagem de luminância com o uso de uma máscara não precisa de múltipla escala e técnicas para aplicar ganhos de sombreamento de lente para corrigir irregularidades de sombreamento de lentes. Ademais, deve-se compreender que as técnicas aqui descritas podem ser aplicadas a ambas imagens em movimento (por exemplo, vídeo) e imagens paradas e podem ser utilizadas em qualquer tipo adequado de aplicação de imageamento, como uma câmera digital, um dispositivo eletrônico que tem uma câmera digital integrada, um sistema de vigilância ou segurança de vídeo, um sistema de imageamento médico e assim por diante.

[000143] Com o ponto acima em mente, a Figura 1 é um diagrama de bloco que ilustra um exemplo de um dispositivo eletrônico 10 que pode fornecer o processamento de dados de imagem com o uso de uma ou mais técnicas de processamento de imagem brevemente mencionadas acima. O dispositivo eletrônico 10 pode ser qualquer tipo de dispositivo eletrônico, como um computador do tipo laptop ou de mesa, um telefone móvel, um tocador de mídia digital ou similares, que esteja configurado para receber e processar dados de imagem, como dados adquiridos como uso de um ou mais componentes de captação de imagem. A título de exemplo apenas, o dispositivo eletrônico 10 pode ser um dispositivo eletrônico portátil, como um modelo de um iPod® ou iPhone®, disponível junto à Apple Inc. de Cupertino, California. Adicionalmente, o dispositivo eletrônico 10 pode ser um computador de mesa ou do tipo laptop, como um modelo de um MacBook®, MacBook® Pro, MacBook Air®, iMac®, Mac® Mini, ou Mac Pro®, disponíveis junto à Apple Inc. Em outras modalidades, o dispositivo eletrônico 10 também pode ser um modelo de um dispositivo eletrônico de outro fabricante que seja capaz de obter e processar dados de imagem.

[000144] Independentemente de sua forma (por exemplo, portátil ou não), deve-se compreender que o dispositivo eletrônico 10 pode fornecer o processamento de dados de imagem com o uso de uma ou mais técnicas de processamento de imagem brevemente discutidas acima, que podem incluir técnicas de correção e/ou detecção de pixel defectivo, técnicas de correção de sombreamento de lente, técnicas de interpolação ou técnicas de ajuste de nitidez de imagem, dentre outras. Em algumas modalidades, o dispositivo eletrônico 10 pode aplicar tais técnicas de processamento de imagem aos dados de imagem armazenados em uma memória do dispositivo eletrônico 10. Em modalidades adicionais, o dispositivo eletrônico 10 pode incluir um ou mais dispositivos de imageamento, como uma câmera digital integrada ou interna, configurada para adquirir dados de imagem, que podem, então, ser processados pelo dispositivo eletrônico 10 como uso de uma ou mais das técnicas de processamento de imagem mencionadas acima. As modalidades que mostram tanto modalidades portáteis quanto não portáteis do dispositivo eletrônico 10 serão adicionalmente discutidas abaixo nas Figuras 3 a 6.

[000145] Conforme mostrado na Figura 1, o dispositivo eletrônico 10 pode incluir vários componentes internos e/ou externos que contribuem com a função do dispositivo 10. Aqueles indivíduos de habilidade comum na técnica constatarão que vários blocos funcionais mostrados na Figura 1 podem compreender elementos de hardware (incluindo conjuntos de circuitos), elementos de software (incluindo código de computador armazenado em um meio legível por computador) ou uma combinação de elementos tanto de hardware quanto de software. Por exemplo, na modalidade aqui ilustrada, o dispositivo eletrônico 10 pode incluir portas de entrada/saída (I/O) 12, estruturas de entrada 14, um ou mais processadores 16, dispositivo de memória 18, armazenamento não volátil 20, cartão(ões) de expansão 22, dispositivo de rede 24, fonte de alimentação 26 e visor 28. Adicionalmente, o dispositivo eletrônico 10 pode incluir um ou mais dispositivos de imageamento 30, como uma câmera digital e conjunto de circuitos de processamento de imagem 32. Conforme será adicionalmente discutido abaixo, o conjunto de circuitos de processamento de imagem 32 pode ser configurado para implantar uma ou mais das técnicas de processamento de imagem discutidas acima ao processar dados de imagem. Conforme pode ser constatado, dados de imagem processados por um conjunto de circuitos de processamento de imagem 32 podem ser recuperados da memória 18 e/ou do(s) dispositivo(s) de armazenamento não volátil 20, ou podem ser adquiridos com o uso do dispositivo de imageamento 30.

[000146] Antes de continuar, deve-se compreender que o diagrama de bloco do sistema do dispositivo 10 mostrado na Figura 1 é destinado a ser um diagrama de controle de alto nível que mostra vários componentes que podem ser incluídos em tal dispositivo 10. Ou seja, as linhas de conexão entre cada componente individual mostrado na Figura 1 podem não necessariamente representar trajetos ou direções através dos quais os dados fluem ou são transmitidos entre vários componentes do dispositivo 10. De fato, conforme discutido abaixo, o(s) processador(es) mostrado(s) 16 pode, em algumas modalidades, incluir processadores múltiplos, como um processador principal (por exemplo, CPU), e processadores de imagem e/ou vídeo dedicados. Em tais modalidades, o processamento de dados de imagem pode ser primariamente manejado por esses processadores dedicados, descarregando com eficácia, portanto, tais tarefas de um processador principal (CPU).

[000147] Em relação a cada um dos componentes ilustrados na Figura 1, as portas de I/O 12 podem incluir portas configuradas para se conectarem a uma variedade de dispositivos externos, como uma fonte de alimentação, um dispositivo de emissão de áudio (por exemplo, acessórios de cabeça ou fones de ouvido), ou outros dispositivos eletrônicos (como dispositivos portáteis e/ou computadores, impressoras, projetores, visores externos modems, estações de encaixe e assim por diante). Em uma modalidade, as portas de I/O 12 podem ser configuradas para se conectarem a um dispositivo de imageamento externo, como uma câmera digital, para a aquisição de dados de imagem que podem ser processados com o uso do conjunto de circuitos de processamento de imagem 32. As portas de I/O 12 podem suportar qualquer tipo de interface adequado, como uma porta de barramento em série universal (USB), uma porta de conexão em série, uma porta IEEE-1394 (FireWire), uma porta de Ethernet ou modem, e/ou uma porta de conexão de potência CA/CC.

[000148] Em algumas modalidades, certas portas de I/O 12 podem ser configuradas para mais que uma função. Por exemplo, em uma modalidade, as portas de I/O 12 podem incluir uma porta proprietária da Apple Inc. que pode funcionar não só para facilitar a transferência de dados entre o dispositivo eletrônico 10 e uma fonte externa, mas também para acoplar o dispositivo 10 a uma interface de carregamento de potência, como um adaptador de potência projetado para fornecer potência a partir de uma saída de parede elétrica ou um cabo de interface configurado para extrair potência de outro dispositivo elétrico, como um computador de mesa ou do tipo laptop, para carregar a fonte de alimentação 26 (que pode incluir uma ou mais baterias recarregáveis). Portanto, a porta de I/O 12 pode ser configurada para funcionar de modo duplo, como ambas uma porta de transferência de dados e uma porta de conexão de potência CA/CC, dependendo, por exemplo, do componente externo que é acoplado ao dispositivo 10 através da porta de I/O 12.

[000149] As estruturas de entrada 14 podem fornecer entrada ou retroalimentação de usuário ao(s) processador(es) 16. Por exemplo, as estruturas de entrada 14 podem ser configuradas para controlar uma ou mais funções do dispositivo eletrônico 10, como aplicações que são executadas no dispositivo eletrônico 10. A título de exemplo, apenas, as estruturas de entrada 14 podem incluir botões, controles deslizantes, comutadores, teclado de controle, teclas, maçanetas, rodas de rolagem, teclados, mouses, touchpads e assim por diante ou alguma combinação dos mesmos. Em uma modalidade, as estruturas de entrada 14 podem permitir que um usuário navegue uma interface de usuário gráfica (GUI) exibida no dispositivo 10. Adicionalmente, as estruturas de entrada 14 podem incluir um mecanismo sensível ao toque fornecido em conjunto com o visor 28. Em tais modalidades, um usuário pode selecionar ou interagir com elementos de interface exibidos através do mecanismo sensível ao toque.

[000150] As estruturas de entrada 14 podem incluir os vários dispositivos, conjunto de circuitos e trajetos através dos quais a entrada ou retroalimentação de usuário é fornecida a um ou mais processadores 16. Tais estruturas de entrada 14 podem ser configuradas para controlar uma função do dispositivo 10, as aplicações que são executadas no dispositivo 10, e/ou quaisquer interfaces ou dispositivos conectados a ou usados pelo dispositivo eletrônico 10. Por exemplo, as estruturas de entrada 14 podem permitir que um usuário navegue por uma interface de usuário ou interface de aplicação exibida. Exemplos das estruturas de entrada 14 podem incluir botões, controles deslizantes, comutadores, teclados de controle, teclas, maçanetas, rodas de rolagem, teclados, mouses, touchpads e assim por diante.

[000151] Em certas modalidades, uma estrutura de entrada 14 e o dispositivo de exibição 28 podem ser fornecidos juntos, como no caso de uma "tela sensível ao toque"através da qual um mecanismo sensível ao toque é fornecido em conjunto com o visor 28. Em tais modalidades, o usuário pode selecionar ou interagir com os elementos de interface exibidos através do mecanismo sensível ao toque. Dessa forma, a interface exibida pode fornecer funcionalidade interativa, permitindo que um usuário navegue pela interface exibida ao tocar o visor 28. Por exemplo, a interação de usuário com as estruturas de entrada 14, de modo a interagir com um usuário ou interface de aplicação exibida no visor 26, pode gerar sinais elétricos indicativos da entrada de usuário. Esses sinais de entrada podem ser roteados através de trajetórias adequadas, como um hub de entrada ou barramento de dados, ao um ou mais processadores 16 para processamento adicional.

[000152] Em uma modalidade, as estruturas de entrada 14 podem incluir um dispositivo de entrada de áudio. Por exemplo, um ou mais dispositivos de captura de áudio, como um ou mais microfones, podem ser fornecidos com o dispositivo eletrônico 10. Os dispositivos de captura de áudio podem ser integrados ao dispositivo eletrônico 10 ou podem ser um dispositivo externo acoplado ao dispositivo eletrônico 10, como por meio das portas de I/O 12. Conforme discutido adicionalmente abaixo, o dispositivo eletrônico 10 pode ser ambos um dispositivo de entrada de áudio e um dispositivo de imageamento 30 para capturar dados de som e de imagem (por exemplo, dados de vídeo), e pode incluir lógica configurada para fornecer a sincronização dos dados de vídeo e áudio capturados.

[000153] Além do processamento de vários sinais de entrada recebidos através da estrutura de entrada(s) 14, o(s) processador(es) 16 pode controlar a operação geral do dispositivo 10. Por exemplo, o(s) processador(es) 16 pode fornecer a capacidade de processamento para executar um sistema operacional, programas, interfaces de usuário e de aplicação e quaisquer outras funções do dispositivo eletrônico 10. O(s) processador(es) 16 pode incluir um ou mais microprocessadores, como um ou mais microprocessadores de "propósito geral", um ou mais microprocessadores de propósito especial e/ou microprocessadores de aplicação específica (ASICs) ou uma combinação de tais componentes de processamento. Por exemplo, o(s) processador(es) 16 podem incluir um ou mais processadores de conjunto de instruções (por exemplo, RISC), assim como processadores de gráfico (GPU), processadores de vídeo, processadores de áudio e/ou conjuntos de chip relacionados. Conforme será descrito, o(s) processador(es) 16 podem ser acoplados a um ou mais barramentos de dados para transferir dados e instruções entre vários componentes do dispositivo 10. Em certas modalidades, o(s) processador(es) 16 podem fornecer a capacidade de processamento para executar aplicações de imageamento no dispositivo eletrônico 10, como Photo Booth®, Aperture®, iPhoto® ou Preview®, disponível junto à Apple Inc., ou as aplicações "Câmera"e/ou "Photo" fornecidas pela Apple Inc. e disponíveis em modelos do iPhone®.

[000154] As instruções ou dados a serem processados pelo(s) processador(es) 16 podem ser armazenados em um meio legível por computador, como um dispositivo de memória 18. O dispositivo de memória 18 pode ser fornecido como uma memória volátil, como memória de acesso aleatório (RAM) ou como uma memória não volátil, como memória de apenas leitura (ROM) ou como uma combinação de um ou mais dispositivos RAM e ROM. A memória 18 pode armazenar uma variedade de informações e pode ser usada para vários fins. Por exemplo, a memória 18 pode armazenar firmware para o dispositivo eletrônico 10, como um sistema de entrada/saída básico (BIOS), um sistema operacional, vários programas, aplicações ou quaisquer outras rotinas que possam ser executadas no dispositivo eletrônico 10, incluindo funções de interface de usuário, funções de processador e assim por diante. Ademais, a memória 18 pode ser usada para armazenar temporariamente ou armazenar em cache durante a operação do dispositivo eletrônico 10. Por exemplo, em uma modalidade, a memória 18 inclui um ou mais armazenamentos temporários de quadro para armazenar temporariamente dados de vídeo conforme estão sendo emitidos para o visor 28.

[000155] Além do dispositivo de memória 18, o dispositivo eletrônico 10 pode incluir, ainda, um armazenamento não volátil 20 para armazenamento persistente de dados e/ou instruções. O armazenamento não volátil 20 pode incluir memória flash, uma unidade rígida, ou qualquer outro meio de armazenamento óptico, magnético e/ou de estado sólido ou alguma combinação dos mesmos. Portanto, embora mostrado como um dispositivo único na Figura 1 para fins de esclarecimento, deve-se compreender que o(s) dispositivo(s) de armazenamento não volátil 20 pode incluir uma combinação de um ou mais dos dispositivos de armazenamento listados acima que operam em conjunto com o(s) processador(es) 16. O armazenamento não volátil 20 pode ser usado para armazenar firmware, arquivos de dados, dados de imagem, programas e aplicações de software, informações de conexão sem fio, informações pessoais, preferências de usuário e quais outros dados adequados. De acordo com aspectos da presente descrição, os dados de imagem armazenados no armazenamento não volátil 20 e/ou no dispositivo de memória 18 podem ser processados pelo conjunto de circuitos de processamento de imagem 32 anteriormente a serem emitidos em um visor.

[000156] A modalidade ilustrada na Figura 1 também pode incluir uma ou mais fendas de cartão ou expansão. As fendas de cartão podem ser configuradas para receber um cartão de expansão 22 que pode ser usado para acrescentar funcionalidade, como memória adicional, funcionalidade de I/O, ou capacidade de formação de rede, ao dispositivo eletrônico 10. Tal cartão de expansão 22 pode se conectar ao dispositivo através de qualquer tipo de conector adequado e pode ser acessado interna ou externamente em relação a um alojamento do dispositivo eletrônico 10. Por exemplo, em uma modalidade, o cartão de expansão 24 pode ser um cartão de memória flash, como um cartão SecureDigital (SD), um cartão mini ou microSD, um cartão CompactFlash ou similares ou pode ser um dispositivo de PCMCIA. Adicionalmente, o cartão de expansão 24 pode ser um cartão de módulo de identidade do assinante (SIM), para uso com uma modalidade do dispositivo eletrônico 10 que fornece capacidade de telefone móvel.

[000157] O dispositivo eletrônico 10 também inclui o dispositivo de rede 24, que pode ser um controlador de rede ou um cartão de interface de rede (NIC) que pode fornecer conectividade de rede através de um padrão de formação de rede sem fio padrão 802.11 ou qualquer outro adequado, como uma rede de área local (LAN), uma rede de área ampla (WAN), como Taxas de Dados Acentuadas para Evolução de GSM (EDGE), uma rede de dados 3G ou a Internet. Em certas modalidades, o dispositivo de rede 24 pode fornecer uma conexão a um provedor de conteúdo de mídia digital online, como o sérvio de música iTunes®, disponível junto à Apple Inc.

[000158] A fonte de alimentação 26 do dispositivo 10 pode incluir a capacidade de fornecer potência ao dispositivo 10 em ambas as configurações portátil e não portátil. Por exemplo, em uma configuração portátil, o dispositivo 10 pode incluir uma ou mais baterias, como uma bateria Li-Ion, para energizar o dispositivo 10. A bateria pode ser recarregada ao conectar o dispositivo 10 a uma fonte de alimentação externa, como a uma saída de parede elétrica. Em uma configuração não portátil, a fonte de alimentação 26 pode incluir uma unidade de fonte de alimentação (PSU) configurada para extrair potência de uma saída de parede elétrica, e para distribuir a potência a vários componentes de um dispositivo eletrônico não portátil, como um sistema de computação de mesa.

[000159] O visor 28 pode ser usado para exibir várias imagens geradas pelo dispositivo 10, como uma GUI para um sistema operacional, ou dados de imagem (incluindo dados de imagens paradas e de vídeo) processados pelo conjunto de circuitos de processamento de imagem 32, conforme será adicionalmente discutido abaixo. Conforme mencionado acima, os dados de imagem podem incluir dados de imagem adquiridos com o uso do dispositivo de imageamento 30 ou dados de imagem extraídos da memória 18 e/ou armazenamento não volátil 20. O visor 28 pode ser qualquer tipo adequado de visor, como visor de cristal líquido (LCD), visor de plasma ou um visor de diodo de emissão de luz orgânico (OLED), por exemplo. Adicionalmente, conforme discutido acima, o visor 28 pode ser fornecido em conjunto com o mecanismo sensível ao toque discutido acima (por exemplo, uma tela sensível ao toque) que pode funcionar como parte de uma interface de controle para o dispositivo eletrônico 10.

[000160] O(s) dispositivo(s) de imageamento ilustrado(s) 30 pode ser fornecido como uma câmera digital configurada para adquirir ambas imagens paradas e imagens em movimento (por exemplo, vídeo). A câmera 30 pode incluir uma lente e um ou mais sensores de imagem configurados para capturar e converter luz em sinais elétricos. A título de exemplo, apenas, o sensor de imagem pode incluir um sensor de imagem de CMOS (por exemplo, um sensor de pixel ativo CMOS (APS)) ou um sensor de CCD (dispositivo acoplado a carga). Em geral, o sensor de imagem na câmera 30 inclui um circuito integrado que tem um arranjo de pixels, em que cada pixel inclui um fotodetector para captar luz. Conforme aqueles versados na técnica constatarão, os fotodetectores nos pixels de imageamento detectam, em geral, a intensidade de luz capturada através das lentes da câmera. Entretanto, fotodetectores, por si só, são, em geral, incapazes de detectar o comprimento de onda da luz capturada e, portanto, são incapazes de determinar informações de cor.

[000161] Em conformidade, o sensor de imagem pode incluir, ainda, uma matriz de filtro de cor (CFA) que pode se sobrepor ou ser disposta através do arranjo de pixel do sensor de imagem para capturar informações de cor. A matriz de filtro de cor pode incluir um arranjo de pequenos filtros de cor, sendo que cada um dos quais pode se sobrepor a um respectivo pixel do sensor de imagem e filtrar a luz capturada por comprimento de onda. Portanto, quando usados em conjunto, a matriz de filtro de cor e os fotodetectores podem fornecer ambas as informações de comprimento de onda quanto de intensidade em relação à luz capturada através da câmera, que pode ser representativa de uma imagem capturada.

[000162] Em uma modalidade, a matriz de filtro de cor pode incluir uma matriz de filtro de cor Bayer, que fornece um padrão de filtro que é 50% de elementos verdes, 25% de elementos vermelhos e 25% de elementos azuis. Por exemplo, a Figura 2 mostra que um bloco de pixel 2x2 de um Bayer CFA inclui 2 elementos verdes (Gr e Gb), 1 elemento vermelho (R) e 1 elemento azul (B). Portanto, um sensor de imagem que utiliza uma matriz de filtro de cor Bayer pode fornecer informações relativas à intensidade da luz recebida pela câmera 30 nos comprimentos de onda de verde, vermelho e azul, em que cada pixel de imagem registra apenas uma das três cores (RGB). Essas informações, que podem ser referidas como "dados de imagem brutos" ou dados no "domínio bruto" podem, então, ser processadas com o uso de uma ou mais técnicas de interpolação para converter os dados de imagem brutos em uma imagem de cor completa, em geral, ao interpolar um conjunto de valores de vermelho, verde e azul para cada pixel. Conforme será adicionalmente discutido abaixo, tais técnicas de interpolação podem ser realizadas pelo conjunto de circuitos de processamento de imagem 32.

[000163] Conforme mencionado acima, o conjunto de circuitos de processamento de imagem 32 pode fornecer várias etapas de processamento de imagem, como detecção/correção de pixel defectivo, correção de sombreamento de lente, interpolação e ajuste de nitidez de imagem, redução de ruído, correção gama, acentuação de imagem, conversão de cor-espaço, compressão de imagem, subamostragem croma e operações de escalonamento de imagem e assim por diante. Em algumas modalidades, o conjunto de circuitos de processamento de imagem 32 pode incluir vários subcomponentes e/ou unidades distintas de lógica que formam, coletivamente, uma "pipeline" de processamento de imagem para realizar cada uma das várias etapas de processamento de imagem. Esses subcomponentes podem ser implantados com o uso de hardware (por exemplo, processadores de sinal digital ou ASICs) ou software, ou através de uma combinação de componentes de hardware e software. As várias operações de processamento de imagem que podem ser fornecidas pelo conjunto de circuitos de processamento de imagem 32 e, particularmente, aquelas operações de processamento relativas à detecção/correção de pixel defectivo, correção de sombreamento de lente, interpolação e ajuste de nitidez de imagem serão discutidas com maiores detalhes abaixo.

[000164] Antes de continuar, deve-se notar que, embora várias modalidades das várias técnicas de processamento de imagem discutidas abaixo possam utilizar Bayer CFA, as técnicas aqui apresentadas não são destinadas a serem limitadas por esses aspecto. Na verdade, aqueles versados na técnica constatarão que as técnicas de processamento de imagem fornecidas no presente documento podem ser aplicáveis a qualquer tipo adequado de matriz de filtro de cor, incluindo filtros RGBW, filtros CYGM e assim por diante.

[000165] Com referência, novamente, ao dispositivo eletrônico 10, as Figuras 3 a 6 ilustram várias formas que o dispositivo eletrônico 10 pode assumir. Conforme mencionado acima, o dispositivo eletrônico 10 pode assumir a forma de um computador, incluindo computadores que são, em geral, portáteis (como computadores do tipo laptop, notebook e tablets), assim como computadores que são, em geral, não portáteis (como computadores de mesa, estações de trabalho e/ou servidores) ou outro tipo de dispositivo eletrônico, como dispositivo eletrônico portátil de mãos (por exemplo, tocador de mídia digital ou telefone móvel). Em particular, as Figuras 3 e 4 mostram o dispositivo eletrônico 10 na forma de um computador do tipo laptop 40 e um computador de mesa 50, respectivamente. As Figuras 5 e 6 mostram a vista frontal e posterior, respectivamente, do dispositivo eletrônico 10 na forma de um dispositivo portátil de mão 60.

[000166] Conforme mostrado na Figura 3, o computador do tipo laptop 40 mostrado inclui um alojamento 42, o visor 28, as portas de I/O 12 e as estruturas de entrada 14. As estruturas de entrada 14 podem incluir um teclado e um mouse do tipo touchpad que são integrados ao alojamento 42. Adicionalmente, a estrutura de entrada 14 pode incluir vários outros botões e/ou comutadores que podem ser usados para interagir com o computador 40, como para ativar ou inicializar o computador, para operar um GUI ou uma aplicação que está sendo executada no computador 40, assim como ajustar vários outros aspectos referentes à operação do computador 40 (por exemplo, volume de som, claridade de visor, etc.). O computador 40 também pode incluir várias portas de I/O 12 que fornecem conectividade a dispositivos adicionais, conforme discutido acima, como uma porta FireWire® ou USB, uma porta de interface de multimídia de alta definição (HDMI), ou qualquer outro tipo de porta que seja adequado para conectar a um dispositivo externo. Adicionalmente, o computador 40 pode incluir conectividade de rede (por exemplo, dispositivo de rede 26), memória (por exemplo, memória 20) e capacidades de armazenamento (por exemplo, dispositivo de armazenamento 22), conforme descrito acima com relação à Figura 1.

[000167] Ademais, o computador do tipo laptop 40, na modalidade ilustrada, pode incluir um dispositivo de imageamento integrado 30 (por exemplo, câmera). Em outras modalidades, o computador do tipo laptop 40 pode utilizar uma câmera externa (por exemplo, uma câmera de USB externa ou uma "webcam") conectada a uma ou mais dentre as portas de I/O 12 em vez de ou em adição à câmera integrada 30. Por exemplo, uma câmera externa pode ser uma câmera iSight® disponível junto à Apple Inc. a câmera 30, seja integrada ou externa, pode fornecer a captura e registro das imagens. Tais imagens podem, então, ser visualizadas por um usuário com o uso de uma aplicação de visualização de imagem, ou podem ser utilizadas por outras aplicações, incluindo aplicações de conferência de vídeo, como iChat®, e aplicações de edição/visualização de imagem, como Photo Booth®, Aperture®, iPhoto® ou Preview®, que estão disponíveis junto à Apple Inc. Em certas modalidades, o computador do tipo laptop 40 retratado pode ser um modelo dentre MacBook®, MacBook® Pro, MacBook Air® ou PowerBook® disponível junto à Apple Inc. Adicionalmente, o computador 40, em uma modalidade, pode ser um dispositivo de computação de tablete portátil, como um modelo de um computador do tipo tablet iPad®, também disponível junto à Apple Inc.

[000168] A Figura 4 ilustra, ainda, uma modalidade na qual o dispositivo eletrônico 10 é fornecido como um computador de mesa 50. Conforme será constatado, o computador de mesa 50 pode incluir várias características que podem ser, em geral, similares àquelas fornecidas pelo computador do tipo laptop 40 mostrado na Figura 4, mas podem ter, em geral, fator de forma maior. Conforme mostrado, o computador de mesa 50 pode ser alojado em uma invólucro 42 que inclui o visor 28, assim como vários outros componentes discutidos acima em relação ao diagrama de bloco mostrado na Figura 1. Ademais, o computador de mesa 50 pode incluir um teclado e mouse externos (estruturas de entrada 14) que podem ser acoplados ao computador 50 através de uma ou mais portas de I/O 12 (por exemplo, USB) ou podem se comunicar com o computador 50 de modo sem fio (por exemplo, RF, Bluetooth, etc.). o computador de mesa 50 também inclui um dispositivo de imageamento 30, que pode ser uma câmera integrada ou externa, conforme discutido acima. Em certas modalidades, o computador de mesa 50 retratado pode ser um modelo de um iMac®, Mac® mini ou Mac Pro®, disponível junto à Apple Inc.

[000169] Conforme adicionalmente mostrado, o visor 28 pode ser configurado para gerar várias imagens que podem ser visualizadas por um usuário. Por exemplo, durante a operação do computador 50, o visor 28 pode exibir uma interface de usuário gráfica ("GUI") 52 que permite que o usuário interaja com um sistema operacional e/ou aplicação sendo executada no computador 50. A GUI 52 pode incluir várias camadas, janelas, telas, templates ou outros elementos gráficos que podem exibir o total ou apenas uma porção do dispositivo de exibição 28. Por exemplo, na modalidade mostrada, um sistema operacional GUI 52 pode incluir vários ícones gráficos 54, cada um dos quais pode corresponder a várias aplicações que podem ser abertas ou executadas mediante a detecção de uma seleção de usuário (por exemplo, através de entrada por teclado/mouse ou tela sensível ao toque). Os ícones 54 podem ser exibidos em uma doca 56 ou em um ou mais elementos de janela gráficos 58 exibidos na tela. Em algumas modalidades, a seleção de um ícone 54 pode levar a um processo de navegação hierárquico, de modo que a seleção de um ícone 54 leve a uma tela ou abra outra janela gráfica que inclui um ou mais ícones adicionais ou outro elementos de GUI. A título de exemplo, apenas, o sistema operacional GUI 52 exibida na Figura 4 pode ser de uma versão do sistema operacional Mac OS®, disponível junto à Apple Inc.

[000170] Continuando com as Figuras 5 e 6, o dispositivo eletrônico 10 é adicionalmente ilustrado na forma de um dispositivo eletrônico portátil de mão 60, que pode ser um modelo de um iPod® ou iPhone® disponível junto à Apple Inc. Na modalidade mostrada, o dispositivo de mão 60 inclui um invólucro 42, que pode funcionar pra proteger os componentes internos de danos físicos e para protegê-los de interferência eletromagnética. O invólucro 42 pode ser formado a partir de qualquer material adequado ou combinação de materiais, como plástico, metal ou um material compósito, e pode permitir que certas frequências de radiação eletromagnética, como sinais de rede sem fio, passem através do conjunto de circuitos de comunicação sem fio (por exemplo, dispositivo de rede 24), que podem ser dispostos no invólucro 42, conforme mostrado na Figura 5.

[000171] O invólucro 42 também inclui várias estruturas de entrada de usuário 14 através das quais um usuário pode realizar interface com o dispositivo de mão 60. Por exemplo, cada estrutura de entrada 14 pode ser configurada para controlar uma ou mais funções de dispositivo respectivas quando pressionada ou acionada. A título de exemplo, uma ou mais das estruturas de entrada 14 podem ser configuradas para invocar uma tela "inicial" 42 ou menu, para alternar entre um modo de dormir, despertar ou ativado/desativado, para silenciar um toque para uma aplicação de telefone celular, para aumentar ou diminuir uma saída de volume e assim por diante. Deve-se compreender que as estruturas de entrada 14 ilustradas são meramente exemplificadoras e que o dispositivo de mão 60 pode incluir qualquer número de estruturas de entrada de usuário adequadas existentes em várias formas, incluindo botões, comutadores, teclas, maçanetas, rodas de rolagem e assim por diante.

[000172] Conforme mostrado na Figura 5, o dispositivo de mão 60 pode incluir várias portas de I/O 12. Por exemplo, as portas de I/O 12 retratadas podem incluir uma porta de conexão proprietária 12a para transmitir e receber arquivos de dados ou para mudar uma fonte de alimentação 26 e uma porta de conexão de áudio 12b para conectar o dispositivo 60 a um dispositivo de emissão de áudio (por exemplo, fones de ouvido ou autofalantes). Ademais, em modalidades em que o dispositivo de mão 60 fornece funcionalidade de telefone móvel, o dispositivo 60 pode incluir uma porta de I/O 12c para receber um cartão de módulo de identificação de assinante (SIM) (por exemplo, um cartão de expansão 22).

[000173] O dispositivo de exibição 28, que pode ser um LCD, OLED, ou qualquer tipo adequado de visor, pode exibir várias imagens geradas pelo dispositivo de mão 60. Por exemplo, o visor 28 pode exibir vários indicadores de sistema 64 que fornecem retroalimentação a um usuário em relação a um ou mais estados do dispositivo de mão 60, como situação de potência, força do sinal, conexões de dispositivo externa e assim por diante. O visor também pode exibir uma GUI 52 que permite um usuário a interaja com o dispositivo 60, conforme discutido acima com referência à Figura 4. A GUI 52 pode incluir elementos gráficos, como os ícones 54 que podem corresponder a várias aplicações que podem ser abertas ou executadas mediante a detecção de uma seleção de usuário de um respectivo ícone 54. A título de exemplo, um dos ícones 54 pode representar uma aplicação de câmera 66 que pode ser usada em conjunto com uma câmera 30 (mostrada em linhas pontilhadas na Figura 5) para a aquisição de imagens. Com referência breve à Figura 6, uma vista posterior do dispositivo eletrônico de mão 60 mostrado na Figura 5 é ilustrada, a qual mostra a câmera 30 como sendo integrada ao alojamento 42 e posicionada na parte posterior do dispositivo de mão 60.

[000174] Conforme mencionado acima, os dados de imagem adquiridos com o uso da câmera 30 podem ser processados com o uso do conjunto de circuitos de processamento de imagem 32, que pode incluir hardware (por exemplo, disposto no interior do invólucro 42) e/ou software armazenado em um ou mais dispositivos de armazenamento (por exemplo, memória 18 ou armazenamento não volátil 20) do dispositivo 60. As imagens adquiridas com o uso da aplicação de câmera 66 e a câmera 30 podem ser armazenadas no dispositivo 60 (por exemplo, no dispositivo de armazenamento 20) e podem ser visualizadas em um momento posterior com o uso de uma aplicação de visualização de foto 68.

[000175] O dispositivo de mão 60 também pode incluir vários elementos de entrada e saída de áudio. Por exemplo, os elementos de entrada/saída de áudio, mostrados, em geral, pelo número de referência 70, podem incluir um receptor de entrada, como um ou mais microfones. Por exemplo, onde o dispositivo de mão 60 inclui funcionalidade de telefone celular, os receptores de entrada podem ser configurados para receber entrada de usuário de áudio, como a voz de um usuário. Adicionalmente, os elementos de entrada/saída de áudio 70 podem incluir um ou mais transmissores de saída. Tais transmissores de saída podem incluir um ou mais autofalantes que podem funcionar para transmitir sinais de áudio a um usuário, como durante a reprodução de dados de música com o uso de uma aplicação de tocador de mídia 72. Ademais, em modalidades em que o dispositivo de mão 60 inclui uma aplicação de telefone celular, um transmissor de saída de áudio adicional 74 pode ser fornecido, conforme mostrado na Figura 5. Como os transmissores de saída dos elementos de entrada/saída de áudio 70, o transmissor de saída 74 também pode incluir um ou mais autofalantes configurados para transmitir sinais de áudio a um usuário, como dados de voz recebidos durante uma ligação telefônica. Portanto, os elementos de entrada/saída de áudio 70 e 74 podem operar em conjunto para funcionar como os elementos de recebimento e transmissão de um telefone.

[000176] Tendo fornecido algum contexto em relação às várias formas que o dispositivo eletrônico 10 pode assumir, a presente discussão focará, agora, no conjunto de circuitos de processamento de imagem 32 mostrado na Figura 1. Conforme mencionado acima, o conjunto de circuitos de processamento de imagem 32 pode ser implantado com o uso de componentes de hardware e/ou software, e pode incluir várias unidades de processamento que definem uma pipeline de sinal de imagem processamento (ISP). Em particular, a discussão a seguir pode focar em aspectos das técnicas de processamento de imagem apresentados na presente descrição, particularmente aqueles referentes a técnicas de detecção/correção de pixel defectivo, técnicas de correção de sombreamento de lente, técnicas de interpolação e técnicas de ajuste de nitidez de imagem.

[000177] Com referência, agora, à Figura 7, um diagrama de bloco de nível de topo simplificado que mostra diversos componentes funcionais que podem ser implantados como parte do conjunto de circuitos de processamento de imagem 32 é ilustrado, de acordo com uma modalidade das técnicas aqui apresentadas. Particularmente, a Figura 7 é destinada a ilustrar como os dados de imagem podem fluir através do conjunto de circuitos de processamento de imagem 32, de acordo com pelo menos uma modalidade. Para fornecer uma visão geral do conjunto de circuitos de processamento de imagem 32, uma descrição geral de como esses componentes funcionais operam para processar dados de imagem é fornecida aqui com referência à Figura 7, enquanto uma descrição mais específica de cada um dos componentes funcionais ilustrados, assim como seus respectivos subcomponentes, será adicionalmente fornecida abaixo.

[000178] Com referência à modalidade ilustrada, o conjunto de circuitos de processamento de imagem 32 pode incluir lógica de processamento de front-end de processamento de sinal de imagem (ISP) 80, lógica de processamento de pipe de ISP 82 e lógica de controle 84. Os dados de imagem capturada pelo dispositivo de imageamento 30 podem, primeiramente, ser processados pela lógica de front-end de ISP 80 e analisados para capturar estatísticas de imagem que podem ser usadas para determinar um ou mais parâmetros de controle para a lógica de pipe de ISP 82 e/ou o dispositivo de imageamento 30. A lógica de front-end de ISP 80 pode ser configurada para capturar dados de imagem a partir de um sensor de imagem sinal de entrada. Por exemplo, conforme mostrado na Figura 7, o dispositivo de imageamento 30 pode incluir uma câmera que tem uma ou mais lentes 88 e sensor(es) de imagem 90. Conforme discutido acima, o(s) sensor(es) de imagem 90 pode incluir uma matriz de filtro de cor (por exemplo, um filtro Bayer) e pode, então, fornecer ambas intensidade de luz e informações de comprimento de onda capturadas por cada pixel de imageamento dos sensores de imagem 90 para fornecer um conjunto de dados de imagem brutos que podem ser processados pela lógica de front-end de ISP 80. Por exemplo, a saída 92 do dispositivo de imageamento 30 pode ser recebida por uma interface de sensor 94, que pode, então, fornecer os dados de imagem brutos 96 para a lógica de front-end de ISP 80 com base, por exemplo, no tipo de interface de sensor. A título de exemplo, a interface de sensor 94 pode utilizar uma interface de Arquitetura de Imageamento Móvel Padrão (SMIA) ou outras interfaces de câmera em série ou paralelas, ou alguma combinação dos mesmos. Em certas modalidades, a lógica de front-end de ISP 80 pode operar em seu próprio domínio e pode fornecer uma interface assíncrona à interface de sensor 94 para suportar sensores de imagem de tamanhos diferentes e exigências de temporização. A interface de sensor 94 pode incluir, em algumas modalidades, uma subinterface no lado do sensor (por exemplo, interface de lateral de sensor) e uma subinterface no lado do front-end de ISP, sendo eu as subinterfaces formam a interface de sensor 94.

[000179] Os dados de imagem brutos 96 podem ser fornecidos à lógica de front-end de ISP 80 e processados em uma base de pixel por pixel em vários formatos. Por exemplo, cada pixel de imagem por ter uma profundidade de bit de 8, 10, 12 ou 14 bits. Vários exemplos de formatos de memória que mostram como os dados de pixel podem ser armazenados e encaminhados na memória são discutidos com mais detalhes abaixo. A lógica de front-end de ISP 80 pode realizar uma ou mais operações de processamento de imagem nos dados de imagem brutos 96, assim como coletar estatísticas sobre os dados de imagem 96. As operações de processamento de imagem, assim como a coleta de dados estatísticos, podem ser realizadas em precisões de profundidade de bit iguais ou diferentes. Por exemplo, em uma modalidade, o processamento dos dados de pixel de imagem bruta 96 pode ser realizado a uma precisão de 14 bits. Em tais modalidades, dados de pixel brutos recebidos pela lógica de front-end de ISP 80 que tem uma profundidade de bit menor que 14 bits (por exemplo, 8 bits, 10 bits, 12 bits) podem ser amostrados ascendentemente a 14 bits para fins de processamento de imagem. Em outra modalidade, o processamento estatístico pode ocorrer a uma precisão de 8 bits e, portanto, dados de pixel brutos que têm uma profundidade de bit mais alta podem ser amostrados descendentemente para um formato de 8 bits para fins estatísticos. Conforme será constatado, a amostragem descendente para 8 bits pode reduzir o tamanho de hardware (por exemplo, área) e também pode reduzir a complexidade computacional/de processamento para os dados estatísticos. Adicionalmente, os dados de imagem brutos podem ser avaliados espacialmente para permitir que as estatísticas sejam mais robustas em relação a ruído.

[000180] Ademais, conforme mostrado na Figura 7, a lógica de frontend de ISP 80 também pode receber dados de pixel a partir da memória 108. Por exemplo, conforme mostrado pelo número de referência 98, os dados de pixel brutos podem ser enviados para a memória 108 a partir da interface de sensor 94. Os dados de pixel brutos que residem na memória 108 podem, então, ser fornecidos para a lógica de front-end de ISP 80 para processamento, conforme indicado pelo número de referência 100. A memória 108 pode ser parte do dispositivo de memória 18, do dispositivo de armazenamento 20, ou pode ser uma memória dedicada separada no interior do dispositivo eletrônico 10 e pode incluir características de acesso à memoria direto (DMA). Ademais, em certas modalidades, a lógica de front-end de ISP 80 pode operar em seu próprio domínio de relógio e fornecer uma interface assíncrona à interface de sensor 94 para suportar os sensores de tamanhos diferentes e que têm exigências de temporização diferentes.

[000181] Mediante o recebimento dos dados de imagem brutos 96 (da interface de sensor 94) ou 100 (da memória 108), a lógica de front-end de ISP 80 pode realizar uma ou mais operações de processamento de imagem, como filtragem temporal e/ou filtragem de compensação de compartimentalização. Os dados de imagem processados podem, então, ser fornecidos à lógica de pipe de ISP 82 (sinal de saída 109) para processamento adicional anteriormente a serem exibidos (por exemplo, no dispositivo de exibição 28), ou podem ser enviados à memória (sinal de saída 110). A lógica de pipe de ISP 82 recebe os dados processados de "front-end", ou diretamente a partir da lógica de front-end de ISP 80 ou da memória 108 (sinal de entrada 112) e pode fornecer processamento adicional dos dados de imagem no domínio bruto, assim como nos espaços de cor RGB e YCbCr. Os dados de imagem processados pela lógica de pipe de ISP 82 podem, então, ser emitidos (sinal 114) ao visor 28 para a visualização por um usuário e/ou podem ser adicionalmente processados por um mecanismo de gráfico ou GPU. Adicionalmente, a emissão da lógica de pipe de ISP 82 pode ser enviada para a memória 108 (sinal 115) e o visor 28 pode ler os dados de imagem a partir da memória 108 (sinal 116), que pode, em certas modalidades, ser configurada para implantar um ou mais armazenamentos temporários de quadro. Ademais, em algumas implantações, a saída da lógica de pipe de ISP 82 também pode ser fornecida para um motor de compressão/descompressão 118 (sinal 117) para encodificar/decodificar os dados de imagem. Os dados de imagem encodificados podem ser armazenados e, então, posteriormente descomprimidos anteriormente a serem exibidos no dispositivo de visor 28 (sinal 119). A título de exemplo, o mecanismo de compressão ou "encodificador" 118 pode ser um mecanismo de compressão de JPEG para encodificar imagens paradas ou um mecanismo de compressão de H.264 para encodificar imagens de vídeo, ou alguma combinação dos mesmos, assim como um mecanismo de descompressão correspondente para decodificar os dados de imagem. Informações adicionais em relação às operações de processamento de imagem que podem ser fornecidas na lógica de pipe de ISP 82 serão discutidas com mais detalhes abaixo em relação às Figuras 98 a 133. Ademais, deve-se notar que a lógica de pipe de ISP 82 também pode receber dados de imagem brutos a partir da memória 108, conforme mostrado pelo sinal de entrada 112.

[000182] Os dados estatísticos 102 determinados pela lógica de frontend de ISP 80 podem ser fornecidos a uma unidade de lógica de controle 84. Os dados estatísticos 102 podem incluir, por exemplo, estatísticas de sensor de imagem referentes à auto-exposição, auto- equilíbrio de branco, autofoco, detecção de oscilação, compensação de nível de preto (BLC), correção de sombreamento de lente e assim por diante. A lógica de controle 84 pode incluir um processador e/ou microcontrolador configurado para executar uma ou mais rotinas (por exemplo, firmware) que possam ser configuradas para determinar, com base nos dados estatísticos recebidos 102, parâmetros de controle 104 para o dispositivo de imageamento 30, assim como parâmetros de controle 106 para a lógica de processamento de pipe de ISP 82. A título de exemplo, apenas, os parâmetros de controle 104 podem incluir parâmetros de controle de sensor (por exemplo, ganhos, tempo de integração para controle de exposição), parâmetros de controle de flash de câmera, parâmetros de controle de lente (por exemplo, distancia focal para focalização ou zoom), ou uma combinação de tais parâmetros. Os parâmetros de controle de ISP 106 podem incluir níveis de ganho e coeficientes de matriz de correão de cor (CCM) para o auto- equilíbrio de branco e ajuste de cor (por exemplo, durante o processamento de RGB), assim como parâmetros de correção de sombreamento de lente que, conforme discutido abaixo, podem ser determinados com base em parâmetros de equilíbrio de ponto branco. Em algumas modalidades, a lógica de controle 84 pode, além de analisar dados estatísticos 102, também analisar estatísticas históricas, que podem ser armazenadas no dispositivo eletrônico 10 (por exemplo, na memória 18 ou armazenamento 20).

[000183] Com referência à modalidade ilustrada, o conjunto de circuitos de processamento de imagem 32 pode incluir lógica de processamento de front-end de processamento de sinal de imagem (ISP) 80, lógica de processamento de pipe de ISP 82 e lógica de controle 84. Os dados de imagem capturada pelo dispositivo de imageamento 30 podem, primeiramente, ser processados pela lógica de front-end de ISP 80 e analisados para capturar estatísticas de imagem que podem ser usados para determinar um ou mais parâmetros de controle para a lógica de pipe de ISP 82 e/ou o dispositivo de imageamento 30. A lógica de front-end de ISP 80 pode ser configurada para capturar dados de imagem a partir de um sensor de imagem sinal de entrada. Por exemplo, conforme mostrado na Figura 7, o dispositivo de imageamento 30 pode incluir uma câmera que tem uma ou mais lentes 88 e sensor(es) de imagem 90. Conforme discutido acima, o(s) sensor(es) de imagem 90 pode incluir uma matriz de filtro de cor (por exemplo, um filtro Bayer) e pode, então, fornecer ambas intensidade de luz e informações de comprimento de onda capturadas por cada pixel de imageamento dos sensores de imagem 90 para fornecer um conjunto de dados de imagem brutos que pode ser processado pela lógica de front-end de ISP 80. Por exemplo, a emissão 92 a partir do dispositivo de imageamento 30 pode ser recebida por uma interface de sensor 94, que pode, então, fornecer os dados de imagem brutos 96 à lógica de front-end de ISP 80 com base, por exemplo, no tipo de interface de sensor. A título de exemplo, a interface de sensor 94 pode utilizar uma interface de Arquitetura de Imageamento Móvel Padrão (SMIA) ou outras interfaces de câmera ou em série ou paralelas, ou alguma combinação dos mesmos. Em certas modalidades, a lógica de front-end de ISP 80 pode operar em seu próprio domínio de relógio e pode fornecer uma interface assíncrona à interface de sensor 94 para suportar sensores de imagem de tamanhos e exigências de temporização diferentes.

[000184] A Figura 8 mostra um diagrama de bloco que mostra outra modalidade do conjunto de circuitos de processamento de imagem 32, em que os mesmos componentes são marcados com os mesmos números de referência. Em geral, a operação e a funcionalidade do conjunto de circuitos de processamento de imagem 32 da Figura 8 são similares ao conjunto de circuitos de processamento de imagem 32 da Figura 7, exceto pelo fato de que a modalidade mostrada na Figura 8 inclui, ainda, uma unidade de lógica de processamento de back-end de ISP 120, que pode ser acoplada a jusante da pipeline de ISP 82 e pode fornecer etapas de pós-processamento adicionais.

[000185] Na modalidade ilustrada, a lógica de back-end de ISP 120 pode receber a emissão 114 da pipeline de ISP 82 e realizar pós- processamento os dados recebidos 114. Adicionalmente, o back-end de ISP 120 pode receber dados de imagem diretamente da memória 108, conforme mostrado pela entrada 124. Conforme será adicionalmente discutido abaixo com referência às Figuras 134 a 142, uma modalidade da lógica de back-end de ISP 120 pode fornecer a compressão de faixa dinâmica de dados de imagem (frequentemente chamada de "mapeamento de tom"), ajustes de claridade, contraste e de cor, assim como a lógica de escalonamento para escalonar os dados de imagem para um tamanho ou resolução desejada (por exemplo, com base em uma resolução de um dispositivo de exibição de saída). Ademais, a lógica de back-end de ISP 120 também pode incluir a lógica de detecção de característica para detectar certas características nos dados de imagem. Por exemplo, em uma modalidade, a lógica de detecção de característica pode incluir a lógica de detecção de face configurada para identificar áreas nas quais faces e/ou características faciais estão localizadas e/ou posicionadas nos dados de imagem. Os dados de detecção facial podem ser alimentados à unidades de processamento de estatística de front-end como dados de retroalimentação para a determinação de estatísticas de auto-equilíbrio de branco, autofoco, oscilação e auto-exposição. Por exemplo, a unidades de processamento de estatística na front-end de ISP 80 (discutida com mais detalhes abaixo nas Figuras 68 a 97) pode ser configurada para selecionar janelas para os processamentos de estatística com base nos locais determinados de faces e/ou características faciais nos dados de imagem.

[000186] Em algumas modalidades, os dados de detecção facial, além de ou em vez de serem retroalimentados para um laço de controle de retroalimentação de estatísticas de front-end de ISP, também podem ser fornecidos a pelo menos uma dentre a lógica de mapeamento de tom local processamento, uma unidade de estatísticas de back-end de ISP ou à unidade de encodificador/decodificador 118. Conforme discutido adicionalmente abaixo, os dados de detecção facial fornecidos à unidade de estatísticas de back-end podem ser utilizados para controlar parâmetros de quantização. Por exemplo, ao encodificar ou comprimir a emissão de dados de imagem (por exemplo, em macroblocos) a quantização pode ser reduzida para áreas da imagem que foram determinadas como incluindo faces e/ou características faciais, melhorando, assim, a qualidade visual de faces e características faciais quando a imagem é exibida e visualizada por um usuário.

[000187] Em modalidades adicionais, a lógica de detecção de característica também pode ser configurada para detectar os locais de cantos de objetos no quadro de imagem. Esses dados podem ser usados para identificar a localização de características em quadros de imagem consecutivos para determinar uma estimativa de movimento global entre quadros, que pode ser usado para realizar certas operações de processamento de imagem, como registro de imagem. Em uma modalidade, a identificação de características de canto e similares pode ser particularmente útil para algoritmos que combinam múltiplos quadros de imagem, como em certos algoritmos de montagem panorâmica.

[000188] Ademais, conforme mostrado na Figura 8, dados de imagem processados pela lógica de back-end de ISP 120 podem ser emitidos (sinal 126) para o dispositivo de exibição 28 para a visualização por um usuário e/ou podem ser adicionalmente processados por um mecanismo de gráfico ou GPU. Adicionalmente, a emissão a partir da lógica de back-end de ISP 120 pode ser enviada para a memória 108 (sinal 122) e o visor 28 pode ler os dados de imagem a partir da memória 108 (sinal 116), que pode, em certas modalidades, ser configurada para implantar um ou mais armazenamentos temporários. Na modalidade ilustrada, a emissão da lógica de back-end de ISP 120 também pode ser fornecida para o mecanismo de compressão/descompressão 118 (sinal 117) para encodificar/decodificar os dados de imagem para armazenamento e subsequente reprodução, conforme em geral discutido acima na Figura 7. Em modalidades adicionais, o subsistema de ISP 32 da Figura 8 pode ter a opção de desviar a unidade de processamento de back-end de ISP 120. Em tais modalidades, se a unidade de processamento de back-end 120 for desviada, o subsistema de ISP 32 da Figura 8 pode operar de maneira similar àquela mostrada na Figura 7, isto é, a emissão da pipeline de ISP 82 é enviada direta/indiretamente a um ou mais dentre memória 108, encodificador/decodificador 118 ou o visor 28.

[000189] As técnicas de processamento de imagem mostradas nas modalidades mostradas na Figura 7 e na Figura 8 podem ser, em geral, resumidas pelo método 130 mostrado por meio de um fluxograma na Figura 9. Conforme mostrado, o método 130 começa no bloco 132, no qual os dados de imagem brutos (por exemplo, dados de padrão Bayer) são recebidos com o uso de uma interface de sensor a partir de um sensor de imagem (por exemplo, 90). No bloco 134, os dados de imagem brutos recebidos na etapa 132 são processados com o uso da lógica de front-end de ISP 80. Conforme mencionado acima, a lógica de front-end de ISP 80 pode ser configurada para aplicar filtragem temporal, filtragem de compensação de compartimentalização. A seguir, na etapa 136, os dados de imagem brutos processados pela lógica de front-end de ISP 80 podem ser adicionalmente processados pela pipeline de ISP 82, que pode realizar várias etapas de processamento para retirar de mosaico os dados de imagem brutos em dados de cor RGB total e para converter, adicionalmente, os dados de cor RGB em um espaço de cor de YUV ou YC1C2 (em que C1 e C2 representam cores de diferença cromática diferente e em que C1 e C2 podem representar a diferença de azul (Cb) e a diferença de vermelho (Cr) croma em uma modalidade).

[000190] A partir da etapa 136, o método 130 pode ou continuar para a etapa 138 ou para a etapa 160. Por exemplo, em uma modalidade (Figura 7) em que a emissão da pipeline de ISP 82 é fornecida a um dispositivo de exibição 28, o método 130 continua para a etapa 140, em que os dados de imagem YC1C2 são exibidos com o uso do dispositivo de exibição 28 (ou enviados a partir da pipeline de ISP 82 para a memória 108). Alternativamente, em uma modalidade em que a emissão da pipeline de ISP 82 é pós-processada por uma unidade de back-end de ISP 120 (Figura 8), o método 130 pode continuar a partir da etapa 136 para a etapa 138, em que a emissão YC1C2 da pipeline de ISP 82 é processada pela lógica de processamento de back-end de ISP 120 antes de ser exibida pelo dispositivo de exibição na etapa 140.

[000191] Devido ao projeto em geral complexo do conjunto de circuitos de processamento de imagem 32 mostrado no presente documento, pode ser benéfico separar a discussão da lógica de front end de ISP 80, a lógica de processamento de pipe de ISP 82 (ou pipeline de ISP) e a lógica de processamento de back-end de ISP 120 em seções separadas, conforme mostrado abaixo. Particularmente, as Figuras 10 a 97 do presente pedido de patente pode se referir à discussão de várias modalidades e aspectos da lógica de front-end de ISP 80, as Figuras 98 a 133 do presente pedido de patente podem se referir à discussão de várias modalidades e aspectos da lógica de processamento de pipe de ISP 82 e as Figuras 134 a 142 podem se referir à discussão de várias modalidades e aspectos da lógica de back-end de ISP 120.

Lógica de processamento de front-end de ISP

[000192] A Figura 10 é um diagrama de bloco mais detalhado que mostra blocos de lógica funcionais que podem ser implantados na lógica de front-end de ISP 80, de acordo com uma modalidade. Dependendo da configuração do dispositivo de imageamento 30 e/ou interface de sensor 94, conforme discutido acima na Figura 7, os dados de imagem brutos podem ser fornecidos à lógica de front-end de ISP 80 através de um ou mais sensores de imagem 90. Na modalidade retratada, os dados de imagem brutos podem ser fornecidos à lógica de front-end de ISP 80 por um primeiro sensor de imagem 90a (Sensor0) e um segundo sensor de imagem 90b (Sensor1). Conforme será adicionalmente discutido abaixo, cada sensor de imagem 90a e 90b pode ser configurado para aplicar compartimentalização para dados de imagem de resolução total para aumentar a razão de sinal para ruído do sinal de imagem. Por exemplo, uma técnica de compartimentalização, como a compartimentalização de 2x2, pode ser aplicada, a qual pode interpolar um pixel de imagem bruto "compartimentalizado" com base em quatro pixels de imagem de resolução total da mesma cor. Em uma modalidade, isso pode resultar na existência de quatro componentes de sinal acumulados associados ao pixel compartimentalizado versus um único componente e ruído, melhorando, assim, a razão de sinal para ruído dos dados de imagem, mas reduzindo a resolução geral. Adicionalmente, a compartimentalização também pode resultar em uma amostragem espacial desigual ou não uniforme dos dados de imagem, que pode ser corrigida com o uso de filtragem de compensação de compartimentalização, conforme será discutido com mais detalhes abaixo.

[000193] Conforme mostrado, os sensores de imagem 90a e 90b podem fornecer os dados de imagem brutos como sinais Sif0 e Sif1, respectivamente. Cada um dos sensores de imagem 90a e 90b podem ser, em geral, associados às respectivas unidades de processamentos de estatística 142 (StatsPipe0) e 144 (StatsPipe1), que podem ser configuradas para processar dados de imagem para a determinação de um ou mais conjuntos de estatísticas (conforme indicado por sinais Stats0 e Stats1), incluindo estatísticas referentes à auto-exposição, auto-equilíbrio de branco, autofoco, detecção de oscilação, compensação de nível de preto e correção de sombreamento de lente e assim por diante. Em certas modalidades, quando apenas um dos sensores 90a ou 90b está obtendo ativamente a imagem, os dados de imagem podem ser enviados pra ambos StatsPipe0 e StatsPipe1 se estatísticas adicionais forem desejadas. Por exemplo, para fornecer um exemplo, se StatsPipe0 e StatsPipe1 estiverem ambos disponíveis, StatsPipe0 pode ser utilizado para coletar estatísticas para um espaço de cor (por exemplo, RGB) e StatsPipe1 pode ser utilizado para coletar estatísticas para outro espaço de cor (por exemplo, YUV ou YCbCr). Ou seja, as unidades de processo de estatísticas 142 e 144 podem operar em paralelo para coletar múltiplos conjuntos de estatísticas para quadro dos dados de imagem adquiridos pelo sensor ativo.

[000194] Na presente modalidade, cinco fontes assíncronas de dados são fornecidas na front-end de ISP 80. Estas incluem: (1) uma entrada direta a partir de uma interface de sensor correspondente ao Sensor0 (90a) (chamada de Sif0 ou Sens0), (2) uma entrada direta a partir de uma interface de sensor correspondente ao Sensor1 (90b) (chamado de Sif1 ou Sens1), (3) entrada de dados de Sensor0 a partir da memória 108 (chamada de SifIn0 ou Sens0DMA), que pode incluir uma interface de DMA, (4) entrada de dados do Sensor1 a partir da memória 108 (chamada aqui de SifIn1 ou Sens1DMA), e (5) um conjunto de dados de imagem com quadros a partir da entrada de dados de Sensor0 e Sensor1 recuperada da memória 108 (chamada de FeProcIn ou ProcInDMA). A front-end de ISP 80 também pode incluir múltiplos destinos aos quais os dados de imagem a partir das fontes podem ser roteados, em que cada destino pode ser ou um local de armazenamento na memória (por exemplo, em 108), ou uma unidade de processamento. Por exemplo, na presente modalidade, a front-end de ISP 80 inclui seis destinos: (1) Sif0DMA para receber dados do Sensor0 na memória 108, (2) Sif1DMA para receber dados do Sensor1 na memória 108, (3) a primeira unidades de processamento de estatística 142 (StatsPipe0), (4) a segunda unidades de processamento de estatística 144 (StatsPipe1), (5) a unidade de processamento de pixel de front-end (FEProc) 150, e (6) FeOut (ou FEProcOut) para a memória 108 ou a pipeline de ISP 82 (discutida com maiores detalhes abaixo). Em uma modalidade, a frontend de ISP 80 pode ser configurada de modo que apenas certos destinos sejam válidos para uma fonte particular, conforme mostrado na Tabela 1 abaixo.

Tabela 1 - Exemplo de destinos válidos de front-end de ISP para cada fonte

[000195] Por exemplo, de acordo com a Tabela 1, a fonte Sens0 (interface de sensor do Sensor0) pode ser configurada para fornecer dados aos destinos SIf0DMA (sinal 154), StatsPipe0 (sinal 156), StatsPipe1 (sinal 158), FEProc (sinal 160), ou FEOut (sinal 162). Em relação ao FEOut, os dados de fonte podem, em alguns casos, ser fornecidos para o FEOut para desviar o processamento de pixel por FEProc, como para fins de depuração ou teste. Adicionalmente, a fonte Sens1 (interface de sensor do Sensor1) pode ser configurada para fornecer dados para destinos SIf1DMA (sinal 164), StatsPipe0 (sinal 166), StatsPipe1 (sinal 168), FEProc (sinal 170) ou FEOut (sinal 172), a fonte Sens0DMA (dados de Sensor0 a partir da memória 108) pode ser configurada para fornecer dados para StatsPipe0 (sinal 174), a fonte Sens1DMA (dados de Sensor1 a partir da memória 108) pode ser configurada para fornecer dados para StatsPipe1 (sinal 176) e a fonte ProcInDMA (dados do Sensor0 e Sensor1 a partir da memória 108) pode ser configurada para fornecer dados para FEProc (sinal 178) e FEOut (sinal 182).

[000196] Deve-se notar que a modalidade atualmente ilustrada é configurada de modo que Sens0DMA (quadros de Sensor0 da memória 108) e Sens1DMA (quadros do Sensor1 a partir da memória 108) sejam apenas fornecidos para StatsPipe0 e StatesPipe1, respectivamente. Essa configuração permite que a front-end de ISP 80 retenha um certo número de quadros anteriores (por exemplo, 5 quadros) na memória. Por exemplo, devido a um atraso ou lentidão entre o tempo em que um usuário inicia um evento de captura (por exemplo, transitar o sistema de imagem a partir de um modo de pré-visualização para um modo de captura ou registro ou mesmo ao apenas ativar ou inicializar o sensor de imagem) com o uso do sensor de imagem e quando uma cena de imagem é capturada, nem todos os quadros que o usuário pretendia capturar pode ser capturado e processado substancialmente em tempo real. Portanto, ao reter um certo número de quadros prévios na memória 108 (por exemplo, a partir de uma fase de previsão), esses quadros anteriores podem ser processados posteriormente ou ao mesmo tempo em que os quadros de fato capturados em resposta ao evento de captura, compensando, assim, por qualquer tal atraso e fornecendo um conjunto de dados de imagem mais completo.

[000197] Em relação à configuração ilustrada da Figura 10, deve-se notar que o StatsPipe0 142 é configurado para receber uma das entradas 156 (a partir de Sens0), 166 (de Sens1) e 174 (de Sens0DMA), conforme determinado por uma lógica de seleção 146, como um multiplexador. De modo similar, a lógica de seleção 148 pode selecionar uma entrada dos sinais 158, 176 e 168 para fornecer a StatsPipe1, e a lógica de seleção 152 pode selecionar uma entrada a partir dos sinais 160, 170 e 178 para fornecer para FEProc. Conforme mencionado acima, os dados estatísticos (Stats0 e Stats1) podem ser fornecidos à lógica de controle 84 para a determinação de vários parâmetros de controle que podem ser usados para operar o dispositivo de imageamento 30 e/ou a lógica de processamento de pipe de ISP 82. Conforme pode ser constatado, os blocos de lógica de seleção (146, 148 e 152) mostrados na Figura 10 podem ser fornecidos por qualquer tipo de lógica adequado, como um multiplexador que seleciona um dentre múltiplos sinais de entrada em resposta a um sinal de controle.

[000198] A unidade de processamento de pixel (FEProc) 150 pode ser configurada para realizar várias operações de processamento de imagem nos dados de imagem brutos em uma base de pixel por pixel. Conforme mostrado, FEProc 150, como uma unidade de processamento de destino, pode receber dados de imagem a partir de fontes Sens0 (sinal 160), Sens1 (sinal 170), ou ProcInDMA (sinal 178) por meio da lógica de seleção 152. FEProc 150 também pode receber e emitir vários sinais (por exemplo, Rin, Hin, Hout e Yout - que podem representar história de movimento e dados de luma usados durante a filtragem temporal) ao realizar as operações de processamento de pixel, que podem incluir filtragem temporal e filtragem de compensação de compartimentalização, conforme será adicionalmente discutido abaixo. A emissão 109 (FEProcOut) da unidade de processamento de pixel 150 pode, então, ser encaminhada para a lógica de pipe de ISP 82, como através de uma ou mais filas do tipo primeiro a entrar, primeiro a sair (FIFO), ou pode ser enviada para a memória 108.

[000199] Ademais, conforme mostrado na Figura 10, a lógica de seleção 152, além de receber os sinais 160, 170 e 178, pode receber, ainda, os sinais 180 e 184. O sinal 180 pode representar dados de imagem brutos "pré-processados" a partir de StatsPipe0 e o sinal 184 pode representar dados de imagem brutos "pré-processados" a partir de StatsPipe1. Conforme será discutido abaixo, cada uma das unidades de processamentos de estatística pode aplicar uma ou mais operações de pré-processamento aos dados de imagem brutos antes de coletar as estatísticas. Em uma modalidade, cada uma das unidades de processamentos de estatística pode realizar u grau de detecção/correão de pixel defectivo, correção de sombreamento de lente, compensação de nível de preto e compensação de nível de preto inversa. Portanto, os sinais 180 e 184 podem representar dados de imagem brutos que foram processados com o uso das operações de pré-processamento supracitadas (conforme será discutido com mais detalhes abaixo na Figura 68). Portanto, a lógica de seleção 152 dá à lógica de processamento de front-end de ISP 80 a flexibilidade de fornecer ou dados de imagem brutos não pré-processados do Sensor0 (sinal 160) e Sensor1 (sinal 170) ou dados de imagem brutos pré-processados a partir de StatsPipe0 (sinal 180) e StatsPipe1 (sinal 184). Adicionalmente, conforme mostrado pelas unidades de lógica de seleção 186 e 188, a lógica de processamento de front-end de ISP 80 também tem a flexibilidade de gravar ou dados de imagem brutos não pré-processados a partir do Sensor0 (sinal 154) ou Sensor1 (sinal 164) na memória 108, ou gravar dados de imagem brutos pré-processados a partir de StatsPipe0 (sinal 180) ou StatsPipe1 (sinal 184) na memória 108.

[000200] Para controlar a operação da lógica de front-end de ISP 80, uma unidade de controle de front-end 190 é fornecida. A unidade de controle 190 pode ser configurada para inicializar e programar registros de controle (chamados, aqui, de "registros go") para configurar e iniciar o processamento de um quadro de imagem e para selecionar um banco(s) de registro apropriado para atualizar registos de dados duplamente armazenados temporariamente. Em algumas modalidades, a unidade de controle 190 também pode fornecer lógica de monitoramento de desempenho para informações de ciclos de relógio de log, latência de memória e qualidade de serviço (QOS). Ademais, a unidade de controle 190 também pode controlar porta de relógio dinâmica, que pode ser usada para desabilitar relógio para uma ou mais porções da front-end de ISP 0 quando não há dados o suficiente na fila de entrada a partir do sensor ativo.

[000201] Com o uso de "registros go" mencionados acima, a unidade de controle 190 pode ser capaz de controlar a atualização de vários parâmetros para cada uma das unidades de processamento (por exemplo, StatsPipe0, StatsPipe1 e FEProc) e pode ter interface com a interface de sensores para controlar o início e a interrupção das unidades de processamento. Em geral, cada uma das unidades de processamento de front-end opera em uma base de quadro por quadro. Conforme discutido acima (Tabela 1), a entrada para as unidades de processamento pode ser a partir da interface de sensor (Sens0 ou Sens1) ou a partir da memória 108. Ademais, as unidades de processamento podem utilizar vários parâmetros e dados de configuração, que podem ser armazenados em registros de dados correspondentes. Em uma modalidade, os registros de dados associados a cada unidade de processamento ou destino podem ser agrupados em blocos que formam um grupo de banco de registro. Na modalidade da Figura 10, sete grupos de banco de registro podem ser definidos na front-end de ISP: SIf0, SIf1, StatsPipe0, StatsPipe1, ProcPipe, FEOut e ProcIn. Cada espaço de endereço de bloco de registro é duplicado para fornecer dois bancos de registros. Apenas os registros que são duplamente temporariamente armazenados são instanciados no segundo banco. Se um registro não for duplamente temporariamente armazenado, o endereço no segundo banco pode ser mapeado para o endereço do mesmo registro no primeiro banco.

[000202] Para registros que são duplamente temporariamente armazenados, os registros de um banco são ativos e usados pelas unidades de processamento enquanto os registros do outro banco são sombreados. O registro sombreado pode ser atualizado pela unidade de controle 190 durante o atual intervalo de quadro enquanto o hardware está usando os registros ativos. A determinação de qual banco usar para uma unidade de processamento particular em um quadro particular pode ser especificada por um campo "NextBk"(próximo banco) em um registro go correspondente à fonte que fornece os dados de imagem à unidade de processamento. Essencialmente, NextBk é um campo que permite que a unidade de controle 190 controle qual banco de registro se torna ativo em um evento de acionamento para o quadro subsequente.

[000203] Antes de discutir a operação dos registros go em detalhes, a Figura 11 fornece um método geral 200 para o processamento de dados de imagem em uma base de quadro a quadro de acordo com as presentes técnicas. Iniciando na etapa 202, as unidades de processamento de destino alvejadas por uma fonte de dados (por exemplo, Sens0, Sens1, Sens0DMA, Sens1DMA, ou ProcInDMA) entram em um estado ocioso. Isso pode indicar que o processamento para o quadro atual está completo e, portanto, a unidade de controle 190 pode se preparar para o processamento do próximo quadro. Por exemplo, na etapa 204, parâmetros programáveis para cada unidade de processamento de destino são atualizados. Isso pode incluir, por exemplo, atualizar o campo NextBk no registro go correspondente à fonte, assim como atualizar quaisquer parâmetros nos registros de dados correspondentes às unidades de destino. Posteriormente, na etapa 206, um evento de acionamento pode posicionar as unidades de destino em um estado de execução. Ademais, conforme mostrado na etapa 208, cada unidade de destino alvejada pela fonte completa suas operações de processamento para o quadro atual e o método 200 pode, subsequentemente, retornar para a etapa 202 para o processamento do próximo quadro.

[000204] A Figura 12 mostra uma vista de diagrama de bloco que mostra dois bancos de registros de dados 210 e 212 que podem ser usados pelas várias unidades de destino da front-end de ISP. Por exemplo, o Banco 0 (210) pode incluir os registros de dados 1-n (210a- 210d) e o Banco 1 (212) pode incluir os registros de dados 1-n (212a- 212d). Conforme discutido acima, a modalidade mostrada na Figura 10 pode utilizar um banco de registro (Banco 0) que tem sete grupos de banco de registro (por exemplo, SIf0, SIf1, StatsPipe0, StatsPipe1, ProcPipe, FEOut e ProcIn). Portanto, em tal modalidade, o espaço de endereço do bloco de registro de cada registro é duplicado para fornecer um segundo banco de registro (Banco 1).

[000205] A Figura 12 também ilustra o registro go 214 que pode corresponder a uma das fontes. Conforme mostrado, o registro go 214 inclui um campo "NextVld" 216 e o banco supracitado "NextBk" 218. Esses campos podem ser programados anteriormente ao início do processamento do quadro atual. Particularmente, NextVld pode indicar o(s) destino(s) para onde os dados da fonte devem ser enviados. Conforme discutido acima, NextBk pode selecionar um registro de dados correspondente ou do Banco0 ou do Banco1 para cada destino alvejado, conforme indicado por NextVld. Embora não seja mostrado na Figura 12, o registro go 214 também pode incluir uma porção de armação, chamada, no presente documento, de "porção go," que pode ser configurada para armar o registro go. Quando um evento de acionamento 226 para um quadro atual for detectado, NextVld e NextBk podem ser copiados em um campo CurrVld 222 e um campo CurrBk 224 de uma corrente correspondente ou registro "ativo" 220. Em uma modalidade, o(s) registro(s) atual(is) 220 podem ser registros de apenas leituras que podem ser configurados por hardware, enquanto permanecem inacessíveis a comandos de software na front-end de ISP 80.

[000206] Conforme será constatado, para cada fonte de front-end de ISP, um registro go correspondente pode ser fornecido. Para os propósitos dessa descrição, os registros go correspondentes às fontes discutidas acima Sens0, Sens1, Sens0DMA, Sens1DMA e ProcInDMA podem ser referidos como Sens0Go, Sens1Go, Sens0DMAGo, Sens1DMAGo e ProcInDMAGo, respectivamente. Conforme mencionado acima, a unidade de controle pode utilizar os registros go para controlar o sequenciamento do quadro processamento na front end de ISP 80. Cada registro go contém um campo NextVld e um campo NextBk para indicar quais destinos serão válidos e qual banco de registro (0 ou 1) será usado, respectivamente, para o próximo quadro. Quando o evento de acionamento 226 do próximo quadro ocorre, os campos NextVld e NextBk são copiados para um registro de apenas leitura ativo correspondente 220 que indica os destinos válidos atuais e os números de banco, conforme mostrado acima na Figura 12. Cada fonte pode ser configurada para operar de maneira assíncrona e pode enviar dados para qualquer um de seus destinos válidos. Ademais, deve-se compreender que, para cada destino, em geral apenas uma fonte pode ser ativa durante um quadro atual.

[000207] Em relação à armação e ao acionamento do registro go 214, afirmar uma porção de armação ou "porção go" no registro go 214 arma a fonte correspondente com os campos associados NextVld e NextBk. Para o acionamento, vários modos estão disponíveis, dependendo em se os dados de entrada de fonte são lidos a partir da memória (por exemplo, Sens0DMA, Sens1DMA ou ProcInDMA), ou se os dados de entrada de fonte são de uma interface de sensor (por exemplo, Sens0 ou Sens1). Por exemplo, se a entrada for da memória 108, a armação da porção go em si pode servir como o evento de acionamento, já que a unidade de controle 190 tem controle sobre quando os dados são lidos a partir da memória 108. Se os quadros de imagem estão sendo inseridos pela interface de sensor, então o evento de acionamento pode depender do momento no qual o registro go correspondente é armado em relação a quando os dados da interface de sensor são recebidos. De acordo com a presente modalidade, três técnicas diferentes para o tempo de acionamento a partir de uma entrada de interface de sensor são mostradas nas Figuras 13 a 15.

[000208] Com referência, primeiramente, à Figura 13, um primeiro caso é ilustrado no qual o acionamento ocorre uma vez que todos os destinos alvejados pela fonte transitam de um estado ocupado ou de execução para um estado ocioso. Aqui, um sinal de dados VVALID (228) representa um sinal de dados de imagem a partir de uma fonte. O pulso 230 representa um quadro atual de dados de imagem, o pulso 236 representa o próximo quadro de dados de imagem e o intervalo 232 representa um intervalo de supressão vertical (VBLANK) 232 (por exemplo, representa o diferencial de tempo entre a última linha do quadro atual 230 e o próximo quadro 236). O diferencial de tempo entre a borda ascendente e a borda descendente do pulso 230 representa um intervalo de quadro 234. Portanto, na Figura 13, a fonte pode ser configurada para acionar quando todos os destinos alvejados terminaram as operações de processamento no quadro atual 230 e a transição para um estado ocioso. Nesse contexto, a fonte é armada (por exemplo, ao configurar a armação ou porção "go") antes que os destinos completem o processamento de modo que a fonte possa acionar e iniciar o processamento do próximo quadro 236 assim que os destinos alvejados se tornarem ociosos. Durante o intervalo de supressão vertical 232, as unidades de processamento podem ser configuradas e configurada para o próximo quadro 236 com o uso dos bancos de registro especificados pelo registro go correspondente à fonte antes que os dados de entrada de sensor chegue. A título de exemplo, apenas, armazenamentos temporários de leitura usados por FEProc 150 podem ser preenchidos antes que o próximo quadro 236 chegue. Nesse caso, registros sombreados correspondentes aos bancos de registro ativos podem ser atualizados após o evento de acionamento, permitindo, assim, que um intervalo de quadro completo configure os registros duplamente armazenados temporariamente para o próximo quadro (por exemplo, após o quadro 236).

[000209] A Figura 14 ilustra um segundo caso no qual a fonte é acionada pela armação da porção go no registro go correspondente à fonte. Sob essa configuração "acionar em go", as unidades de destino alvejadas pela fonte estão prontamente ociosas e a armação da porção go é o evento de acionamento. Esse modo de acionamento pode ser utilizado para registros que não são duplamente armazenados temporariamente e, portanto, são atualizados durante o apagamento vertical (por exemplo, em oposição à atualização de um registro de sombra duplamente armazenado temporariamente durante o intervalo de quadro 234).

[000210] A Figura 15 ilustra um terceiro modo de acionamento no qual a fonte é acionada mediante a detecção do início do próximo quadro, isto é, um VSYNC ascendente. Entretanto, deve-se notar que nesse modo, se o registro go for armado (ao configurar a porção go) após o próximo quadro 236 já ter iniciado o processamento, a fonte usará os destinos-alvo e os bancos de registro correspondentes para o quadro anterior, já que os campos CurrVld e CurrBk não são atualizados antes de o destino iniciar o processamento. Isso não deixa nenhum intervalo de supressão vertical para configurar as unidades de processamento de destino e pode, potencialmente, resultar em quadros abandonados, particularmente ao operar em um modo de sensor duplo. Deve-se notar, entretanto, que esse modo pode, ainda assim, resultar na operação precisa se o conjunto de circuitos de processamento de imagem 32 estiver operando em um modo de sensor único que usa os mesmos bancos de registro para cada quadro (por exemplo, o destino (NextVld) e os bancos de registro (NextBk) não mudam).

[000211] Com referência, agora, à Figura 16, um registro de controle (ou "registro go") 214 é ilustrado com mais detalhes. O registro go 214 inclui a porção de armação "go" 238, assim como o campo NextVld 216 e o campo NextBk 218. Conforme discutido acima, cada fonte (por exemplo, Sens0, Sens1, Sens0DMA, Sens1DMA ou ProcInDMA) da front-end de ISP 80 pode ter um registro go correspondente 214. Em uma modalidade, a porção go 238 pode ser um campo de bit único e o registro go 214 pode ser armado ao configurar a porção go 238 para 1. O campo NextVld 216 pode conter um número de bits correspondente ao número de destinos na front-end de ISP 80. Por exemplo, na modalidade mostrada na Figura 10, a front-end de ISP inclui seis destinos: Sif0DMA, Sif1DMA, StatsPipe0, StatsPipe1, FEProc e FEOut. Portanto, o registro go 214 pode incluir seis bits no campo NextVld 216, com um bit correspondente a cada destino e em que os destinos alvejados são configurados para 1. De modo similar, o campo NextBk 216 pode conter um número de bits correspondente ao número de registros de dados na front-end de ISP 80. Por exemplo, conforme discutido acima, a modalidade da front-end de ISP 80 mostrada na Figura 10 pode incluir sete registros de dados: SIf0, SIf1, StatsPipe0, StatsPipe1, ProcPipe, FEOut e ProcIn. Em conformidade, o campo NextBk 218 pode incluir sete bits, com um bit correspondente a cada registro de dados e em que os registros de dados correspondentes ao Banco 0 e 1 são selecionados ao configurar seus respectivos valores de bit para 0 ou 1, respectivamente. Portanto, com o uso do registro go 214, a fonte, mediante acionamento, sabe precisamente quais unidades de destino estão para receber dados de quadro e quais bancos de registro devem ser usados para configurar as unidades de destino alvejadas.

[000212] Adicionalmente, devido à configuração de sensor dupla apoiada pelo conjunto de circuitos de ISP 32, a front-end de ISP pode operar em um modo de configuração de sensor único (por exemplo, apenas um sensor está obtendo dados) e um modo de configuração de sensor dupla (por exemplo, ambos os sensores estão obtendo dados). Em uma configuração de sensor único típica, dados de entrada a partir de uma interface de sensor, como Sens0, são enviados para StatsPipe0 (para o processamentos de estatística) e FEProc (para processamento de pixel). Ademais, os quadros de sensor também podem ser enviados à memória (SIf0DMA) para processamento futuro, conforme discutido acima.

[000213] Um exemplo de como os campos NextVld correspondentes a cada fonte da front-end de ISP 80 podem ser configurados ao operar em um modo de sensor único é mostrado abaixo, na Tabela 2.

Tabela 2 - Exemplo de NextVld por fonte: modo de sensor único

[000214] Conforme discutido acima, com referência à Tabela 1, a front-end de ISP 80 pode ser configurada de modo que apenas certos destinos sejam válidos para uma fonte particular. Assim, os destinos na Tabela 2 marcados com "X" são destinados a indicar que a front-end de ISP 80 não é configurada para permitir que uma fonte particular envie dados de quadro para aquele destino. Para tais destinos, os bits do campo NextVld da fonte correspondente particular para aquele destino podem sempre ser 0. Deve-se compreender, entretanto, que isso é meramente uma modalidade e, de fato, em outras modalidades, a frontend de ISP 80 pode ser configurada de modo que cada fonte seja capaz de alvejar cada unidade de destino disponível.

[000215] A configuração mostrada acima, na Tabela 2, representa um modo de sensor único no qual apenas o Sensor0 está fornecendo dados de quadro. Por exemplo, o registro Sens0Go indica destinos como sendo SIf0DMA, StatsPipe0 e FEProc. Portanto, quando acionado, cada quadro dos dados de imagem do Sensor0 é enviado a esses três destinos. Conforme discutido acima, SIf0DMA pode armazenar quadros na memória 108 para o processamento posterior, StatsPipe0 aplica processamentos de estatística para determinar vários pontos de dados de estatística e FEProc processa o quadro com o uso, por exemplo, de filtragem temporal e filtragem de compensação de compartimentalização. Ademais, em algumas configurações em que estatísticas adicionais são desejadas (por exemplo, estatísticas em espaços de cor diferentes), StatsPipe1 também pode ser habilitado (NextVld correspondente é configurado para 1) durante o modo de sensor único. Em tais modalidades, o Sensor0 dados de quadro é enviado para ambos StatsPipe0 e StatsPipe1. Ademais, conforme mostrado na presente modalidade, apenas uma única interface de sensor (por exemplo, Sens0 ou, alternativamente, Sen0) é a única fonte ativa durante o modo de sensor único.

[000216] Com isso em mente, a Figura 17 fornece um fluxograma que mostra um método 240 para o processamento dados de quadro na frontend de ISP 80 quando apenas um único sensor está ativo (por exemplo, Sensor 0). Enquanto o método 240 ilustra, em particular, o processamento dos dados de quadro do Sensor0 por FEProc 150 como um exemplo, deve-se compreender que esse processo pode ser aplicado a qualquer outra fonte e unidade de destino correspondente na front-end de ISP 80. Iniciando na etapa 242, o Sensor0 começa a obter dados de imagem e enviar os quadros capturados para a front-end de ISP 80. A unidade de controle 190 pode inicializar a programação do registro go correspondente a Sens0 (a interface de Sensor0) para determinar destinos-alvo (incluindo FEProc) e quais registros de banco usar, conforme mostrado na etapa 244. Posteriormente, a lógica de decisão 246 determina se uma fonte evento de acionamento ocorreu. Conforme discutido acima, a entrada de dados de quadro a partir de uma interface de sensor pode utilizar modos de acionamento diferentes (Figuras 13 a 15). Se um evento de acionamento não for detectado, o processo 240 continua a esperar pelo acionamento. Uma vez que o acionamento ocorre, o próximo quadro se torna o quadro atual e é enviado para FEProc (e outros destinos-alvo) para o processamento na etapa 248. FEProc pode ser configurado com o uso de parâmetros de dados com base em um registro de dados correspondente (ProcPipe) especificado no campo NextBk do registro Sens0Go. Após processamento de o quadro atual ser concluído na etapa 250, o método 240 pode voltar à etapa 244, em que o registro Sens0Go é programado para o próximo quadro.

[000217] Quando tanto o Sensor0 e quanto o Sensor1 da front-end de ISP 80 estão ativos, os processamentos de estatística permanecem, em geral, em funcionamento, já que cada entrada de sensor pode ser processada por um respectivo bloco de estatísticas, StatsPipe0 e StatsPipe1. Entretanto, porque a modalidade ilustrada da front-end de ISP 80 fornece apenas uma única unidade de processamento de pixel (FEProc), FEProc pode ser configurada para alternar entre processamento de quadros correspondentes aos dados de entrada do Sensor0 e os quadros correspondentes aos dados de entrada do Sensor1. Conforme será constatado, os quadros de imagem são lidos a partir de FEProc na modalidade ilustrada para evitar uma condição na qual os dados de imagem a partir de um sensor são processados em tempo real enquanto os dados de imagem do outro sensor não são processados em tempo real. Por exemplo, conforme mostrado na Tabela 3 abaixo, que mostra uma possível configuração dos campos NextVld nos registros go para cada fonte quando a front-end de ISP 80 está operando em um modo de sensor duplo, os dados de entrada de cada sensor são enviados para a memória (SIf0DMA e SIf1DMA) e para as unidades de processamento de estatística correspondentes (StatsPipe0 e StatsPipe1).

Tabela 3 - Exemplo de NextVld por fonte: Modo de sensor duplo

[000218] Os quadros de sensor na memória são enviados para FEProc a partir da fonte de ProcInDMA, de modo que alternem entre Sensor0 e Sensor1 a uma taxa baseada em suas taxas de quadro correspondentes. Por exemplo, se o Sensor0 e o Sensor1 estiverem ambos obtendo dados de imagem a uma taxa de 30 quadros por segundo (fps), então seus quadros de sensor podem ser intercalados de maneira de um 1 para 1. Se o Sensor0 (30 fps) estiver obtendo dados de imagem a uma taxa duas vezes aquela do Sensor1 (15 fps), então a intercalação pode ser 2 para 1, por exemplo. Ou seja, dois quadros de dados de Sensor0 são lidos a partir da memória para cada quadro dos dados do Sensor1.

[000219] Com isso em mente, a Figura 18 mostra um método 252 para o processamento de dados de quadro na front-end de ISP 80 que tem dois sensores que obtêm dados de imagem simultaneamente. Na etapa 254, ambos o Sensor0 e o Sensor1 começam a obter quadros de imagem. Conforme será constatado, o Sensor0 e o Sensor1 podem obter os quadros de imagem com o uso de taxas de quadro e resoluções diferentes e assim por diante. Na etapa 256, os quadros adquiridos a partir do Sensor0 e do Sensor1 gravados na memória 108 (por exemplo, com o uso dos destinos SIf0DMA e SIf1DMA). A seguir, a fonte ProcInDMA lê os dados de quadro da memória 108 de maneira alternante, conforme indicado na etapa 258. Conforme discutido, os quadros podem alternar entre dados de Sensor0 e dados de Sensor1, dependendo da taxa de quadro na qual os dados são adquiridos. Na etapa 260, o próximo quadro de ProcInDMA é adquirido. Posteriormente, na etapa 262, os campos NextVld e NextBks do registro go correspondente à fonte, aqui ProcInDMA, são programados dependendo se o próximo quadro são dados do Sensor0 ou do Sensor1. Posteriormente, a lógica de decisão 264 determina se um evento de acionamento de fonte ocorreu. Conforme discutido acima, a entrada de dados a partir da memória pode ser acionada pela armação da porção go (por exemplo, modo de "acionamento de go"). Portanto, o acionamento pode ocorrer uma vez que a porção go do registro go for configurada como 1. Uma vez que o acionamento ocorre, o próximo quadro se torna o quadro atual e é enviado para FEProc para processamento na etapa 266. Conforme discutido acima, FEProc pode ser configurado com o uso de parâmetros de dados com base em um registro de dados correspondente (ProcPipe) especificado no campo NextBk do registro ProcInDMAGo. Após processamento de o quadro atual ser concluído na etapa 268, o método 252 pode voltar à etapa 260 e continuar.

[000220] Um evento operacional adicional para o qual a front-end de ISP 80 é configurada para manejar é uma mudança de configuração durante o processamento de imagem. Por exemplo, tal evento pode ocorrer quando a front-end de ISP 80 transita de uma configuração de sensor único para uma configuração de sensor dupla, ou vice-versa. Conforme discutido acima, os campos de NextVld para certas fontes podem ser diferentes, dependendo de se um ou ambos os sensores de imagem estão ativos. Portanto, quando o a configuração de sensor é modificada, a unidade de controle da front-end de ISP 190 pode liberar todas as unidades de destino antes que sejam alvejadas por uma nova fonte. Isso pode evitar configurações inválidas (por exemplo, designar múltiplas fontes para um destino). Em uma modalidade, a liberação das unidades de destino pode ser realizada ao configurar os campos de NextVld de todos os registros go para 0, desabilitando, assim, todos os destinos e armando a porção go. Após as unidades de destino serem liberadas, os registros go podem ser reconfigurados, dependendo do modo de sensor atual e o processamento de imagem pode continuar.

[000221] Um método 270 para comutar entre as configurações de sensor única e dupla é mostrado na Figura 19, de acordo com uma modalidade. Iniciando na etapa 272, um próximo quadro de dados de imagem a partir de uma fonte particular da front-end de ISP 80 é identificado. Na etapa 274, os destinos-alvo (NextVld) são programados no registro go correspondente à fonte. A seguir, na etapa 276, dependendo dos destinos-alvo, NextBk é programado para apontar para os registros de dados corretos associados aos destinos-alvo. Posteriormente, a lógica de decisão 278 determina se um evento de acionamento de fonte ocorreu. Uma vez que o acionamento ocorreu, o próximo quadro é enviado para as unidades de destino especificadas por NextVld e processadas pelas unidades de destino com o uso dos registros de dados correspondentes especificados por NextBk, conforme mostrado na etapa 280. O processamento continua até a etapa 282, na qual o processamento do quadro atual é concluído.

[000222] Subsequentemente, a lógica de decisão 284 determina se há uma mudança nos destinos-alvo para a fonte. Conforme discutido acima, os ajustes de NextVld dos registros go correspondentes a Sens0 e Sens1 podem variar, dependendo em se um sensor ou dois sensores estão ativos. Por exemplo, com referencia à Tabela 2, se apenas o Sensor0 estiver ativo, os dados de Sensor0 são enviados para SIf0DMA, StatsPipe0 e FEProc. Entretanto, com referência à Tabela 3, se ambos o Sensor0 e o Sensor1 estiverem ativos, então os dados do Sensor0 não são enviados diretamente para FEProc. Em vez disso, conforme mencionado acima, os dados do Sensor0 e do Sensor1 são gravados na memória 108 e são lidos para FEProc de maneira alternante pela fonte ProcInDMA. Portanto, se nenhuma mudança de destino-alvo for detectada na lógica de decisão 284, a unidade de controle 190 deduz que a configuração de sensor não mudou e o método 270 volta para a etapa 276, em que o campo NextBk da fonte registro go é programado para apontar para os registros de dados corretos para o próximo quadro e continuar.

[000223] Entretanto, se uma mudança de destino for detectada na lógica de decisão 28, então a unidade de controle 190 determina que ocorreu uma mudança de configuração de sensor. Por exemplo, isso poderia representar a comutação do modo de sensor único para o modo de sensor duplo ou a desativação dos sensores em geral. Em conformidade, o método 270 continua para a etapa 286, em que todos os bits dos campos NextVld para todos os registros go são configurados para 0, desabilitando, assim, com eficácia o envio dos quadros para qualquer destino no próximo acionamento. Então, na lógica de decisão 288, uma determinação é realizada em relação a se todas as unidades de destino têm transição para um estado ocioso. Se não, o método 270 espera na lógica de decisão 288 até que todas as unidades de destino concluíram suas operações atuais. A seguir, na lógica de decisão 290, uma determinação é realizada em relação a se o processamento de imagem deve continuar. Por exemplo, se a mudança de destino representou a desativação de ambos o Sensor0 e o Sensor1, então o processamento de imagem termina na etapa 292. Entretanto, se foi determinado que o processamento de imagem deve continuar, então o método 270 volta à etapa 274 e os campos NextVld dos registros go são programados de acordo com o modo de operação atual (por exemplo, sensor único ou sensor duplo). Conforme mostrado no presente documento, as etapas 284 a 292 para limpar os registros go e os campos de destino podem ser chamados, coletivamente, pelo número de referência 294.

[000224] Em seguida, A Figura 20 mostra uma modalidade adicional por meio do fluxograma (método 296) que fornece outro modo de sensor duplo de operação. O método 296 mostra uma condição em que um sensor (por exemplo, Sensor0) está ativamente obtendo dados de imagem e enviando os quadros de imagem para FEProc 150 para processamento, enquanto também envia os quadros de imagem para StatsPipe0 e/ou memória 108 (Sif0DMA), enquanto o outro sensor (por exemplo, Sensor1) está inativo (por exemplo, desativado), conforme mostrado na etapa 298. A lógica de decisão 300 detecta, então, uma condição na qual o Sensor1 se tornará ativo no próximo quadro para enviar dados de imagem para FEProc. Se essa condição não for cumprida, então o método 296 volta para a etapa 298. Entretanto, se essa condição for cumprida, então o método 296 prossegue ao realizar a ação 294 (coletivamente, as etapas 284 a 292 da Figura 19), através da qual os campos de destino das fontes são limpos e reconfigurados na etapa 294. Por exemplo, na etapa 294, o campo NextVld do registro go associado ao Sensor1 pode ser programado para especificar FEProc como um destino, assim como StatsPipe1 e/ou memória (Sif1DMA), enquanto o campo NextVld do registro go associado ao Sensor0 pode ser programado para limpar FEProc como um destino. Nessa modalidade, embora os quadros capturados pelo Sensor0 não sejam enviados para FEProc no próximo quadro, o Sensor0 pode permanecer ativo e continuar a enviar seus quadros de imagem para StatsPipe0, conforme mostrado na etapa 302, enquanto o Sensor1 captura e envia os dados para FEProc para o processamento na etapa 304. Portanto, ambos os sensores, Sensor0 e Sensor1, podem continuar a operar nesse modo de "sensor duplo", embora apenas quadros de imagem a partir de um sensor sejam enviados para FEProc para processamento. Para o propósito desse exemplo, um sensor que envia quadros para FEProc para processamento pode ser referido como um "sensor ativo", um sensor que não esta enviando quadro FEProc mas ainda está enviando dados para as unidades de processamentos de estatística pode ser chamado de um "sensor semiativo", e um sensor que não esta obtendo nenhum dado pode ser chamado de "sensor inativo."

[000225] Um benefício da técnica precedente é que, como as estatísticas continuam a ser adquiridas para o sensor semiativo (Sensor0), da próxima vez em que o sensor semiativo transitar para um estado ativo e o sensor ativo atual (Sensor1) transitar para um estado semiativo ou inativo, o sensor semiativo pode começar a adquirir dados em um quadro, já que o equilíbrio de cor e os parâmetros de exposição já podem estar disponíveis devido à coleta continuada de estatísticas de imagem. Essa técnica pode ser chamada de "comutação quente" dos sensores de imagem, e evita desvantagens associadas a "inícios frios" dos sensores de imagem (por exemplo, iniciar sem nenhuma informação de estatísticas disponível). Ademais, para economizar energia, já que cada fonte é assíncrona (conforme mencionado acima), o sensor semiativo pode operar a um relógio e/ou taxa de quadro reduzido durante o período semiativo.

[000226] Antes de continuar com uma descrição mais detalhada dos processamentos de estatística e operações de processamento de pixel mostradas na lógica de front-end de ISP 80 da Figura 10, acredita-se que uma breve introdução em relação a diversos tipos de memória que tratam de formatos que podem ser usados em conjunto com as técnicas aqui apresentadas, assim como uma definição de várias regiões de quadro de ISP, auxiliar uma melhor compreensão da presente matéria.

[000227] Com referência, agora, às Figuras 21 e 22, um modo de tratamento linear e um modo de tratamento lado a lado que pode ser aplicado aos dados de pixel recebido do(s) sensor(es) de imagem 90 e armazenado na memória (por exemplo, 108) são ilustrados, respectivamente. A modalidade retratada pode ser baseada em um tamanho de solicitação de bloco de interface de hospedeiro de 64 bytes. Conforme será constatado, outras modalidades podem utilizar tamanhos de solicitação de bloco diferentes (por exemplo, 32 bytes, 128 bytes e assim por diante). No modo de tratamento linear mostrado na Figura 21, amostras de imagem estão localizadas na memória em ordem sequencial. O termo "distância linear" especifica a distância em bytes entre 2 pixels verticais adjacentes. No presente exemplo, o endereço base de início de um plano plane é alinhado a um limite de 64-byte e a distância linear pode ser um múltiplo de 64 (com base no tamanho da solicitação do bloco).

[000228] No exemplo de um formato de modo lado a lado, conforme mostrado na Figura 22, as amostras de imagem são primeiramente dispostas sequencialmente em "azulejos," que são, então, armazenados na memória sequencialmente. Na modalidade ilustrada, cada azulejo pode ser de 256 bytes de largura e 16 fileiras de altura. O termo "distância de azulejo" deveria ser compreendido como se referindo à distância em bytes entre 2 azulejos verticais adjacentes. No presente exemplo, o endereço base de início de um plano em modo em azulejos é alinhado a um limite de 4.096 byte (por exemplo, o tamanho de um azulejo) e a distância de azulejo pode ser um múltiplo de 4.096.

[000229] Com isso em mente, várias regiões de quadro que podem ser definidas em um quadro de fonte de imagem são ilustradas na Figura 23. O formato para um quadro de fonte fornecido ao conjunto de circuitos de processamento de imagem 32 pode usar os modos de tratamento lado a lado ou linear discutidos acima, assim como pode utilizar os formatos de pixel em precisão de 8, 10, 12, 14 ou 16 bits. O quadro de fonte de imagem 306, conforme mostrado na Figura 23, pode incluir uma região de quadro de sensor 308, uma região de quadro bruto 308 e uma região ativa 310. O quadro de sensor 308 é, em geral, o tamanho de quadro máximo que o sensor de imagem 90 pode fornecer ao conjunto de circuitos de processamento de imagem 32. A região de quadro bruto 310 pode ser definida como a região do quadro de sensor 308 que é enviada à lógica de processamento de front-end de ISP 80. A região ativa 312 pode ser definida como uma porção do quadro de fonte 306, tipicamente na região de quadro bruto 310, na qual o processamento é realizado para uma operação de processamento de imagem particular. De acordo com as modalidades da presente técnica, aquela região ativa 312 pode ser igual ou diferente para operações de processamento de imagem diferentes.

[000230] De acordo com aspectos da presente técnica, a lógica de front-end de ISP 80 recebe apenas o quadro bruto 310. Portanto, para fins da presente discussão, o tamanho de quadro global para a lógica de processamento de front-end de ISP 80 pode ser presumido como o tamanho de quadro bruto, conforme determinado pela largura 314 e altura 316. Em algumas modalidades, o deslocamento dos limites do quadro de sensor 308 para o quadro bruto 310 pode ser determinado e/ou mantido pela lógica de controle 84. Por exemplo, a lógica de controle 84 pode incluir firmware que pode determinar a região de quadro bruto 310 com base em parâmetros de entrada, como o deslocamento x 318 e o deslocamento y 320, que são especificados em relação ao quadro de sensor 308. Ademais, em alguns casos, uma unidade de processamento na lógica de front-end de ISP 80 ou a lógica de pipe de ISP 82 pode ter uma região ativa definida, de modo que os pixels no quadro bruto, mas fora da região ativa 312, não serão processados, isto é, deixados descarregados. Por exemplo, uma região ativa 312 para uma unidade de processamento particular que tem uma largura 322 e altura 324 pode ser definida com base em um deslocamento x 326 e deslocamento y 328 em relação ao quadro bruto 310. Ademais, onde uma região ativa não é especificamente definida, uma modalidade do conjunto de circuitos de processamento de imagem 32 pode presumir que a região ativa 312 é igual ao quadro bruto 310 (por exemplo, deslocamento x 326 e deslocamento y 328 são ambos iguais a 0). Portanto, para fins de operações de processamento de imagem realizadas nos dados de imagem, as condições limite podem ser definidas em relação aos limites do quadro bruto 310 ou região ativa 312. Adicionalmente, em algumas modalidades, uma janela (quadro) pode ser especificada ao identificar um local de início e de fim na memória, em vez de um local de início e informações de tamanho de janela.

[000231] Em algumas modalidades, a unidade de processamento de front-end de ISP (FEProc) 80 também pode suportar o processamento de um quadro de imagem por meio de tiras verticais sobrepostas, conforme mostrado na Figura 24. Por exemplo, o processamento de imagem no presente exemplo pode ocorrer em três passadas, com uma tira esquerda (Stripe0), uma tira do meio (Stripe1) e uma tira direita (Stripe2). Isso pode permitir que a unidade de processamento de frontend de ISP 80 processe uma imagem mais larga em múltiplos passos sem a necessidade de aumentar o tamanho de armazenamento temporário da linha. Essa técnica pode ser chamada de "tratamento de distância".

[000232] Quando ocorre o processamento de um quadro de imagem por múltiplas tiras verticais, o quadro de entrada é lido com alguma sobreposição para permitir sobreposição de contexto de filtro o suficiente de modo que haja pouca ou nenhuma diferença entre a leitura da imagem em múltiplos passadas versos uma única passada. Por exemplo, no presente exemplo, a Stripe0 com uma largura SrcWidth0 e a Stripe1 com uma largura SrcWidth1, se sobrepõem parcialmente, conforme indicado pela região de sobreposição 330. De modo similar, a Stripe1 também se sobrepõe no lado direito à Stripe2 que tem uma largura de SrcWidth2, conforme indicado pela região de sobreposição 332. No presente documento, a distância total é a soma da largura de cada tira (SrcWidth0, SrcWidth1, SrcWidth2) menos as larguras (334, 336) das regiões de sobreposição 330 e 332. Ao gravar o quadro de imagem na memória (por exemplo, 108), uma região de emissão ativa é definida e apenas dados dentro da região ativa de emissão são gravados. Conforme mostrado na Figura 24, em uma gravação na memória, cada tira é gravada com base em larguras que não se sobrepõem de ActiveDst0, ActiveDst1 e ActiveDst2.

[000233] Conforme discutido acima, o conjunto de circuitos de processamento de imagem 32 pode receber dados de imagem diretamente de uma interface de sensor (por exemplo, 94) ou pode receber dados de imagem da memória 108 (por exemplo, DMA memória). Onde os dados de entrada são fornecidos a partir da memória, o conjunto de circuitos de processamento de imagem 32 e a lógica de processamento de front-end de ISP 80 podem ser configurados para fornecer permutação de byte, em que os dados de pixel de entrada a partir da memória podem ser permutados em byte antes do processamento. Em uma modalidade, um código de permutação pode ser usado para indicar se palavras duplas adjacentes, palavras, meias palavras ou bytes de dados de entrada a partir da memória são permutados. Por exemplo, com referência à Figura 25, a permutação de byte pode ser realizada em um conjunto de dados de 16 bytes (bytes 0 a 15) com o uso de um código de permutação de quatro bits.

[000234] Conforme mostrado, o código de permutação pode incluir quatro bits, que podem ser chamados de bit3, bit2, bit1 e bit0, da esquerda para a direita. Quando todos os bits são configurados para 0, conforme mostrado pelo número de referência 338, nenhuma permutação de byte é realizada. Quando o bit3 é configurado para 1, conforme mostrado pelo número de referência 340, palavras duplas (por exemplo, 8 bytes) são permutadas. Por exemplo, conforme mostrado na Figura 25, a palavra dupla representadas pelos bytes 0 a 7 é permutada com a palavra dupla representada pelos bytes 8-15. Se o bit2 for configurado para 1, conforme mostrado pelo número de referência 342, a permutação de palavra (por exemplo, 4 bytes) é realizada. No exemplo ilustrado, isso pode resultar na palavra representada pelos bytes 8-11 que são permutados com a palavra representada pelos bytes 12 a 15 e a palavra representada pelos bytes 0 a 3 que são permutados com a palavra representada pelos bytes 4 a 7. Similarmente, se o bit1 for configurado para 1, conforme mostrado pelo número de referência 344, então a permutação de meia palavra (por exemplo, 2 bytes) é realizada (por exemplo, bytes 0 a 1 permutados com os bytes 2-3, etc.) e se o bit0 for configurado para 1, conforme mostrado pelo número de referência 346, então a permutação de byte é realizada.

[000235] Na presente modalidade, a permutação pode ser realizada ao avaliar os bits 3, 2, 1 e 0 do código de permutação de maneira ordenada. Por exemplo, se os bits 3 e 2 forem configurados para um valor de 1, então a permutação de palavra dupla (bit3) é primeiramente realizada, seguida pela permutação de palavra (bit2). Portanto, conforme mostrado na Figura 25, quando o código de permutação é configurado para "1111," o resultado final são os dados de entrada sendo permutados do formato little endian para o formato big endian.

[000236] A seguir, vários formatos de memória para dados de pixel de imagem que podem ser suportados pelo conjunto de circuitos de processamento de imagem 32 para os dados de imagem brutos (por exemplo, dados de RGB Bayer), dados de cor de RGB, e YUV (YCC, dados de luma/croma) são discutidos com mais detalhes de acordo com certas modalidades apresentadas. Primeiramente, formatos para pixels de imagem bruta (por exemplo, dados de Bayer anteriormente à interpolação) em um quadro de destino/fonte que podem ser suportados pelas modalidades do conjunto de circuitos de processamento de imagem 32 são discutidos. Conforme mencionado, certas modalidades podem suportar o processamento de pixels de imagem em precisão de 8, 10, 12, 14 e 16 bits. No contexto dos dados de imagem brutos, os formatos de pixel bruto de 8, 10, 12, 14 e 16 bits podem ser referidos, no presente documento, como formatos RAW8, RAW10, RAW12, RAW14 e RAW16, respectivamente. Exemplos que mostram como cada um dentre os formatos RAW8, RAW10, RAW12, RAW14 e RAW16 podem ser armazenados na memória são mostrados como formas não empacotadas graficamente na Figura 26. Para formatos de imagem bruta que têm uma precisão de bit maior que 8 bits (e não sendo múltiplo de 8 bits), os dados de pixel também podem ser armazenados nos formatos empacotados. Por exemplo, a Figura 27 mostra um exemplo de como os pixels RAW10 de imagem podem ser armazenados na memória. De modo similar, a Figura 28 e a Figura 29 ilustram exemplos através dos quais pixels de imagem RAW12 e RAW14 podem ser armazenados na memória. Conforme será adicionalmente discutido abaixo, quando os dados de imagem estão sendo gravados em/lidos da memória, um registro de controle associado à interface de sensor 94 pode definir o formato de pixel destino/fonte, se o pixel está em um formato empacotado ou não, o formato de tratamento (por exemplo, linear ou lado a lado) e o código de permutação. Portanto, a maneira na qual os dados de pixel são lidos e interpretados pelo conjunto de circuitos de processamento de ISP 32 pode depender do formato de pixel.

[000237] O conjunto de circuitos de processamento de sinal de imagem (ISP) 32 também pode suportar certos formatos de pixels de cor de RGB no quadro de fonte/destino de interface de sensor (por exemplo, 310). Por exemplo, quadros de imagem de RGB podem ser recebidos a partir da interface de sensor (por exemplo, em modalidades em que a interface de sensor inclui lógica de interpolação a bordo) e gravados na memória 108. Em uma modalidade, a lógica de processamento de front-end de ISP 80 (FEProc) pode desviar os processamentos de estatística e pixel quando os quadros de RGB estão sendo recebidos. A título de exemplo, apenas, o conjunto de circuitos de processamento de imagem 32 pode suportar os seguintes formatos de pixel de RGB: RGB-565 e RGB-888. Um exemplo de como dados de pixel de RGB-565 podem ser armazenados na memória é mostrado na Figura 30. Conforme ilustrado, o formato de RGB-565 pode fornecer um plano de um componente de cor vermelho de 5 bit intercalado, componente de cor verde de 6 bits e componente de cor azul de 5 bits em ordem de RGB. Portanto, o total de 16 bits pode ser usado para representar um pixel de RGB-565 (por exemplo, {R0, G0, B0} ou {R1, G1, B1}).

[000238] Um formato de RGB-888, conforme mostrado na Figura 31, pode incluir um plano de componentes de cor vermelho, verde e azul de 8 bits intercalados em ordem de RGB. Em uma modalidade, o conjunto de circuitos de ISP 32 também pode suportar um formato de RGB-666, que, em geral, fornece um plano de componentes de cor vermelho, verde e azul de 6 bits intercalados em ordem de RGB. Em tal modalidade, quando um formato RGB-666 é selecionado, os dados de pixel de RGB-666 podem ser armazenados na memória com o uso do formato de RGB-888 mostrado na Figura 31, mas com cada pixel deixado justificado e os dois bits menos significativos (LSB) configurados como zero.

[000239] Em certas modalidades, o conjunto de circuitos de ISP 32 também pode suportar formatos de pixel de RGB que permitem que pixels tenham uma faixa estendida e precisão de valores de ponto de flutuação. Por exemplo, em uma modalidade, o conjunto de circuitos de ISP 32 pode suportar o formato de pixel de RGB mostrado na Figura 32, em que um componente de cor vermelho (R0), verde (G0) e azul (B0) é expresso como um valor de 8 bits, com um exponente de 8 bits compartilhado (E0). Portanto, em tal modalidade, os valores reais de vermelho (R’), verde (G’) e azul (B’) definidos por R0, G0, B0 e E0 podem ser expressos como:

[000240] Esse formato de pixel pode ser referido como o formato de RGBE, que também é algumas vezes conhecido como o formato de pixel de imagem de radiância.

[000241] As Figuras 33 e 34 ilustram formatos de pixel de RGB adicionais que podem ser suportados pelo conjunto de circuitos de ISP 32. Particularmente, a Figura 33 mostra um formato de pixel que pode armazenar componentes de vermelho, verde e azul de 9 bits com um exponente compartilhado de 5 bits. Por exemplo, os oito bits superiores [8:1] de cada pixel vermelho, verde e azul estão armazenados em bytes respectivos na memória. Um byte adicional é usado para armazenar o exponente de 5 bits (por exemplo, E0[4:0]) e o bit menos significativo [0] de cada pixel vermelho, verde e azul. Portanto, em tal modalidade, os valores reais de vermelho (R’), verde (G’) e azul (B’) definidos por R0, G0, B0 e E0 podem ser expressos como:

[000242] Ademais, o formato de pixel ilustrado na Figura 33 também é flexível no que pode ser compatível com o formato de RGB-888 mostrado na Figura 31. Por exemplo, em algumas modalidades, o conjunto de circuitos de processamento de ISP 32 pode processar os valores de RGB completos com o componente exponencial, ou também pode processar apenas a porção de 8 bits superior [7:1] de cada componente de cor de RGB de maneira similar ao formato de RGB-888.

[000243] A Figura 34 mostra um formato de pixel que pode armazenar componentes de vermelho, verde e azul de 10 bits com um exponente compartilhado de 2 bits. Por exemplo, os 8 bits superiores [9:2] de cada pixel vermelho, verde e azul estão armazenados em bytes respectivos na memória. Um byte adicional é usado para armazenar o exponente de 2 bits (por exemplo, E0[1:0]) e os 2 bits menos significativos [1:0] de cada pixel vermelho, verde e azul. Portanto, em tal modalidade, os valores reais de vermelho (R’), verde (G’) e azul (B’) definidos por R0, G0, B0 e E0 podem ser expressos como:

[000244] Adicionalmente, como o formato de pixel mostrado na Figura 33, o formato de pixel ilustrado na Figura 34 também é flexível no que pode ser compatível com o formato de RGB-888 mostrado na Figura 31. Por exemplo, em algumas modalidades, o conjunto de circuitos de processamento de ISP 32 pode processar os valores de RGB totais com o componente de exponencial ou também pode processar apenas a porção de 8 bits superior (por exemplo, [9:2]) de cada componente de cor de RGB de maneira similar ao formato de RGB-888.

[000245] O conjunto de circuitos de ISP 32 também pode suportar, adicionalmente, certos formatos de pixels de YCbCr (YUV) luma e croma no quadro de fonte/destino de interface de sensor (por exemplo, 310). Por exemplo, os quadros de imagem YCbCr podem ser recebidos a partir da interface de sensor (por exemplo, nas modalidades em que a interface de sensor inclui lógica de interpolação embutida e lógica configurada para converter dados de imagem de RGB em um espaço de cor de YCC) e gravados na memória 108. Em uma modalidade, a lógica de processamento de front-end de ISP 80 pode desviar o pixel e os processamentos de estatística quando os quadros de YCbCr sendo recebidos. A título de exemplo, apenas, o conjunto de circuitos de processamento de imagem 32 pode suportar o seguinte formato de YCbCr de pixels: YCbCr-4:2:0 8, de 2 planos; e YCbCr-4:2:2 8, de 1 plano.

[000246] O formato de pixel de YCbCr-4:2:0, de 2 planos pode fornecer dois planos de imagem separados na memória, uma para pixels de luma (Y) e um para pixels de croma (Cb, Cr), em que o plano de croma intercala as amostras de pixel Cb e Cr. Adicionalmente, o plano de croma pode ser subamostrado por metade tanto nas direções horizontal (x) e vertical (y). Um exemplo que mostra como dados de YCbCr-4:2:0, 2 planos, podem ser armazenados na memória é mostrado na Figura 35, que mostra um plano de luma 347 para armazenar as amostras de luma (Y) e um plano de croma para armazenar amostras de croma 348 (Cb, Cr). Um formato de plano YCbCr-4:2:2 8, de 1 plano, que é mostrado na Figura 36, pode incluir um plano de imagem de amostras de pixel de luma (Y) e croma (Cb, Cr) intercaladas, sendo que as amostras de croma são subamostradas por metade de ambas as direções horizontal (x) e vertical (y). Em algumas modalidades, o conjunto de circuitos de ISP 32 também pode suportar formatos de pixel de YCbCr de 10 pixels ao gravar as amostras de pixel na memória com o uso do formato de 8 bits descrito acima com arredondamento (por exemplo, os dois menos significativos dos bits dos dados de 10 bits são arredondados). Ademais, conforme será constatado, os valores de YC1C2 também podem ser armazenados como uso de qualquer um dos formatos de pixel de RGB discutidos acima nas Figuras 30 a 34, sendo que cada um dentre os componentes Y, C1 e C2 está armazenado de maneira análoga a um componente de R, G e B.

[000247] Com referência novamente para a lógica de processamento de front-end de ISP 80 mostrada na Figura 10, vários canais de leitura e gravação na memória 108 são fornecidos. Em uma modalidade, os canais de leitura/gravação podem compartilhar um barramento de dados comum, que pode ser fornecido com o uso de Arquitetura de Barramento de Microcontrolador Avançado, como um barramento de Interface Extensível Avançada (AXI), ou qualquer outro tipo adequado de barramento (AHB, ASB, APB, ATB, etc.). Dependendo das informações do quadro de imagem (por exemplo, formato de pixel, formato de tratamento, método de empacotamento) que, conforme discutido acima, podem ser determinadas através de um registro de controle, um bloco de geração de endereço, que pode ser implantado como parte da lógica de controle 84, pode ser configurado para fornecer endereço e romper informações de tamanho à interface de barramento. A título de exemplo, o calculo de tratamento pode depender de vários parâmetros, como se os dados de pixel são empacotados ou não, os dados de formato de pixel (por exemplo, formatos RAW8, RAW10, RAW12, RAW14, RAW16, RGB ou YCbCr/YUV), se o formato de tratamento lado a lado ou linear foi usado, deslocamentos x e y dos dados de quadro de imagem em relação à matriz de memória, assim como largura, altura e distância de quadro. Parâmetros adicionais que podem ser usados no cálculo de tratamentos de pixel podem incluir valores de unidade de pixel mínimos (MPU), máscaras de deslocamento, um valor de byte por MPU (BPPU), e um Log2 de valor de MPU (L2MPU). A Tabela 4, que é mostrada abaixo, ilustra os parâmetros supracitados para os formatos de pixel empacotados e não empacotados, de acordo com uma modalidade.

Tabela 4 - Parâmetros de cálculo de tratamento de pixel (MPU, L2MPU, BPPU)

[000248] Conforme será compreendido, os ajustes da MPU e da BPPU permitem que o conjunto de circuitos de ISP 32 avalie o número de pixels que precisam ser lidos para ler um pixel, mesmo que nem todos os dados lidos sejam necessários. Ou seja, os ajustes de MPU e de BPPU podem permitir que o conjunto de circuitos de ISP 32 lido nos dados de formato de pixels que estão ambos alinhados com (por exemplo, um múltiplo de 8 bits (1 byte) é usado para armazenar um valor de pixel) e desalinhados do byte de memória (por exemplo, valores de pixel estão armazenados com o uso de menos ou mais que um múltiplo de 8 bits (1 byte), isto é, RAW10, RAW12, etc.).

[000249] Com referência à Figura 37, um exemplo que mostra o local de um quadro de imagem 350 armazenado na memória sob tratamento linear é ilustrado, em que cada bloco representa 64 bytes (conforme discutido acima na Figura 21). Em uma modalidade, o pseudo-código a seguir ilustra um processo que pode ser implantado pela lógica de controle para identificar um bloco de início e uma largura de bloco do quadro armazenado em tratamento linear:

[000250] Em que Stride representa as distâncias do quadro em bytes e é um múltiplo de 64. Por exemplo, na Figura 37, SrcStride e DstStride são 4, o que significa que 4 blocos de 64 bytes. Com referência à Tabela 4 acima, os valores para L2MPU e BPPU podem depender do formato dos pixels no quadro 350. Conforme mostrado, uma vez que o BlockOffsetX é conhecido, BlockStart pode ser determinado. BlockWidth pode, subsequentemente, ser determinada com o uso de BlockOffsetX e LastBlockX, que põem ser determinados com o uso dos valores de L2MPU e BPPU correspondentes ao formato de pixel do quadro 350.

[000251] Um exemplo similar sob tratamento lado a lado é mostrado na Figura 38, em que o quadro de fonte de imagem, chamado, no presente documento, pelo número de referência 352, é armazenado na memória e sobrepõe uma porção do Tile0, Tile 1, Tile n, e Tile n+1. Em uma modalidade, o seguinte pseudo-código ilustra um processo que pode ser implantado pela lógica de controle para identificar um bloco de início e a largura de bloco do quadro armazenado no tratamento lado a lado

[000252] No cálculo retratado acima, a expressão "(OffsetY>>4)*(Stride>>6)" pode representar o número de blocos para se alcançar a fileira de azulejos na qual o quadro de imagem está localizado na memória. A expressão "(BlockOffsetX>>2)*64" pode representar o número de blocos que o quadro de imagem armazenado é deslocado na direção x. A expressão "OffsetY[3:0]*4" pode representar o número de blocos para se obter uma fileira em um azulejo na qual o endereço inicial do quadro de imagem está localizado. Ademais, a expressão "BlockOffsetX[1:0]" pode representar o número de blocos para se obter um deslocamento x em um azulejo correspondente ao endereço inicial do quadro de imagem. Adicionalmente, em uma modalidade ilustrada na Figura 38, o número de blocos para cada azulejo (BlocksPerTile) pode ser 64 blocos e o número de bytes por bloco (BytesPerBlock) pode ser de 64 bytes.

[000253] Conforme mostrado acima, na Tabela 4, para pixels armazenados em formatos empacotados RAW10, RAW12 e RAW14, quatro pixels compõem uma unidade de pixel mínima (MPU) de cinco, seis ou sete bytes (BPPU), respectivamente. Por exemplo, com referência ao exemplo de formato de pixel RAW10 mostrado na Figura 27, uma MPU de quatro pixels P0-P3 inclui 5 bytes, em que os 8 bits superiores de cada um dos pixels P0-P3 é armazenado em quatro bytes respectivos e os 2 bytes inferiores de cada um dos pixels são armazenados nos bits 0 a 7 do endereço de 32 bits 01h. De modo similar, com referência, novamente, à Figura 28, uma MPU de quatro pixels P0-P3 com o uso do formato RAW12 inclui 6 bytes, sendo que os 4 bits inferiores de pixels P0 e P1 são armazenados no byte correspondente aos bits 16 a 23 do endereço 00h e os 4 bits de pixels P2 e P3 mais inferiores são armazenados no byte correspondente aos bits 8 a 15 do tratamento 01h. A Figura 29 mostra uma MPU de quatro pixels P0-P3 com o uso do formato RAW14, como incluindo 7 bytes, com 4 bytes par armazenar os 8 bits superiores de cada pixel da MPU e 3 bytes para armazenar os 6 bits inferiores de cada pixel da MPU.

[000254] Com o uso desses formatos de pixel, é possível, ao final de uma linha de quadro, ter uma MPU parcial em que menos que quatro pixels da MPU são usados (por exemplo, quando o módulo de largura de linha quatro é não zero). Ao ler uma MPU parcial, pixels não usados podem ser ignorados. Similarmente, ao gravar uma MPU parcial a um quadro de destino, pixels não usados podem ser gravados com um valor de zero. Ademais, em alguns casos, a última MPU de uma linha de quadro pode não alinhar a um limite de bloco de 64 bytes. Em uma modalidade, os bytes após a última MPU e até o final do último bloco de 64 byte não estão gravados.

[000255] De acordo com modalidades da presente descrição, o conjunto de circuitos de ISP 32 também pode ser configurado para fornecer o manejo de sobrefluxo. Por exemplo, uma condição de sobrefluxo (também chamada de "saturação") pode ocorrer em certas situações em que a lógica de processamento de front-end de ISP 80 recebe pressão posterior a partir de sua própria unidade de processamentos interna, a partir da unidade de processamentos a jusante (por exemplo, a pipeline de ISP 82 e/ou lógica de processamento de back-end de ISP 120), ou de uma memória de destino (por exemplo, onde os dados de imagem devem ser gravados). As condições de sobrefluxo podem ocorrer quando os dados de pixel estão sendo lidos (por exemplo, seja da interface de sensor ou da memória) mais rapidamente que um ou mais blocos de processamento são capazes de processar os dados, ou mais rápido que os dados podem ser gravados em um destino (por exemplo, memória 108).

[000256] Conforme será adicionalmente discutido abaixo, a leitura e a gravação na memória podem contribuir com condições de sobrefluxo. Entretanto, já que os dados de entrada são armazenados, no caso de uma condição de sobrefluxo, o conjunto de circuitos de ISP 32 pode simplesmente atrasar a leitura dos dados de entrada até que a condição de sobrefluxo se recupere. Entretanto, quando os dados de imagem estão sendo lidos diretamente de um sensor de imagem, os dados "vivos" em geral não podem ser atrasados, já que o sensor de imagem está, em geral, adquirindo os dados de imagem in real time. Por exemplo, o sensor de imagem (por exemplo, 90) pode operar de acordo com um sinal de temporização com base em seu próprio relógio interno e pode ser configurado para emitir quadros de imagem em uma certa taxa de quadro, como 15 ou 30 quadros por segundo (fps). As entradas de sensor para o conjunto de circuitos de ISP 32 e a memória 108 podem, então, incluir filas de entrada que podem armazenar temporariamente os dados de imagem de entrada antes de seu processamento (pelo conjunto de circuitos de ISP 32) ou antes que sejam gravados na memória (por exemplo, 108). Em conformidade, se os dados de imagem estão sendo recebidos na fila de entrada mais rápido do que põem relidos da fila e processados ou armazenados (por exemplo, gravados na memória), uma condição de sobrefluxo pode ocorrer. Ou seja, se os armazenamentos temporários/filas estão cheios, pixels de entrada adicional não podem ser armazenados temporariamente e, dependendo do manejo de sobrefluxo, a técnica implantada pode ser deixada.

[000257] A Figura 39 mostra um diagrama de bloco do conjunto de circuitos de ISP 32 e foca nas características da lógica de controle 84 que podem fornecer o manejo de sobrefluxo de acordo com uma modalidade. Conforme ilustrado, os dados de imagem associados ao Sensor0 90a e ao Sensor1 90b podem ser lidos a partir da memória 108 (por meio das interfaces 174 e 176, respectivamente) para a lógica de processamento de front-end de ISP 80 (FEProc), ou podem ser fornecidos à lógica de processamento de front-end de ISP 80 diretamente a partir da respectiva interface de sensores. No último caso, dados de pixel de entrada dos sensores de imagem 90a e 90b podem ser passados para filas de entrada 400 e 402, respectivamente, antes de ser enviado para a lógica de processamento de front-end de ISP 80.

[000258] Quando uma condição de sobrefluxo ocorre, o(s) bloco(s) de processamento (por exemplo, blocos 80, 82 ou 120) ou memória (por exemplo, 108) em que o sobrefluxo ocorrido pode fornecer um sinal (conforme indicado pelos sinais 405, 407 e 408) para configurar um bit em um registro de solicitação de interrupção (IRQ) 404. Na presente modalidade, o registro de IRQ 404 pode ser implantado como parte da lógica de controle 84. Adicionalmente, registros de IRQ separados 404 podem ser implantados para cada um dentre os dados de imagem de Sensor0 e dados de imagem de Sensor1. Com base no valor armazenado no registro de IRQ 404, a lógica de controle 84 pode ser capaz de determinar quais as unidades de lógica nos blocos de processamento de ISP 80, 82, 120 ou memória 108 geradas pela condição de sobrefluxo. As unidades de lógica podem ser chamadas de "unidades de destino", já que podem constituir destinos ao quais os dados de pixel são enviados. Com base nas condições de sobrefluxo, a lógica de controle 84 também pode (por exemplo, através de manejo de firmware/software) governar quais quadros são deixados (por exemplo, ou não aso gravados à memória ou não emitem o visor para visualização).

[000259] Uma vez que uma condição de sobrefluxo é detectada, a maneira na qual o manejo de sobrefluxo é realizada pode depender de se a front-end de ISP está lendo dados de pixel da memória 108 ou das filas de sensor de imagem input (por exemplo, armazenamentos temporários) 400, 402, que podem ser filas do tipo primeiro a sair primeiro a entrar (FIFO) em uma modalidade. Em uma modalidade, quando os dados de pixel de entrada são lidos a partir da memória 108 através, por exemplo, de uma interface de DMA associada (por exemplo, 174 ou 176), a front-end de ISP atrasará a leitura dos dados de pixel se receber pressão posterior como consequência de uma condição de sobrefluxo que está sendo detectada (por exemplo, através da lógica de controle 84 com o uso do registro de IRQ 404) a partir de quaisquer blocos de destino a jusante que possam incluir a pipeline de ISP 82, a lógica de processamento de back-end de ISP 120 ou a memória 108 em casos em que a saída da lógica de front-end de ISP 80 é gravada na memória 108. Nesse caso, a lógica de controle 84 pode evitar o sobrefluxo ao parar a leitura dos dados de pixel da memória 108 até que a condição de sobrefluxo se recupere. Por exemplo, a recuperação de sobrefluxo pode ser sinalizada quando uma unidade a jusante que causa a condição de sobrefluxo configura um bit correspondente no registro de IRQ 404, indicando que o sobrefluxo não está mais ocorrendo. Uma modalidade desse processo é, em geral, ilustrada pelas etapas 412 a 420 do método 410 da Figura 40.

[000260] Enquanto as condições de sobrefluxo podem, em geral, ser monitoradas nas filas de entrada de sensor, deve0se compreender que muitas filas adicionais podem estar presentes entre as unidades de processamentos do subsistema de ISP 32 (por exemplo, incluindo unidades internas da lógica de front-end de ISP 80, da pipeline de ISP 82, assim como a lógica de back-end de ISP 120). Adicionalmente, as várias unidades internas do subsistema de ISP 32 também podem incluir armazenamento temporário em linha, que também pode funcionar como filas. Portanto, todas as filas e armazenamento temporário em linha do subsistema de ISP 32 podem fornecer armazenamento temporário. Em conformidade , quando o último bloco de processamento em uma cadeia particular de blocos de processamento está cheio (por exemplo, seu armazenamento temporário em linha e quaisquer filas intermediárias estão cheias), pressão posterior pode ser aplicada ao bloco de processamento precedente (por exemplo, a montante) e assim por diante, de modo que a pressão posterior se propague para cima através da cadeia de lógica até que alcance a interface de sensor, onde as condições de sobrefluxo podem ser monitoradas. Assim, quando um sobrefluxo ocorre na interface de sensor, isso pode significar que todas as filas a jusante e o armazenamento temporário em linha estão cheios.

[000261] Conforme mostrado na Figura 40, o método 410 começa no bloco 412, no qual os dados de pixel para uma forma atual são lidos a partir da memória para a unidade de processamento de front-end de ISP 80. A lógica de decisão 414 determina, então, se uma condição de sobrefluxo está presente. Conforme discutido acima, isso pode ser avaliado ao determinar o estado dos bits no(s) registro(s) de IRQ 404. Se nenhuma condição de sobrefluxo for detectada, então o método 410 volta para a etapa 412 e continua a ler nos pixels a partir do quadro atual. Se uma condição de sobrefluxo for detectada pela lógica de decisão 414, o método 410 para de ler pixels do quadro atual da memória, conforme mostrado no bloco 416. A seguir, a lógica de decisão 418, determina-se se a condição de sobrefluxo se recuperou. Se a condição de sobrefluxo ainda persistir, o método 410 espera na lógica de decisão 418 até que a condição de sobrefluxo se recupere. Se a lógica de decisão 418 indicar que a condição de sobrefluxo se recuperou, então o método 410 prossegue para o bloco 420 e retoma a leitura dos dados de pixel para o quadro atual a partir da memória.

[000262] Quando uma condição de sobrefluxo ocorre enquanto a entrada de dados de pixel está sendo lida a partir da interface de sensor(s), interrupções podem indicar quais unidades a jusante (por exemplo, blocos de processamento ou memória de destino) geraram o sobrefluxo. Em uma modalidade, o manejo de sobrefluxo pode ser fornecido com base em dois cenários. Em um primeiro cenário, a condição de sobrefluxo ocorre durante um quadro de imagem, mas recupera anteriormente ao início do quadro de imagem subsequente. Nesse caso, pixels de entrada do sensor de imagem são descartados até que a condição de sobrefluxo se recupere e o espaço se torne disponível na fila de entrada correspondente ao sensor de imagem. A lógica de controle 84 pode fornecer um contador 406 que pode rastrear o número de pixels descartados e/ou quadros descartados. Quando a condição de sobrefluxo se recuperar, os pixels descartados podem ser substituídos por valores de pixel não definidos (por exemplo, todos 1’s (por exemplo, 11111111111111 para um valor de pixel de 14 bits), todos 0’s, ou um valor programado em um registro de dados que configura quais são os valores de pixel não definidos) e o processamento a jusante pode ser retomado. Em uma modalidade adicional, os pixels descartados podem ser substituídos por um pixel de não sobrefluxo anterior (por exemplo, o último "bom" pixel lido no armazenamento temporário de entrada). Isso garante que um número correto de pixels (por exemplo, um número de pixels correspondente ao número de pixels esperado em um quadro completo) é enviado para a lógica de processamento de front-end de ISP 80, habilitando, assim, a lógica de processamento de front-end de ISP 80 para emitir o número correto de pixels para o quadro que estava sendo lido a partir da fila de entrada de sensor quando ocorreu o sobrefluxo.

[000263] Enquanto o número correto de pixels pode ser emitido pela front-end de ISP nesse primeiro contexto, dependendo do número de pixels que foram descartados e substituídos durante a condição de sobrefluxo, o manejo de software (por exemplo, firmware), que pode ser implantado como parte da lógica de controle 84, pode optar por descartar (por exemplo, excluir) o quadro sendo enviado ao visor e/ou gravado na memória. Tal determinação pode se basear, por exemplo, no valor do contador de pixel descartado 406 comparado a um valor limítrofe de pixel descartado aceitável. Por exemplo, se uma condição de sobrefluxo ocorrer apenas brevemente durante o quadro de modo que apenas uma quantidade relativamente baixa de pixels seja descartada (por exemplo, e substituída por valores não definidos ou falsos; por exemplo, 10 a 20 pixels ou menos), então a lógica de controle 84 pode optar por exibir e/ou armazenar essa imagem, apesar do pequeno número de pixels descartados, ainda que a presença dos pixels de substituição possa aparecer muito brevemente como um artefato secundário na imagem resultante. Entretanto, devido ao numero baixo de pixels de substituição, tal artefato pode passar, em geral, não despercebido ou marginalmente percebido por um usuário. Ou seja, a presença de quaisquer artefatos devido aos pixels não definidos a partir da condição de sobrefluxo predefinida pode degradar de modo não significativo a qualidade estética da imagem (por exemplo, qualquer tal degradação é mínima ou negligenciável ao olho humano).

[000264] Em um segundo caso, a condição de sobrefluxo pode permanecer presente no início do quadro de imagem subsequente. Nesse caso, os pixels do quadro atual também são descartados e contados como o primeiro caso descrito acima. Entretanto, se uma condição de sobrefluxo ainda estiver presente mediante a detecção de uma borda ascendente de VSYNC (por exemplo, indicando o início de um quadro subsequente), a lógica de processamento de front-end de ISP 80 pode ser configurada para adiar o próximo quadro, descartando, assim, todo o próximo quadro. Nesse caso, o próximo quadro e os quadros subsequentes continuarão a ser descartados até que ocorra o sobrefluxo. Uma vez que o sobrefluxo se recupera, o quadro atual anterior (por exemplo, o quadro sendo lido quando o sobrefluxo foi primeiramente detectado) pode substituir seus pixels descartados pelos valores de pixel não definidos, permitindo, assim, que a lógica de frontend de ISP 80 emita o número correto de pixels para aquele quadro. Depois disso, o processamento a jusante pode ser retomado. Quanto aos quadros descartados, a lógica de controle 84 pode incluir, ainda, um contador que conta o número de quadros descartados. Esses dados podem ser usados para ajustar as temporizações para a sincronização de áudio-vídeo. Por exemplo, para o vídeo capturado em 30 fps, cada quadro tem uma duração de aproximadamente 33 milissegundos. Portanto, se três quadros são descartados devido ao sobrefluxo, então a lógica de controle 84 pode ser configurada para ajustar os parâmetros de sincronização de áudio-vídeo para dar conta de aproximadamente 99 milissegundos (33 milissegundos x 3 quadros) de duração atribuíveis aos quadros descartados. Por exemplo, para compensar pelo tempo atribuível aos quadros descartados, a lógica de controle 84 pode controlar a saída de imagem ao repetir um ou mais dos quadros anteriores.

[000265] Uma modalidade de um processo 430 que mostra os casos discutidos acima que podem ocorrer quando a entrada de dados de pixel está sendo lida a partir da interface de sensores é ilustrada na Figura 41. Conforme mostrado, o método 430 começa no bloco 432, no qual os dados de pixel para um quadro atual são lidos a partir do sensor para a unidade de processamento de front-end de ISP 80. A lógica de decisão 434 determina, então, se uma condição de sobrefluxo existe. Se não houver sobrefluxo, o método 430 continua a ler os pixels do quadro atual (por exemplo, retorna ao bloco 432). Se a lógica de decisão 434 determinar que uma condição de sobrefluxo está presente, então o método 430 continua no bloco 436, onde o próximo pixel de entrada do quadro atual é descartado. A seguir, a lógica de decisão 438 determina se o quadro atual terminou e o próximo quadro começou. Por exemplo, em uma modalidade, isso pode incluir detectar uma borda ascendente no sinal VSYNC. Se o sensor ainda estiver enviando o quadro atual, o método 430 continua para a lógica de decisão 440, que determina se a condição de sobrefluxo detectada originalmente na lógica 434 ainda está presente. Se a condição de sobrefluxo não foi recuperada, então o método 430 prossegue para o bloco 442, no qual o contador de pixel descartado é incrementado (por exemplo, para se responsabilizar pelo pixel a seguir descartado no bloco 436). O método retorna, então, para o bloco 436 e continua.

[000266] Se na lógica de decisão 438 for detectado que o quadro atual terminou e que o sensor está enviando o próximo quadro (por exemplo, aumento de VSYNC detectado), então o método 430 prossegue para o bloco 450 e todos os pixels do próximo quadro, e quadros subsequentes, são descartados contanto que a condição de sobrefluxo permaneça (por exemplo, mostrada por lógica de decisão 452). Conforme discutido acima, um contador separado pode rastrear o número de quadros descartados, que podem ser usados para ajustar os parâmetros de sincronização áudio-vídeo. Se a lógica de decisão 452 indicar que a condição de sobrefluxo se recuperou, então os pixels descartados do quadro inicial no qual a condição de sobrefluxo ocorreu primeiramente são substituídos por um número de valores de pixel não identificados correspondentes ao número de pixels descartados daquele quadro inicial, conforme indicado pelo contador de pixel descartado. Conforme mencionado acima, os valores não definidos de pixel podem ser todos 1’s, todos 0’s, um valor de substituição programado em um registro de dados, ou podem assumir o valor de um pixel anterior que foi lido anteriormente à condição de sobrefluxo (por exemplo, o último pixel lido antes da condição de sobrefluxo ser detectada). Em conformidade, isso permite que o quadro inicial seja processado com o número correto de pixels e, no bloco 446, o processamento de imagem a jusante pode continuar, o que pode incluir a gravação do quadro na memória. Conforme também foi discutido acima, dependendo do número de pixels que foram descartados no quadro, a lógica de controle 84 pode optar ou por excluir ou incluir o quadro ao emitir dados de vídeo (por exemplo, se o número de pixels descartados estiver acima ou abaixo de um limite de pixel descartado aceitável). Conforme será constatado, o manejo de sobrefluxo pode ser realizado separadamente para cada fila de entrada 400 e 402 do subsistema de ISP 32.

[000267] Outra modalidade de manejo de sobrefluxo que pode ser implantada de acordo com a presente descrição é mostrada na Figura 42 por meio de um fluxograma que mostra o método 460. Aqui, o manejo de sobrefluxo para uma condição de sobrefluxo que ocorre durante um quadro atual, mas recupera anteriormente ao final de um quadro atual é realizado da mesma maneira, conforme mostrado na Figura 41 e, portanto, aquelas etapas foram assim numeradas com números de referência similares 432 a 446. A diferença entre o método 460 da Figura 42 e o método 430 da Figura 41 concerne o manejo de sobrefluxo quando uma condição de sobrefluxo continua no próximo quadro. Por exemplo, com referência à lógica de decisão 438, quando a condição de sobrefluxo continua no próximo quadro, em vez de descartar o próximo quadro como no método 430 da Figura 41, o método 460 implanta o bloco 462, no qual o contador de pixel descartado é limpo, a fila de entrada de sensor é limpa e a lógica de controle 84 é sinalizada para descartar o quadro atual parcial. Ao limpar a fila de entrada de sensor e o contador de pixel descartado, o método 460 se prepara para adquirir o próximo quadro (que agora se torna o quadro atual), retornando o método para o bloco 432. Conforme será constatado, os pixels para este quadro atual podem ser lidos na fila de entrada de sensor. Se a condição de sobrefluxo recuperar antes que a fila de entrada se torne cheia, então o processamento a jusante é retomado. Entretanto, se a condição de sobrefluxo persistir, o método 460 continuará a partir do bloco 436 (por exemplo, começar a descartar pixels até que o sobrefluxo ou recupere ou o próximo quadro inicie).

[000268] Conforme mencionado acima, o dispositivo eletrônico 10 também pode fornecer a captura de dados de áudio (por exemplo, através de um dispositivo de captura de áudio fornecido como uma das estruturas de entrada 14) simultaneamente aos dados de imagem (por exemplo, através do dispositivo de imageamento 30 que tem sensores de imagem 90). Por exemplo, conforme mostrado diagramaticamente na Figura 43, os dados de áudio 470 e os dados de imagem 472 podem representar dados de vídeo e de áudio capturados simultaneamente pelo dispositivo eletrônico. Os dados de áudio 470 podem incluir amostras de áudio 474 capturadas através do tempo (t) e, de modo similar, os dados de imagem 472 podem representar uma série de quadros de imagem capturados através do tempo t. cada amostra dos dados de imagem 472, aqui chamadas pelo número de referência 476, pode representar um quadro de imagem parado. Portanto, quando os quadros de imagem parados são visualizados em sucessão cronológica através do tempo (por exemplo, um número particular de quadros por segundo, como 15 a 30 quadros por segundo), um visualizados perceberá a aparência de uma imagem em movimento, fornecendo, assim, dados de vídeo. Quando os dados de áudio 470 forem adquiridos e representados como dados digitais, podem ser armazenados como valores binários que representam amostras (por exemplo, 474) da amplitude do sinal de áudio em intervalos de tempo iguais. Ademais, embora seja mostrado na Figura 43 como tendo divisões distintas 474, deve-se constatar que os dados de áudio, em uma implantação prática, podem ter uma taxa de amostra que é suficientemente rápida para que o ouvido humano perceba os dados de áudio 470 como som contínuo.

[000269] Durante a reprodução dos dados de vídeo 472, os dados de áudio correspondentes 470 também podem ser reproduzidos, permitindo, assim, que um espectador não só apenas visualize os dados de vídeo de um evento capturado, mas também ouça o som correspondente ao evento capturado. Idealmente, os dados de vídeo 472 e os dados de áudio 470 são reproduzidos de maneira sincronizada. Por exemplo, se a amostra de áudio aqui designada como 474a ocorresse originalmente no tempo tA então, sob condições de reprodução ideais, um quadro de imagem originalmente capturado no tempo tA é emitido simultaneamente à amostra de áudio 474a. Entretanto, se a sincronização não for alcançada, o espectador pode perceber um atraso de tempo ou deslocamento entre os dados de áudio e de vídeo. Por exemplo, suponha que a amostra de áudio 474a seja emitida com um quadro de imagem 476c originalmente capturado no tempo t0, que é cronologicamente anterior ao tempo tA. Nesse caso, os dados de áudio 470 estão "à frente" dos dados de vídeo 472 e o usuário pode passar por um atraso entre ouvir a amostra de áudio do tempo tA e ver sua amostra de vídeo correspondente esperada (quadro de imagem 476a do tempo tA), sendo que o atraso é a diferença entre os tempos tA e t0. De modo similar, suponha que a amostra de áudio 474a seja emitida com um quadro de imagem 476b do tempo tB, que é cronologicamente posterior ao tempo tA. No último caso, os dados de áudio 470 estão "atrás"dos dados de vídeo 472 e o usuário pode passar por atraso entre ver a amostra de vídeo (476a) no tempo tA e ouvir sua amostra de áudio correspondente do tempo tA, sendo que o atraso é a diferença entre os tempos tA e tB. Esses tipos de atraso são, algumas vezes, chamados de erro de "lip-sync". Conforme será constatado, os dois últimos casos podem afetar negativamente a experiência do usuário. Para alcançar a sincronização de áudio-vídeo, um sistema é, em geral, configurado de tal modo que qualquer compensação pelos problemas de sincronização priorize o áudio em relação ao vídeo, por exemplo, se um problema de sincronização está presente, os quadros de imagem podem ser descartados ou repetidos sem alteração de áudio.

[000270] Em alguns sistemas convencionais, a sincronização de dados de áudio e de vídeo é realizada com o uso do início de interrupções de quadro (por exemplo, com base no sinal de VSYNC). Quando tal interrupção ocorre, indicando o início de um novo quadro, um processador pode executar uma rotina de serviço de interrupção para servir a interrupção (por exemplo, limpar bits), e um carimbo de data e hora correspondente a quando a interrupção é realizada pelo processador é associado àquele quadro. Conforme será constatado, há, em geral, alguma latência entre a solicitação de interrupção e o tempo no qual a interrupção é realizada pelo processador. Portanto, um carimbo de data e hora que é associado a um quadro de imagem particular pode refletir essa latência e, portanto, não representar de fato o tempo preciso no qual o quadro realmente iniciou. Adicionalmente, essa latência pode ser variável, dependendo da carga do processador e da largura de banda, que pode complicar ainda mais os problemas de sincronização de áudio-vídeo.

[000271] Conforme discutido acima, a lógica de front-end de ISP 80 pode operar em seu próprio domínio de relógio e fornecer uma interface assíncrona à interface de sensor 94 para suportar sensores de tamanhos diferentes e que têm exigências de temporização diferentes. Para fornecer a sincronização de áudio e de dados de vídeo, o conjunto de circuitos de ISP 32 pode utilizar o relógio de front-end de ISP para fornecer um contador que pode ser usado para gerar carimbos de data e hora que podem ser associados a quadros capturados de imagem. Por exemplo, com referência à Figura 44, quatro registros, incluindo um registro de configuração de temporizador 490, um registro de código de tempo 492, um registro de código de tempo de Sensor0 494 e um registro de código de tempo de Sensor1 496, todos os quais podem ser utilizados para fornecer funções de carimbo de data e hora em uma modalidade com base pelo menos parcialmente no relógio para a lógica de processamento de front-end de ISP 80. Em uma modalidade, o registro 490, 492, 494 e 496 pode incluir registros de 32 bits.

[000272] O registro de configuração de tempo 490 pode ser configurado para fornecer um valor, NClk, que pode ser usado para fornecer uma contagem para gerar códigos de carimbo de data e hora. Em uma modalidade, NClk pode ser um valor de 4 bits que varia de 0 a 15. Com base em NClk, um temporizador ou contador que indica um código de tempo atual pode ser incrementado por um valor de um a cada 2ANClk ciclos de relógio (com base no domínio de relógio de frontend de ISP). O código de tempo atual pode ser armazenado no registro de código de tempo 492, fornecendo, assim, um código de tempo com 32 bits de resolução. O registro de código de tempo 492 também pode ser reinicializado pela lógica de controle 84.

[000273] Com referência, agora, à Figura 10, para cada interface de entrada de sensor, Sif0 e Sif1, o registro de código de tempo 492 pode ser amostrado quando uma borda ascendente é detectada no sinal de sincronização vertical (VSYNC) (ou se uma borda descendente for detectada, dependendo de como VSYNC é configurado), indicando, portanto, o início de um novo quadro (por exemplo, ao final de um intervalo de supressão vertical). O código de tempo correspondente à borda ascendente do VSYNC pode ser armazenado no registro de código de tempo 494 ou 496, dependendo do sensor (Sensor0 ou Sensor1) a partir do qual o quadro de imagem é fornecido, fornecendo, assim, um carimbo de data e hora que indica o tempo no qual a captura do quadro atual iniciou. Em algumas modalidades, o sinal VSYNC do sensor pode ter um atraso programado ou programável. Por exemplo, se o primeiro pixel do quadro estiver atrasado por n ciclos de relógio, a lógica de controle 84 pode ser configurada para compensar por esse atraso, como ao fornecer um deslocamento em hardware ou usar compensação de software/firmware. Portanto, o carimbo de data e hora pode ser gerado a partir da borda ascendente do VSYNC com um atraso programado adicionado. Em outra modalidade, o carimbo de data e hora correspondente ao início de um quadro poderia ser determinado como uso da borda descendente do sinal VSYNC com um atraso programável.

[000274] Conforme o quadro atual está sendo processado, a lógica de controle 84 leu o carimbo de data e hora a partir do sensor registro de código de tempo (494 ou 496), e o carimbo de data e hora pode ser associado ao quadro de imagem de vídeo como um parâmetro nos metadados associados ao quadro de imagem. Isso é mostrado mais claramente na Figura 45, que fornece uma vista diagramática de um quadro de imagem 476 e seus metadados associados 498, que incluem o carimbo de data e hora 500 lido a partir do registro de código de tempo apropriado (por exemplo, registro 494 para o Sensor0 ou registro 496 para o Sensor1). Em uma modalidade, a lógica de controle 84 pode, então, ler o carimbo de data e hora a partir do registro de código de tempo quando acionado pelo início da interrupção de quadro. Portanto, cada quadro de imagem capturado pelo conjunto de circuitos de ISP 32 pode ter um carimbo de data e hora associado com base no sinal VSYNC. O conjunto de circuitos ou firmware de controle, que pode ser implantando como parte da lógica de controle de ISP 84 ou parte de uma unidade de controle separada do dispositivo eletrônico 10, pode usar o carimbos de data e hora de quadro de imagem para alinhar ou sincronizar um conjunto de dados de áudio correspondente, alcançando, assim, a sincronização de áudio-vídeo.

[000275] Em algumas modalidades, o dispositivo 10 pode incluir um processador de áudio configurado para manejar o processamento de dados de áudio (por exemplo, dados de áudio 470). Por exemplo, o processador de áudio pode ser uma unidade de processamento independente (por exemplo, parte do(s) processador(es) 16), ou pode ser integrado a um processador principal, ou pode ser parte de um dispositivo de processamento de sistema-em-chip. Em tais modalidades, o processador de áudio e o conjunto de circuitos de processamento de imagem 32, que pode ser controlado por um processador (por exemplo, parte da lógica de controle 84) separado do processador de áudio, pode operar com base em relógios independentes. Por exemplo, os relógios poderiam ser gerados com ouso de laços de travamento em fase separados (PLL). Portanto, para fins de sincronização de áudio-vídeo, o dispositivo 10 pode precisar ser capaz de correlacionar um carimbo de data e hora de imagem com um carimbo de data e hora de áudio. Em uma modalidade, essa correlação pode ser atingida com o uso de um processador principal do dispositivo 10 (por exemplo, uma CPU). Por exemplo, o processador principal pode sincronizar seu próprio relógio com aquele do processador de áudio e do conjunto de circuitos de ISP 32 para determinar a diferença entre os respectivos relógios do processador de áudio e do conjunto de circuitos de ISP 32. Essa diferença, uma vez conhecida, pode ser usada para correlacionar carimbos de data e hora de áudio dos dados de áudio (por exemplo, 470) com carimbos de data e hora de quadro de imagem dos dados de imagem (por exemplo, 472).

[000276] Em uma modalidade, a lógica de controle 84 também pode ser configurada para manejar condições de envolvimento, como quando o valor máximo do código de tempo de 32 bits é alcançado e em que o próximo aumento exigiria um bit adicional (por exemplo, 33 bits) para fornecer um valor preciso. Para fornecer um exemplo simplificado, esse tipo de envolvimento pode ocorrer quando em um contador de quatro dígitos quando o valor 9999 é incrementado e se torna 0000 em vez de 10000 devido à limitação de quatro dígitos. Embora a lógica de controle 84 pode ser capaz de reinicializar o registro de código de tempo 492, pode ser indesejável fazê-lo quando a condição de envolvimento ocorre enquanto uma sessão de vídeo ainda está sendo capturada. Assim, em tais casos, a lógica de controle 84 pode incluir lógica, que pode ser implantada por software em uma modalidade, configurada para manejar a condição de envolvimento ao gerar carimbos de data e hora de precisão mais alta (por exemplo, 64 bits) com base nos valores de registro de 32 bits. O software pode gerar os carimbos de data e hora de precisão mais alta, que podem ser gravados nos metadados de quadro de imagem até que o registro de código de tempo 492 seja reinicializado. Em uma modalidade, o software pode ser configurado para detectar envolvimento e para acrescentar a diferença de tempo resultante da condição de envolvimento a um contador de resolução mais alta. Por exemplo, em uma modalidade, quando uma condição de envolvimento é detectada para um contador de 32 bits, o software pode somar o valor máximo do contador de 32 bits (para dar conta do envolvimento) com o valor de tempo atual indicado pelo contador de 32 bits e armazenar o resultado em um contador de resolução mais alta (por exemplo, maior que 32 bits). Em tais casos, o resultado no contador de alta resolução pode ser gravado nas informações de metadados de imagem até que o contador de 32 bits seja reinicializado.

[000277] A Figura 46 mostra um método 510 que descreve, em geral, as técnicas de sincronização de áudio-vídeo discutidas acima. Conforme mostrado, o método 510 começa na etapa 512, em que os dados de pixel são recebidos a partir de um sensor de imagem (por exemplo, o Sensor0 ou o Sensor1). A seguir, na lógica de decisão 514, uma determinação é realizada em relação a se o sinal VSYNC indica um início de um novo quadro. Se um novo quadro não for detectado, o método 510 retorna para a etapa 512 e continua recebendo dados de pixel a partir do quadro atual de imagem. Se um novo quadro é detectado na lógica de decisão 514, então o método 510 continua para a etapa 516, na qual o registro de código de tempo (por exemplo, registro 492) é amostrado para obter um valor de carimbo de data e hora correspondente à borda ascendente (ou descendente) do sinal VSYNC detectado na etapa 514. A seguir, na etapa 518, o valor de carimbo de data e hora é armazenado no registro de código de tempo (por exemplo, registro 494 ou 496) correspondente ao sensor de imagem que fornece a entrada de dados de pixel. Subsequentemente, na etapa 520, o carimbo de data e hora é associado aos metadados do novo quadro de imagem e, posteriormente, as informações de carimbo de data e hora nos metadados de quadro de imagem podem ser usadas para a sincronização de áudio-vídeo. Por exemplo, o dispositivo eletrônico 10 pode ser configurado para fornecer sincronização de áudio-vídeo ao alinhar os dados de vídeo (com o uso dos carimbos de data e hora de cada quadro individual) aos dados de áudio correspondentes de modo que qualquer atraso entre as saídas de áudio e vídeo correspondentes seja substancialmente minimizado. Por exemplo, conforme discutido acima, um processador principal do dispositivo 10 pode ser utilizado para determinar como correlacionar os carimbos de data e hora de áudio a carimbos de data e hora de vídeo. Em uma modalidade, se os dados de áudio estão à frente dos dados de vídeo, os quadros de imagem podem ser descartados para permitir que o quadro de imagem correto "alcance" o fluxo de dados de áudio e, se os dados de áudio estiverem atrás dos dados de vídeo, os quadros de imagem podem ser repetidos para permitir que os dados de áudio "alcancem" o fluxo de vídeo.

[000278] Continuando para as Figuras 47 a 50, a lógica ou subsistema de processamento de ISP 32 também pode ser configurada para fornecer sincronização flash (também chamada de "estrobo"). Por exemplo, ao usar um módulo de flash, luz artificial pode ser temporariamente fornecida para auxiliar na iluminação de uma cena de imagem. A título de exemplo, o uso de um flash pode ser benéfico ao capturar uma cena de imagem sob condições de luz baixas. O flash ou estrobo pode ser fornecido com o uso de qualquer fonte de iluminação adequada, como um dispositivo de flash de LED ou um dispositivo de flash de xenon, etc.

[000279] Na presente modalidade, o subsistema de ISP 32 pode incluir um controlador de flash configurado para controlar a temporização e/ou intervalo durante o qual um módulo de flash está ativo. Conforme será constatado, é desejável, em geral, controlar a temporização e duração através da qual o módulo de flash está ativo de modo que o intervalo de flash inicie antes de o primeiro pixel de um quadro-alvo (por exemplo, um quadro de imagem que deve ser capturado) ser capturado e termina após o último pixel do quadro-alvo ser capturado, mas antes do início de um quadro de imagem consecutivo subsequente. Isso ajuda a garantir que todos os pixels no quadro-alvo sejam expostos a condições de iluminação similares enquanto a cena de imagem está sendo capturada.

[000280] Com referência à Figura 47, um diagrama de bloco que mostra um controlador de flash 550 implantado como parte do subsistema de ISP 32 e configurado para controlar um módulo de flash 552 é ilustrado de acordo com uma modalidade da presente descrição. Em algumas modalidades, o módulo de flash 552 pode incluir mais que um dispositivo de estrobo. Por exemplo, em certas modalidades, o controlador de flash 550 pode ser configurado para fornecer um pré- flash (por exemplo, para a redução de olhos vermelhos), seguido por um flash principal. Os eventos de pré-flash e flash podem ser sequenciais e podem ser fornecidos com o uso de dispositivos de estrobo iguais ou diferentes.

[000281] Na modalidade ilustrada, a temporização do módulo de flash 552 pode ser controlada com base em informações de temporização fornecidas a partir dos sensores de imagem 90a e 90b. Por exemplo, a temporização de um sensor de imagem pode ser controlada com o uso de uma técnica de obturação de rolagem, através da qual o tempo de integração é governado com o uso de uma abertura em fenda que varre a matriz de pixel do sensor de imagem (por exemplo, 90a e 90b). Com o uso do sensor informações de temporização (mostrado aqui como o número de referência 556), que pode ser fornecido ao subsistema de ISP 32 através da interface de sensores 94a e 94b (cada um dos quais pode incluir uma interface lateral de sensor 548 e uma interface lateral de front-end 549), a lógica de controle 84 pode fornecer parâmetros de controle 554 apropriados para o controlador de flash 550, que pode, então, ser utilizado pelo controlador de flash 550 para ativar o módulo de flash 552. Conforme discutido acima, ao usar as informações de temporização de sensor 556, o controlador de flash 556 pode garantir que o módulo de flash está ativado antes do primeiro pixel do quadroalvo ser capturado e permanece ativado pela duração do quadro-alvo, com o módulo de flash estando desativado após o último pixel do quadro-alvo ser capturado e anteriormente ao início do próximo quadro (por exemplo, VSYNC ascendente). Esse processo pode ser chamado de técnicas de "sincronização de flash" ou "sincronização de estrobo", que são discutidas adicionalmente abaixo.

[000282] Adicionalmente, conforme mostrado na modalidade da Figura 47, a lógica de controle 84 também pode utilizar dados estatísticos a partir da front-end de ISP 80, mostrada aqui como o número de referência 558, para determinar se as condições de luz presentes na cena de imagem correspondentes ao quadro-alvo são apropriadas para o uso do módulo de flash. Por exemplo, o subsistema de ISP 32 pode utilizar auto-exposição para tentar manter um nível de exposição-alvo (por exemplo, nível de luz) ao ajustar tempo de integração e/ou ganhos de sensor. Entretanto, conforme será constatado, o tempo de integração não pode ser mais longo que o tempo de quadro. Por exemplo, para dados de vídeo adquiridos a 30 fps, cada quadro tem uma duração de aproximadamente 33 milissegundos. Portanto, se um nível de exposição-alvo não pode ser alcançado como uso de um tempo de integração máximo, os ganhos de sensor também podem ser aplicados. Entretanto, se o ajuste de ambos o tempo de integração e ganhos de sensor é incapaz de alcançar uma exposição-alvo (por exemplo, se o nível de luz for menor que o limite alvejado), então o controlador de flash pode ser configurado para ativar o módulo de flash. Ademais, em uma modalidade, o tempo de integração também pode ser limitado para evitar desfoque por movimento. Por exemplo, embora o tempo de integração possa ser estendido por até a duração do quadro, ele poderia ser adicionalmente limitado em algumas modalidades para evitar desfoque por movimento.

[000283] Conforme discutido acima, para garantir que a ativação do flash ilumina o quadro-alvo por toda sua duração (por exemplo, que o flash está ativado anteriormente ao primeiro pixel do quadro-alvo e desativado após o último pixel do quadro-alvo), o subsistema de ISP 32 pode utilizar informações de temporização de sensor 556 para determinar quando ativar/desativar o flash 552

[000284] A Figura 48 mostra graficamente como o sinal de temporização de sensor dos sensores de imagem 90 podem ser usados para controlar a sincronização de flash. Por exemplo, a Figura 48 mostra uma porção de um sinal de imagem de temporização de sensor 556 que pode ser fornecida por um dos sensores de imagem 90a ou 90b. As porções altas lógicas do sinal 556 representam intervalos de quadro. Por exemplo, um primeiro quadro (QUADRO N) é representado pelo número de referência 570 e um segundo quadro (QUADRO N+1) é representado pelo número de referência 572. O tempo real no qual o primeiro quadro 570 começa é indicado pela borda ascendente do sinal 556 no tempo tVSYNC_ra0 (por exemplo, com "r" designando uma borda ascendente e "a" designando o aspecto "real" do sinal de temporização 556) e o tempo real no qual o primeiro quadro 570 termina é indicado pela borda descendente do sinal 556 no tempo tVSYNC_fa0 (por exemplo, com "f" designando uma borda descendente). De modo similar, o tempo real no qual o segundo quadro 572 começa é indicado pela borda ascendente do sinal 556 no tempo tVSYNC_ra1 e o tempo real no qual o segundo quadro 572 termina é indicado pela borda descendente do sinal 556 no tempo tVSYNC_fa1. O intervalo 574 entre os primeiro e segundo quadros pode ser chamado de um intervalo de supressão (por exemplo, limpeza vertical), que pode permitir que um conjunto de circuitos de processamento de imagem (por exemplo, subsistema de ISP 32) identifique quando os quadros de imagem terminam e começam. Deve-se constatar que os intervalos de quadro e intervalos de supressão vertical mostrados na presente figura não estão necessariamente em escala.

[000285] Conforme mostrado na Figura 48, o sinal 556 pode representar a temporização real a parir do ponto de vista do sensor de imagem 90. Ou seja, o sinal 556 representa a temporização na qual os quadros estão sendo de fato adquiridos pelo sensor de imagem. Entretanto, conforme as informações de temporização de sensor são fornecidas para componentes a jusante do sistema de processamento de imagem 32, atrasos podem ser introduzidos no sinal de temporização de sensor. Por exemplo, o sinal 576 representa um sinal de temporização atrasado (atrasado por um primeiro atraso de tempo 578) que pode ser visto do ponto de vista da interface lateral de sensor 548 da lógica de interface 94 entre o sensor 90 e a lógica de processamento de front-end de ISP 80. O sinal 580 pode representar o sinal de temporização atrasado de sensor a partir do ponto de vista da interface de lado de front-end 549, que é mostrado na Figura 48 como sendo atrasado em relação à interface lateral de sensor sinal de temporização 572 por um segundo atraso de tempo 582, e atrasado em relação ao sinal de temporização de sensor original 556 por um terceiro atraso de tempo 584, que é igual à soma do primeiro atraso de tempo 578 e do segundo atraso de tempo 582. A seguir, conforme o sinal 580 do lado de front-end 549 da interface 94 é fornecido à lógica de processamento de front-end de ISP 80 (FEProc), um atraso adicional pode ser conferido de modo que o sinal atrasado 588 seja visto a partir do ponto de vista da lógica de processamento de front-end de ISP 80. Especificamente, o sinal 588 visto pela lógica de processamento de front-end de ISP 80 é mostrado no presente documento como estando atrasado em relação ao sinal atrasado 580 (sinal de temporização de lado de front-end) pro um quarto atraso de tempo 590 e atrasado em relação ao sinal de temporização de sensor original 556 por um quinto atraso de tempo 592, que é igual à soma do primeiro atraso de tempo 578, do segundo atraso de tempo 582 e do quarto atraso de tempo 590.

[000286] Para fins de controle de temporização de flash, o controlador de flash 550 pode utilizar o primeiro sinal disponível à front-end de ISP que é, portanto, deslocada pela menor quantidade de tempo de atraso em relação ao sinal real de temporização de sensor 556. Portanto, na presente modalidade, o controlador de flash 550 pode determinar parâmetros de temporização de flash com base no sinal de temporização de sensor 580, conforme visto do ponto de vista do lado de front-end 549 da interface sensor-para-ISP 94. Portanto, o sinal 596, que é usado pelo controlador de flash 550 no presente exemplo, pode ser idêntico ao sinal 580. Conforme mostrado, o sinal atrasado 596 (atrasado pelo tempo de atraso 584 em relação ao sinal 556) inclui os intervalos de quadro localizados entre os tempos tVSYNC_rd0 e t- VSYNC_fd0 (por exemplo, em que "d" representava "atrasado") que se correlacionam ao primeiro quadro 570 e entre tempos tVSYNC_rd1 e tVSYNC_fd1, que se correlacionam ao segundo quadro 572. Conforme discutido acima, é desejável, em geral, ativar o flash anteriormente ao início de um quadro e pela duração do quadro (por exemplo, para desativar o flash após o último pixel do quadro) para garantir que a cena de imagem seja iluminada pela totalidade do quadro e para se responsabilizar para qualquer tempo de aquecimento que o flash possa precisar durante a ativação para alcançar a intensidade total (que pode ser da ordem de um microssegundo (por exemplo, 100 a 800 microssegundos) por alguns milissegundos (por exemplo, 1 a 5 milissegundos)). Entretanto, já que o sinal 596 sendo analisado pelo controlador de flash 550 está atrasado em relação ao sinal real de temporização 556, esse atraso é levado em consideração ao determinar os parâmetros de temporização de flash.

[000287] Por exemplo, presumindo que o flash deva ser ativado para iluminar a cena de imagem para o segundo quadro 572, a borda ascendente atrasada em tVSYNC_rd1 ocorre após a borda ascendente real em tVSYNC_ra1. Portanto, pode ser difícil para o controlador de flash 550 usar a borda ascendente atrasada tVSYNC_rd1 para determinar um tempo de início de ativação de flash, já que a borda ascendente atrasada tVSYNC_rd1 ocorre após o segundo quadro 572 já ter iniciado (por exemplo, após tVSYNC_ra1 do sinal 556). Na presente modalidade, o controlador de flash 550 pode, em vez disso, determinar o tempo de início da ativação de flash com base no final do quadro anterior, aqui a borda descendente no tempo tVSYNC_fd0. Por exemplo, o controlador de flash 550 pode acrescentar um intervalo de tempo 600 (que representa o intervalo de supressão vertical 574) ao tempo tVSYNC_fd0, para calcular um tempo que corresponde ao tempo de borda ascendente atrasada tVSYNC_rd1 do quadro 572. Conforme pode ser constatado, o tempo de borda ascendente atrasada tVSYNC_rd1 ocorre após o tempo de borda ascendente real tVSYNC_ra1 (sinal 556) e, portanto, um deslocamento de tempo 598 (Deslocamento1), que corresponde ao atraso de tempo 584 do sinal 580, é subtraído da soma de tempo tVSYNC_fd0 e do tempo de intervalo de supressão 600. Isso produz um tempo de início de ativação de flash que inicia simultaneamente ao início do segundo quadro 572, no tempo tVSYNC_ra1. Entretanto, conforme mencionado acima, dependendo do tipo de dispositivo de flash que é fornecido (por exemplo, xenon, LED, etc.), o módulo de flash 552 pode passar por um tempo de aquecimento entre quando o módulo de flash é ativado e quando o dispositivo de flash alcança sua luminosidade total. A quantidade do tempo de aquecimento pode depender do tipo de dispositivo de flash usado (por exemplo, xenon dispositivo, LED dispositivo, etc.). Portanto, para dar conta de tais tempos de aquecimento, um deslocamento adicional 602 (Deslocamento2), que pode ser programado ou pré-configurado (por exemplo, com o uso de um registro de controle), pode ser subtraído do início do segundo quadro 572, no tempo tVSYNC_ra1. Isso move o tempo de início de ativação de flash para o tempo 604, garantindo, assim, que o flash seja ativado (se necessário para iluminar a cena) anterior ao início do quadro 572 sendo adquirido pelo sensor de imagem. Esse processo para determinar o tempo de ativação de flash pode ser expresso com o uso da fórmula abaixo:

[000288] Na modalidade ilustrada, a desativação do flash pode ocorrer no tempo tVSYNC_fd1 do controlador de flash sinal 596, contanto que o tempo tVSYNC_fd1 ocorra anteriormente ao início do quadro após o quadro 572 (por exemplo, QUADRO N+2, que não é mostrado na Figura 48) conforme indicado pelo tempo 605 no sinal de temporização de sensor 556. Em outras modalidades, a desativação do flash pode ocorrer em um tempo (por exemplo, um deslocamento 606) após o tempo tVSYNC_fd1 do sinal 596, mas antes do início do próximo quadro (por exemplo, antes de uma borda ascendente de VSYNC subsequente no sinal de temporização de sensor 556 que indica o início do QUADRO N+2), ou pode ocorrer em um intervalo 608 imediatamente anterior ao tempo tVSYNC_fd1, em que o intervalo 608 é menor que a quantidade de Deslocamento1 (598). Conforme pode ser constatado, isso garante que o flash permanece ativado por toda a duração do quadro-alvo (por exemplo, quadro 572).

[000289] A Figura 49 mostra um processo 618 para determinar um tempo de início de ativação de flash no dispositivo eletrônico 10 de acordo com a modalidade mostrada na Figura 48. Iniciando no bloco 620, um sinal de temporização de sensor (por exemplo, 556) de um sensor de imagem é adquirido e fornecido para a lógica de controle de flash (por exemplo, controlador de flash 550), que pode ser parte de um subsistema de processamento de sinal de imagem (por exemplo, 32) do dispositivo eletrônico 10. O sinal de temporização de sensor é fornecido à lógica de controle de flash, mas pode ser atrasado em relação ao sinal de temporização original (por exemplo, 556). No bloco 622, o atraso (por exemplo, atraso 584) entre o sinal de temporização de sensor e o sinal de temporização atrasado de sensor (por exemplo, 596) é determinado. A seguir, um quadro-alvo (por exemplo, quadro 572) que solicita iluminação de flash é identificado no bloco 624. para determinar o tempo no qual o módulo de flash (por exemplo, 552) deveria ser ativado para garantir que o flash está ativo anteriormente ao início do quadro-alvo, o processo 618 então prossegue para o bloco 626, no qual um primeiro tempo (por exemplo, o tempo tVSYNC_fd0) correspondente ao final do quadro anterior ao quadro-alvo, conforme indicado pelo sinal de temporização atrasado, é determinado. Posteriormente, no bloco 628, o comprimento de um intervalo de supressão entre quadros é determinado e adicionado ao primeiro tempo determinado no bloco 626 para determinar um segundo tempo. O atraso determinado no bloco 622 é, então, subtraído do segundo tempo, conforme mostrado no bloco 630, para determinar um terceiro tempo. Conforme discutido acima, isso configura o tempo de ativação de flash para coincidir com o início real do quadro-alvo de acordo com o sinal de temporização não atrasado de sensor.

[000290] Para garantir que o flash está ativo anteriormente ao início do quadro-alvo, um deslocamento (por exemplo, 602, Deslocamento2) é subtraído do terceiro tempo, conforme mostrado no bloco 632, para determinar o tempo de ativação de flash desejado. Conforme será constatado, em algumas modalidades, o deslocamento do bloco 632 pode não apenas garantir que o flash esteja ativado antes do quadroalvo, mas também pode compensar qualquer tempo de aquecimento que o flash possa exigir entre estar inicialmente ativado e alcançar luminosidade total. No bloco 634, o flash 552 é ativado no tempo de início de flash determinado no bloco 632. Conforme discutido acima e mostrado no bloco 636, o flash pode permanecer por toda a duração do quadro-alvo, e pode ser desativado após o final do quadro-alvo, de modo que todos os pixels no quadro-alvo sejam submetidos a condições de iluminação similares. Embora a modalidade descrita acima nas Figuras 48 e 49 tenha discutido a aplicação de técnicas de sincronização de flash com ouso de um único flash, deve-se constatar, ainda, que essas técnicas de sincronização e flash também podem ser aplicáveis a modalidades dos dispositivos que têm dois ou mais dispositivos de flash (por exemplo, dois flashes de LED). Por exemplo, se mais que um módulo de flash for utilizado, as técnicas acima podem ser aplicadas a ambos os módulos de flash, de modo que cada módulo de flash seja ativado pelo controlador de flash anteriormente ao início de um quadro e permaneça pela duração do quadro (por exemplo, os módulos de flash podem não necessariamente ser ativados para os mesmos quadros).

[000291] As técnicas de temporização de flash descritas no presente documento podem ser aplicadas ao obter imagens com o uso do dispositivo 10. Por exemplo, em uma modalidade, uma técnica pré-flash pode ser usada durante a aquisição de imagem. Por exemplo, quando uma aplicação de câmera ou aquisição de imagem está ativa no dispositivo 10, a aplicação pode operar em um modo de "visualização". No modo de pré-visualização, o(s) sensor(es) de imagem (por exemplo, 90) podem estar obtendo quadros de dados de imagem que podem ser processados pelo subsistema de ISP 32 do dispositivo 10 para fins de visualização (por exemplo, a visualização em um visor 28), embora os quadros possam não ser realmente capturados ou armazenados até uma solicitação de captura ser iniciada por um usuário para colocar o dispositivo 10 em um modo de "captura". A título de exemplo, isso pode ocorrer através de uma ativação de usuário de um botão de captura físico no dispositivo 10, ou um botão de captura macio, que pode ser implantado através de b software como parte de uma interface de usuário gráfica e exibido em um visor do dispositivo 10 e que é responsivo a entradas de interface de usuário (por exemplo, entradas de tela sensível ao toque).

[000292] Como o flash não está tipicamente ativo durante o modo de pré-visualização, a ativação repentina de e a iluminação de uma cena de imagem com o uso de flash pode, em alguns casos, alterar significativamente certas estatísticas de imagem para uma cena particular, como aquelas relacionadas a estatísticas de auto-equilíbrio de branco, etc., em relação à mesma cena de imagem que não é iluminada pelo flash. Portanto, para melhorar as estatísticas usadas para processar um quadro-alvo desejado, em uma modalidade, uma técnica de operação pré-flash pode incluir receber uma solicitação de usuário para capturar um quadro de imagem que solicita a iluminação de flash, com o uso do flash em um primeiro tempo para iluminar um primeiro quadro enquanto o dispositivo 10 ainda está em modo de pré- visualização, e atualizando as estatísticas (por exemplo, estatísticas de auto-equilíbrio de branco) anteriormente ao início do próximo quadro. O dispositivo 10 pode entrar em modo de captura e capturar o próximo quadro com o uso de estatísticas atualizadas com o flash ativado, fornecendo, assim, precisão melhorada de imagem/cor.

[000293] A Figura 50 mostra um fluxograma que ilustra um processo 640 com mais detalhes. O processo 640 começa no bloco 642 no qual uma solicitação é recebida para capturar uma imagem com o uso do flash. No bloco 644, o flash é ativado (por exemplo, pode ser temporizado com o uso de técnicas mostradas nas Figuras 48 e 49) para iluminar um primeiro quadro enquanto o dispositivo 10 ainda está em modo de pré-visualização. A seguir, no bloco 646, estatísticas de imagem, como estatísticas de auto-equilíbrio de branco, são atualizadas com base em estatísticas adquiridas a partir de um primeiro quadro iluminado. Posteriormente, no bloco 648, o dispositivo 10 pode entrar no modo de captura e adquirir o próximo quadro com o uso das estatísticas de imagem atualizadas do bloco 646. Por exemplo, as estatísticas de imagem atualizadas podem ser usadas para determinar ganhos de equilíbrio de branco e/ou matrizes de correção de cor (CCM), que podem ser suadas por firmware (por exemplo, lógica de controle 84) para programar a pipeline de ISP 82. Portanto, o quadro (por exemplo, próximo quadro) adquirido no bloco 648 pode ser processado pela pipeline de ISP 82 com o uso de um ou mais parâmetros que são determinados com base nas estatísticas de imagem atualizadas a partir do bloco 646.

[000294] Em outra modalidade, as propriedades de cor de uma cena de imagem de não flash (por exemplo, adquirida ou visualizada sem flash) podem ser aplicadas ao capturar um quadro de imagem com flash. Conforme será constatado, uma cena de imagem de não flash exibe, em geral, melhores propriedades de cor em relação a uma cena de imagem que está iluminada com o flash. O uso do flash pode, entretanto, oferecer ruído reduzido e claridade melhorada (por exemplo, em condições de luz baixa) em relação à imagem de não flash. Entretanto, o uso do flash também pode resultar em algumas das cores na imagem de flash aparecendo de certa forma desbotadas em relação a uma imagem sem flash da mesma cena. Portanto, em uma modalidade, para reter os benefícios de baixo ruído e claridade de uma imagem com flash enquanto também se retém parcialmente algumas das propriedades de cor da imagem de não flash, o dispositivo 10 pode ser configurado para analisar um primeiro quadro sem o flash para obter suas propriedades de cor. Então, o dispositivo 10 pode capturar um segundo quadro com o uso do flash e pode aplicar uma técnica de transferência de paleta de cores à imagem de flash com o uso de propriedades de cor a partir da imagem de não flash.

[000295] Em certas modalidades, o dispositivo 10 configurado para implantar qualquer uma das técnicas de flash/estrobo discutidas acima pode ser um modelo dos dispositivos de computação iPod®, iPhone®, iMac® ou MacBook® com dispositivos de imageamento integrados ou externos, todos os quais estão disponíveis junto à Apple Inc. Ademais, a aplicação de câmera/imageamento pode ser uma versão das aplicações Câmera®, iMovie® ou PhotoBooth®, também da Apple Inc.

[000296] Continuando com a Figura 51, uma vista mais detalhada da lógica de processamento de pixel da front-end de ISP 150 (previamente discutida na Figura 10) é ilustrada, de acordo com uma modalidade da presente técnica. Conforme mostrado, a lógica de processamento de pixel de front-end de ISP 150 inclui um filtro temporal 650 e um filtro de compensação de compartimentalização 652. O filtro temporal 650 pode receber um dentre os sinais de entrada de imagem Sif0, Sif1, FEProcIn ou sinais de imagem pré-processados (por exemplo, 180, 184) e pode operar nos dados de pixel brutos antes que qualquer processamento adicional seja realizado. Por exemplo, o filtro temporal 650 pode processar, incialmente, os dados de imagem para reduzir ruído ao ponderar quadros de imagem na direção temporal. O filtro de compensação de compartimentalização 652, que é discutido com mais detalhes abaixo, pode aplicar escala e reamostragem aos dados de imagem brutos compartimentalizados a partir de um sensor de imagem (por exemplo, 90a, 90b) para manter uma distribuição espacial uniforme dos pixels de imagem.

[000297] O filtro temporal 650 pode ser adaptativo de pixel com base em características de movimento e claridade. Por exemplo, quando o movimento de pixel é alto, a força de filtragem pode ser reduzida para evitar a aparição de "rastro" ou "artefatos fantasma" na imagem processada resultante, enquanto a força de filtragem pode ser aumentada enquanto pouco ou nenhum movimento é detectado. Adicionalmente, a força de filtragem também pode ser ajustada com base em dados de claridade (por exemplo, "luma"). Por exemplo, conforme a claridade de imagem aumenta, artefatos de claridade podem se tornar mais notáveis ao olho humano. Portanto, a força de filtragem pode ser adicionalmente reduzida quando um pixel tem um nível alto de claridade.

[000298] Ao aplicar filtro temporariamente, o filtro temporal 650 pode receber dados de pixel de referência (Rin) e dados de entrada de histórico de movimento (Hin), que podem ser de um quadro previamente filtrado ou original. Com o uso desses parâmetros, o filtro temporal 650 pode fornecer dados de saída de histórico de movimento (Hout) e saída de pixel filtrado (Yout). A saída de pixel filtrada Yout é, então, passada para o filtro de compensação de compartimentalização 652, que pode ser configurada para realizar uma ou mais operações de escala nos dados de saída de pixel filtrado Yout para produzir o sinal de saída FEProcOut. Os dados de pixel processados FEProcOut podem, então, ser encaminhados para a lógica de processamento de pipe de ISP 82, conforme discutido acima.

[000299] Com referência à Figura 52, um diagrama de processo que mostra um processo de temporalização de filtro 654 que pode ser realizado pelo filtro temporal mostrado na Figura 51 é ilustrado, de acordo com uma primeira modalidade. O filtro temporal 650 pode incluir um filtro de 2 taps, em que os coeficientes de filtro são ajustados de modo adaptativo em uma base por pixel baseado pelo menos parcialmente em dados de movimento e claridade. Por exemplo, pixels de entrada x(t), com a variável "t" que denota um valor temporal podem ser comparados a pixels de referência r(t-1) em um quadro previamente filtrado ou um quadro original prévio para gerar um índice de movimento em uma tabela de histórico de movimento (M) 655 que pode conter coeficientes de filtro. Adicionalmente, com base nos dados de entrada de histórico de movimento h(t-1), uma saída de histórico de movimento h(t) correspondente à entrada de pixel atual x(t) pode ser determinada.

[000300] A saída de histórico de movimento h(t) e um coeficiente de filtro, K, pode ser determinada com base em um movimento delta d(j,i,t), em que (j,i) representa coordenadas do local espacial de um pixel atual x(j,i,t). o delta de movimento d(j,i,t) pode ser computado ao determinar o máximo de três deltas absolutos entre os pixels original e de referência para três pixels posicionados horizontalmente da mesma cor. Por exemplo, com referência, agora, à Figura 53, os locais espaciais dos três pixels de referência posicionados 657, 658, e 659 que correspondem aos pixels de entrada originais 660, 661 e 662 são ilustrados. Em uma modalidade, o movimento delta pode ser calculado com base nesses pixels origina e de referência com o uso da fórmula abaixo:

[000301] Um fluxograma que mostra essa técnica para determinar o valor delta de movimento é ilustrado mais abaixo na Figura 55. Ademais, deve-se compreender que a técnica para calcular o valor delta de movimento, conforme mostrado acima na Equação 1a (e abaixo na Figura 55), é apenas destinada a fornecer uma modalidade para determinar um valor delta de movimento.

[000302] Em outras modalidades, uma matriz de pixels da mesma cor poderia ser avaliada para determinar um valor delta de movimento. Por exemplo, além dos três pixels referenciados na Equação 1a, uma modalidade para determinar valores delta de movimento pode incluir também a avaliação dos deltas absolutos entre pixels de mesma cor a partir de duas fileiras acima (por exemplo, j-2; presumindo o padrão Bayer) dos pixels de referência 660, 661 e 662 e seus pixels colocados correspondentes e duas fileiras abaixo (por exemplo, j+2; presumindo um padrão Bayer) dos pixels de referência 660, 661, e 662 e seus pixels posicionados correspondentes. Por exemplo, em uma modalidade, o valor delta de movimento pode ser expresso conforme segue:

[000303] Portanto, na modalidade mostrada pela Equação 1b, o valor delta de movimento pode ser determinado ao comparar o delta absoluto entre uma matriz 3x3 d pixels da mesma cor, com o pixel atual (661) estando localizado no centro da matriz 3x3 (por exemplo, realmente uma matriz 5x5 para padrões de cor Bayer se os pixels de cores diferentes forem contados). Deve-se constatar que qualquer matriz bidimensional adequada de pixels da mesma cor (por exemplo, incluindo matrizes que têm todos os pixels na mesma fileira (por exemplo, Equação 1a) ou matrizes que têm todos os pixels na mesma coluna) com o pixel atual (por exemplo, 661) estando localizado no centro da matriz poderia ser analisada para determinar um valor delta de movimento. Ademais, embora o valor delta de movimento possa ser determinado como o máximo dos deltas absolutos (por exemplo, conforme mostrado nas Equações 1a e 1b), em outras modalidades, o valor delta de movimento também poderia ser selecionado como a média ou mediana dos deltas absolutos. Adicionalmente, as técnicas anteriores também podem ser aplicadas em outros tipos de matrizes de filtro de cor (por exemplo, RGBW, CYGM, etc.) e não são destinadas a serem exclusivas de padrões Bayer.

[000304] Com referência, novamente, à Figura 52, uma vez que o valor delta de movimento é determinado, uma consulta de índice de movimento que pode ser usada para selecionar o coeficiente de filtro K a partir da tabela de movimento (M) 655 pode ser calculada ao somar o delta de movimento d(t) para o pixel atual (por exemplo, na localização espacial (j,i)) com a entrada de histórico de movimento h(t-1). Por exemplo, o coeficiente de filtro K pode ser determinado conforme segue:

[000305] Adicionalmente, a saída de histórico de movimento h(t) pode ser determinada com o uso da seguinte fórmula:

[000306] A seguir, a claridade do pixel de entrada atual x(t) pode ser usada para gerar uma consulta de índice de luma em uma tabela de luma (L) 656. Em uma modalidade, a tabela de luma ode conter fatores de atenuação que podem estar entre 0 e 1 e podem ser selecionados com base no índice de luma. Um segundo coeficiente de filtro, K’ pode ser calculado ao multiplicar o primeiro coeficiente de filtro K pelo fator de atenuação de luma, conforme mostrado na seguinte equação:

[000307] O valor determinado para K’ pode, então, ser usado como o coeficiente de filtragem para o filtro temporal 650. Conforme discutido acima, o filtro temporal 650 pode ser um filtro de 2 taps. Adicionalmente, o filtro temporal 650 pode ser configurado como um filtro de resposta de impulso infinita (IIR) com o uso de quadro previamente filtrado ou como um filtro de resposta de impulso infinita (FIR) com o uso de quadro original prévio. O filtro temporal 650 pode computar o pixel de saída filtrado y(t) (Yout) com o uso do pixel de entrada atual x(t), o pixel de referência r(t-1) e o coeficiente de filtro K’ com o uso da fórmula a seguir:

[000308] Conforme discutido acima, o processo de temporalização do filtro 654 mostrado na Figura 52 pode ser realizado em uma base de pixel por pixel. Em uma modalidade, a tabela M de mesmo movimento e a tabela L de luma podem ser usadas para componentes de todas as cores (por exemplo, R, G, e B). Adicionalmente, algumas modalidades podem fornecer um mecanismo de desvio, no qual a temporização de filtro pode ser desviada, como em resposta a um sinal de controle a partir da lógica de controle 84. Ademais, conforme será discutido abaixo em relação às Figuras 57 e 58, uma modalidade do filtro temporal 650 pode utilizar movimento separado e tabelas de luma para cada componente de cor dos dados de imagem.

[000309] A modalidade da técnica de filtragem temporal descrita com referência às Figuras 52 e 53 pode ser mais bem compreendida tendo em vista a Figura 54, que mostra um fluxograma que ilustra um método 664, de acordo com a modalidade descrita acima. O método 664 começa na etapa 665, na qual um pixel atual x(t) localizado na localização espacial (j,i) de um quadro atual de dados de imagem é recebido pelo sistema de temporização de filtro 654. Na etapa 666, um valor delta de movimento d(t) é determinado para o pixel atual x(t) com base, pelo menos parcialmente, em um ou mais pixels de referência posicionados (por exemplo, r(t-1)) a partir de um quadro anterior dos dados de imagem (por exemplo, o quadro de imagem que precede imediatamente o quadro atual). Uma técnica para determinar um valor delta de movimento d(t) na etapa 666 é adicionalmente explicada abaixo com referência à Figura 55 e pode ser realizada de acordo com a Equação 1a, conforme mostrado acima.

[000310] Uma vez que o valor delta de movimento d(t) da etapa 666 é obtido, um índice de consulta à tabela de movimento pode ser determinado com o uso do valor delta de movimento d(t) e um valor de entrada de histórico de movimento h(t-1) correspondente à localização espacial (j,i) a partir do quadro anterior, conforme mostrado na etapa 667. Adicionalmente, embora não seja mostrado, um valor de histórico de movimento h(t) correspondente ao pixel atual x(t) também pode ser determinado na etapa 667 uma vez que o valor delta de movimento d(t) é conhecido, por exemplo, através do uso da Equação 3a mostrada acima. Posteriormente, na etapa 668, um primeiro coeficiente de filtro K pode ser selecionado a partir de uma tabela de movimento 655 com o uso do índice de consulta à tabela de movimento da etapa 667. A determinação do índice de consulta à tabela de movimento e a seleção do primeiro coeficiente de filtro K da tabela de movimento pode ser realizada de acordo com a Equação 2a, conforme mostrado acima.

[000311] A seguir, na etapa 669, um fator de atenuação pode ser selecionado a partir de uma tabela de luma 656. Por exemplo, a tabela de luma 656 pode conter fatores de atenuação na faixa de aproximadamente 0 e 1 e o fator de atenuação pode ser selecionado a partir da tabela de luma 656 com o uso do valor do pixel atual x(t) como um índice de consulta. Uma vez que o fator de atenuação é selecionado, um segundo coeficiente de filtro K’ pode ser determinado na etapa 670 com o uso do fator de atenuação selecionado e do primeiro coeficiente de filtro K (a partir da etapa 668), conforme mostrado in Equação 4a acima. Então, na etapa 671, um valor de saída filtrado temporariamente y(t) correspondente ao pixel de entrada atual x(t) é determinado com base no segundo coeficiente de filtro K’ (a partir da etapa 669), o valor do pixel de referência posicionado r(t-1) e o valor do pixel de entrada x(t). Por exemplo, em uma modalidade, o valor de saída y(t) pode ser determinado de acordo com a Equação 5a, conforme mostrado acima.

[000312] Com referência à Figura 55, a etapa 666 para determinar o valor delta de movimento d(t) do método 664 é ilustrado com mais detalhes, de acordo com uma modalidade. Em particular, a determinação do valor delta de movimento d(t) pode corresponder, em geral, à operação retratada acima de acordo com a Equação 1a. Conforme mostrado, a etapa 666 pode incluir as subetapas 672 a 675. Iniciando na subetapa 672, um conjunto de três pixels horizontalmente adjacentes que têm o mesmo valor de cor que o pixel de entrada atual x(t) é identificado. A título de exemplo, de acordo com a modalidade mostrada na Figura 53, os dados de imagem podem incluir dados de imagem de Bayer e os três pixels horizontalmente adjacentes podem incluir o pixel de entrada atual x(t) (661), um segundo pixel 660 da mesma cor à esquerda do pixel de entrada atual 661 e um terceiro pixel da mesma cor à direita do pixel de entrada atual 661.

[000313] A seguir, na subetapa 673, três pixels de referência posicionados 657, 658 e 659 do quadro anterior correspondente ao conjunto de três pixels horizontalmente adjacentes selecionado 660, 661, e 662 são identificados. Com o uso dos pixels selecionados 660, 661, e 662 e os três pixels de referência posicionados 657, 658, e 659, os valores absolutos das diferenças entre cada um dos três pixels selecionados 660, 661, e 662 e seus pixels de referência posicionados correspondentes 657, 658 e 659, respectivamente, são determinados na subetapa 674. Subsequentemente, na subetapa 675, o máximo das três diferenças da subetapa 674 é selecionado como o valor delta de movimento d(t) para o pixel de entrada atual x(t). Conforme discutido acima, a Figura 55, que ilustra a técnica de cálculo de valor delta de movimento mostrada na Equação 1a, é apenas destinada a fornecer uma modalidade. De fato, conforme discutido acima, qualquer matriz bidimensional adequada de pixels da mesma cor com o pixel atual estando centralizado na matriz pode ser usada para determinar a valor delta de movimento (por exemplo, Equação 1b).

[000314] Outra modalidade de uma técnica para aplicar temporização de filtro aos dados de imagem é adicionalmente mostrada na Figura 56. Por exemplo, já que as razões de sinal para ruído para diferentes componentes de cor dos dados de imagem podem ser diferentes, um ganho pode ser aplicado ao pixel atual, de modo que o pixel atual seja ganho antes de selecionar valores de movimento e luma da tabela de movimento 655 e da tabela de luma 656. Ao aplicar um ganho respectivo que é dependente de cor, a razão de sinal para ruído pode ser mais consistente dentre os componentes de cor diferentes. A título de exemplo, apenas, em uma implantação que usa dados de imagem Bayer brutos, os canais de cor vermelho e azul podem ser mais sensíveis comparado aos canais de cor verde (Gr e Gb). Portanto, ao aplicar um ganho dependente de cor apropriado a cada pixel processado, a variação de sinal para ruído entre cada componente de cor pode ser, em geral, reduzido, reduzindo, por meio disso, dentre outras coisas, artefatos de formação de fantasma, assim como consistência através de cores diferentes após ganhos de equilíbrio de branco automático.

[000315] Com isso em mente, a Figura 56 fornece um fluxograma que mostra um método 676 para aplicar a temporização de filtro aos dados de imagem recebidos pela unidade de processamento de front-end 150 de acordo com tal modalidade. Começando na etapa 677, um pixel atual x(t) localizado na localização espacial (j,i) de um quadro atual dos dados de imagem é recebido pelo sistema de temporização de filtro 654. Na etapa 678, um valor delta de movimento d(t) é determinado para o pixel atual x(t) com base pelo menos parcialmente em um ou mais pixels de referência posicionados (por exemplo, r(t-1)) a partir de um quadro anterior aos dados de imagem (por exemplo, o quadro de imagem imediatamente precedente ao quadro atual). A etapa 678 pode ser similar à etapa 666 da Figura 54 e pode utilizar a operação representada na Equação 1 acima.

[000316] A seguir, na etapa 679, um índice de consulta à tabela de movimento pode ser determinado com o uso do valor delta de movimento d(t), um valor de entrada de histórico de movimento h(t-1) correspondente à localização espacial (j,i) a partir do quadro anterior (por exemplo, correspondente ao pixel de referência posicionado r(t-1)), e um ganho associado à cor do pixel atual. Posteriormente, na etapa 680, um primeiro coeficiente de filtro K pode ser selecionado a partir da tabela de movimento 655 com o uso do índice de consulta à tabela de movimento determinado na etapa 679. A título de exemplo, apenas, em uma modalidade, o coeficiente de filtro K e o índice de consulta à tabela de movimento podem ser determinados conforme segue:

[000317] em que M representa a tabela de movimento, e em que o ganho [c] corresponde a um ganho associado à cor do pixel atual. Adicionalmente, embora não seja mostrado na Figura 56, deve-se compreender que uma saída de valor de histórico de movimento h(t) para o pixel atual também pode ser determinada e pode ser usada para aplicar temporização de filtro a um pixel posicionado de um quadro de imagem subsequente (por exemplo, o próximo quadro). Na presente modalidade, a saída de histórico de movimento h(t) para o pixel atual x(t) pode ser determinada com o uso da seguinte fórmula:

[000318] A seguir, na etapa 681, um fator de atenuação pode ser selecionado a partir da tabela de luma 656 com o uso de uma tabela de luma índice de consulta determinada com base no ganho (gain[c]) associado à color do pixel atual x(t). Conforme discutido acima, os fatores de atenuação armazenados na tabela de luma podem ter uma faixa de aproximadamente 0 a 1. Posteriormente, na etapa 682, um segundo coeficiente de filtro K’ pode ser calculado com base no fator de atenuação (a partir da etapa 681) e no primeiro coeficiente de filtro K (a partir da etapa 680). A título de exemplo, apenas, em uma modalidade, o segundo coeficiente de filtro K’ e a tabela de luma índice de consulta podem ser determinados conforme segue:

[000319] A seguir, na etapa 683, um valor de saída filtrado temporariamente y(t) correspondente ao pixel de entrada atual x(t) é determinado com base no segundo coeficiente de filtro K’ (a partir da etapa 682), no valor do pixel de referência posicionado r(t-1) e no valor do pixel de entrada x(t). Por exemplo, em uma modalidade, o valor de saída y(t) pode ser determinado conforme segue:

[000320] Continuando para a Figura 57, uma modalidade adicional do processo de temporalização do filtro 384 é mostrado. Aqui, o processo de temporalização do filtro 384 pode ser alcançado de maneira similar à modalidade discutida na Figura 56, exceto pelo fato de que, em vez de aplicar um ganho dependente de cor (por exemplo, gain[c]) a cada pixel de entrada e usar tabelas de movimento e luma compartilhadas, tabelas de movimento e luma separadas são fornecidas para cada um dos componentes de cor. Por exemplo, conforme mostrado na Figura 57, a tabela de movimentos 655 pode incluir uma tabela de movimento 655a correspondente a uma primeira cor, uma tabela de movimento 655b correspondente a uma segunda cor e uma tabela de movimento 655c correspondente a uma enésima cor, em que n depende do número de cores presentes nos dados de imagem brutos. De maneira similar, a tabelas de luma 656 pode incluir uma tabela de luma 656a correspondente à primeira cor, uma tabela de luma 656b correspondente à segunda cor e uma tabela de luma 656c correspondente à enésima cor. Portanto, em uma modalidade em que os dados de imagem brutos são dados de imagem de Bayer, três tabelas de movimento e luma podem ser fornecidas para cada um dentre os componentes de cor vermelho, azul e verde. Conforme discutido abaixo, a seleção de coeficientes de filtragem K e fatores de atenuação podem depender da tabela de movimento e da tabela de luma selecionadas para a cor atual (por exemplo, a cor do pixel de entrada atual).

[000321] Um método 685 que ilustra uma modalidade adicional para a temporização de filtro como uso de tabelas de movimento e luma dependentes de cor é mostrado na Figura 58. Conforme será constatado, os vários cálculos e fórmulas que podem ser empregados pelo método 685 podem ser similares à modalidade mostrada na Figura 54, mas com uma tabela de movimento e luma particular sendo selecionada para cada cor, ou similar à modalidade mostrada na Figura 56, mas substituindo o uso do gain[c] dependente de cor com a seleção de uma tabela de movimento e luma dependente de cor.

[000322] Começando na etapa 686, um pixel atual x(t) localizado na localização espacial (j,i) de um quadro atual de dados de imagem é recebido pelo sistema de temporização de filtro 684 (Figura 57). Na etapa 687, um valor delta de movimento d(t) é determinado para o pixel atual x(t) com base pelo menos parcialmente em um ou mais pixels de referência posicionados (por exemplo, r(t-1)) a partir de um quadro anterior dos dados de imagem (por exemplo, o quadro de imagem imediatamente precedente ao quadro atual). A etapa 687 pode ser similar à etapa 666 da Figura 54 e pode utilizar a operação mostrada na Equação 1 acima.

[000323] A seguir, na etapa 688, um índice de consulta à tabela de movimento ode ser determinado com o uso do valor delta de movimento d(t) e um valor de entrada de histórico de movimento h(t-1) correspondente à localização espacial (j,i) a partir do quadro anterior (por exemplo, correspondente ao pixel de referência posicionado r(t-1)). Posteriormente, na etapa 689, um primeiro coeficiente de filtro K pode ser selecionado a partir de uma dentre as tabelas de movimento disponíveis (por exemplo, 655a, 655b, 655c) com base na cor do pixel de entrada atual. Por exemplo, quando a tabela de movimento apropriada é identificada, o primeiro coeficiente de filtro K pode ser selecionado com o uso do índice de consulta à tabela de movimento determinado na etapa 688.

[000324] Após selecionar o primeiro coeficiente de filtro K, uma tabela de luma correspondente à cor atual é selecionada e um fator de atenuação é selecionado a partir da tabela de luma selecionada com base no valor do pixel atual x(t), conforme mostrado na etapa 690. Posteriormente, na etapa 691, um segundo coeficiente de filtro K’ é determinado com base no fator de atenuação (a partir da etapa 690) e o primeiro coeficiente de filtro K (etapa 689). A seguir, na etapa 692, um valor de saída filtrado temporariamente y(t) correspondente ao pixel de entrada atual x(t) é determinado com base no segundo coeficiente de filtro K’ (a partir da etapa 691), no valor do pixel de referência posicionado r(t-1), e no valor do pixel de entrada x(t). Enquanto a técnica mostrada na Figura 58 pode ser mais dispendiosa para ser implantada (por exemplo, devido à memória necessária para armazenar movimento adicional e tabelas de luma), ela pode, em alguns casos, oferecer melhorias adicionais em relação a artefatos de formação de fantasma e consistência através de cores diferentes após ganhos de equilíbrio de branco automático.

[000325] De acordo com modalidades adicionais, o processo de temporalização do filtro fornecida pelo filtro temporal 650 pode utilizar uma combinação de ganhos dependentes de cor e movimento específico de cor e/ou tabelas de luma para aplicar temporização de filtro aos pixels de entrada. Por exemplo, em tal modalidade, uma única tabela de movimento pode ser fornecida para todos os componentes de cor e o índice de consulta à tabela de movimento para selecionar o primeiro coeficiente de filtragem (K) a partir da tabela de movimento pode ser determinado com base em um ganho dependente de cor (por exemplo, conforme mostrado na Figura 56, etapas 679 a 680), enquanto a tabela de luma índice de consulta pode não ter um ganho dependente de cor aplicado à mesma, mas pode ser usada para selecionar o fator de atenuação de claridade a partir de uma das múltiplas tabelas de luma, dependendo da color do pixel de entrada atual (por exemplo, conforme mostrado na Figura 58, etapa 690). Alternativamente, em outra modalidade, múltiplas tabelas de movimento podem ser fornecidas e um índice de consulta à tabela de movimento (sem um ganho dependente de cor aplicado) pode ser usado para selecionar o primeiro coeficiente de filtragem (K) a partir de uma tabela de movimento correspondente à color do pixel de entrada atual (por exemplo, conforme mostrado na Figura 58, etapa 689), enquanto uma única tabela de luma pode ser fornecida para todos os componentes de cor, e em que a tabela de luma índice de consulta para selecionar o fator de atenuação de claridade pode ser determinada com base em um ganho dependente de cor (por exemplo, conforme mostrado na Figura 56, etapas 681 a 682). Ademais, em uma modalidade em que uma matriz de filtro de cor de Bayer é utilizada, uma tabela de movimento e/ou tabela de luma pode ser fornecida para cada um dentre os componentes de cor vermelho (R) e azul (B), enquanto uma tabela de movimento e/ou tabela de luma comum pode ser fornecida para ambos os componentes de cor verde (Gr e Gb).

[000326] A emissão do filtro temporal 650 pode, subsequentemente, ser enviada ao filtro de compensação de compartimentalização (BCF) 652, que pode ser configurado upara processar os pixels de imagem para compensar pelo posicionamento não linear (por exemplo, distribuição espacial não uniforme) das amostras de cor devido à compartimentalização pelo(s) sensor(es) de imagem 90a ou 90b, de modo que as operações de processamento de imagem subsequentes na lógica de pipe de ISP 82 (por exemplo, interpolação, etc.) que dependem da colocação linear das amostras de cor possam operar corretamente. Por exemplo, com referência, agora, à Figura 59, uma amostra de resolução completa 693 de dados de imagem de Bayer é mostrada. Isso pode representar dados de imagem brutos de amostra de resolução completa capturados pelo sensor de imagem 90a (ou 90b) acoplado à lógica de processamento de front-end de ISP 80.

[000327] Conforme será constatado, sob certas condições de captura de imagem, pode não ser prático enviar os dados de imagem capturada de resolução total pelo sensor de imagem 90a para o conjunto de circuitos de ISP 32 para processamento. Por exemplo, ao capturar dados de vídeo, para preservar a aparência de uma imagem em movimento fluido a partir da perspectiva do olho humano, uma taxa de quadro de pelo menos aproximadamente 30 quadros por segundo pode ser desejada. Entretanto, se a quantidade de dados de pixel contida em cada quadro de uma amostra de resolução total exceder as capacidades de processamento do conjunto de circuitos de ISP 32 quando amostrada a 30 quadros por segundo, a filtragem de compensação de compartimentalização pode ser aplicada em conjunto com a compartimentalização pelo sensor de imagem 90a para reduzir a resolução do sinal de imagem enquanto também melhoram a razão de sinal para ruído. Por exemplo, conforme discutido acima, várias técnicas de compartimentalização, como a compartimentalização 2x2, podem ser aplicadas para produzir um pixel de imagem bruta "compartimentalizada" ao ponderar os valores de pixels circundantes na região ativa 312 do quadro bruto 310.

[000328] Com referência à Figura 60, uma modalidade do sensor de imagem 90a que pode ser configurada para compartimentalizar os dados de imagem de resolução total 693 da Figura 59 para produzir dados de imagem brutos compartimentalizados correspondentes 700 mostrados na Figura 61 é ilustrada de acordo com uma modalidade. Conforme mostrado, o sensor de imagem 90a pode capturar os dados de imagem brutos de resolução completa 693. A lógica de compartimentalização 699 pode ser configurada para aplicar compartimentalização aos dados de imagem brutos de resolução completa 693 para produzir os dados de imagem brutos compartimentalizados 700, que podem ser fornecidos à lógica de processamento de front-end de ISP 80 com o uso da interface de sensor 94a que, conforme discutido acima, pode ser uma interface SMIA ou quaisquer outras interfaces de câmera paralelas ou em série adequadas.

[000329] Conforme ilustrado na Figura 61, a lógica de compartimentalização 699 pode aplicar a compartimentalização 2x2 aos dados de imagem brutos de resolução completa 693. Por exemplo, em relação aos dados de imagem compartimentalizados 700, os pixels 695, 696, 697 e 698 podem formar um padrão Bayer e podem ser determinados ao ponderar os valores dos pixels a partir dos dados de imagem brutos de resolução completa 693. Por exemplo, com referência a ambas as Figuras 59 e 61, o pixel Gr compartimentalizado 695 pode ser determinado como a média ou mediana dos pixels Gr de resolução total 695a a 695d. De modo similar, o pixel R compartimentalizado 696 pode ser determinado como a média dos pixels R de resolução total 696a a 696d, o pixel B compartimentalizado 697 pode ser determinado como a média dos pixels B de resolução total 697a a 697d e o pixel Gb compartimentalizado 698 pode ser determinado como a média dos pixels Gb de resolução total 698a a 698d. Portanto, na presente modalidade, a compartimentalização 2x2 pode fornecer um conjunto de quatro pixels de resolução total, incluindo um pixel da esquerda superior (por exemplo, 695a), direita superior (por exemplo, 695b), esquerda inferior (por exemplo, 695c) e direita inferior (por exemplo, 695d) que são ponderados para derivar um pixel compartimentalizado localizado no centro de um quadrado formado pelo conjunto de quatro pixels de resolução total. Em conformidade, o bloco de Bayer compartimentalizado 694 mostrado na Figura 61 contém quatro "superpixels" que representam os 16 pixels contidos nos blocos Bayer 694a a 694d da Figura 59.

[000330] Além de reduzir a resolução espacial, a compartimentalização também oferece a vantagem adicionada de reduzir ruído no sinal de imagem. Por exemplo, quando um sensor de imagem (por exemplo, 90a) é exposto a um sinal de luz, pode haver uma certa quantia de ruído, como ruído de fóton, associada à imagem. Esse ruído pode ser aleatório ou sistemático e também pode vir de múltiplas fontes. Portanto, a quantidade de informações contidas em uma imagem capturada pelo sensor de imagem pode ser expressa em termos de uma razão de sinal para ruído. Por exemplo, cada vez que uma imagem é capturada por um sensor de imagem 90a e transferida para um circuito de processamento, como o conjunto de circuitos de ISP 32, pode haver algum grau de ruído nos valores de pixel porque o processo de leitura e transferência dos dados de imagem introduz inerentemente "ruído de leitura" no sinal de imagem. Esse "ruído de leitura" pode ser aleatório e é, em geral, inevitável. Ao usar a média de quatro pixels, ruído, (por exemplo, ruído de fóton) pode, em geral, ser reduzido independentemente da fonte do ruído.

[000331] Portanto, ao considerar os dados de imagem de resolução total 693 da Figura 59, cada padrão Bayer (bloco 2x2) 694a a 694d contém 4 pixels, cada um dos quais contém um sinal e componente de ruído. Se cada pixel, por exemplo, no bloco de Bayer 694a, for lido separadamente, então quatro componentes de sinal e quatro componentes de ruído estão presentes. Entretanto, ao aplicar a compartimentalização, conforme mostrado nas Figuras 59 e 61, de modo que quatro pixels (por exemplo, 695a, 695b, 695c, 695d) possam ser representados por um único pixel (por exemplo, 695) nos dados de imagem compartimentalizados, a mesma área ocupada pelos quatro pixels nos dados de imagem de resolução total 693 pode ser lida como um único pixel com apenas um caso de um componente de ruído, melhorando, assim, a razão de sinal para ruído.

[000332] Ademais, embora a presente modalidade mostre a lógica de compartimentalização 699 da Figura 60 como sendo configurada para aplicar um processo de compartimentalização de 2x2, deve-se constatar que a lógica de compartimentalização 699 pode ser configurada para aplicar qualquer tipo adequado de processo de compartimentalização, como a compartimentalização 3x3, compartimentalização vertical, compartimentalização horizontal e assim por diante. Em algumas modalidades, o sensor de imagem 90a pode ser configurada para selecionar dentre modos de compartimentalização diferentes durante o processo de captura de imagem. Adicionalmente, em modalidades adicionais, o sensor de imagem 90a também pode ser configurado para aplicar uma técnica que pode ser chamada de "omissão,"em que em vez de amostras de pixel médias, a lógica 699 seleciona apenas certos pixels dos dados de resolução completa 693 (por exemplo, um a cada dois pixels, um a cada 3 pixels, etc.) para emitir para a front-end de ISP 80 para o processamento. Ademais, embora apenas o sensor de imagem 90a seja mostrado na Figura 60, deve-se constatar que o sensor de imagem 90b pode ser implantado de maneira similar.

[000333] Conforme também é mostrado na Figura 61, um efeito do processo de compartimentalização é que a amostram espacial dos pixels compartimentalizados pode não ser igualmente espaçada. Essa distorção espacial pode, em alguns sistemas, resultar em aliasing (por exemplo, bordas denteadas), o que não é, em geral, desejável. Ademais, porque certas etapas de processamento de imagem na lógica de pipe de ISP 82 podem depender depende do posicionamento linear das amostras de cor para operar corretamente, o filtro de compensação de compartimentalização (BCF) 652 pode ser aplicado para realizar a reamostragem e o reposicionamento dos pixels compartimentalizados de modo que os pixels compartimentalizados estejam distribuídos espacial e uniformemente. Ou seja, o BCF 652 compensa, essencialmente, pela distribuição espacial não uniforme (por exemplo, mostrada na Figura 61) ao reamostrar a posição das amostras (por exemplo, pixels). Por exemplo, a Figura 62 ilustra uma porção reamostrada dos dados de imagem compartimentalizados 702 após ser processada pelo BCF 652, em que o bloco de Bayer 703 que contém os pixels reamostrados distribuídos de forma uniforme 704, 705, 706 e 707 correspondem aos pixels compartimentalizados 695, 696, 697 e 698, respectivamente, dos dados de imagem compartimentalizados 700 da Figura 61. Adicionalmente, em uma modalidade que utiliza omissão (por exemplo, em vez de compartimentalização), conforme mencionado acima, a distorção especial mostrada na Figura 61 pode não estar presente. Nesse caso, o BCF 652 pode funcionar como um filtro passa baixa para reduzir artefatos (por exemplo, aliasing) que podem ocorrer quando a omissão é empregada pelo sensor de imagem 90a.

[000334] A Figura 63 mostra um diagrama de bloco do filtro de compensação de compartimentalização 652 de acordo com uma modalidade. O BCF 652 pode incluir a lógica de compensação de compartimentalização 708 que pode processar pixels compartimentalizados 700 para aplicar escalonamento horizontal e vertical com o uso de lógica de escalonamento horizontal 709 e lógica de escalonamento vertical 710, respectivamente, para reamostrar e reposicionar os pixels compartimentalizados 700 de modo que estejam dispostos em uma distribuição espacialmente uniforme, conforme mostrado na Figura 62. Em uma modalidade, a(s) operação(ões) de escalonamento realizadas pelo BCF 652 podem ser realizadas com o uso de filtragem polifásica de múltiplos taps horizontal e vertical. Por exemplo, o processo de filtragem pode incluir a seleção dos pixels apropriados a partir dos dados de imagem de fonte de entrada (por exemplo, os dados de imagem compartimentalizados 700 fornecidos pelo sensor de imagem 90a), multiplicando cada um dos pixels selecionados por um coeficiente de filtragem, e somando os valores resultantes para formar um pixel de saída em um destino desejado.

[000335] A seleção dos pixels usados nas operações de escala, que podem incluir um pixel central e pixels vizinhos circundantes da mesma cor pode ser determinada com o uso de analisadores diferenciais separados 711, um para o escalonamento vertical e um para o escalonamento horizontal. Na modalidade retratada, os analisadores diferenciais 711 podem ser analisadores diferenciais digitais (DDAs) e podem ser configurados para controlar a posição de pixel de saída atual durante as operações de escalonamento nas direções vertical e horizontal. Na presente modalidade, um primeiro DDA (chamado de 711a) é usado para o escalonamento de todos os componentes de cor durante horizontal e um segundo DDA (chamado de 711b) é usado para todos os componentes de cor durante o escalonamento vertical. A título de exemplo, apenas, o DDA 711 pode ser fornecido como um registro de dados de 32 bits que contém um número de ponto fixo de complemento 2’s que tem 16 bits na porção inteira e 16 bits na fração. A porção inteira de 16 bits pode ser usada para determinar a posição atual para um pixel de saída. A porção fracional do DDA 711 pode ser usada para determinar um índice ou fase atual, que podem ser baseados na posição fracional entre pixels da posição atual do DDA (por exemplo, correspondente à localização espacial do pixel de saída). O índice ou fase pode ser usada para selecionar um conjunto de coeficientes apropriado a partir de tabelas de conjunto de coeficiente de filtro 712. Adicionalmente, a filtragem pode ser realizada por componente de cor com o uso de pixels de cores iguais. Portanto, os coeficientes de filtragem podem ser selecionados com base não apenas na fase da posição atual do DDA, mas também a cor do pixel atual. Em uma modalidade, 8 fases podem estar presentes entre cada pixel de entrada e, portanto, os componentes de escalonamento vertical e horizontal podem utilizar 8 tabelas de coeficientes profundos, de modo que os 3 bits de alta ordem da porção de fração de 16 bits sejam usados para expressar a fase ou índice atual. Portanto, conforme usado no presente documento, o termo dados de "imagem bruta" ou similares deve ser compreendido como se referindo a dados de imagem de múltiplas cores que são adquiridos por um único sensor com um padrão de matriz de filtro de cor (por exemplo, Bayer) sobrepondo o mesmo, sendo que os mesmos compreendem componentes de cor múltiplos em um plano. Em outra modalidade, DDAs separados podem ser usados para cada componente de cor. Por exemplo, em tais modalidades, o BCF 652 pode extrair os componentes de R, B, Gr, e Gb dos dados de imagem brutos e processar cada componente como um plano separado.

[000336] Em operação, o escalonamento horizontal e vertical pode incluir a inicialização do DDA 711 e a realização de filtragem polifásica de múltiplos taps com o uso das porções integral e fracional do DDA 711. Embora realizados separadamente e com DDAs separados, as operações de escalonamento horizontal e vertical são realizadas de maneira similar. Um valor de etapa ou tamanho de etapa (DDAStepX para escalonamento horizontal e DDAStepY para escalonamento vertical) determina quanto o valor de DDA (currDDA) é aumentado após cada pixel de saída ser determinado e a filtragem polifásica de múltiplos taps é repetida com o uso do próximo valor currDDA. Por exemplo, se o valor de etapa for menor que 1, então a imagem é escalonada ascendentemente e se o valor de etapa for maior que 1, a imagem é escalonada descendentemente. Se o valor de etapa for igual a 1, então nenhum escalonamento ocorre. Ademais, deve-se notar que etapas de tamanho igual ou diferentes podem ser usadas para o escalonamento horizontal e vertical.

[000337] Pixels de saída são gerados pelo BCF 652 na mesma ordem que pixels de entrada (por exemplo, com o uso do padrão Bayer). Na presente modalidade, os pixels de entrada podem ser classificados como sendo pares ou ímpares, com base em sua ordenação. Por exemplo, com referência à Figura 64, a representação gráfica das localizações de pixel de entrada (fileira 713) e as localizações de pixel de saída correspondentes com base em vários valores de Etapa de DDA (fileiras 714 a 718) são ilustradas. Nesse exemplo, a fileira retratada representa uma fileira de pixels vermelhos (R) e verdes (Gr) nos dados de imagem brutos de Bayer. Para fins de filtragem horizontal, o pixel vermelho na posição 0.0 na fileira 713 pode ser considerado como um pixel par, o pixel verde na posição 1.0 na fileira 713 pode ser considerado como um pixel ímpar e assim por diante. Para as localizações de pixel de saída, pixels pares e ímpares podem ser determinados com base no bit menos significativo na porção de fração (16 bits inferiores) do DDA 711. Por exemplo, presumindo uma etapa DDA de 1,25, conforme mostrado in fileira 715, o bit menos significativo corresponde ao bit 14 do DDA, já que esse bit fornece uma resolução de 0.25. Portanto, o pixel de saída vermelho na posição DDA (currDDA) 0.0 pode ser considerado como um pixel par (o bit menos significativo, bit 14, é 0), o pixel de saída verde em currDDA 1.0 (bit 14 é 1), e assim por diante. Ademais, embora a Figura 64 seja discutida em relação à filtragem na direção horizontal (com o uso de DDAStepX), deve-se compreender que a determinação de pixels de entrada e saída pares e ímpares pode ser aplicada da mesma maneira em relação à filtragem (com o uso de DDAStepY). Em outras modalidades, os DDAs 711 também podem ser usados para rastrear as localizações dos pixels de entrada (por exemplo, em vez de rastrear as localizações de pixel de saída desejadas). Ademais, deve-se constatar que as DDAStepX e DDAStepY podem ser configuradas para valores iguais ou diferentes. Ademais, presumindo que um padrão Bayer seja usado, deve-se notar que o pixel inicial usado pelo BCF 652 poderia ser qualquer um dentre um pixel Gr, Gb, R, ou B, dependendo, por exemplo, de qual pixel está localizado em um canto na região ativa 312.

[000338] Com isso em mente, os pixels pares/ímpares de entrada são usados para gerar os pixels pares/ímpares de saída, respectivamente. Dado que uma localização de pixel de saída alternante entre a posição par e ímpar, uma localização de pixel de entrada de fonte central (chamada aqui de "currPixel") para fins de filtragem é determinada ao arredondar o DDA para a localização de pixel de entrada par ou ímpar mais próxima para a localização de pixels de saída par ou ímpar (com base em DDAStepX), respectivamente. Em uma modalidade em que o DDA 711a está configurado para usar 16 bits para representar um número inteiro 16 bits para representar uma fração, currPixel pode ser determinado para as posições de currDDA par e ímpar como uso das Equações 6a e 6b abaixo:

[000339] As localizações de Pixel de saída par podem ser determinadas com base nos bits [31:16] de:

[000340] As localizações de pixel de saída ímpares podem ser determinadas com base nos bits [31:16] de:

[000341] Essencialmente, as equações acima apresentam uma operação de arredondamento, através das quais as posições de pixel de saída pares e ímpares, conforme determinado por currDDA são arredondadas para as posições de pixel de entrada pares e ímpares mais próximas, respectivamente, para a seleção de currPixel.

[000342] Adicionalmente, um índice ou fase atual (currIndex) também pode ser determinado em cada posição currDDA. Conforme discutido acima, os valores de índice ou fase representam a posição entre-pixel fracional do pixel de saída position em relação às posições do pixel de entrada. Por exemplo, em uma modalidade, 8 fases podem ser definidas entre cada posição de pixel de entrada. Por exemplo, com referência, novamente, à Figura 64, 8 valores de índice de 0 a 7 são fornecidos entre o primeiro pixel vermelho de entrada na posição 0.0 e o próximo pixel vermelho de entrada na posição 2.0. Similarmente, 8 valores de índice 0 a 7 são fornecidos entre o primeiro pixel de entrada verde na posição 1.0 e o próximo pixel de entrada verde na posição 3.0. Em uma modalidade, os valores de currIndex podem ser determinados de acordo com as Equações 7a e 7b abaixo para localizações de pixel de saída pares e ímpares, respectivamente:

[000343] Localizações de pixel de saída pares podem ser determinadas com base nos bits [16:14] de:

[000344] Localizações de pixel de saída ímpares podem ser determinadas com base nos bits [16:14] de:

[000345] Para as posições ímpares, o deslocamento de 1 pixel adicional é equivalente à adição de um deslocamento de quatro para o índice de coeficiente para localizações de pixel de saída ímpares para dar conta do deslocamento de índice entre componentes de cor diferentes em relação ao DDA 711.

[000346] Uma vez que os currPixel e currIndex foram determinados como uma localização de currDDA particular, o processo de filtragem pode selecionar um ou mais pixels vizinhos da mesma cor com base no currPixel (o pixel de entrada central selecionado). A título de exemplo, em uma modalidade em que a lógica de escalonamento horizontal 709 inclui um filtro polifásico de 5 taps e a lógica de escalonamento vertical 710 inclui um filtro polifásico de 3 taps, dois pixels da mesma cor em cada lado de currPixel na direção horizontal podem ser selecionados para a filtragem horizontal (por exemplo, -2, -1, 0, +1, +2) e um pixel de mesma cor em cada lado do currPixel na direção vertical pode ser selecionado para a filtragem vertical (por exemplo, -1, 0, +1). Ademais, currIndex pode ser usado como um índice de seleção para selecionar os coeficientes de filtragem apropriados a partir da tabelas de coeficiente de filtro 712 para aplicar aos pixels selecionados. Por exemplo, com o uso da modalidade de filtragem horizontal de 5 taps/vertical de 3 taps, cinco tabelas de profundidade 8 podem ser fornecidas para a filtragem horizontal e três tabelas de profundidade 8 podem ser fornecidas para a filtragem vertical. Embora ilustrado como parte do BCF 652, deve-se constatar que as tabelas de coeficiente de filtro 712 podem, em certas modalidades, ser armazenadas em uma memória que é fisicamente separada do BCF 652, como a memória 108.

[000347] Antes de discutir as operações de escalonamento horizontal e vertical com mais detalhes, a Tabela 5 abaixo mostra exemplos de como os valores de currPixel e currIndex, conforme determinado com base em várias posições de DDA com o uso de diferentes valores de DDAStep (por exemplo, poderia aplicar a DDAStepX ou DDAStepY).

Tabela 5: Filtro de compensação de compartimentalização - Exemplos de DDA de cálculo de currPixel e currIndex

[000348] Para fornecer u exemplo, presuma que um tamanho de etapa de DDA (DDAStep) de 1.5 é selecionado (fileira 716 da Figura 64), com a posição de DDA atual (currDDA) começando em 0, indicando uma posição de pixel de saída par. Para determinar currPixel, a Equação 6a tem que ser aplicada, conforme mostrado abaixo:

currPixel (determinado como bits [31:16] do resultado) = 0; Portanto, na posição currDDA 0.0 (fileira 716), o pixel central de entrada de fonte para filtragem corresponde ao pixel de entrada vermelho na posição 0.0 da fileira 713.

[000349] Para determinar currIndex no currDDA 0.0 par, a Equação 7a pode ser aplicada, conforme mostrado abaixo:

currIndex (determinado como bits [16:14] do resultado) = [000] = 0; Portanto, na posição currDDA 0.0 (fileira 716), um valor de currIndex de 0 pode ser usado para selecionar os coeficientes de filtragem a partir das tabelas de coeficiente de filtro 712.

[000350] Em conformidade, a filtragem (que pode ser vertical ou horizontal, dependendo de se a DDAStep está na direção X (horizontal) ou Y (vertical)) pode ser aplicada com base nos valores de currPixel e currIndex determinados em currDDA 0.0, e o DDA 711 é aumentado pela DDAStep (1.5), e os próximos valores de currPixel e currIndex são determinados. Por exemplo, na próxima posição currDDA 1.5 (uma posição ímpar), o currPixel pode ser determinado com o uso da Equação 6b, conforme segue:

currPixel (determinado como bits [31:16] do resultado) = 1; Portanto, na posição de currDDA 1.5 (fileira 716), o pixel central de entrada de fonte para filtrar corresponde ao pixel de entrada verde na posição 1.0 da fileira 713.

[000351] Ademais, o índice atual no currDDA 1.5 par pode ser determinado com o uso da Equação 7b, conforme mostrado abaixo:

currIndex (determinado como os bits [16:14] do resultado) = [010] = 2; Portanto, na posição de currDDA 1.5 (fileira 716), um valor de currIndex de 2 pode ser usado para selecionar os coeficientes de filtragem apropriados a partir das tabelas de coeficiente de filtro 712. A filtragem (que pode ser vertical ou horizontal, dependendo de se a DDAStep está na direção X (horizontal) ou Y (vertical)) pode, portanto, ser aplicada com o uso desses valores de currPixel e currIndex.

[000352] A seguir, o DDA 711 é aumentado novamente pela DDAStep (1.5), resultando em um valor de currDDA de 3.0. o currPixel correspondente a currDDA 3.0 pode ser determinado com o uso da Equação 6a, conforme mostrado abaixo:

currPixel (determinado como bits [31:16] do resultado) = 4; Portanto, na posição de currDDA 3.0 (fileira 716), o pixel central de entrada de fonte para a filtragem corresponde ao pixel de entrada vermelho na posição 4.0 da fileira 713.

[000353] A seguir, o currIndex no currDDA par 3.0 pode ser determinado com ouso da Equação 7a, conforme mostrado abaixo:

currIndex (determinado como bits [16:14] do resultado) = [100] = 4;

[000354] Portanto, na posição currDDA 3.0 (fileira 716), um valor currIndex de 4 pode ser usado para selecionar os coeficientes de filtragem apropriados a partir das tabelas de coeficiente de filtro 712. Conforme será constatado, o DDA 711 pode continuar a ser aumentado por DDAStep para cada pixel de saída e a filtragem (que pode ser vertical ou horizontal, dependendo de se a DDAStep está na direção X (horizontal) ou Y (vertical)) pode ser aplicada com o uso do currPixel e currIndex determinado para cada valor de currDDA.

[000355] Conforme discutido acima, o currIndex pode ser usado como um índice de seleção para selecionar os coeficientes de filtragem apropriados a partir das tabelas de coeficiente de filtro 712 para aplicar aos pixels selecionados. O processo de filtragem pode incluir obter os valores de pixel de fonte acerca do pixel central (currPixel), multiplicando cada um dos pixels selecionados pelos coeficientes de filtragem apropriados selecionados a partir das tabelas de coeficiente de filtro 712 com base em currIndex, e somando os resultados para obter um valor do pixel de saída na localização correspondente ao currDDA. Ademais, devido à presente modalidade utilizar 8 fases entre pixels da mesma cor, o uso da modalidade de filtragem horizontal de 5 taps/vertical de 3 taps, tabelas de profundidade 8 podem ser fornecidas para a filtragem horizontal e três tabelas de profundidade 8 podem ser fornecida para a filtragem vertical. Em uma modalidade, cada uma das entradas da tabela de coeficiente pode incluir um número de ponto fixo de complemento de 2 de 16 com 3 bits inteiros e 13 frações de bits.

[000356] Ademais, presumindo um padrão de imagem de Bayer, em uma modalidade, o componente de escalonamento vertical pode incluir quatro filtros polifásicos de 3 taps separados, um para cada componente de cor: Gr, R, B, e Gb. Cada um dos filtros de 3 taps pode usar o DDA 711 para controlar o progresso do pixel central atual e o índice para os coeficientes, conforme descrito acima. Similarmente, os componentes de escalonamento horizontal podem incluir quatro filtros polifásicos de 5 taps separados, um para cada componente de cor: Gr, R, B, e Gb. Cada um dos filtros de 5 taps pode usar o DDA 711 para controlar o progresso (por exemplo., através de DDAStep) do pixel central atual e do índice para os coeficientes. Deve-se compreender, entretanto, que menos ou mais taps poderiam ser utilizados pelas escalas horizontal e vertical em outras modalidades.

[000357] Para casos limítrofes, os pixels usados no processo de filtragem horizontal e vertical podem depender das relações da posição de DDA atual (currDDA) relativa a uma borda de quadro (por exemplo, borda definida pela região ativa 312 na Figura 23). Por exemplo, na filtragem horizontal, se a posição de currDDA, quando comparada à posição do pixel de entrada central (SrcX) e à largura (SrcWidth) do quadro (por exemplo, largura 322 da região ativa 312 da Figura 23), indicar que o DDA 711 está próximo à borda de modo que não haja pixels o suficiente para realizar a filtragem de 5 taps, então pixels de borda de entrada de mesma cor podem ser repetidos. Por exemplo, se o pixel de entrada central selecionado estiver na borda esquerda do quadro, então o pixel central pode ser replicado duas vezes para a filtragem horizontal. Se o pixel de entrada central estiver próximo à borda esquerda do quadro de modo que apenas um pixel esteja disponível entre o pixel de entrada central e a borda esquerda, então, para fins de filtragem horizontal, o único pixel disponível é replicado para fornecer valores de dois pixels à esquerda do pixel de entrada central. Ademais, a lógica de escalonamento horizontal 709 pode ser configurada de modo que o número de pixels de entrada (incluindo pixels originais e replicados) não exceda a largura de entrada. Isso pode ser expresso conforme segue:

[000358] em que, DDAInitX representa a posição inicial do DDA 711, DDAStepX representa o valor de etapa de DDA na direção horizontal e BCFOutWidth representa a largura de saída do quadro pelo BCF 652.

[000359] Para a filtragem vertical, se a posição currDDA, quando comparada à posição do pixel de entrada central (SrcY) e a largura (SrcHeight) do quadro (por exemplo, largura 322 da região ativa 312 da Figura 23) indicar que o DDA 711 está próximo à borda de modo que não haja pixels o suficiente para realizar a filtragem de 3 taps, então os pixels de borda de entrada podem ser repetidos. Ademais, a lógica de escalonamento vertical 710 pode ser configurada de modo que o número de pixels de entrada (incluindo pixels originais e replicados) não possa exceder a altura de entrada. Isso pode ser expresso conforme segue:

[000360] em que, DDAInitY representa a posição inicial do DDA 711, DDAStepY representa o valor de etapa de DDA na direção vertical e BCFOutHeight representa a largura da saída de quadro pelo BCF 652.

[000361] Com referência, agora, à Figura 65, um fluxograma que mostra um método 720 para aplicar filtragem de compensação de compartimentalização aos dados de imagem recebidos pela unidade de processamento de pixel de front-end 150, de acordo com uma modalidade. Será constatado que o método 720 ilustrado na Figura 65 pode ser aplicado a ambos os escalonamentos vertical e horizontal. Iniciando na etapa 721, o DDA 711 é inicializado e um valor de etapa de DDA (que pode corresponder à DDAStepX para escalonamento horizontal e DDAStepY para escalonamento vertical) é determinado. A seguir, na etapa 722, uma posição de DDA atual (currDDA), com base na DDAStep, é determinada. Conforme discutido acima, currDDA pode corresponder a uma localização de pixel de saída. Com o uso de currDDA, o método 720 pode determinar um pixel central (currPixel) a partir da entrada de dados de pixel que podem ser usados para a filtragem de compensação de compartimentalização para determinar um valor de saída correspondente em currDDA, conforme indicado na etapa 723. Subsequentemente, na etapa 724, um índice correspondente a currDDA (currIndex) pode ser determinado com base na posição entre-pixel fracional do currDDA em relação aos pixels de entrada (por exemplo, fileira 713 da Figura 64). A título de exemplo, em uma modalidade em que o DDA inclui 16 bits inteiros e 16 bits fracionais, currPixel pode ser determinado de acordo com as Equações 6a e 6b e o currIndex pode ser determinado de acordo com as Equações 7a e 7b, conforme mostrado acima. Embora a configuração de 16 bits inteiros /16 bits fracionais seja descrita no presente documento como um exemplo, deve-se constatar que outras configurações do DDA 711 podem ser utilizadas de acordo com a presente técnica. A título de exemplo, outras modalidades do DDA 711 podem ser configuradas para incluir uma porção inteira de 12 bits e uma porção fracional de 20 bits, uma porção inteira de 14 bits e uma porção fracional de 18 bits e assim por diante.

[000362] Uma vez que currPixel e currIndex são determinados, pixels de fonte de mesma cor acerca de currPixel podem ser selecionados para a filtragem de múltiplos taps, conforme indicado pela etapa 725. Por exemplo, conforme discutido acima, uma modalidade pode utilizar a filtragem polifásica de 5 taps na direção horizontal (por exemplo, selecionando 2 pixels da mesma cor em cada lado do currPixel) e pode utilizar a filtragem polifásica de 3 taps na direção vertical (por exemplo, selecionando 1 pixel de mesma cor em cada lado do currPixel). A seguir, na etapa 726, uma vez que os pixels de fonte são selecionados, os coeficientes de filtragem podem ser selecionados a partir das tabelas de coeficiente de filtro 712 do BCF 652 com base no currIndex.

[000363] Posteriormente, na etapa 727, a filtragem pode ser aplicada aos pixels de fonte para determinar o valor de um pixel de saída correspondente à posição representada por currDDA. Por exemplo, em uma modalidade, os pixels de fonte podem ser multiplicados por seus respectivos coeficientes de filtragem e os resultados podem ser somados para obter o valor de pixel de saída. A direção na qual a filtragem é aplicada na etapa 727 pode ser vertical ou horizontal, dependendo em se a DDAStep está na direção X (horizontal) ou Y (vertical). Finalmente, na etapa 263, o DDA 711 é aumentado pela DDAStep na etapa 728 e o método 720 retorna à etapa 722, através da qual o próximo valor de pixel de saída é determinado com o uso de técnicas de filtragem de compensação de compartimentalização discutidas no presente documento.

[000364] Com referência à Figura 66, a etapa 723 para determinar o currPixel a partir do método 720 é ilustrada com mais detalhes, de acordo com uma modalidade. Por exemplo, a etapa 723 pode incluir a subetapa 729 de determinação sobre se a localização de pixel de saída correspondente ao currDDA (da etapa 722) é par ou ímpar. Conforme discutido acima, um pixel de saída par ou ímpar pode ser determinado com base no bit menos significativo de currDDA com base na DDAStep. Por exemplo, dada uma DDAStep de 1.25, um valor de currDDA de 1,25 pode ser determinado como ímpar, já que o bit menos significativo (correspondente ao bit 14 da porção fracional do DDA 711) tem um valor de 1. Para um valor de currDDA de 2,5, o bit 14 é 0, indicando, assim uma localização de pixel de saída par.

[000365] Na lógica de decisão 730, uma determinação é realizada em relação a se a localização de pixel de saída correspondente a currDDA é par ou ímpar. Se o pixel de saída for par, a lógica de decisão 730 continua para a subetapa 731, em que o currPixel é determinado pelo aumento do valor de currDDA em 1 e arredondamento do resultado para a localização de pixel de entrada par mais próximo, conforme representado pela Equação 6a acima. Se o pixel de saída for ímpar, então a lógica de decisão 730 continua para a subetapa 732, em que o currPixel é determinado pelo arredondamento do valor de currDDA para a localização de pixel de entrada ímpar mais próxima, conforme representado pela Equação 6b acima. O valor de currPixel pode, então, ser aplicado à etapa 725 do método 720 para selecionar pixels de fonte para a filtragem, conforme discutido acima.

[000366] Com referência, também, à Figura 67, a etapa 724 para determinar o currIndex a partir do método 720, é ilustrada com maiores detalhes, de acordo com uma modalidade. Por exemplo, a etapa 724 pode incluir a subetapa 733 de determinação de se a localização de pixel de saída correspondente ao currDDA (da etapa 722) é par ou ímpar. Essa determinação pode ser realizada de maneira similar à etapa 729 da Figura 66. Na lógica de decisão 734, uma determinação é realizada em relação a se a localização de pixel de saída correspondente a currDDA é par ou ímpar. Se o pixel de saída for par, a lógica de decisão 734 continua para a subetapa 735, em que o currIndex é determinado pelo aumento do valor de currDDA por uma etapa de índice que determina o currIndex com base no bit inteiro de orem mais baixa os dois bits fracionais de ordem mais alta do DDA 711. Por exemplo, em uma modalidade em que 8 fases são fornecidas entre cada pixel de mesma cor, e em que o DDA inclui 16 bits inteiros e 16 bits fracionais, uma etapa de índice pode corresponder a 0.125, e o currIndex pode ser determinado com base em bits [16:14] do valor de currDDA aumentado em 0.125 (por exemplo, Equação 7a). Se o pixel de saída for ímpar, a lógica de decisão 734 continua para a subetapa 736, em que o currIndex é determinado ao aumentar o valor de currDDA em uma etapa de índice e um deslocamento de pixel, e determina o currIndex com base no bit inteiro de ordem mais baixa e nos dois bits fracionais de ordem mais alta do DDA 711. Portanto, em uma modalidade em que 8 fases são fornecidas entre cada pixel de mesma cor e em que o DDA inclui 16 bits inteiros e 16 bits fracionais, uma etapa de índice pode corresponder a 0.125, um deslocamento de pixel pode corresponder a 1.0 (um deslocamento de 8 etapas de índice para o próximo pixel de mesma cor) e o currIndex pode ser determinado com base nos bits [16:14] do valor de currDDA aumentado em 1.125 (por exemplo, Equação 7b).

[000367] Embora a modalidade aqui ilustrada forneça o BCF 652 como um componente da unidade de processamento de pixel de frontend 150, outras modalidades podem incorporar o BCF 652 em uma pipeline de processamento de dados de imagem brutos do pipe de ISP 82 que, conforme discutido adicionalmente abaixo, pode incluir lógica de detecção/correção de pixel defectivo, blocos de ganho/deslocamento/compensação, lógica de redução de ruído, lógica de correção de sombreamento de lente, e lógica de interpolação. Ademais, em modalidades em que a lógica de detecção/correção de pixel defectivo, blocos de ganho/deslocamento/compensação, lógica de redução de ruído, lógica de correção de sombreamento de lente supracitados não contam com o posicionamento linear dos pixels, o BCF 652 pode ser incorporado com a lógica de interpolação para realizar a filtragem de compensação de compartimentalização e reposicionar os pixels anteriormente à interpolação, já que a interpolação conta, em geral, com o posicionamento espacial par dos pixels. Por exemplo, em uma modalidade, o BCF 652 pode ser incorporado em qualquer lugar entre a entrada de sensor e a lógica de interpolação, sendo que temporização de filtro e/ou detecção/correção de pixel defectivo são aplicadas aos dados de imagem brutos anteriormente à compensação de compartimentalização.

[000368] Conforme discutido acima, a saída do BCF 652, que pode ser a saída FEProcOut (109) que tem dados de imagem distribuídos espacialmente uniformemente (por exemplo, amostra 702 da Figura 62), pode ser encaminhada para a lógica de processamento de pipe de ISP 82 para processamento adicional. Entretanto, antes do deslocamento de foco dessa discussão para a lógica de processamento de pipe de ISP 82, uma descrição mais detalhada de várias funcionalidades que pode ser fornecida pelas unidades de processamentos de estatística (por exemplo, 142 e 144) que podem ser implantadas na lógica de frontend de ISP 80 serão primeiramente fornecidas.

[000369] Com referência, novamente, á descrição geral das unidades de processamentos de estatística 142 e 144, essas unidades podem ser configuradas para coletar várias estatísticas sobre os sensores de imagem que capturam e fornecem os sinais de imagem brutos (Sif0 e Sif1), como estatísticas referentes à auto-exposição, auto-equilíbrio de branco, autofoco, detecção de oscilação, compensação de nível de preto e correção de sombreamento de lente e assim por diante. Ao fazer isso, as unidades de processamentos de estatística 142 e 144 podem primeiramente aplicar uma ou mais operações de processamento de imagem a seus respectivos sinais de entrada, Sif0 (do Sensor0) e Sif1 (do Sensor1).

[000370] Por exemplo, com referência à Figura 68, uma vista de diagrama de bloco mais detalhada das unidades de processamento de estatística 142 associadas ao Sensor0 (90a) é ilustrada de acordo com uma modalidade. Conforme mostrado, as unidades de processamento de estatística 142 podem incluir os seguintes blocos funcionais: detecção de pixel defectivo e lógica de correção 738, lógica de compensação de nível de preto (BLC) 739, lógica de correção de sombreamento de lente 740, lógica de BLC inversa 741 e lógica de coleta de estatísticas 742. Cada um desses blocos funcionais será discutido abaixo. Ademais, deve-se compreender que as unidades de processamento de estatística 144 associadas ao Sensor1 (90b) podem ser implantadas de maneira similar.

[000371] Inicialmente, a saída da lógica de seleção 146 (por exemplo, Sif0 ou SifIn0) é recebida pela lógica de correção de pixel defectivo de front-end 738. Conforme será constatado, "pixels defectivos" podem ser compreendidos como se referindo a pixels de imageamento com o(s) sensor(es) de imagem 90 que não obtêm sucesso ao captar níveis de luz com precisão. Os pixels defectivos podem ser atribuíveis a um número de fatores e podem incluir pixels "quentes" (ou vazados), pixels "presos" e "pixels mortos." Um "pixel quente" aparece, em geral, como sendo mais claro que um pixel não defectivo dada a mesma quantidade de luz na mesma localização espacial. Pixels quentes podem resultar devido a falhas de reinicialização e/ou alto vazamento. Por exemplo, um pixel quente pode exibir um vazamento de carga mais alto que o normal em relação aos pixels não defectivos e, portanto, pode parecer mais claro que outros pixels não defectivos. Adicionalmente, pixels "mortos" e "presos" podem ser o resultado de impurezas, como poeira ou outros materiais de rastro, que contaminam o sensor de imagem durante o processo de fabricação e/ou montagem, que pode levar certos pixels defectivos a serem mais escuros ou mais claros que um pixel não defectivo ou pode levar um pixel defectivo a ser fixado em um valor particular independentemente da quantidade de luz a qual está de fato exposto. Adicionalmente, pixels mortos e presos também podem resultar de falhas de circuito que ocorrem durante a operação do sensor de imagem. A título de exemplo, um pixel preso pode parecer como sempre estando ativado (por exemplo, totalmente carregado) e portanto parecer mais claro, enquanto um pixel morto parece estar sempre desativado.

[000372] A lógica de detecção e correção de pixel defectivo (DPDC) 738 na lógica de front-end de ISP 80 pode corrigir (por exemplo, substituir valores de pixel defectivo) pixels defectivos antes que sejam considerados na coleta de estatísticas (por exemplo, 742). Em uma modalidade, a correção de pixel defectivo é realizada independentemente para cada componente de cor (por exemplo, R, B, Gr, e Gb para um padrão de Bayer). Em geral, a lógica de front-end DPDC 738 pode fornecer a correção de defeito dinâmica, em que os locais de pixels defectivos são determinados automaticamente com base em gradientes direcionais computados com o uso de pixels vizinhos da mesma cor. Conforme será compreendido, os defeitos podem ser "dinâmicos"no sentido de que a caracterização de um pixel como sendo defectivo em um dado tempo pode depender dos dados de imagem nos pixels vizinhos. A título de exemplo, um pixel preso que esta sempre em claridade máxima pode não ser tido como um pixel defectivo se a localização do pixel preso estiver em uma área da imagem atual que seja dominada por cores mais claras ou branco. De modo contrário, se o pixel preso estiver em uma região da imagem atual que está dominada por preto ou cores mais escuras, então o pixel preso pode ser identificado como um pixel defectivo durante o processamento pela lógica de DPDC 738 e corrigido em conformidade.

[000373] A lógica de DPDC 738 pode utilizar um ou mais pixels vizinhos horizontais de mesma cor em cada lado de um pixel atual para determinar se o pixel atual é defectivo com o uso de gradientes direcionais pixel por pixel. Se um pixel atual for identificado como sendo defectivo, o valor do pixel defectivo pode ser substituído pelo valor de um pixel vizinho horizontal. Por exemplo, em uma modalidade, cinco pixels horizontais vizinhos da mesma cor que estão dentro do limite do quadro bruto 310 (Figura 23) são usados, em que os cinco pixels vizinhos horizontais incluem o pixel atual e dois pixels vizinhos em cada lado. Portanto, conforme ilustrado na Figura 69, para um dado componente de cor c e para o pixel atual P, os pixels vizinhos horizontais P0, P1, P2, e P3 podem ser considerados pela lógica de DPDC 738. Deve-se notar, entretanto, que, dependendo da localização do pixel atual P, os pixels fora do quadro bruto 310 não são considerados ao calcular os gradientes pixel por pixel.

[000374] Por exemplo, conforme mostrado na Figura 69, em um caso de "borda esquerda" 743, o pixel atual P está na borda mais à esquerda do quadro bruto 310 e, portanto, os pixels vizinhos P0 e P1 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P, P2, e P3 (N=3). Em um caso "borda esquerda + 1" 744, o pixel atual P está a um pixel de unidade da borda mais à esquerda do quadro bruto 310 e, portanto, o pixel P0 não é considerado. Isso deixa apenas os pixels P1, P, P2, e P3 (N=4). Ademais, em um caso "centralizado" 745, os pixels P0 e P1 no lado esquerdo do pixel atual P e os pixels P2 e P3 no lado direito do pixel atual P estão no limite de quadro bruto 310 e, portanto, todos os pixels vizinhos P0, P1, P2, e P3 (N=5) são considerados no cálculo de gradientes de pixel por pixel. Adicionalmente, casos similares 746 e 747 que podem ser encontrados na borda mais à direita do quadro bruto 310 são abordados. Por exemplo, dado o caso de "borda direita - 1" 746, o pixel atual P está a um pixel de unidade da borda mais à direita do quadro bruto 310 e, portanto, o pixel P3 não é considerado (N=4). De modo similar, no caso da "borda direita" 747, o pixel atual P está na borda mais à direita do quadro bruto 310 e portanto, ambos os pixels vizinhos pixels P2 e P3 não são considerados (N=3).

[000375] Na modalidade ilustrada, para cada pixel vizinho (k = 0 a 3) no limite da figura (por exemplo, quadro bruto 310), os gradientes de pixel a pixel podem ser calculados conforme segue:

[000376] Uma vez que os gradientes pixel a pixel foram determinados, a detecção de pixel defectivo pode ser realizada pela lógica de DPDC 738 conforme segue. Primeiramente, presume-se que um pixel é defectivo se um certo número de seus gradientes Gk estiverem em ou abaixo de um limite particular, denotado pela variável dprTh. Portanto, para cada pixel, uma contagem (C) do número de gradientes para pixels vizinhos dentro dos limites que estão em ou abaixo do limite dprTh é acumulada. A título de exemplo, para cada pixel vizinho dentro do quadro bruto 310, a contagem acumulada C dos gradientes Gk que estão em ou abaixo do limite dprTh podem ser computados conforme segue:

para 0<k<3(apenas para k no quadro bruto)

[000377] Conforme será constatado, dependendo dos componentes de cor, o valor limite dprTh pode variar. A seguir, se a contagem acumulada C for determinada como sendo menor ou igual a uma contagem máxima, denotada pela variável dprMaxC, então o pixel pode ser considerado defectivo. Essa lógica é expressa abaixo:

[000378] Pixels defectivos são substituídos com o uso de um número de convenções de substituição. Por exemplo, em uma modalidade, um pixel defectivo pode ser substituído pelo pixel à sua esquerda imediata, P1. Em uma condição limite (por exemplo, P1 está fora do quadro bruto 310), um pixel defectivo pode ser substituído pelo pixel à sua direita imediata, P2. Ademais, deve-se compreender que os valores de substituição podem ser retidos ou propagados pra operações de detecção de pixel defectivo sucessivas. Por exemplo, com referência ao conjunto de horizontal pixels mostrado na Figura 69, se P0 ou P1 foram previamente identificados pela lógica DPDC 738 como sendo pixels defectivos, seus valores de substituição correspondentes podem ser usados para a detecção de pixel defectivo e substituição do pixel atual P.

[000379] Para resumir a detecção de pixel defectivo discutida acima e técnicas de correção, um fluxograma que mostra tal processo é fornecido na Figura 70 e referido pelo número de referência 748. Conforme mostrado, o processo 748 começa na etapa 749, no qual um pixel atual (P) é recebido e um conjunto de pixels vizinhos é identificado. De acordo com a modalidade descrita acima, os pixels vizinhos podem incluir dois pixels horizontais do mesmo componente de cor a partir de lados opostos do pixel atual (por exemplo, P0, P1, P2, e P3). A seguir, na etapa 750, gradientes pixel a pixel horizontais são calculados em relação a cada pixel vizinho no quadro bruto 310, conforme descrito na Equação 8 acima. Posteriormente, na etapa 751, uma contagem C do número de gradientes que são menores ou iguais a um limite particular dprTh é determinada. Conforme mostrado na lógica de decisão 752, se C for menor ou igual a dprMaxC, então o processo 748 continua para a etapa 753, e o pixel atual é identificado como sendo defectivo. O pixel defectivo é, então, corrigido na etapa 754 com o uso de um valor de substituição. Adicionalmente, com referencia, novamente, à lógica de decisão 752, se C é maior que dprMaxC, então o processo continua para a etapa 755 e o pixel atual é identificado como não sendo defectivo e seu valor não é modificado.

[000380] Deve-se notar que as técnicas de detecção/correção de pixel defectivo aplicadas durante os processamentos de estatística de frontend de ISP podem ser menos robustas que a detecção/correção de pixel defectivo que é realizada na lógica de pipe de ISP 82. Por exemplo, conforme será discutido com mais detalhes abaixo, detecção/correção de pixel defectivo realizada na lógica de pipe de ISP 82 pode, além da correção de defeito dinâmica, fornecer adicionalmente a correção de efeito fixo, em que as localizações de pixels defectivos são conhecidas a priori e carregadas em uma ou mais tabelas de defeito. Ademais, a correção de defeito dinâmica na lógica de pipe de ISP 82 também pode considerar gradientes de pixel em ambas as direções horizontal e vertical e também pode fornecer a detecção/correção de ruído mancha, conforme será discutido abaixo.

[000381] Voltando à Figura 68, a saída da lógica de DPDC 738 é, então, passada para a lógica de compensação de nível de preto (BLC) 739. A lógica de BLC 739 pode fornecer ganho digital, deslocamento e recorte, independentemente de cada componente de cor "c" (por exemplo, R, B, Gr e Gb para Bayer) nos pixels usados para a coleta de estatísticas. Por exemplo, conforme expresso pela operação a seguir, o valor de entrada para o pixel atual é o primeiro desvio por um valor assinado e, então, multiplicado por um ganho.

[000382] em que X representa o valor de pixel de entrada para um dado componente de cor c (por exemplo, R, B, Gr ou Gb), O[c] representa um deslocamento de 16 bits assinado para o componente de cor c atual e G[c] representa um valor de ganho para o componente de cor c. Em uma modalidade, o ganho G[c] pode ser um número não assinado de 16 bits com 2 bits inteiros 14 bits fracionais (por exemplo, 2.14 na representação de ponto de flutuação) e o ganho G[c] pode ser aplicado com arredondamento. A título de exemplo, apenas, o ganho G[c] pode ter uma faixa entre 0 e 4X (por exemplo, 4 vezes o valor do pixel de entrada).

[000383] A seguir, conforme mostrado pela Equação 12 abaixo, o valor computado Y, que é assinado, pode, então, ser recortado para uma faixa mínima e máxima:

[000384] As variáveis min[c] e max[c] podem representar "valores de recorte" de 16 bits assinados para os valores de saída mínimos e máximos, respectivamente. Em uma modalidade, a lógica de BLC 739 também pode ser configurada para manter uma contagem do número de pixels que foram recortados acima e abaixo do máximo e do mínimo, respectivamente, por componente de cor.

[000385] Subsequentemente, a saída da lógica BLC 739 é encaminhada para a lógica de correção de sombreamento de lente (LSC) 740. A lógica de LSC 740 pode ser configurada para aplicar um ganho apropriado em uma base por pixel para compensar quedas de intensidade, que são, em geral, quase proporcionais à distância a partir do centro óptico da lente 88 do dispositivo de imageamento 30. Conforme pode ser constatado, tais quedas podem ser o resultado da óptica geométrica da lente. A título de exemplo, uma lente que tem propriedades ópticas ideais pode ser modelada como a quarta potência do cosseno do ângulo incidente, cos4(θ), chamado de lei de cos4. Entretanto, porque a fabricação da lente não é perfeita, várias irregularidades na lente podem levar as propriedades ópticas a desviarem do modelo cos4 presumido. Por exemplo, as bordas mais finas da lente normalmente exibem a maior parte das irregularidades. Adicionalmente, as irregularidades em padrões de sombreamento da lente também podem ser resultado de um arranjo de microlente em um sensor de imagem que não está perfeitamente alinhado com o filtro de matriz de cor. Ademais, o filtro de infravermelho (IR) em algumas lentes pode fazer com que a queda seja dependente de iluminação e, portanto, ganhos de sombreamento de lente podem ser adaptados, dependendo da fonte de luz detectada.

[000386] Com referência à Figura 71, um perfil tridimensional 756 que mostra a intensidade de luz versus a posição de pixel para uma lente típica é ilustrado. Conforme mostrado, a intensidade de luz próxima ao centro 757 da lente gradualmente cai em direção aos cantos ou bordas 758 da lente. As irregularidades de sombreamento da lente mostradas na Figura 71 podem ser mais bem ilustradas pela Figura 72, que mostra um desenho colorido de uma imagem 759 que exibe quedas na intensidade de luz em direção aos cantos e bordas. Particularmente, deve-se notar que a intensidade de luz no centro aproximado da imagem parece ser mais claro que a intensidade de luz nos cantos e/ou bordas da imagem.

[000387] De acordo com modalidades das presentes técnicas, os ganhos de correção de sombreamento de lente podem ser especificados como uma grade bidimensional de ganhos por canal de cor (por exemplo, Gr, R, B, Gb para um filtro Bayer). Os pontos de grade de ganho podem ser distribuídos em intervalos horizontais e verticais fixos no quadro bruto 310 (Figura 23). Conforme discutido acima na Figura 23, o quadro bruto 310 pode incluir uma região ativa 312 que define uma área na qual o processamento é realizado para uma operação de processamento de imagem particular. Em relação à operação de correção de sombreamento de lente, uma região de processamento ativo, que pode ser chamada de região de LSC, é definida na região de quadro bruto 310. Conforme será discutido abaixo, a região de LSC tem que estar completamente dentro ou nos limites de grade de ganho, senão os resultados podem ser indefinidos.

[000388] Por exemplo, com referência à Figura 73, uma região de LSC 760 e uma grade de ganho 761 que pode ser definida no quadro bruto 310 são mostrados. A região LSC 760 pode ter uma largura 762 e uma altura 763, e podem ser definidas por um deslocamento x 764 e um deslocamento y 765 em relação ao limite do quadro bruto 310. Os deslocamentos de grade (por exemplo, deslocamento de grade x 766 e deslocamento de grade y 767) a partir da base 768 dos ganhos de grade 761 em relação ao primeiro pixel 769 na região de LSC 760 também é fornecido. Esses deslocamentos podem estar no primeiro intervalo de grade para um dado componente de cor. Os intervalos de ponto de grade horizontal (direção x) e vertical (direção y) 770 e 771, respectivamente, podem ser especificados independentemente para cada canal de cor.

[000389] Conforme discutido acima, presumindo que o uso de uma matriz de filtro de cor de Bayer, ganhos de grade de 4 canais de cor (R, B, Gr, e Gb) podem ser definidos. Em uma modalidade, um total de 4K (4096) pontos de grade pode estar disponível e para cada canal de cor, um endereço de base para o local inicial de ganhos de grade pode ser fornecido, como pelo uso de um apontador. Ademais, os intervalos de ponto de grade horizontal (770) e vertical (771) podem ser definidos em termos de pixels na resolução de um plano de cor e, em certas modalidades, pode ser fornecido para intervalos de ponto de grade separados por uma potência de 2, como por 8, 16, 32, 64 ou 128, etc., nas direções horizontal e vertical. Conforme pode ser constatado, ao utilizar uma potência de 2, a implantação eficaz de interpolação de ganho como uso de um deslocamento (por exemplo, divisão) e operações de soma podem ser alcançadas. Com o uso desses parâmetros, os mesmos valores de ganho podem ser usados mesmo que a região de corte do sensor de imagem esteja mudando. Por exemplo, apenas alguns parâmetros precisam ser atualizados para alinhar os pontos de grade à região cortada (por exemplo, atualizando os deslocamentos de grade 770 e 771) em vez de atualizar todos os valores de ganho de grade. A título de exemplo, apenas, isso pode ser útil quando o corte é usado durante operações de ampliação digital. Ademais, embora a grade de ganho 761 mostrada na modalidade da Figura 73 seja mostrada como tendo pontos de grade espaçados, em geral, de modo igualitário, deve-se compreender que, em outras modalidades, os pontos de grade podem não necessariamente ser igualmente espaçados. Por exemplo, em algumas modalidades, os pontos de grade podem ser distribuídos de modo desigual (por exemplo, logaritmicamente), de modo que os pontos de grade esteja menos concentrados no centro da região de LSC 760, mas mais em direção aos cantos da região de LSC 760, tipicamente onde a distorção de sombreamento de lente é mais notável.

[000390] De acordo com as técnicas de correção de sombreamento de lente apresentadas no presente documento, quando uma localização de pixel atual está fora da região de LSC 760, nenhum ganho é aplicado (por exemplo, o pixel é passado não modificado). Quando a localização de pixel atual está em um local de grade de ganho, o valor de ganho naquele ponto de grade particular pode ser usado. Entretanto, quando uma localização de pixel atual está entre pontos de grade, o ganho pode ser interpolado com o uso de interpolação bilinear. Um exemplo de interpolação do ganho para a localização de pixel "G" na Figura 74 é fornecido abaixo.

[000391] Conforme mostrado na Figura 74, o pixel G está entre os pontos de grade G0, G1, G2, e G3, que podem corresponder aos ganhos de topo-esquerda, topo-direita, fundo-esquerda e fundo-direita, respectivamente, em relação à localização rela de pixel G. O tamanho horizontal e vertical do intervalo de grade é representado por X e Y, respectivamente. Adicionalmente, ii e jj representam os deslocamentos de pixel horizontal e vertical, respectivamente, em relação à posição do ganho de topo-esquerda G0. Com base nesses fatores, o ganho correspondente à posição G pode, portanto, ser interpolado conforme segue:

[000392] Os termos na Equação 13a acima podem, então, ser combinados para obter a seguinte expressão:

[000393] Em uma modalidade, o método de interpolação pode ser realizado de modo incrementado, em vez de usar um multiplicador em cada pixel, reduzindo, assim, a complexidade computacional. Por exemplo, o termo (ii)(jj) pode ser realizado com o uso de um adicionador que pode ser inicializado para 0 no local (0, 0) da grade de ganho 761 e aumentado pelo número de fileira atual cada vez que o número de coluna atual aumentar em um pixel. Conforme discutido acima, já que os valores de X e Y podem ser selecionados como potências de dois, a interpolação de ganho pode ser alcançada com o uso de operações de deslocamento simples. Portanto, o multiplicador é necessário apenas no ponto de grade G0 (em vez de em cada pixel), e apenas operações de adição são necessárias para determinar o ganho interpolado para os pixels restantes.

[000394] Em certas modalidades, a interpolação de ganhos entre os pontos de grade pode usar a precisão de 14 bits e os ganhos de grade podem ser valores de 10 bits não assinados com 2 bits inteiros e 8 bits fracionais (por exemplo, uma representação de ponto de flutuação de 2.8. Com o uso dessa convenção, o ganho pode ter uma faixa entre 0 e 4X e a resolução de ganho entre pontos de grade pode ser 1/256.

[000395] As técnicas de correção de sombreamento de lente podem ser adicionalmente ilustradas pelo processo 772 mostrado na Figura 75. Conforme mostrado, o processo 772 começa na etapa 773, em cuja posição de um pixel atual é determinada em relação aos limites da região de LSC 760 da Figura 73. A seguir, a lógica de decisão 774 determina se a posição de pixel atual esta na região de LSC 760. Se a posição de pixel atual estiver fora da região de LSC 760, o processo 772 continua até a etapa 775 e nenhum ganho é aplicado ao pixel atual (por exemplo, o pixel passa não modificado).

[000396] Se a posição de pixel atual estiver na região LSC 760, o processo 772 continua até a lógica de decisão 776, na qual se determina, ainda, se a posição de pixel atual corresponde a um ponto de grade na grade de ganho 761. Se a posição de pixel atual corresponder a um ponto de grade, então o valor de ganho naquele ponto de grade é selecionado e aplicado ao pixel atual, conforme mostrado na etapa 777. Se a posição de pixel atual não corresponder a um ponto de grade, então o processo 772 continua para a etapa 778 e um ganho é interpolado com base nos pontos de grade de borda (por exemplo, G0, G1, G2 e G3 da Figura 74). Por exemplo, o ganho interpolado pode ser computado de acordo com as Equações 13a e 13b, conforme discutido acima. Posteriormente, o processo 772 termina na etapa 779, em que o ganho interpolado da etapa 778 é aplicado ao pixel atual.

[000397] Conforme será constatado, o processo 772 pode ser repetido para cada pixel dos dados de imagem. Por exemplo, conforme mostrado na Figura 76, um perfil tridimensional que mostra os ganhos que podem ser aplicados a cada posição de pixel em uma região de LSC (por exemplo 760) é ilustrado. Conforme mostrado, o ganho aplicado nos cantos 780 da imagem podem, em geral, ser maiores que o ganho aplicado ao centro 781 da imagem devido a uma intensidade de queda maior na intensidade de luz nos cantos, conforme mostrado nas Figuras 71 e 72. Com o uso das técnicas de correção de sombreamento de lente aqui descritas, a aparição de quedas de intensidade de luz na imagem pode ser reduzida ou substancialmente eliminada. Por exemplo, a Figura 77 fornece um exemplo de como o desenho colorido da imagem 759 da Figura 72 pode aparecer após correção de sombreamento de lente ser aplicada. Conforme mostrado, comparado à imagem original da Figura 72, a intensidade de luz geral é, em geral, mais uniforme através da imagem. Particularmente, a intensidade de luz no centro aproximado da imagem pode ser substancialmente igual aos valores de intensidade de luz nos cantos e/ou bordas da imagem. Adicionalmente, conforme mencionado acima, o cálculo de ganho interpolado (Equações 13a e 13b) pode, em algumas modalidades, ser substituído por um "delta" aditivo entre pontos de grade ao tirar vantagem da estrutura de adição de coluna e fileira sequencial. Conforme será constatado, isso reduz a complexidade computacional.

[000398] Em modalidades adicionais, além de usar ganhos de grade, um ganho global por componente de cor que é escalonado como função da distância a partir do centro da imagem é usado. O centro da imagem pode ser fornecido como um parâmetro de entrada e pode ser estimado ao analisar a amplitude de intensidade de luz de cada pixel de imagem na imagem iluminada uniformemente. A distância radial entre o pixel de centro identificado e o pixel atual, pode, então, ser usado para obter um ganho radial escalonado linearmente, Gr, conforme mostrado abaixo:

[000399] em que Gp[c] representa um parâmetro de ganho global para cada componente de cor c (por exemplo, componentes R, B, Gr, e Gb para um padrão Bayer), e em que R representa a distância radial entre o pixel central e o pixel atual.

[000400] Com referência à Figura 78, que mostra a região LSC 760 discutida acima, a distância R pode ser calculada ou estimada com o uso de diversas técnicas. Conforme mostrado, o pixel C correspondente ao centro da imagem pode ter as coordenadas (x0, y0), e o pixel atual G pode ter as coordenadas (xG, yG). Em uma modalidade, a lógica de LSC 740 pode calcular a distância R com o uso da equação a seguir:

[000401] Em outra modalidade, uma fórmula de estimativa mais simples, mostrada abaixo, pode ser utilizada para obter um valor estimado para R.

[000402] Na Equação 16, os coeficientes de estimativa α e β podem ser escalonados para valores de 8 bits. A título de exemplo, apenas, em uma modalidade, α pode ser igual a aproximadamente 123/128 e β pode ser igual a aproximadamente 51/128 para fornecer um valor estimado para R. com o uso desses valores de coeficiente, o maior erro pode ser de aproximadamente 4%, com um erro médio de aproximadamente 1,3%. Portanto, ainda que a técnica de estimativa possa ser de alguma forma menos precisa que o uso da técnica de cálculo na determinação de R (Equação 15), a margem de erro é baixa o suficiente para que os valores estimados ou R sejam adequados para a determinação de componentes de ganho radial para as presentes técnicas de correção de sombreamento de lente.

[000403] O ganho radial Gr pode, então, ser multiplicado pelo valor de ganho de grade interpolado G (Equações 13a e 13b) para o pixel atual para determinar um ganho total que pode ser aplicado ao pixel atual. O pixel de saída Y é obtido ao multiplicar o valor de pixel de entrada X pelo ganho total, conforme mostrado abaixo:

[000404] Portanto, de acordo com a presente técnica, a correção de sombreamento de lente pode ser realizada com o uso apenas do ganho interpolado, ambos os componentes de ganho interpolado e de ganho radial. Alternativamente, a correção de sombreamento de lente também pode ser realizada com om uso apenas de ganho radial em conjunto com uma tabela de grade radial que compensa os erros de aproximação radial. Por exemplo, em vez de uma grade de ganho retangular 761, conforme mostrado na Figura 73, uma grade de ganho radial que tem uma pluralidade de ponto de grade que definem ganhos nas direções radial e angular pode ser fornecida. Portanto, ao determinar o ganho para aplicar a um pixel que não se alinha a um dos pontos de grade radial na região de LSC 760, a interpolação pode ser aplicada com o uso de quatro pontos de grade que abrangem o pixel para determinar um ganho de sombreamento de lente interpolada apropriada.

[000405] Com referência à Figura 79, o uso de componentes de ganho radial e interpolados na correção de sombreamento de lente é ilustrado pelo processo 782. Deve-se notar que o processo 782 pode incluir etapas que são similares ao processo 772, descrito acima, na Figura 75. Em conformidade, tais etapas foram numeradas com números de referência similares. Começando na etapa 773, o pixel atual é recebido e seu local relativo à região LSC 760 é determinado. A seguir, a lógica de decisão 774 determina se a posição atual de pixel está na região de LSC 760. Se a posição atual de pixel estiver fora da região de LSC 760, o processo 782 continua na etapa 775, e nenhum ganho é aplicado ao pixel atual (por exemplo, o pixel passa não modificado). Se a posição de pixel atual estiver na região de LSC 760, então o processo 782 pode continuar simultaneamente à etapa 783 e à lógica de decisão 776. Com referência, primeiramente, à etapa 783, os dados que identificam o centro da imagem são recuperados. Conforme discutido acima, determinar o centro da imagem pode incluir analisar as amplitudes de intensidade de luz para os pixels sob iluminação uniforme. Isso pode ocorrer durante a calibração, por exemplo. Portanto, deve-se compreender que a etapa 783 não necessariamente abrange calcular repetidamente o centro da imagem para o processamento de cada pixel, mas pode se referir aos dados (por exemplo, coordenadas) do centro de imagem previamente determinado. Uma vez que o centro da imagem é identificado, o processo 782 pode continuar para a etapa 784, em que a distância entre o centro da imagem e o local atual de pixel (R) é determinada. Conforme discutido acima, o valor de R pode ser calculado (Equação 15) ou estimado (Equação 16). Então, na etapa 785, um componente de ganho radial Gr pode ser computado com o uso da distância R e o parâmetro de ganho global correspondente ao componente de cor do pixel atual (Equação 14). O componente de ganho radial Gr pode ser usado para determinar o ganho total, conforme será discutido na etapa 787 abaixo.

[000406] Com referência, novamente, à lógica de decisão 776, é determinado se a posição de pixel atual corresponde a um ponto de grade na grade de ganho 761. Se a posição de pixel atual corresponder a um ponto de grade, então o valor de ganho naquele ponto de grade é determinado, conforme mostrado na etapa 786. Se a posição de pixel atual não corresponder a um ponto de grade, então o processo 782 continua para a etapa 778 e um ganho interpolado é computado com base nos pontos de grade de borda (por exemplo, G0, G1, G2 e G3 da Figura 74). Por exemplo, o ganho interpolado pode ser computado de acordo com as equações 13a e 13b, conforme discutido acima. A seguir, na etapa 787, um ganho total é determinado com base no ganho radial determinado na etapa 785, assim como um dentre os ganhos de grade (etapa 786) ou o ganho interpolado (778). Conforme pode ser constatado, isso pode depender de qual ramificação a lógica de decisão 776 toma durante o processo 782. O ganho total é, então, aplicado ao pixel atual, conforme mostrado na etapa 788. Novamente, deve-se notar que como o processo 772, o processo 782 também pode ser repetido para cada pixel dos dados de imagem.

[000407] O uso do ganho radial em conjunto com os ganhos de grade pode oferecer várias vantagens. Por exemplo, o uso de um ganho radial permite o uso de grade de ganho comum única para todos os componentes de cor. Isso pode reduzir enormemente o espaço de armazenamento total exigido para armazenar grades de ganho separadas para cada componente de cor. Por exemplo, em um sensor de imagem de Bayer, o uso de uma grade de ganho única para cada um dos componentes R, B, Gr e Gb pode reduzir os dados de grade de ganho em aproximadamente 75%. Conforme será constatado, essa redução no ganho de grade pode diminuir os custos de implantação, já que as tabelas de dados de ganho de grade podem dar conta de uma porção significativa de área de memória ou chip no hardware de processamento de imagem. Ademais, dependendo da implantação de hardware, o uso de um único conjunto de valores de grade de ganho pode oferecer vantagens adicionais, como a redução da área de chip geral (por exemplo, como quando os valores de grade de ganho estão armazenados em uma memória de chip) e a redução de exigências de largura de banda de memória (por exemplo, como quando os valores de grade de ganho estão armazenados em uma memória externa fora de chip).

[000408] Tendo descrito a fundo as funcionalidades da lógica de correção de sombreamento de lente 740 mostrada na Figura 68, a saída da lógica de LSC 740 é subsequentemente encaminhada para a lógica de compensação de nível de preto inversa (IBLC) 741. A lógica IBLC 741 fornece o ganho, o deslocamento e o recorte independentemente uns dos outros para cada componente de cor (por exemplo, R, B, Gr e Gb) e realiza, em geral, a função inversa à lógica BLC 739. Por exemplo, conforme mostrado pela operação a seguir, o valor do pixel de entrada é primeiramente multiplicado por um ganho e, então, deslocado por um valor assinado.

[000409] em que X representa o valor de pixel de entrada para um dado componente de cor c (por exemplo, R, B, Gr, ou Gb), O[c] representa um deslocamento de 16 bits assinado para o componente de cor atual c e G[c] representa um valor de ganho para o componente de cor c. Em uma modalidade, o ganho G[c] pode ter uma faixa entre aproximadamente 0 e 4X (4 vezes o valor de pixel de entrada X). Deve- se notar que essas variáveis põem ser iguais àquelas discutidas acima na Equação 11. O valor Y computado pode ser recortado para uma faixa mínima e máxima com o uso, por exemplo, da Equação 12. Em uma modalidade, a lógica IBLC 741 pode ser configurada para manter uma contagem do número de pixels que foram recortados acima e abaixo do máximo e do mínimo, respectivamente, por componente de cor.

[000410] Posteriormente, a saída da lógica IBLC 741 é recebida pelo bloco de coleta de estatísticas 742, que pode fornecer a coleta de vários pontos de dados estatísticos acerca do(s) sensor(es) de imagem 90, como aqueles que se referem à auto-exposição (AE), auto-equilíbrio de branco (AWB), autofoco (AF), detecção de oscilação e assim por diante. Com isso em mente, uma descrição de certas modalidades do bloco de coleta de estatísticas 742 e vários aspectos relacionados ao mesmo é fornecida abaixo em relação às Figuras 80 a 97.

[000411] Conforme será constatado, as estatísticas de AWB, AE e AF podem ser usadas na aquisição de imagens em câmeras digitais paradas assim como em câmeras de vídeo. Para simplicidade, as estatísticas de AWB, AE e AF podem ser referidas coletivamente como "estatísticas 3A". Na modalidade da lógica de front-end de ISP ilustrada na Figura 68, a arquitetura para a lógica de coleta de estatísticas 742 ("lógica de estatísticas 3A") pode ser implantada em hardware, software ou uma combinação dos mesmos. Ademais, o software ou firmware de controle pode ser utilizado para a análise dos dados de estatística coletados pela lógica de estatísticas 3A 742 e controla vários parâmetros da lente (por exemplo, comprimento focal), sensor (por exemplo, ganhos analógicos, tempos de integração) e a pipeline de ISP 82 (por exemplo, ganhos digitais, coeficientes de matriz de correção de cor). Em certas modalidades, o conjunto de circuitos de processamento de imagem 32 pode ser configurado para fornecer flexibilidade na coleta de estatísticas para permitir que o software ou firmware de controle implante vários algoritmos de AWB, AE e AF.

[000412] Em relação ao equilíbrio de branco (AWB), a resposta de sensor de imagem em cada pixel pode depender da fonte de iluminação, já que a fonte de luz é refletida a partir de objetos na cena de imagem. Portanto, cada valor de pixel gravado na cena de imagem é relacionado à temperatura de cor da fonte de luz. Por exemplo, a Figura 79 mostra um gráfico 789 que ilustra a faixa de cor de áreas brancas sob temperaturas de cor baixas e altas para um espaço de cor de YCbCr. Conforme mostrado, o eixo geométrico x do gráfico 789 representa o croma de diferença de azul (Cb) e eixo geométrico y do gráfico 789 representa o croma de diferença de vermelho (Cr) do espaço de cor de YCbCr. O gráfico 789 também mostra um eixo geométrico de temperatura de cor baixa 790 e um eixo geométrico de temperatura de cor alta 791. A região 792 na qual os eixos geométricos 790 e 791 estão posicionados representa a faixa de cor de áreas brancas sob temperaturas de cor baixas e altas no espaço de cor de YCbCr. Deve- se compreender, entretanto, que o espaço de cor de YCbCr é meramente um exemplo de um espaço de cor que pode ser usado em conjunto com o processamento de equilíbrio de branco na presente modalidade. Outras modalidades podem utilizar qualquer espaço de cor adequado. Por exemplo, em certas modalidades, outros espaços de cor adequados podem incluir um espaço de cor Lab (CIELab) (por exemplo, com base no CIE 1976), um espaço de cor de vermelho/azul normalizado (por exemplo, um espaço de cor R/(R+2G+B) e B/(R+2G+B); um espaço de cor R/G e B/G; um espaço de cor Cb/Y e Cr/Y, etc.). Em conformidade, para fins dessa descrição, os eixos geométricos do espaço de cor usado pela lógica de estatísticas 3A 742 podem ser chamados de C1 e C2 (como no caso da Figura 80).

[000413] Quando um objeto branco é iluminado sob uma temperatura de cor baixa, pode parecer avermelhado na imagem capturada. De modo contrário, um objeto branco que é iluminado sob uma temperatura de cor alta pode parecer azulado na imagem capturada. O objetivo do equilíbrio de branco é, portanto, ajustar os valores de RGB de modo que a imagem pareça, ao olho humano, como se tivesse sido tirada sob luz canônica. Portanto, no contesto de estatísticas de imageamento referentes ao equilíbrio de branco, as informações de cor acerca de objetos brancos são coletadas para determinar a temperatura de cor da fonte de luz. Em geral, os algoritmos do equilíbrio de branco podem incluir duas etapas principais. Primeiro, a temperatura de cor da fonte de luz é estimada. Segundo, a temperatura de cor estimada é usada para ajustar os valores de ganho de cor e/ou determinar/ajustar os coeficientes de uma matriz de correção de cor. Tais ganhos podem ser uma combinação de ganhos de sensor de imagem analógico e digital, assim como ganhos digitais de ISP.

[000414] Por exemplo, em algumas modalidades, o dispositivo de imageamento 30 pode ser calibrado com o uso de iluminadores de referencias diferentes múltiplos. Em conformidade, o ponto branco da cena atual pode ser determinado ao selecionar os coeficientes de correção de cor correspondentes a um iluminador referência que combina de modo mais próximo com o iluminador da cena atual. A título de exemplo, apenas, uma modalidade pode calibrar o dispositivo de imageamento 30 com o uso de cinco iluminadores de referência, um iluminador de temperatura de cor baixa, um iluminador de temperatura de cor média-baixa, um iluminador de temperatura de cor média, um iluminador de temperatura de cor média-alta e um iluminador de temperatura de cor alta. Conforme mostrado na Figura 81, uma modalidade pode definir os ganhos de equilíbrio de branco com o uso dos seguintes perfis de correção de cor: Horizonte (H) (simulando uma temperatura de cor de aproximadamente 2.300 graus), Incandescente (A ou IncA) (simulando uma temperatura de cor de aproximadamente 2.856 graus), D50 (simulando uma temperatura de cor de aproximadamente 5.000 graus), D65 (simulando uma temperatura de cor de aproximadamente 6.500 graus) e D75 (simulando uma temperatura de cor de aproximadamente 7.500 graus).

[000415] Dependendo dos iluminantes da cena atual, os ganhos de equilíbrio de branco podem ser determinados com o uso dos ganhos correspondentes ao iluminador de referência que mais combina com o iluminador atual. Por exemplo, se a lógica de estatísticas 742 (descrita com maiores detalhes na Figura 82 abaixo) determinar que o iluminador atual combina aproximadamente com o iluminador de temperatura de cor média de referência, D50, então os ganhos de equilíbrio de branco de aproximadamente 1.37 e 1.23 podem ser aplicados aos canais de cor vermelho e azul, respectivamente, embora aproximadamente nenhum ganho (1.0) seja aplicado aos canais de verde (G0 e G1 para dados de Bayer). Em algumas modalidades, se a temperatura de cor de iluminador atual estiver entre dois iluminadores de referência, ganhos de equilíbrio de branco podem ser determinados através da interpolação dos ganhos de equilíbrio de branco entre os dois iluminadores de referência. Ademais, embora o presente exemplo mostre um dispositivo de imageamento que esta sendo calibrado com o uso dos iluminadores H, A, D50, D65 e D75, deve-se compreender que qualquer tipo adequado de iluminador pode ser usado para a calibração de câmera, como TL84 ou CWF (iluminadores de referência fluorescentes) e assim por diante.

[000416] Conforme será adicionalmente discutido abaixo, diversas estatísticas podem ser fornecidas para o AWB, incluindo um histograma de cor bidimensional (2D) e somas de RGB ou YCC para fornecer múltiplas faixas de cor programáveis. Por exemplo, em uma modalidade, a lógica de estatísticas 742 pode fornecer um conjunto de múltiplos filtros de pixel, dos quais um subconjunto dos múltiplos filtros de pixel pode ser selecionado para o processamento de AWB. Em uma modalidade, oito conjuntos de filtros, cada um com parâmetros configuráveis diferentes, podem ser fornecidos e três conjuntos de filtros de faixa de cor podem ser selecionados a partir do conjunto para unir estatísticas de azulejo, assim como para reunir estatísticas para cada janela flutuante. A título de exemplo, um primeiro filtro selecionado pode ser configurado para cobrir a temperatura de cor atual para obter a estimativa de cor precisa, um segundo filtro selecionado pode ser configurado para cobrir as áreas de temperatura de cor baixa e um terceiro filtro pode ser configurado para cobrir as áreas de temperatura de cor alta. Essa configuração particular pode permitir que o algoritmo de AWB ajuste a área de temperatura de cor atual conforme a fonte de luz está mudando. Ademais, o histograma de cor 2D pode ser utilizado para determinar os iluminadores local e global e para determinar vários limites de filtro de pixel para acumular valores de RGB. Novamente, deve-se compreender que a seleção de três filtros de pixel é destinada a ilustrar apenas uma modalidade. Em outras modalidades, menos ou mais filtros de pixel podem ser selecionados para as estatísticas de AWB.

[000417] Ademais, além de selecionar três filtros de pixel, um filtro de pixel adicional também pode ser usado para a auto-exposição (AE), que se refere, em geral, a um processo de ajuste de tempo de integração de pixel e ganhos para controlar a luminosidade da imagem capturada. Por exemplo, a auto-exposição pode controlar a quantidade de luz a partir da cena que é capturada pelo(s) sensor(es) de imagem ao configurar o tempo de integração. Em certas modalidades, os azulejos e janelas flutuantes de estatísticas de luminosidade podem ser coletados através da lógica de estatísticas 3A 742 e processados para determinar os parâmetros de controle de integração e ganho.

[000418] Ademais, o autofoco pode se referir à determinação do comprimento focal ótimo da lente para otimizar substancialmente o foco da imagem. Em certas modalidades, as janelas flutuantes de estatísticas de frequência altas podem ser coletadas e o comprimento focal da lente pode ser ajustado para colocar uma imagem em foco. Conforme discutido adicionalmente abaixo, em uma modalidade, os ajustes de autofoco podem utilizar ajustes grossos e finos com base em uma ou mais métrica, chamada de classificações de autofoco (classificações de AF) para coloca ruma imagem em foco. Ademais, em algumas modalidades, as estatísticas/classificações de AF podem ser determinadas para cores diferentes e a relatividade entre as estatísticas/classificações de AF para cada canal de cor pode ser usada para determinar a direção do foco.

[000419] Portanto, esses vários tipos de estatísticas, dentre outras, podem ser determinados e coletados através do bloco de coleta de estatísticas 742. Conforme mostrado, a saída STATS0 do bloco de coleta de estatísticas 742 das unidades de processamento de estatística do Sensor0 142 pode ser enviada para a memória 108 e roteada para a lógica de controle 84 ou, alternativamente, pode ser enviada diretamente para a lógica de controle 84. Ademais, deve-se compreender que as unidades de processamento de estatística de Sensor1 144 também podem incluir um bloco de coleta de estatísticas 3A configurado de modo similar que fornece estatísticas STATS1, conforme mostrado na Figura 10.

[000420] Conforme discutido acima, a lógica de controle 84, que pode ser um processador dedicado no subsistema de ISP 32 do dispositivo 10, pode processar os dados estatísticos coletados para determinar um ou mais parâmetros de controle para controlar o dispositivo de imageamento 30 e/ou o conjunto de circuitos de processamento de imagem 32. Por exemplo, tais parâmetros de controle podem incluir parâmetros para a operação da lente do sensor de imagem 90 (por exemplo, parâmetros de ajuste de comprimento focal), parâmetros de sensor de imagem (por exemplo, ganhos analógicos e/ou digitais, tempo de integração), assim como parâmetros de processamento de pipe de ISP (por exemplo, coeficientes de valores de ganho digital, matriz de correção de cor (CCM)). Adicionalmente, conforme mencionado acima, em certas modalidades, o processamento estatístico pode ocorrer a uma precisão de 8 bits e, portanto, os dados de pixel brutos que têm uma profundidade de bit mais alta podem ser escalonados descendentemente para um formato de 8 bits para fins estatísticos. Conforme discutido acima, o escalonamento descendente para 8 bits (ou qualquer outra resolução de bit inferior) pode reduzir o tamanho de hardware (por exemplo, área) e também pode reduzir a complexidade de processamento, assim como permitir que as estatísticas data sejam mais robustas a ruído (por exemplo, com o uso de média espacial dos dados de imagem).

[000421] Com o anterior em mente, a Figura 82 é um diagrama de bloco que retrata a lógica para a implantação de uma modalidade da lógica de estatísticas 3A 742. Conforme mostrado, a lógica de estatísticas 3A 742 pode receber um sinal 793 que representa dos dados de RGB de Bayer que, conforme mostrado na Figura 68, podem corresponder à saída da lógica de BLC inversa 741. A lógica de estatísticas 3A 742 pode processar os dados de RGB de Bayer 793 para obter várias estatísticas 794, que podem representar a STATS0 de saída da lógica de estatísticas 3A 742, conforme mostrado na Figura 68, ou, alternativamente, a STATS1 de saída de uma lógica de estatísticas associada à unidades de processamento de estatísticas do Sensor1 144.

[000422] Na modalidade ilustrada, para que as estatísticas sejam mais robustas em relação ao ruído, os pixels de RGB de Bayer de entrada Bayer 793 são primeiramente ponderados pela lógica 795. Por exemplo, a ponderação pode ser realizada em um tamanho de janela de 4x4 pixels de sensor que consistem em quatro 2x2 quads de Bayer (por exemplo, um bloco de pixels 2x2 que representa o padrão de Bayer) e os valores ponderados de vermelho (R), verde (G) e azul (B) na janela 4x4 podem ser computador e convertidos em 8 bits, conforme mencionado acima. Esse processo é ilustrado com mais detalhes em relação à Figura 83, que mostra uma janela 4x4 796 de pixels formados como quatro quads de Bayer 2x2 797. Com o uso dessa disposição, cada canal de cor inclui um bloco de pixels correspondentes 2x2 com a janela 796 e os pixels da mesma cor podem ser somados e ponderados para produzir um valor de cor médio para cada canal de cor na janela 796. Por exemplo, pixels vermelhos 799 podem ser ponderados para que se obtenha um valor de vermelho médio (RAV) 803 e os pixels azuis 800 podem ser ponderados para que se obtenha um valor de azul médio (BAV) 804 na amostra 796. Em relação à ponderação dos pixels verdes, diversas técnicas podem ser utilizadas já que o padrão de Bayer tem duas vezes mais amostras verdes que amostras vermelhas ou azuis. Em uma modalidade, o valor de verde médio (GAV) 802 pode ser obtido pela ponderação de apenas pixels Gr 798, apenas pixels Gb 801, ou todos os pixels Gr e Gb 798 e 801 juntos. Em outra modalidade, os pixels Gr e Gb 798 e 801 em cada quad de Bayer 797 pode ser ponderado e a média dos valores de verde para cada quad de Bayer 797 pode ser adicionalmente ponderada para obter GAV 802. Conforme será constatado, a ponderação dos valores de pixel através de blocos de pixel pode fornecer a redução de ruído. Ademais, deve-se compreender que o uso de um bloco 4x4 como uma janela de amostra é meramente destinado a fornecer um exemplo. De fato, em outras modalidades, qualquer tamanho de bloco adequado pode ser utilizado (por exemplo, 8x8, 16x16, 32x32, etc.).

[000423] Posteriormente, os valores de RGB de Bayer escalonados descendentemente 806 são inseridos nas unidades de lógica de conversão de espaço de cor 807 e 808. Devido a alguns dos dados de estatísticas 3A poderem se apoiar sobre pixels após aplicar a conversão de espaço de cor, a lógica de conversão de espaço de cor (CSC) 807 e a lógica de CSC 808 podem ser configuradas para converter os valores de RGB de Bayer amostrados descendentemente 806 em um ou mais espaços de cor. Em uma modalidade, a lógica de CSC 807 pode fornecer outra conversão de espaço não linear e a lógica de CSC 808 pode fornecer uma conversão de espaço linear. Portanto, as unidades de lógica de CSC 807 e 808 podem converter os dados de imagem brutos a partir do sensor Bayer de RGB para outro espaço de cor (por exemplo, sRGBlinear, sRGB, YCbCr, etc.) que possa ser mais ideal ou adequado para a realização de estimativa de ponto de branco para o equilíbrio de branco.

[000424] Na presente modalidade, a lógica de CSC não linear 807 pode ser configurada para realizar uma multiplicação de matriz 3x3, seguida por um mapeamento não linear implantado como uma tabela de consulta e seguida, adicionalmente, por outra multiplicação de matriz 3x3 com um deslocamento adicionado. Isso permite uma conversão de espaço de cor de estatísticas 3A para replicar o processamento de cor do processamento de RGB na pipeline de ISP 82 (por exemplo, ao aplicar o ganho de equilíbrio de branco, aplicando uma matriz de correção de cor, aplicando ajustes de gama RGB e realizando conversão de espaço de cor) para uma dada temperatura de cor. Também se pode fornecer a conversão dos valores de RGB de Bayer a um espaço de cor de cor mais consistente, como CIELab, ou quaisquer outros espaços de cor discutidos acima (por exemplo, YCbCr, um espaço de cor normalizado de vermelho/azul, etc.). Sob algumas condições, um espaço de cor Lab pode ser mais adequado para operações de equilíbrio de branco porque a cromaticidade é mais linear em relação à claridade.

[000425] Conforme mostrado na Figura 82, os pixels de saída do sinal escalonado descendentemente de RGB de Bayer 806 são processados com uma primeira matriz de correção de cor 3x3 (3A_CCM), chamada, aqui, pelo número de referência 808. Na presente modalidade, a 3A_CCM 809 pode ser configurada para converter a partir de um espaço de cor de RGB de câmera (camRGB), para um espaço calibrado de sRGB linear (sRGBlinear). Uma conversão de espaço de cor programável que pode ser usado em uma modalidade é fornecida abaixo pelas Equações 19 a 21:

[000426] em que 3A_CCM_00 - 3A_CCM_22 representa os coeficientes assinados da matriz 808. Portanto, cada um dentre sRlinear, sGlinear e sBlinear, os componentes do espaço de cor sRGBlinear pode ser determinado ao se determinar, primeiramente, a soma dos valores de RGB de Bayer amostrados descendentemente de vermelho, azul e verde com coeficientes 3A_CCM correspondentes aplicados e, então, recortando esse valor ou a 0 ou a 255 (os valores de pixel mínimo e máximo para dados de pixel de 8 bits) se o valor exceder 255 ou for menor que 0. Os valores de sRGBlinear resultantes são representados na Figura 82 pelo número de referência 810 como a saída de 3A_CCM 809. Adicionalmente, a lógica de estatísticas 3A 742 pode manter uma contagem a do número de pixels recortados para cada um dentre os componentes sRlinear, sGlinear, e sBlinear, conforme expresso abaixo:

[000427] A seguir, os pixels sRGBlinear 810 podem ser processados com o uso de uma tabela de consulta não linear 811 para produzir pixels sRGB 812. A tabela de consulta 811 pode conter entradas de valores de 8 bits, sendo que cada valor de entrada de tabela representa um nível de saída. Em uma modalidade, a tabela de consulta 811 pode incluir 65 entradas de inserção distribuídas de modo uniforme, em que um índice de tabela representa valores de entrada nas etapas de 4. Quando o valor de entrada cai entre intervalos, os valores de saída são interpolados de modo linear.

[000428] Conforme será constatado, o espaço de cor de sRGB pode representar o espaço de cor da imagem final produzida pelo dispositivo de imageamento 30 (Figura 7) para um dado ponto branco, conforme a coleta de estatísticas de equilíbrio de branco é realizada no espaço de cor da imagem final produzida pelo dispositivo de imagem. Em uma modalidade, um ponto branco pode ser determinado ao combinar as características da cena de imagem a um ou mais iluminadores de referência com base, por exemplo, em razões de vermelho para verde e/ou azul para verde. Por exemplo, um iluminador de referência pode ser D65, um iluminador padrão de CIE para simular condições de luz do dia. Além de D65, a calibração do dispositivo de imageamento 30 também pode ser realizada para outros iluminadores de referência diferentes e o processo de determinação de equilíbrio do branco pode incluir a determinação de um iluminador atual de modo que o processamento (por exemplo, o equilíbrio de color) possa ser ajustado para o iluminador atual com base nos pontos de calibração correspondentes. A título de exemplo, em uma modalidade, o dispositivo de imageamento 30 e a lógica de estatísticas 3A 742 podem ser calibrados com o uso, além de D65, do iluminador referência florescente branco frio (CWF), o iluminador referência TL84 (outra fonte fluorescente) e o iluminador referência IncA (ou A), que simula iluminação incandescente. Adicionalmente, conforme discutido acima, vários outros iluminantes correspondentes a temperaturas de cor diferentes (por exemplo, H, IncA, D50, D65 e D75, etc.) também podem ser usados na calibração da câmera para o processamento de equilíbrio de branco. Portanto, um ponto branco pode ser determinado ao analisar uma cena de imagem e determinar qual iluminador referência combina mais com a fonte de iluminadora atual.

[000429] Com referência, ainda, à lógica de CSC não linear 807, a saída de pixel de sRGB 812 da tabela de consulta 811 pode ser adicionalmente processada com uma segunda matriz de correção de cor 3x3 813, aqui chamada de 3A_CSC. Na modalidade retratada, a matriz 3A_CSC 813 é mostrada como sendo configurada para converter a partir do espaço de cor sRGB par ao espaço de cor YCbCr, embora possa ser configurada para converter os valores sRGB também em outros espaços de cor. A título de exemplo, a seguinte a conversão de espaço de cor programável (Equações 22 a 27) pode ser usado:

[000430] em que 3A_CSC_00 a 3A_CSC_22 representam coeficientes assinados para a matriz 813, 3A_OffsetY, 3A_OffsetC1, e 3A_OffsetC2 representam deslocamentos assinados e C1 e C2 representam cores diferentes, aqui croma de diferença de azul (Cb) e croma de diferença de vermelho (Cr), respectivamente. Deve-se compreender, entretanto, que C1 e C2 podem representar quaisquer cores de diferença de croma adequada e não precisam ser necessariamente cores Cb e Cr.

[000431] Conforme mostrado nas Equações 22 a 27, ao determinar cada componente de YCbCr, coeficientes apropriados da matriz 813 são aplicados aos valores sRGB 812 e o resultado é somado a um deslocamento correspondente (por exemplo, Equações 22, 24, e 26). Essencialmente, essa etapa é uma etapa de multiplicação de matriz 3x. Esse resultado da multiplicação de matriz é, então, recortado entre um valor máximo e mínimo (por exemplo, Equações 23, 25 e 27). Os valores de recorte mínimo e máximo associados podem ser programáveis e podem depender, por exemplo, em padrões de imageamento ou vídeo padrões (por exemplo, BT.601 ou BT.709) sendo utilizados.

[000432] A lógica de estatísticas 3A 742 também pode manter uma contagem do número de pixels recortados para cada um dentre os componentes Y, C1 e C2, conforme expresso abaixo:

[000433] Os pixels de saída a partir do sinal de amostragem descendente de RGB de Bayer 806 também pode ser fornecido 'lógica de conversão de espaço de cor linear 808, que pode ser configurada para implantar uma conversão de espaço de cor de câmara. Por exemplo, os pixels de saída 806 a partir da lógica de amostragem descendente de RGB de Bayer 795 podem ser processados através de outra matriz de conversão de cor 3x3 (3A_CSC2) 815 da lógica de CSC 808 para converter a partir do sensor RGB (camRGB) para um espaço de cor com equilíbrio de branco linear (camYC1C2), em que C1 e C2 podem corresponder a Cb e Cr, respectivamente. Em uma modalidade, os pixels croma podem ser escalonados por luma, que pode ser benéfico ao implantar um filtro de cor que melhorou a consistência de cor e é robusto em relação aos deslocamentos de cor devido às mudanças de luma. Um exemplo de como a conversão do espaço de cor da câmera pode ser realizada como uso da matriz 3x3 815 é fornecido abaixo, nas Equações 28 a 31:

[000434] em que 3A_CSC2_00 a 3A_CSC2_22 representam coeficientes assinados para a matriz 815, 3A_Deslocamento2Y representa um deslocamento assinado para camY e camC1 e camC2 representam cores diferentes, aqui croma de diferença de azul (Cb) e croma de diferença de vermelho (Cr), respectivamente. Conforme mostrado na Equação 28, para determinar camY, coeficientes correspondentes a partir da matriz 815 são aplicados aos valores de RGB de Bayer 806 e o resultado é somado a 3A_Deslocamento2Y. esse resultado é, então, recortado entre um valor máximo e um valor mínimo, conforme mostrado na Equação 29. Conforme discutido acima, os limites do recorte clipping podem ser programáveis.

[000435] Nesse ponto, os pixels de camC1 e camC2 da saída 816 são assinados. Conforme discutido acima, em algumas modalidades, os pixels croma podem ser escalonados. Por exemplo, uma técnica para implantar o escalonamento de croma é mostrada abaixo:

[000436] em que ChromaScale representa um fator de escalonamento de ponto flutuante entre 0 e 8. Nas Equações 32 e 33, a expressão (camY ? camY:1) é destinada evitar uma condição de dividir por zero. Ou seja, se camY for igual a zero, o valor de camY é configurado para 1. Ademais, em uma modalidade, ChromaScale pode ser configurada para um de dois possíveis valores, dependendo do sinal de camC1. Por exemplo, conforme mostrado abaixo in Equação 34, a ChomaScale pode ser configurada para um primeiro valor (ChromaScale0) se camC1 for negativo, ou se tiver que ser configurado para um segundo valor (ChromaScale1):

[000437] Posteriormente, os deslocamentos croma são adicionados e os pixels croma camC1 e camC2 são recortados, conforme mostrado abaixo nas Equações 35 e 36, para gerar os valores de pixel ano designados:

[000438] em que 3A_CSC2_00 - 3A_CSC2_22 são coeficientes assinados da matriz 815, e 3A_Deslocamento2C1 e 3A_Deslocamento2C2 são deslocamentos assinados. Ademais, o número de pixels que são recortados para camY, camC1 e camC2 é contado, conforme mostrado abaixo:

[000439] Portanto, a lógica de conversão de espaço de cor linear e não linear 807 e 808 pode, na presente modalidade, fornecer dados de pixel em vários espaços de cor: sRGBlinear (sinal 810), sRGB (sinal 812), YCbYr (sinal 814) e camYCbCr (sinal 816). It deve-se compreender que os coeficientes para cada matriz de conversão 809 (3A_CCM), 813 (3A_CSC), e 815 (3A_CSC2), assim como os valores na tabela de consulta 811, podem ser independentemente configurados e programados.

[000440] Com referência, ainda, à Figura 82, os pixels de saída croma ou do espaço conversão de cor não linear (YCbCr 814) ou da a conversão de espaço de cor de câmera (camYCbCr 816) podem ser usados para gerar um histograma de cor bidimensional (2D) 817. Conforme mostrado, a lógica de seleção 818 e 819, que ode ser implantada como multiplexadores ou por qualquer outra lógica adequada, pode ser configurada para selecionar entre pixels de luma e de croma a partir de qualquer um dentre o a conversão de espaço de cor não linear ou de câmera. A lógica de seleção 818 e 819 pode operar em resposta aos respectivos sinais de controle que, em uma modalidade, podem ser fornecidos pela lógica de controle principal 84 do conjunto de circuitos de processamento de imagem 32 (Figura 7) e pode ser configurada através de software.

[000441] Para o presente exemplo, pode-se presumir que a lógica de seleção 818 e 819 seleciona a conversão de espaço de cor YC1C2 (814), em que o primeiro componente é Luma, e em que C1, C2 são as primeira e segunda cores (por exemplo, Cb, Cr). Um histograma 2D 817 no espaço de cor C1-C2 é gerado para uma janela. Por exemplo, a janela pode ser especificada com um início de coluna e largura e um início de fileira e altura. Em uma modalidade, a posição e o tamanho da janela podem ser configurados como um múltiplo de 4 pixels, e compartimentos 32x32 podem ser usados para um total de 1024 compartimentos. Os limites do compartimento podem estar em intervalo fixo e, para permitir a ampliação e o movimento panorâmico da coleta de histograma em áreas específicas do espaço de cor, um escalonamento e deslocamento de pixel podem ser definidos.

[000442] Os 5 bits superiores (que representam um total de 32 valores) de C1 e C2 após o deslocamento e o escalonamento pode ser usado para determinar o compartimento. Os índices de compartimento para C1 e C2, aqui chamados de C1_index e C2_index, podem ser determinados conforme segue:

[000443] Uma vez que os índices são determinados, os compartimentos de histograma de cor são aumentados por um valor de Contagem (que pode ter qualquer valor entre 0 e 3 em uma modalidade) se os índices de compartimento estiverem na faixa [0, 31], conforme mostrado abaixo na Equação 39. Efetivamente, isso permite a pesagem das contagens de cor com base nos valores de luma (por exemplo, pixels ais claros são pesados de modo mais pesado, em vez de se pesar tudo igualmente(por exemplo, por 1)).

[000444] em que a Contagem é determinada com base no valor de luma selecionado, Y, nesse exemplo. Conforme será constatado, as etapas representadas pelas Equações 37, 38 e 39 podem ser implantadas por um bloco de lógica de atualização de compartimento 821. Ademais, em uma modalidade, limites de luma múltiplos podem ser configurados para define intervalos de luma. A título de exemplo, quatro limites de luma (Ythd0-Ythd3) podem definir cinco intervalos de luma, com valores de Contagem Count0-4 sendo definidos por cada intervalo. Por exemplo, Count0-Count4 pode ser selecionado (por exemplo, por lógica de condição de pixel 820) com base em limites de luma, conforme segue:

[000445] Com o anterior em mente, a Figura 84 ilustra o histograma de cor com o escalonamento e deslocamentos configurados para zero para ambos C1 e C2. As divisões no espaço CbCr representam cada um dos compartimentos 32x32 (1024 compartimentos, no total). A Figura 85 fornece um exemplo de ampliação e movimento panorâmico no histograma de cor 2D para precisão adicional, em que a área retangular 822, onde o pequeno retângulo especifica o local dos compartimentos 32x32.

[000446] No início de um quadro de dados de imagem, os valores de compartimento são inicializados para zero. Para cada item que vai para o histograma de cor 2D 817, o compartimento correspondente ao valor que combina com o valor C1C2 é aumentado por um valor de Contagem determinado (Count0-Count4) que, conforme discutido acima, pode ser baseado no valor de luma. Para cada compartimento no histograma 2D 817, a contagem de pixel total é relatada como parte dos dados estatísticos (por exemplo, STATS0). Em uma modalidade, a contagem de pixel total para cada compartimento pode ter uma resolução de 22 bits, através da qual uma alocação da memória interna igual a 1024x22 bits é fornecida.

[000447] Com referência novamente à Figura 82, os pixels de RGB de Bayer (sinal 806), pixels de sRGBlinear (sinal 810), pixels de sRGB (sinal 812), e pixels de YC1C2 (por exemplo, YCbCr) (sinal 814) são fornecidos para um conjunto de filtros de pixel 824a-c, através dos quais as somas de RGB, sRGBlinear , sRGB, YC1C2 ou camYC1C2 podem ser acumuladas condicionalmente mediante quaisquer condições de pixel de camYC1C2 ou YC1C2, conforme definido por cada filtro de pixel 824. Ou seja, os valores de Y, C1 e C2 a partir de sua conversão de saída do espaço de cor não linear (YC1C2) ou a saída da conversão do espaço de cor da câmera (camYC1C2) são usados para selecionar condicionalmente valores de RGB, sRGBlinear , sRGB ou YC1C2 para acumular. Embora a presente modalidade mostre as lógicas de estatística 3A 742 como tendo 8 filtros de pixel (PF0-PF7) fornecidos, deve-se compreender que qualquer número de filtros de pixel pode ser fornecido.

[000448] A Figura 86 mostra um diagrama de lógica funcional que mostra uma modalidade dos filtros de pixel, especificamente PF0 (824a) e PF1 (824b) a partir da Figura 82. Conforme mostrado, cada filtro de pixel 824 inclui uma lógica de seleção, que recebe os pixels e RGB de Bayer, os pixels sRGBlinear, os pixels sRGB e um ou outro dentre os pixels YC1C2 ou camYC1C2, conforme selecionado por outra lógica de seleção 826. A título de exemplo, a lógica de seleção 825 e 826 pode ser implantada com o uso de multiplexadores ou qualquer outra lógica adequada. A lógica de seleção 826 pode selecionar ou YC1C2 ou camYC1C2. A seleção pode ser realizada em resposta a um sinal de controle que pode ser fornecido pela lógica de controle principal 84 do conjunto de circuitos de processamento de imagem 32 (Figura 7) e/ou configurado por software. A seguir, o filtro de pixel 824 pode usar lógica 827 para avaliar os pixels de YC1C2 (por exemplo, não linear ou de câmera) selecionados pela lógica de seleção 826 em relação a uma condição de pixel. Cada filtro de pixel 824 pode usar o circuito de seleção 825 para selecionar um dentre os pixels RGB da Bayer, pixels sRGBlinear, pixels sRGB e YC1C2 ou pixel camYC1C2, dependendo da saída do circuito de seleção 826.

[000449] Com o uso dos resultados da avaliação, os pixels selecionados pela lógica de seleção 825 podem ser acumulados (828). Em uma modalidade, a condição de pixel pode ser definida com o uso dos limites C1_min, C1_max, C2_min, C2_max, conforme mostrado no gráfico 789 da Figura 80. Um pixel está incluído nas estatísticas se satisfizer as seguintes condições:

[000450] Com referência ao gráfico 829 da Figura 87, em uma modalidade, o ponto 830 representa os valores (C2, C1) correspondentes aos dados de pixel atuais de YC1C2, conforme selecionado pela 826. C1_delta pode ser determinado como a diferença entre C1_1 e C1_0, e C2_delta podem ser determinados como a diferença entre C2_1 e C2_0. Conforme mostrado na Figura 87, os pontos (C1_0, C2_0) e (C1_1, C2_1) podem definir os limite mínimo e máximo para C1 e C2. O Deslocamento pode ser determinado ao multiplicar C1_delta pelo valor 832 (C2_intercept) onde a linha 831 intercepta o eixo geométrico C2. Portanto, presumindo que Y, C1 e C2 satisfazem as condições limítrofes mínima e máxima, os pixels selecionados (Bayer RGB, sRGBlinear, sRGB e YC1C2/camYC1C2) soa incluídos na soma de acúmulo se sua distância 833 da linha 831 for menor que distance_max 834, que pode ser a distância 833 em pixels a partir da linha multiplicada por um fator de normalização:

[000451] Na presente modalidade, distância, C1_delta e C2_delta podem ter uma faixa de -255 a 255. Portanto, distance_max 834 pode ser representado por 17 bits. Os pontos (C1_0, C2_0) e (C1_1, C2_1), assim como os parâmetros para a determinação de distance_max (por exemplo, fator(es) de normalização), podem ser fornecidos como parte da lógica de condição de pixel 827 em cada filtro de pixel 824. Conforme será constatado, as condições de pixel 827 podem ser configuráveis/programáveis.

[000452] Embora o exemplo mostrado na Figura 87 mostre uma condição de pixel com base em dois conjuntos de pontos (C1_0, C2_0) e (C1_1, C2_1), em modalidades adicionais, certos filtros de pixel podem definir mais formatos e regiões complexos mediante as quais as condições de pixel são determinadas. Por exemplo, a Figura 88 mostra uma modalidade em que um filtro de pixel 824 pode definir um polígono de cinco lados 835 com o uso de pontos (C1_0, C2_0), (C1_1, C2_1), (C1_2, C2_2) e (C1_3, C2_3), e (C1_4, C2_4). Cada lado 836a a 836e pode definir uma condição de linha. Entretanto, diferentemente do caso mostrado na Figura 87 (por exemplo, o pixel pode estar em qualquer lado da linha 831 contanto que distance_max seja satisfeita), a condição ode ser que o pixel (C1, C2) tem que estar localizado no lado da linha 836a a 836e de modo que seja abrangido pelo polígono 835. Assim, o pixel (C1, C2) é contado quando a interseção de condições de linha múltiplas é cumprida. Por exemplo, na Figura 88, tal interseção ocorre em relação ao pixel 837a. Entretanto, o pixel 837b falha ao satisfazer a condição de linha para a linha 836d e, portanto, não seria contado nas estatísticas ao ser processado por um filtro de pixel configurada dessa maneira.

[000453] Em uma modalidade adicional mostrada na Figura 89, uma condição de pixel pode ser determinada com base em formatos sobrepostos. Por exemplo, a Figura 89 mostra como um filtro de pixel 824 pode ter condições de pixel definidas com o uso de formatos sobrepostos, aqui, retângulos 838a e 838b definidos pelos pontos (C1_0, C2_0), (C1_1, C2_1), (C1_2, C2_2) e (C1_3, C2_3) e pelos pontos (C1_4, C2_4), (C1_5, C2_5), (C1_6, C2_6) e (C1_7, C2_7), respectivamente. Nesse exemplo, um pixel (C1, C2) pode satisfazer condições de linha definidas por tal filtro de pixel ao ser abrangido no interior da região coletivamente limitada pelos formatos 838a e 838b (por exemplo, ao satisfazer as condições de linha de cada linha que define ambos os formatos). Por exemplo, na Figura 89, essas condições são satisfeitas em relação ao pixel 839a. Entretanto, o pixel 839b falha ao satisfazer essas condições (especificamente em relação à linha 840a do retângulo 838a e linha 840b do retângulo 838b) e, portanto, não seria contado nas estatísticas quando processado por um filtro de pixel configurado dessa maneira.

[000454] Para cada filtro de pixel 824, a pixels qualificados são identificados com base nas condições de pixel definidas pela lógica 827 e, para valores de pixel qualificados, as seguintes estatísticas podem ser coletadas pelo mecanismo de estatísticas 3A 742: somas de 32 bits: (Rsum, Gsum, Bsum) ou (sRlinear_sum, sGlinear_sum, sBlinear_sum) ou (sRsum, sGsum, sBsum) ou (Ysum, C1sum, C2sum) e uma contagem de pixel de 24 bits, Contagem, que pode representara soma do número de pixels que foram incluídos nas estatísticas. Em uma modalidade, o software pode usar a soma para gerar uma média em um azulejo ou janela.

[000455] Quando os pixels camYC1C2 soa selecionados pela lógica 825 de um filtro de pixel 824, limites de cor podem ser realizados em valores croma escalonados. Por exemplo, já que a intensidade de croma nos pontos brancos aumenta com o valor de luma, o uso de croma escalonado com o valor de luma no filtro de pixel 824 pode, em alguns casos, fornecer resultados com consistência melhorada. Por exemplo, condições de luma mínimas e máximas podem permitir que o filtro ignore áreas escuras e/ou claras. Se o pixel satisfizer a condição de pixel YC1C2, os valores de RGB, sRGBlinear , sRGB ou YC1C2 são acumulados. A seleção dos valores de pixel pela lógica de seleção 825 pode depender do tipo de informações necessárias. Por exemplo, para equilíbrio de branco, tipicamente pixels de RGB ou sRGBlinear são selecionados. Para a detecção de condições específicas, como céu, grama, tons e pele, etc., um conjunto de pixel YCC ou sRGB pode ser mais adequado.

[000456] Na presente modalidade, oito conjuntos de condições de pixel podem ser definidos, um associado a cada um dos filtros de pixel PF0-PF7 824. Algumas condições de pixel podem ser definidas para delimitar uma área no espaço de cor C1-C2 (Figura 80) em que é provável que o ponto branco esteja. Isso pode ser determinado ou estimado com base no iluminador atual. Então, somas de RGB acumuladas podem ser usadas para determinar o ponto branco atual com base nas razões de R/G e/ou B/G para ajustes de equilíbrio de branco. Ademais, algumas condições de pixel podem ser definidas ou adaptadas para realizar análise de cena e classificações. Por exemplo, alguns filtros de pixel 824 e janelas/azulejos podem se utilizados para detectar condições, como o céu azul em uma porção de topo de um quadro de imagem, ou grama verde em uma porção inferior de um quadro de imagem. Essas informações também podem ser usadas para ajustar o equilíbrio de branco. Adicionalmente, algumas condições de pixel podem ser definidas ou adaptadas para detectar tons de pele. Para tais filtros, os azulejos podem ser usados para detectar áreas do quadro de imagem que têm tom de pele. Ao identificar essas áreas, a qualidade do tom de pele pode ser aprimorada ao, por exemplo, reduzir a quantidade de filtro de ruído nas áreas de tom de pele e/ou diminuir a quantização na compressão de vídeo naquelas áreas para melhorar a qualidade.

[000457] A lógica de estatísticas 3A 742 também pode fornecer a coleta de dados de luma. Por exemplo, o valor de luma, camY, a partir da conversão de espaço de cor de câmera (camYC1C2), pode ser usado para acumular estatísticas de soma de luma. Em uma modalidade, as seguintes informações de luma podem ser coletadas pela lógica de estatísticas 3A 742:

[000458] Aqui, Ycount1 pode representar o número de pixels subexpostos e Ycount2 pode representar o número de pixels superexpostos. Isso pode ser usado para determinar se a imagem está superexposta ou subexposta. Por exemplo, se os pixels não saturarem, a soma de camY (Ysum) pode indicar luma média em uma cena, o que pode ser usado para alcançar uma exposição AE-alvo. Por exemplo, em uma modalidade, a luma média pode ser determinada ao dividir Ysum pelo número de pixels. Ademais, ao saber as estatísticas de luma/AE para as estatísticas de azulejo e localizações de janela, a medição de AE pode ser realizada. Por exemplo, dependendo da cena de imagem, pode ser desejável pesar as estatísticas AE na janela central com maior peso que aquelas nas bordas da imagem, como pode ser o caso de um retrato.

[000459] Na modalidade aqui ilustrada, a lógica de coleta de estatísticas 3A pode ser configurada para coletar estatísticas em azulejos e janelas. Na configuração ilustrada, uma janela pode ser definida para as estatísticas de azulejo 863. A janela pode ser especificada com um início e largura de coluna, e um início e altura de fileira. Em uma modalidade, a posição de janela e o tamanho podem ser selecionados como um múltiplo de quatro pixels e, nessa janela, as estatísticas são reunidas em azulejos de tamanhos arbitrários. A título de exemplo, todos os azulejos na janela podem ser selecionados de modo que tenham o mesmo tamanho. O tamanho de azulejo pode ser configurado independentemente para as direções horizontal e vertical e, em uma modalidade, o limite máximo no número de azulejos horizontais pode ser configurado (por exemplo, um limite de 128 azulejos horizontais). Ademais, em uma modalidade, o tamanho de azulejo mínimo pode ser configurado para 8 pixels de largura por 4 pixels de altura, por exemplo. Abaixo estão alguns exemplos de configurações de azulejo com base em modos de vídeo/imageamento diferentes e padrões para a obtenção de uma janela de 16x16 azulejos: VGA 640x480: intervalo de azulejo 40x30 pixels HD 1280x720: intervalo de azulejo 80x45 pixels HD 1920x1080: intervalo de azulejo 120x68 pixels 5MP 2592x1944: intervalo de azulejo 162x122 pixels 8MP 3280x2464: intervalo de azulejo 205x154 pixels

[000460] Em relação à presente modalidade, a partir dos oito filtros de pixel disponíveis 824 (PF0-PF7), quatro podem ser selecionados para estatísticas de azulejo 863. Para cada azulejo, as seguintes estatísticas podem ser coletadas:

[000461] Nas estatísticas listadas acima, Count0-3 representa a contagem de pixels que satisfaz as condições de pixel correspondentes aos quatro filtros de pixel selecionados. Por exemplo, se os filtros de pixel PF0, PF1, PF5 e PF6 forem selecionados como os quatro filtros de pixel para um azulejo ou janela particular, então as expressões fornecidas acima podem corresponder aos valores e somas de Contagem correspondentes aos dados de pixel (por exemplo, Bayer RGB, sRGBlinear, sRGB, YC1Y2, camYC1C2) que são selecionados para aqueles filtros (por exemplo, pela lógica de seleção 825). Adicionalmente, os valores de Contagem podem ser usados para normalizar as estatísticas (por exemplo, ao dividir as somas de cor pelos valores de Contagem correspondentes). Conforme mostrado, dependendo pelo menos parcialmente dos tipos de estatísticas necessárias, os filtros de pixel selecionados 824 podem ser configurados para selecionar qualquer um dentre os dados de pixel de RGB de Bayer, sRGBlinear ou sRGB ou dados de pixel de YC1C2 (conversão de espaço de cor não linear ou de câmera, dependendo da seleção por lógica 826) e determinar as estatísticas de soma de cor para os dados de pixel selecionados. Adicionalmente, conforme discutido acima, o valor de luma, camY, a partir da conversão de espaço de cor de câmera (camYC1C2) também é coletado para informações de som ade luma para estatísticas de auto-exposição (AE).

[000462] Adicionalmente, a lógica de estatísticas 3A 742 também pode ser configurada para coletar estatísticas 861 para múltiplas janelas. Por exemplo, em uma modalidade, até oito janelas flutuantes podem ser usadas, com qualquer região retangular tendo um múltiplo de quatro pixels em cada dimensão (por exemplo, altura x largura), até um tamanho máximo correspondente o tamanho do quadro de imagem. Entretanto, a localização das janelas não é necessariamente restrita aos múltiplos de quatro pixels. Por exemplo, as janelas podem se sobrepor umas às outras.

[000463] Na presente modalidade, quatro filtros de pixel 824 podem ser selecionados a partir dos oito filtros de pixel disponível (PF0-PF7) para cada janela. As estatísticas para cada janela podem ser coletadas da mesma maneira que para azulejos, discutidos acima. Portanto, para cada janela, as seguintes estatísticas 861 podem ser coletadas:

[000464] Nas estatísticas listadas acima, Count0-3 representa a contagem de pixels que satisfaz as condições de pixel correspondentes aos quatro filtros de pixel selecionados para uma janela particular. A partir dos oito filtros de pixel disponíveis PF0-PF7, os quatro filtros de pixel ativos podem ser selecionados independentemente para cada janela. Adicionalmente, um dos conjuntos de estatísticas pode ser coletado com o uso de filtros de pixel ou das estatísticas de luma de camY. As estatísticas de janela coletadas para AWB e AE podem, em uma modalidade, ser mapeadas a um ou mais registros.

[000465] Ainda com referência à Figura 82, a lógica de estatísticas 3A 742 também pode ser configurada para adquirir estatísticas de soma de fileira de luma 859 para uma janela com o uso do valor de luma, camY, para a conversão do espaço de cor de câmera. Essas informações podem ser usadas para detectar e compensar por oscilação. A oscilação é gerada por uma variação periódica em algumas fontes de luz florescente e incandescente, tipicamente causada pelo sinal de potência AC. Por exemplo, com referência à Figura 90, um gráfico que ilustra como a oscilação pode ser causada pela variação em uma fonte de luz é mostrado. A detecção de oscilação pode, portanto, ser usada para detectar a frequência da potência AC usada para a fonte de luz (por exemplo, 50 Hz ou 60 Hz). Uma vez que a frequência é conhecida, a oscilação pode ser evitada ao configurar o tempo de integração do sensor de imagem a um múltiplo inteiro do período de oscilação.

[000466] Para detectar a oscilação, a luma da câmera, camY, é acumulada sobre cada fileira. Devido à amostragem descendente dos dados de Bayer de entrada, cada valor de camY pode corresponder a 4 fileiras dos dados de imagem brutos originais. A lógica de controle e/ou firmware pode, então, realizar uma análise de frequência da média da fileira ou, de maneira mais confiável, das diferenças de média de fileira através de quadros consecutivos para determinar a frequência da potência de AC associada a uma fonte de luz particular. Por exemplo, em relação à Figura 90, os tempos de integração para o sensor de imagem pode ser baseado nos tempos t1, t2, t3 e t4, por exemplo, de modo que a integração ocorra em tempos correspondentes a quando uma fonte de iluminação exiba as variações está, em geral, no mesmo nível de claridade.

[000467] Em uma modalidade, uma janela de soma de fileira de luma pode ser especificada e estatísticas 859 são relatadas para pixels naquela janela. A título de exemplo, para a captura de vídeo HD de 1080p, presumindo uma janela de 1024 pixels de altura, as somas de fileira de 256 lumas são geradas (por exemplo, uma sum para cada quatro fileiras devido ao escalonamento descendente por lógica 795) e cada valor acumulado pode ser expresso com 18 bits (por exemplo, valores de camY de 8 bits para até 1024 amostras por fileira).

[000468] A lógica de coleta de estatísticas 3A 742 da Figura 82 também pode fornecer a coleta de estatísticas de autofoco (AF) 842 por meio da lógica de estatísticas de autofoco estatísticas 841. Um diagrama de bloco funcional que mostra uma modalidade da lógica de estatísticas de AF 841 com mais detalhes é fornecido na Figura 91. Conforme mostrado, a lógica de estatísticas de AF 841 pode incluir um filtro horizontal 843 e um detector de borda 844 que é aplicado ao RGB de Bayer original (não amostrado descendentemente), dois filtros 3x3 846 em Y a partir de Bayer e dois filtros 3x3 847 em camY. Em geral, o filtro horizontal 843 fornece estatísticas de resolução fina por componente de cor, os filtros 3x3 846 podem fornecer estatísticas de resolução fina em BayerY (RGB de Bayer com transformada 3x1 (lógica 845) aplicada) e os filtros 3x3 847 podem fornecer estatísticas bidimensionais mais grossas em relação a camY (já que camY é obtido com o uso de dados de RGB de Bayer escalonados descendentemente, isto é, lógica 815). Ademais, a lógica 841 pode incluir a lógica 852 para decimar os dados de RGB de Bayer (por exemplo, ponderação de 2x2, ponderação de 4x4, etc.), e os dados de RGB de Bayer decimados 853 podem ser filtrados com o uso de filtros 3x3 854 para produzir uma saída filtrada 855 para dados de RGB de Bayer decimados. A presente modalidade fornece 16 janelas de estatísticas. Nos limites do quadro bruto, pixels de borda são replicados para os filtros da lógica de estatísticas de AF 841. Os vários componentes da lógica de estatísticas de AF 841 são descritos com mais detalhes abaixo.

[000469] Primeiro, o processo de detecção de borda horizontal inclui aplicar ao filtro horizontal 843 a cada componente de cor (R, Gr, Gb, B) seguido por um detector de borda opcional 844 em cada componente de cor. Portanto, dependendo das condições de imageamento, essa configuração permite que a lógica de estatística de AF 841 seja configurada como um filtro de passa alta sem nenhuma detecção de borda (por exemplo, detector de borda desabilitado) ou, alternativamente, como um filtro passa baixa seguido por um detector de borda (por exemplo, detector de borda habilitado). Por exemplo, em condições de luz baixa, o filtro horizontal 843 pode ser mais suscetível a ruído e, portanto, a lógica 841 pode configurar o filtro horizontal como um filtro passa baixa seguido por um detector de borda habilitado 844. Conforme mostrado, o sinal de controle 848 pode habilitar ou desabilitar o detector de borda 844. As estatísticas dos diferentes canais de cor são usada para determinar a direção do foco para melhorar nitidez, já que as diferentes cores podem focar em profundidades diferentes. Em particular, a lógica de estatísticas de AF 841 pode fornecer técnicas para habilitar o controle de autofoco com o uso de uma combinação de ajustes grossos e finos (por exemplo, para o comprimento focal da lente). As modalidades de tais técnicas são descritas com mais detalhes abaixo.

[000470] Em uma modalidade, o filtro horizontal pode ser um filtro de 7 taps e pode ser definido conforme segue nas Equações 41 e 42:

[000471] Aqui, cada coeficiente af_horzfilt_coeff[0:3] pode estar na faixa de [-2, 2], e i representa o índice de pixel de entrada para R, Gr, Gb ou B. a saída filtrada out(i) pode ser recortada entre um valor mínimo e máximo de -255 e 255, respectivamente (Equação 42). Os coeficientes de filtro podem ser definidos independentemente por componente de cor.

[000472] O detector de borda opcional 844 pode seguir a saída do filtro horizontal 843. Em uma modalidade, o detector de borda 844 pode ser definido como:

[000473] Portanto, o detector de boda 844, quando habilitado, pode emitir um valor com base nos dois pixels em cada lado do pixel de entrada atual i, conforme mostrado pela Equação 43. O resultado pode ser recortado para um valor de 8 bits entre 0 e 255, conforme mostrado na Equação 44.

[000474] Dependendo do fato de a borda ser detectada, a saída final do filtro de pixel (por exemplo, filtro 843 e detector 844) não pode ser selecionada nem como a saída do filtro horizontal 843 nem a saída do detector de borda 844. Por exemplo, conforme mostrado na Equação 45, a saída 849 do detector de borda 844 pode ser edge(i) se uma borda for detectada, ou pode ser o valor absoluto da saída de filtro horizontal out(i) se nenhuma borda for detectada.

[000475] Para cada janela, os valores acumulados edge_sum[R, Gr, Gb, B], podem ser selecionados para serem ou (1) a soma de edge(j,i) para cada pixel através da janela, ou (2) o valor máximo de edge(i) através de uma linha na janela, max(edge), somado através das linhas na janela. Presumindo que um tamanho de quadro bruto de 4096 x 4096 pixels, o número de bits exigido para armazenar os valores máximos de edge_sum[R, Gr, Gb, B] é 30 bits (por exemplo, 8 bits por pixel, mais 22 bits para uma janela que cobre todo o quadro bruto de imagem).

[000476] Conforme discutido, os filtros 3x3 847 para luma de camY podem incluir dois filtros 3x3 programáveis, chamados de F0 e F1, que são aplicados a camY. O resultado do filtro 847 vai ou para uma função quadrada ou uma função de valor absoluto. O resultado é acumulado através de uma dada janela de AF para ambos os filtros 3x3 F0 e F1 para gerar um valor de borda de luma. Em uma modalidade, os valores de borda de luma em cada pixel de camY são definidos conforme segue:

[000477] em que FX representa os filtros programáveis 3x3, F0 e F1, com coeficientes assinados na faixa [-4, 4]. Os índices j e i representam locais na imagem de camY. Conforme discutido acima, o filtro em camY pode fornecer estatísticas de resolução grossa, já que camY é derivado com o uso de dados de RGB de Bayer escalonados descendentemente (por exemplo, 4x4 a 1). Por exemplo, em uma modalidade, os filtros F0 e F1 podem ser configurados com o uso de um operador Scharr, que oferece simetria rotacional melhorada através de um operador Sobel, um exemplo do qual é mostrado abaixo:

[000478] Para cada janela, os valores acumulados 850 determinados pelos filtros 847, edgecamY_FX_sum (em que FX = F0 e F1), podem ser selecionados para ser ou (1) a soma de edgecamY_FX(j,i) para cada pixel através da janela, ou (2) o valor máximo de edgecamY_FX(j) através de uma linha na janela, somado através das linhas na janela. Em uma modalidade, edgecamY _FX_sum pode saturar para um valor de 32 bits quando f(a) é configurado para aA2 para fornecer estatísticas "com mais picos" com uma resolução mais fina. Para evitar saturação, um tamanho de janela máximo X*Y nos pixels de quadro bruto podem ser configurados de modo que não exceda um total de 1024x1024 pixels (por exemplo, isto é X*Y <= 1048576 pixels). Conforme indicado acima, f(a) também pode ser configurado como um valor absoluto para fornecer estatísticas mais lineares.

[000479] Os filtros AF 3x3 846 em Bayer Y podem ser definidos de maneira similar aos filtros 3x3 em camY, mas são aplicados a valores de luma Y gerados a partir do quad de Bayer (2x2 pixels). Primeiro, os valores de RGB de Bayer de 8 bits são convertidos em Y com coeficientes programáveis na faixa [0, 4] para gerar um valor de Y com equilíbrio de branco, conforme mostrado abaixo na Equação 48:

[000480] Como os filtros 847 para camY, os filtros 3x3 846 para luma de bayerY podem incluir dois filtros programáveis 3x3, chamados de F0 e F1, que são aplicados a bayerY. O resultado do filtro 846 vai ou para uma função quadrada ou uma função de valor absoluto. O resultado é acumulado através de uma dada janela de AF para ambos os filtros 3x3 F0 e F1 para gerar um valor de borda de luma. Em uma modalidade, os valores de borda de luma em cada pixel de bayerY são definidos conforme segue:

[000481] em que FX representa os filtros programáveis 3x3, F0 e F1, com coeficientes assinados na faixa de [-4, 4]. Os índices j e i representam locais de pixel na imagem de bayerY. Conforme discutido acima, o filtro no Bayer Y pode fornecer estatísticas de resolução mais fina, já que o sinal de RGB de Bayer recebido pela lógica de AF 841 não é decimado. A título de exemplos apenas, os filtros F0 e F1 da lógica de filtro 846 pode ser configurada com o uso de uma das seguintes configurações de filtro:

[000482] Para cada janela, os valores acumulados 851 determinados pelos filtros 846, edgebayerY _FX_sum (em que FX = F0 e F1), podem ser selecionados ou para (1) a soma de edgebayerY_FX(j,i) para cada pixel através da janela, ou (2) o valor máximo de edgebayerY_FX(j) através de uma linha na janela, somado através das linhas na janela. Aqui, edgebayerY _FX_sum pode saturar para 32 bits quando f(a) é configurado para aA2. Portanto, para evitar a saturação, o tamanho de janela máximo X*Y nos pixels de quadro bruto deveria ser tal que não excedesse um total de 512x512 pixels (por exemplo, X*Y <= 262144). Conforme discutido acima, o ajuste f(a) para aA2 pode fornecer estatísticas com mais picos estatísticas, enquanto o ajuste de f(a) para abs(a) pode fornecer estatísticas mais lineares.

[000483] Conforme discutido acima, as estatísticas 842 para AF são coletadas para 16 janelas. As janelas podem ser qualquer área retangular sendo que cada dimensão é um múltiplo de 4 pixels. Porque cada lógica de filtragem 846 e 847 inclui dois filtros, em alguns casos, um filtro pode ser usado para a normalização através de 4 pixels, e pode ser configurada para filtrar em ambas as direções vertical e horizontal. Ademais, em algumas modalidades, a lógica de AF 841 pode normalizar as estatísticas de AF por claridade. Isso pode ser alcançado ao ajustar um ou mais dos filtros dos blocos de lógica 846 e 847 como filtros de desvio. Em certas modalidades, o local das janelas pode ser restrito ao múltiplo de 4 pixels, e permite-se que as janelas sejam sobrepostas umas às outras. Por exemplo, uma janela pode ser usada para adquirir valores de normalização, enquanto outra janela pode ser usada para estatísticas adicionais, como variância, conforme discutido abaixo. Em uma modalidade, os filtros AF (por exemplo, 843, 846, 847) podem não implantar a replicação de pixel na borda de um quadro de imagem e, portanto, para que os filtros AF usem todos os pixels válidos, as janelas de AF podem ser configuradas de modo que tenham, cada uma, pelo menos 4 pixels a partir da borda superior do quadro, pelo menos 8 pixels a partir da borda inferior do quadro e pelo menos 12 pixels a partir da borda esquerda/direita do quadro. Na modalidade ilustrada, as seguintes estatísticas podem ser coletadas e reportadas para cada janela:

[000484] Em tal modalidade, a memória exigida para o armazenamento das estatísticas de AF 842 pode ser 16 (janelas) multiplicada por 8 (Gr, R, B, Gb, bayerY_F0, bayerY_F1, camY_F0, camY_F1) multiplicada por 32 bits.

[000485] Portanto, em uma modalidade, o valor acumulado por janela pode ser selecionado entre: a saída do filtro (que pode ser configurada como uma configuração padrão), o pixel de entrada, ou o pixel de entrada ao quadrado. A seleção pode ser feita pra cada uma das janelas 16 AF, e pode aplicar a todas as estatísticas de AF 8 (listadas acima) em uma dada janela. Isso pode ser usado para normalizar a classificação de AF entre duas janelas sobrepostas, uma das quais é configurada para coletar a saída do filtro e uma das quais é configurada para coletar a soma de pixel de entrada. Adicionalmente, para calcular a variância de pixel em caso de duas janelas sobrepostas, uma janela pode ser configurada para coletar a soma de pixel de entrada, e outra para coletar a soma quadrada do pixel de entrada, fornecendo, assim, uma variância que pode ser calculada como:

[000486] Com o uso das estatísticas de AF, a lógica de controle de ISP 84 (Figura 7) pode ser configurada para ajustar um comprimento focal da lente de um dispositivo de imagem (por exemplo, 30) com o uso de uma série de ajustes de comprimento focal com base em "classificações" de autofoco grossas e finas para colocar uma imagem em foco. Conforme discutido acima, os filtros 3x3 847 para camY podem fornecer estatísticas grossas, enquanto o filtro horizontal 843 e o detector de borda 844 podem fornecer estatísticas comparativamente mais finas por componente de cor, enquanto os filtros 3x3 846 em BayerY podem fornecer estatísticas finas em BayerY. Ademais, os filtros 3x3 854 em um sinal de RGB de Bayer decimado 853 podem fornecer estatísticas grossas para cada canal de cor. Conforme discutido adicionalmente abaixo, classificações de AF podem ser calculadas com base nos valores de saída de filtro para um sinal de entrada particular (por exemplo, soma das saídas de filtro F0 e F1 para camY, BayerY, RGB de Bayer RGB decimado, ou com base em saídas de detector horizontal/de borda, etc.).

[000487] A Figura 92 mostra um gráfico 856 que mostra curvas 858 e 860 que representam classificações grossa e fina de AF, respectivamente. Conforme mostrado, as classificações de AF grossas baseadas nas estatísticas grossas podem ter uma reposta mais linear através da distância focal da lente. Portanto, em qualquer posição focal, um movimento de lente pode gerar uma mudança em uma classificação de auto foco que pode ser usada para detectar se a imagem está se ficando mais em foco ou fora de foco. Por exemplo, um aumento na classificação de AF grossa após um ajuste de lente pode indicar que o comprimento focal está sendo ajustado na direção correta (por exemplo, em direção à posição focal).

[000488] Entretanto, conforme a posição focal óptica está se aproximando, a mudança na classificação de AF grossa para etapas de ajuste de lente menores pode diminuir, tornando difícil discernir a direção correta do ajuste focal. Por exemplo, conforme mostrado no gráfico 856, a mudança na classificação de AF grossa entre posição grossa (CP) CP1 e CP2 é representada por Δ C12, que mostra um aumento em aspereza de CP1 para CP2. Entretanto, conforme mostrado, de CP3 a CP4, a mudança ΔC34 na classificação de AF grossa (que passa pela posição focal ótima (OFP)), embora ainda esteja aumentando, é relativamente menor. Deve-se compreender que as posições CP1 a CP6 ao longo do comprimento focal L não soa destinadas a corresponder necessariamente aos tamanhos de etapa assumidos pela lógica de autofoco ao longo do comprimento focal. Ou seja, pode haver etapas adicionais entre cada posição grossa que não são mostradas. As posições ilustradas CP1-CP6 são apenas destinadas a mostrarem a mudança na classificação de AF grossa pode diminuir gradualmente conforme a posição focal se aproxima da OFP.

[000489] Uma vez que a posição aproximada da OFP é determinada (por exemplo, com base nas classificações de AF grossas mostradas na Figura 92, a posição aproximada da OFP pode estar entre CP3 e CP5), valores de classificação de AF fina, representados pela curva 860 pode ser avaliada para refinar a posição focal. Por exemplo, classificações de AF finas podem estar mais planas quando a imagem está fora de foco, de modo que uma grande mudança posicional da lente não cause uma grande mudança na classificação de AF fina. Entretanto, conforme a posição focal se aproxima da posição focal óptica (OFP), a classificação de AF fina pode mudar bruscamente com pequenos ajustes posicionais. Portanto, ao localizar um pico ou ápice 862 na curva de classificação de AF 860, a OFP pode ser determinada para a cena de imagem atual. Portanto, resumindo, classificações de AF grossas podem ser usadas para determinar as proximidades gerais da posição focal óptica, enquanto as classificações de AF finas podem ser usadas para apontar uma posição mais exata naquelas vizinhanças.

[000490] Em uma modalidade, o processo de autofoco pode começar ao adquirir classificações de AF grossas ao longo de todo o comprimento focal disponível, iniciando na posição 0 e terminando na posição L (mostrada no gráfico 856) e determinar as classificações de AF grossas em várias posições de etapa (por exemplo, CP1 a CP6). Em uma modalidade, uma vez que a posição focal da lente alcançou a posição L, a posição pode reiniciar em 0 antes de avaliar aas classificações de AF em várias posições focais. Por exemplo, isso pode ser devido ao tempo de permanência de bobina de um elemento mecânico que controla a posição focal. Nessa modalidade, após reiniciar na posição 0, a posição focal pode ser ajustada em direção à posição L para uma posição que indicou, primeiramente, uma mudança negativa em uma avaliação de AF grossa, aqui, posição CP5 que exibe uma mudança negativa ΔC45 em relação à posição CP4. A partir da posição CP5, a posição focal pode ser ajustada em aumentos menores em relação aos aumentos usados nos ajustes de avaliação de AF grossa (por exemplo, posições FP1, FP2, FP3, etc.) de volta na direção rumo à posição 0, enquanto busca por um pico 862 na curva de classificação de AF fina 860. Conforme discutido acima, a posição focal OFP correspondente ao pico 862 na curva de classificação de AF fina 860 pode ser a posição focal ótima para a cena de imagem atual.

[000491] Conforme será constatado, as técnicas descritas acima para localizar a área ótima e a posição ótima para o foco podem ser chamadas de "escalada de morro" no sentido de que as mudanças nas curvas para as classificações de AF 858 e 860 são analisadas para localizar a OFP. Ademais, enquanto a análise das classificações de AF grossas (curve 858) e as classificações de AF finas (curva 860) são mostradas como usando etapas de mesmo tamanho para a análise de classificação grossa (por exemplo, distância entre CP1 e CP2) e etapas de mesma dimensão para a análise de classificação fina (por exemplo, distância entre FP1 e FP2), em algumas modalidades, os tamanhos de etapa podem ser variados, dependendo da mudança na classificação de uma posição para a próxima. Por exemplo, em uma modalidade, o tamanho de etapa entre CP3 e CP4 pode ser reduzido em relação ao tamanho de etapa entre CP1 e CP2 já que o delta geral na avaliação de AF grossa (ΔC34) é menor que o delta de CP1 a CP2 (ΔC12).

[000492] Um método 864 que retrata esse processo é ilustrado na Figura 93. Iniciando no bloco 865, uma avaliação de AF grossa é determinada para dados de imagem em várias etapas ao longo do comprimento focal, a partir da posição 0 à posição L (Figura 92). Posteriormente, no bloco 866, as classificações de AF grossas são analisadas e a posição grossa que exibe a primeira mudança negativa na avaliação de AF grossa é identificada como um ponto inicial para a análise de classificação de AF fina. Por exemplo, subsequentemente, no bloco 867, a posição focal é retornada em direção À posição inicial 0 em etapas menores, sendo que a classificação de AF fina em cada etapa é analisada até que um pico na curva de classificação de AF (por exemplo, curva 860 da Figura 92) seja localizado. No bloco 868, a posição focal correspondente ao pico é configurada como a posição focal ótima para a cena de imagem atual.

[000493] Conforme discutido acima, devido aos tempos de ajuste de bobina mecânico, a modalidade da técnica mostrada na Figura 93 pode ser adaptada para adquirir classificações de AF grossas ao longo de todo o comprimento focal inicialmente, em vez de analisar cada posição grossa uma a uma e buscar uma área de foco ótima. Outras modalidades, entretanto, modalidades nas quais os tempos de ajuste de bobina não são uma grande preocupação podem analisar classificações de AF grossas uma a uma em cada etapa, em vez de buscar todo o comprimento focal.

[000494] Em certas modalidades, as classificações de AF podem ser determinadas com o uso de valores de luma com equilíbrio de branco derivados dos dados de RGB de Bayer. Por exemplo, o valor de luma, Y, pode ser derivado ao decimar um quad de Bayer 2x2 por um fator de 2, conforme mostrado na Figura 94, ou ao decimar um bloco de pixel 4x4 que consiste em quatro quads de Bayer 2x2 por um fator de 4, conforme mostrado na Figura 95. Em uma modalidade, classificações de AF podem ser determinadas com o uso de gradientes. Em outra modalidade, as classificações de AF podem ser determinadas ao aplicar uma transformada 3x3 com o uso de um operador de Scharr, que fornece simetria rotacional enquanto minimiza erros angulares ao quadrado ponderados no domínio de Fourier. A título de exemplo, o cálculo de uma avaliação de AF grossa ou camY com o uso de um operador de Scharr comum (discutido acima) é mostrado abaixo:

[000495] em que in representa o valor Y de luma decimado. Em outras modalidades, a classificação de AF para ambas as estatísticas grossa e fina pode ser calculada com o uso de outras transformadas 3x3.

[000496] Os ajustes de autofoco também podem ser realizados de modo diferente, dependendo dos componentes de cor, já que comprimentos de onda diferentes de luz podem ser afetados diferentemente pela lente, que é uma razão pela qual o filtro horizontal 843 é aplicado a cada componente de cor independentemente. Portanto, o autofoco ainda pode ser realizado mesmo na presença de uma aberração cromática na lente. Por exemplo, porque vermelho e azul focam tipicamente em uma posição ou distância diferente em relação ao verde quando aberrações cromáticas estão presentes, classificações de AF relativas para cada color podem ser usadas para determinar a direção para o foco. Isso é mais bem ilustrado na Figura 96, que mostra a posição focal ótima para os canais de cor azul vermelho e verde para uma lente 870. Conforme mostrado, as posições focais ótimas para vermelho, verde e azul são mostradas por letras de referência R, G e B respectivamente, cada uma correspondente a uma classificação de AF, com uma posição focal atual 872. Em geral, em tal configuração, pode ser desejável selecionar a posição focal ótima como a posição correspondente à posição focal ótima para componentes verdes (por exemplo, já que RGB de Bayer tem duas vezes mais componentes verdes que vermelhos ou azuis), aqui, posição G. Portanto, pode-se esperar que, para uma posição focal ótima, o canal verde devesse exibir a classificação de autofoco mais alta. Portanto, com base nas posições das posições focais ótimas para cada cor (sendo que aquelas mais próximas à lente têm classificações de AF mais altas), a lógica de AF 841 e a lógica de controle associada 84 podem determinar em qual direção focar, com base nas classificações de AF relativas para azul, verde e vermelho. Por exemplo, se o canal azul tiver uma classificação de AF mais alta em relação ao canal verde (conforme mostrado na Figura 96), então a posição focal é ajustara na direção negativa (em direção ao sensor de imagem) sem ter que primeiramente analisar na direção positiva a partir da atual posição 872. Em algumas modalidades, a detecção ou análise iluminadora com o uso de temperaturas correlacionadas a cor (CCT) pode ser realizada.

[000497] Ademais, conforme mencionado acima, classificações de variância também podem ser usadas. Por exemplo, somas de pixel e valores de soma ao quadrado podem ser acumulados para tamanhos de bloco (por exemplo, 8x8 a 32x32 pixels), e podem ser usadas para derivar classificações de variância (por exemplo, avg_pixel2) - (avg_pixel)A2). As variâncias podem ser somadas para que se obtenha uma classificação de variância total para cada janela. Tamanhos de bloco menores podem ser usados para obter classificações de variância finas e tamanhos de bloco maiores podem ser usados para obter classificações de variância mais grossas.

[000498] Com referência à lógica de estatísticas 3A 742 da Figura 82, a lógica 742 também pode ser configurada para coletar histogramas de componente 874 e 876. Conforme será constatado, os histogramas podem ser usados para analisar a distribuição de nível de pixel em uma imagem. Isso pode ser útil para a implantação de certas funções, como equalização de histograma, em que os dados de histograma são usados para determinar a especificação de histograma (combinação de histograma). A título de exemplo, histogramas de luma podem ser usados para AE (por exemplo, para ajustar/configurar os tempos de integração do sensor) e histogramas de cor podem ser usados para AWB. Na presente modalidade, os histogramas podem ser de 256, 128, 64 ou 32 compartimentos (em que os 8, 7, 6, e 5 compartimentos superiores do pixel são usados para determinar o compartimento, respectivamente) para cada componente de cor, conforme especificado por um tamanho de compartimento (BinSize). Por exemplo, quando os dados de pixel são de 14 bits, um fator de escala adicional entre 0 e 6 e um deslocamento podem ser especificados para determinar que faixa (por exemplo, quais 8 compartimentos) dos dados de pixel é coletada para fins de estatísticas. O número de compartimento pode ser obtido conforme segue:

[000499] Em uma modalidade, os compartimentos de histograma de cor são aumentados apenas se os índices de compartimento estiverem na faixa [0, 2A(8-BinSize)]:

[000500] Na presente modalidade, as unidades de processamento de estatística 142 podem incluir duas unidades de histograma. Esse primeiro histograma 874 (Hist0) pode ser configurado para coletar dados de pixel como parte da coleta de estatísticas após a decimação 4x4. Para Hist0, os componentes podem ser selecionados para serem RGB, sRGBlinear, sRGB ou YC1C2 com o uso do circuito de seleção 880. O segundo histograma 876 (Hist1) pode ser configurada para coletar dados de pixel antes da pipeline de estatísticas (antes da lógica de correção de pixel defectivo 738), conforme mostrado com mais detalhes na Figura 96. Por exemplo, os dados brutos de RGB de Bayer (saída de 146) podem ser decimados (para produzir o sinal 878) com o uso da lógica 882 por pixels de omissão, conforme discutido adicionalmente abaixo. Para o canal verde, a cor pode ser selecionada entre Gr, Gb ou ambas Gr e Gb (ambas as contagens de Gr e Gb são acumuladas nos compartimentos de Verde).

[000501] Para manter a largura de compartimento de histograma igual entre os dois histogramas, Hist1 pode ser configurado para coletar dados de pixel a cada 4 pixels (a cada dois quads de Bayer). O início da janela de histograma determina a localização do primeiro quad de Bayer em que o histograma inicia acumulando. Iniciando nesse local, cada segundo quad de Bayer é pulado horizontalmente e verticalmente para Hist1. A localização de início da janela pode ser qualquer posição de pixel para Hist1 e, portanto, os pixels sendo pulados pelo cálculo de histograma podem ser selecionados ao mudar a localização de janela de início. Hist1 pode ser usado para coletar dados, representados por 884 na Figura 97, fechar o nível de preto para auxiliar a compensação de nível de preto dinâmica no bloco 739. Portanto, embora seja mostrado na Figura 97 como estando separado da lógica de estatísticas 3A 742 para fins ilustrativos, deve-se compreender que o histograma 876 pode, na verdade, ser parte das estatísticas gravadas na memória, e pode ser realmente fisicamente localizado nas unidades de processamento de estatística 142.

[000502] Na presente modalidade, os compartimentos de vermelho (R) e azul (B) podem ser de 20 bits, sendo que o compartimento de verde (G) tem 21 bits (Verde é maior para acomodar o acúmulo de Gr e Gb no Hist1). Isso permite um tamanho de imagem máximo de 4160 por 3120 pixels (12 MP). O tamanho de memória interna exigida é 3x256x20(1) bits (3 componentes de cor, 256 compartimentos).

[000503] Em relação ao formato de memória, estatísticas para janelas de AWB/AE, janelas de AF, histograma de cor 2D e histogramas de componente podem ser mapeados em registros para permitir um acesso precoce por firmware. Em uma modalidade, dois ponteiros de memória podem ser usados para gravar estatísticas na memória, um para estatísticas de azulejo 863, e um para somas de fileira de luma 859, seguido por todas as outras estatísticas coletadas. Todas as estatísticas são gravadas na memória externa, que pode ser memória DMA. Os registros de endereço de memória podem ser duplamente armazenados temporariamente de modo que uma nova localização na memória possa ser especificada em cada quadro.

[000504] Antes de prosseguir com uma discussão detalhada da lógica de pipe de ISP 82 a jusante a partir da lógica de front-end de ISP 80, deve-se compreender que a disposição de vários blocos de lógica funcionais nas unidades de processamentos de estatística 142 e 144 (por exemplo, blocos de lógica 738, 739, 740, 741, e 742) e a unidade de processamento de pixel de front-end de ISP 150 (por exemplo, blocos de lógica 650 e 652) são destinados a ilustrar apenas uma modalidade da presente técnica. De fato, em outras modalidades, os blocos de lógica ilustrados no presente documento podem ser dispostos em ordenação diferente ou podem incluir blocos de lógica adicionais que podem realizar funções de processamento de imagem adicionais não especificamente descritas no presente documento. Ademais, deve-se compreender que as operações de processamento de imagem realizadas nas unidades de processamentos de estatística (por exemplo, 142 e 144), como correção de sombreamento de lente, detecção/correção de pixel defectivo e compensação de nível de preto, são realizadas nas unidades de processamentos de estatística para os fins de coleta de dados estatísticos. Portanto, as operações de processamento realizadas sobres os dados de imagem recebidos pelas unidades de processamento estatísticas não são de fato refletidas no sinal de imagem 109 (FEProcOut) que é emitido a partir da lógica de processamento de pixel de front-end de ISP 150 e encaminhado para a lógica de processamento de pipe de ISP 82.

[000505] Antes de continuar, também se deve notar que, dado o tempo de processamento suficiente e a similaridade entre muitas das exigências de processamento das várias operações descritas no presente documento, é possível reconfigurar os blocos funcionais mostrados no presente documento para realizar o processamento de imagem de maneira sequencial, em vez de uma natureza em pipeline. Conforme será compreendido, isso pode reduzir, ainda, os custos de implantação geral de hardware, mas também aumentará a largura de banda para a memória externa (por exemplo, para armazenar em cache/armazenar resultados/dados imediatos).

A Lógica de Processamento de Pipeline ("Pipe") de ISP

[000506] Tendo descrito a lógica de front-end de ISP 80 com detalhes acima, a presente discussão deslocará seu foco, agora, para a lógica de processamento de pipe de ISP 82. Em geral, a função da lógica de pipe de ISP 82 é para receber dados de imagem brutos, que podem ser fornecidos a partir da lógica de front-end de ISP 80 ou recuperados a partir da memória 108 e para realizar operações de processamento de imagem adicionais, isto é, anteriormente à emissão dos dados de imagem ao dispositivo de exibição 28.

[000507] Um diagrama de bloco que mostra uma modalidade da lógica de pipe de ISP 82 é mostrado na Figura 98. Conforme ilustrado, a lógica de pipe de ISP 82 pode incluir lógica de processamento bruto 900, lógica de processamento de RGB 902, e lógica de processamento de YCbCr 904. A lógica de processamento bruto 900 pode realizar várias operações de processamento de imagem, como detecção e correção de pixel defectivo, correção de sombreamento de lente, interpolação, assim como aplicação de ganhos para auto-equilíbrio de branco e/ou configuração de nível de preto, conforme será adicionalmente discutido abaixo. Conforme mostrado na presente modalidade, o sinal de entrada 908 à lógica de processamento bruto 900 pode ser a saída de pixel bruto 109 (sinal FEProcOut) a partir da lógica de front-end de ISP 80 ou dos dados de pixel brutos 112 a partir da memória 108, dependendo da presente configuração da lógica de seleção 906.

[000508] Como consequência das operações de interpolação realizadas na lógica de processamento bruto 900, a saída de sinal de imagem 910 pode estar no domínio de RGB e pode ser, subsequentemente, encaminhada para a lógica de processamento de RGB 902. Por exemplo, conforme mostrado na Figura 98, a lógica de processamento de RGB 902 recebe o sinal 916, que pode ser o sinal de saída 910 ou um sinal de imagem de RGB 912 a partir da memória 108, dependendo da presente configuração da lógica de seleção 914. A lógica de processamento de RGB 902 pode fornecer várias operações de ajuste de cor de RGB, incluindo correção de cor (por exemplo, com o uso de uma matriz de correção de cor), a aplicação de ganhos de cor para o auto-equilíbrio de branco, assim como o mapeamento de tom global, conforme será adicionalmente discutido abaixo. A lógica de processamento de RGB 904 também pode fornecer conversão de espaço de cor de dados de imagem de RGB em no espaço de cor YCbCr (luma/croma). Portanto, a saída de sinal de imagem 918 pode estar no domínio de YCbCr e pode ser subsequentemente encaminhada para a lógica de processamento de YCbCr 904.

[000509] Por exemplo, conforme mostrado na Figura 98, a lógica de processamento de YCbCr 904 recebe o sinal 924, que pode ser o sinal de saída 918 da lógica de processamento de RGB 902 ou um sinal de YCbCr 920 a partir da memória 108, dependendo da presente configuração da lógica de seleção 922. Conforme será discutido com mais detalhes abaixo, a lógica de processamento de YCbCr 904 pode fornecer operações de processamento de imagem no espaço de cor YCbCr, incluindo ajustes de escalonamento, supressão de croma, nitidez de luma, claridade, contraste e cor (BCC), mapeamento de gama de YCbCr, decimação de croma e assim por diante. A saída de sinal de imagem 926 da lógica de processamento de YCbCr 904 pode ser enviada para a memória 108 ou pode ser saída da lógica de processamento de pipe de ISP 82 como o sinal de imagem 114 (Figura 7). A seguir, de acordo com a modalidade do conjunto de circuitos de processamento de imagem 32 demonstrado na Figura 7, o sinal de imagem 114 pode ser enviado para o dispositivo de exibição 28 (seja diretamente ou através da memória 108) para a visualização por parte do usuário, ou pode ser adicionalmente processado com o uso de um mecanismo de compressão (por exemplo, encodificador 118), uma CPU/GPU, um mecanismo de gráficos ou similares. Adicionalmente, em uma modalidade em que uma unidade de back-end de ISP 120 é incluída no conjunto de circuitos de processamento de imagem 32 (por exemplo, Figura 8), o sinal de imagem 114 pode ser enviado à lógica de processamento de back-end de ISP 120 para pós-processamento a jusante adicional.

[000510] De acordo com modalidades das presentes técnicas, a lógica de pipe de ISP 82 pode suportar o processamento dos dados de pixel brutos em formatos de 8 bits, 10 bits, 12 bits ou 14 bits. Por exemplo, em uma modalidade, dados de entrada de 8 bits, 10 bits ou 12 bits podem ser convertidos em 14 bits na entrada da lógica de processamento bruto 900 e o processamento bruto e as operações de processamento de RGB podem ser realizados com a precisão de 14 bits. Na modalidade posterior, os dados de imagem de 14 bits podem ser amostrados descendentemente para 10 bits anteriormente à conversão dos dados de RGB em espaço de cor de YCbCr e o processamento de YCbCr (lógica 904) pode ser realizado com precisão de 10 bits.

[000511] Para fornecer uma descrição abrangente das várias funções fornecidas pela lógica de processamento de pipe de ISP 82, cada uma dentre a lógica de processamento bruto 900, lógica de processamento de RGB 902 e lógica de processamento de YCbCr 904, assim como lógica interna para realizar várias operações de processamento de imagem que podem ser implantadas em cada unidade de lógica respectiva 900, 902 e 904, será discutida sequencialmente abaixo, começando pela lógica de processamento bruto 900. Por exemplo, com referência, agora, à Figura 99, um diagrama de bloco que mostra uma vista com mais detalhes de uma modalidade da lógica de processamento bruto 900 é ilustrado, de acordo com uma modalidade da presente técnica. Conforme mostrado, a lógica de processamento bruto 900 inclui a lógica de ganho, deslocamento, e clamping (GOC) 930, lógica de detecção/correção de pixel defectivo (DPDC) 932, a lógica de redução de ruído 934, lógica de correção de sombreamento de lente 936, lógica de GOC 938 e lógica de interpolação 940. Ademais, embora os exemplos discutidos abaixo presumam o uso de uma matriz de filtro de cor de Bayer com o(s) sensor(es) de imagem 90, deve-se compreender que outras modalidades da presente técnica podem utilizar tipos diferentes de filtros de cor também.

[000512] O sinal de entrada 908, que pode ser um sinal de imagem bruto, é primeiramente recebido pela lógica de ganho, deslocamento e clamping (GOC) 930. A lógica de GOC 930 pode fornecer funções similares e pode ser implantada de maneira similar em relação à lógica de BLC 739 das unidades de processamento de estatística 142 da lógica de front-end de ISP 80, conforme discutido acima na Figura 68. Por exemplo, a lógica de GOC 930 pode fornecer ganho digital, deslocamentos e clamping (recorte) independentemente de cada componente de cor R, B, Gr e Gb de um sensor de imagem de Bayer. Particularmente, a lógica de GOC 930 pode realizar o auto-equilíbrio de branco ou configurar o nível de preto dos dados de imagem brutos. Ademais, em algumas modalidades, a lógica de GOC 930 também pode ser usada para corrigir ou compensar um deslocamento entre os componentes de cor Gr e Gb.

[000513] Em operação, o valor de entrada para o pixel atual é o primeiro desvio por um valor assinado e multiplicado por um ganho. Essa operação pode ser realizada com o uso da fórmula mostrada na Equação 11 acima, em que X representa o valor de pixel de entrada para um dado componente de cor R, B, Gr ou Gb, O[c] representa um deslocamento de 16 bits assinado para o componente de cor c atual, e G[c] representa um valor de ganho para o componente de cor c. Os valores para G[c] podem ser previamente determinados durante os processamentos de estatística (por exemplo, no bloco de front-end de ISP 80). Em uma modalidade, o ganho G[c] pode ser um número não assinado de 16 bits com 2 bits inteiros 14 bits fracionados (por exemplo, representação de ponto de flutuação de 2.14) e o ganho G[c] pode ser aplicado com arredondamento. A título de exemplo, apenas, o ganho G[c] pode ter uma faixa entre 0 e 4X.

[000514] O valor de pixel computado Y (que inclui o ganho G[c] e deslocamento O[c]) da Equação 11 deve, então, ser recortado para uma faixa de mínimo e máximo de acordo com a Equação 12. Conforme discutido acima, as variáveis min[c] e max[c] podem representar "valores de recorte" de 16 bits assinados para os valores de saída mínimo e máximo, respectivamente. Em uma modalidade, a lógica GOC 930 também pode ser configurada para manter uma contagem do número de pixels que foram recortados acima e abaixo das faixas de máximo e mínimo, respectivamente, para cada componente de cor.

[000515] Subsequentemente, a saída da lógica de GOC 930 é encaminhada para a lógica de detecção e correção de pixel defectivo 932. Conforme discutido acima, com referência à Figura 68 (lógica de DPDC 738), os pixels defectivos podem ser atribuídos a vários fatores e podem incluir pixels "quentes" (ou vazados), pixels "presos" e pixels "mortos", em que pixels quentes exibem uma carga de vazamento mais alta que o normal em relação a pixels não defectivos e, portanto, podem parecer ser mais claros que um pixel não defectivo e em que um pixel preso parece estar sempre ativado (por exemplo, completamente carregado) e, portanto, parece ser mais claro, enquanto um pixel morto parece estar sempre desativado. Sendo assim, pode ser desejável ter um esquema de detecção de pixel que seja robusto o suficiente para identificar e tratar de tipos diferentes de casos de falha. Particularmente, quando comparada à lógica de front-end DPDC 738, que pode fornecer apenas detecção/correção dinâmica, a lógica de pipe de DPDC 932 pode fornecer a detecção/correção de defeito estática ou fixa, detecção/correção de defeito dinâmico, assim como remoção de mancha.

[000516] De acordo com as modalidades das técnicas aqui apresentadas, a correção/detecção de pixel defectivo realizada pela lógica de DPDC 932 pode ocorrer independentemente de cada componente de cor (por exemplo, R, B, Gr e Gb) e pode incluir várias operações para detectar pixels defectivos, assim como para corrigir os pixels defectivos detectados. Por exemplo, em uma modalidade, as operações de detecção de pixel defectivo podem fornecer a detecção de defeitos estatísticos, defeitos dinâmicos, assim como a detecção de mancha, que ode se referir às interferências elétricas ou ruído (por exemplo, ruído de fóton) que pode estar presente no sensor de imageamento. Por analogia, a mancha pode aparecer em uma imagem como artefatos de ruído aparentemente aleatórios, similar ao modo como estática pode aparecer em um visor, como um visor de televisão. Ademais, conforme indicado acima, a correção de defecção dinâmica é tida como sendo dinâmica no sentido de que a caracterização de um pixel como sendo defectivo em um dado momento pode depender dos dados de imagem nos pixels vizinhos. Por exemplo, um pixel preso que está sempre em claridade máxima pode não ser tido como um pixel defectivo se o local do pixel preso estiver em uma área da imagem atual que é dominante por cores brancas claras. De modo contrário, se o pixel preso estiver em uma região da imagem atual que é dominada por preto ou cores mais escuras, então o pixel preso pode ser identificado como um pixel defectivo durante processamento pela lógica de DPDC 932 e corrigido em conformidade.

[000517] Em relação à detecção de defeito estático, o local de cada pixel é comparado a uma tabela de defeito estático, que pode armazenar dados correspondentes ao local dos pixels que são conhecidamente defectivos. Por exemplo, em uma modalidade, a lógica de DPDC 932 pode monitorar a detecção dos pixels defectivos (por exemplo, com o uso de um mecanismo contador ou registro) e, se um pixel particular for observado como falhando repetidamente, o local daquele pixel é armazenado na tabela de defeito estático. Portanto, durante a detecção de defeito estático, se for determinado que o local do pixel atual está na tabela de defeito estático, então o pixel atual é identificado como sendo um pixel defectivo e um valor de substituição é determinado e temporariamente armazenado. Em uma modalidade, o valor de substituição pode ser o valor do pixel anterior (com base em ordem de varredura) do mesmo componente de cor. O valor de substituição pode ser usado para corrigir o defeito estático durante a detecção e correção de defeito dinâmico/mancha, conforme será discutido abaixo. Adicionalmente, se o pixel anterior estiver fora do quadro bruto 310 (Figura 23), então seu valor não é usado e o defeito estático pode ser corrigido durante o processo de correção de defeito dinâmico. Ademais, devido a considerações de memória, a tabela de defeito estático pode armazenar um número finito de entradas de localização. Por exemplo, em uma modalidade, a tabela de defeito estático pode ser implantada como uma fila de FIFO configurada para armazenar um total de 16 localizações para cada duas linhas de dados de imagem. As localizações definidas na tabela de defeito estático serão, ainda assim, corrigidas com o uso de um valor de substituição de pixel anterior (em vez de através do processo de detecção de defeito dinâmico discutido abaixo). Conforme mencionado acima, as modalidades da presente técnica também podem fornecer a atualização da tabela de defeito estático de modo intermitente através do tempo.

[000518] As modalidades podem prover que a tabela de defeito estático seja implantada em memória em chip ou memória fora de chip. Conforme será constatado, o uso de uma implantação em chip pode aumentar a área/tamanho geral do chip, enquanto o uso de uma implantação fora de chip pode reduzir a área/tamanho do chip, mas aumentar as exigências de largura de banda da memória. Portanto, deve-se compreender que a tabela de defeito estático pode ser implantada ou no chip ou fora do chip, dependendo de exigências de implantação específicas, isto é, o número de pixels total que deve ser armazenado na tabela de defeito estático.

[000519] Os processos de detecção de defeito dinâmico e mancha podem ser deslocados no tempo em relação ao processo de detecção de defeito estático discutido acima. Por exemplo, em uma modalidade, o defeito dinâmico e o processo de detecção de mancha podem começar após o processo de detecção e defeito estático ter analisado duas linhas de varredura (por exemplo, fileiras) de pixels. Conforme pode ser constatado, isso permite a identificação de defeitos estáticos e seus respectivos valores de substituição a serem determinados antes que a detecção dinâmica/de mancha ocorra. Por exemplo, durante o processo de detecção dinâmico/de mancha, se o pixel atual estivesse previamente marcado como sendo um defeito estático, em vez de aplicar as operações de detecção dinâmica/de mancha, o defeito estático é simplesmente corrigido com o uso do valor de substituição previamente avaliado.

[000520] Em relação à detecção de defeito dinâmico e mancha, esses processos podem ocorrer sequencialmente ou em paralelo. A detecção e correção de defeito dinâmico e mancha que é realizada pela lógica de DPDC 932 pode contar com a detecção de borda adaptativa com o uso de gradientes de direção de pixel para pixel. Em uma modalidade, a lógica de DPDC 932 pode selecionar os oitos vizinhos imediatos do pixel atual que têm o mesmo componente de cor que estão no quadro bruto 310 (A Figura 23) são usados. Em outras palavras, os pixels atuais e seus oito vizinhos imediatos P0, P1, P2, P3, P4, P5, P6 e P7 podem formar um área 3x3, conforme mostrado abaixo na Figura 100.

[000521] Deve-se notar, entretanto, que, dependendo do local do pixel atual P, os pixels fora do quadro bruto 310 não são considerados ao calcular gradientes pixel a pixel. Por exemplo, em relação ao caso de "superior esquerdo" 942 mostrado na Figura 100, o pixel atual P etapa no canto superior esquerdo do quadro bruto 310 e, portanto, os pixels vizinhos P0, P1, P2, P3 e P5 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P4, P6 e P7 (N=3). No caso "superior" 944, o pixel atual P está na borda mais superior do quadro bruto 310 e, portanto, os pixels vizinhos P0, P1 e P2 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P3, P4, P5, P6 e P7 (N=5). A seguir, no caso "superior direito" 946, o pixel atual P está em um canto superior direito do quadro bruto 310 e, portanto, os pixels vizinhos P0, P1, P2, P4 e P7 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P3, P5 e P6 (N=3). No caso "esquerdo" 948, o pixel atual P está na borda mais esquerda do quadro bruto 310 e, portanto, os pixels vizinhos P0, P3 e P5 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P1, P2, P4, P6 e P7 (N=5).

[000522] No caso do "centro" 950, todos os pixels P0 a P7 se encontram no quadro bruto 310 e são, portanto, usados na determinação de gradientes pixel a pixel (N=8). No caso da "direita" 952, o pixel atual P está na borda mais à direita do quadro bruto 310 e, portanto, os pixels vizinhos P2, P4 e P7 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P0, P1, P3, P5 e P6 (N=5). Adicionalmente, no caso "inferior esquerdo" 954, o pixel atual P está no canto inferior esquerdo do quadro bruto 310 e, portanto, os pixels vizinhos P0, P3, P5, P6 e P7 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P1, P2 e P4 (N=3). No caso "inferior" 956, o pixel atual P está na borda mais inferior do quadro bruto 310 e, portanto, os pixels vizinhos P5, P6 e P7 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P0, P1, P2, P3 e P4 (N=5). Finalmente, no caso "inferior direito" 958, o pixel atual P está no canto inferior direito do quadro bruto 310 e, portanto, os pixels vizinhos P2, P4, P5, P6 e P7 fora do quadro bruto 310 não são considerados, deixando apenas os pixels P0, P1 e P3 (N=3).

[000523] Portanto, dependendo da posição do pixel atual P, o número de pixels usados na determinação dos gradientes pixel a pixel pode ser 3, 5 ou 8. Na modalidade ilustrada, para cada pixel vizinho (k = 0 a 7) no limite da figura (por exemplo, quadro bruto 310), os gradientes pixel a pixel podem ser calculados conforme segue: G = abs(p-p), for o <k <7(apenas para k no quadro bruto) (51)

[000524] Adicionalmente, um gradiente médio, Gav, pode ser calculado como a diferença entre o pixel atual e a média, Pav, de seus pixels vizinhos, conforme mostrado pelas equações abaixo:

[000525] Os valores de gradiente pixel a pixel (Equação 51) podem ser usados na determinação de um caso de defeito dinâmico e a média dos pixels vizinhos (Equações 52a e 52b) pode ser usada na identificação de casos de mancha, conforme discutido adicionalmente abaixo.

[000526] Em uma modalidade, a detecção de defeito dinâmico pode ser realizada pela lógica DPDC 932, conforme segue. Primeiro, presume-se que um pixel está defectivo se um certo número dos gradientes Gk estiver em ou abaixo de um limite particular, denotado pela variável dynTh (limite de defeito dinâmico). Portanto, para cada pixel, uma contagem (C) do número de gradientes para pixels vizinhos dentro dos limites da imagem que estão em ou abaixo do limite dynTh é acumulado. O limite dynTh pode ser uma combinação de um componente limite fixo e um componente limite dinâmico que pode depender da "atividade" presente nos pixels vizinhos. Por exemplo, em uma modalidade, o componente de limite dinâmico para dynTh pode ser determinado ao calcular um valor de componente de alta frequência Phf com base na soma da diferença absoluta entre valores de pixel médios Pav (Equação 52a) e cada pixel vizinho, conforme ilustrado abaixo:

[000527] Em casos em que o pixel está localizado em um canto de imagem (N=3) ou em uma borda de imagem (N=5), o Phf pode ser multiplicado por 8/3 ou 8/5, respectivamente. Conforme pode ser constatado, isso garante que um componente de alta frequência Phf seja normalizado com base em oito pixels vizinhos (N=8).

[000528] Uma vez que o Phf é determinado, o limite de detecção de defeito dinâmico dynTh pode ser computado conforme mostrado abaixo:

[000529] em que dynTh1 representa o componente de limite fixo e em que dynTh2 representa o componente de limite dinâmico e é um multiplicador para Phf na Equação 53. Um componente de limite fixo diferente dynTh1 pode ser fornecido para cada componente de cor, mas para cada pixel de mesma cor, dynTh1 é igual. A título de exemplo, apenas, dynTh1 pode ser configurado de modo que esteja pelo menos acima da variância de ruído na imagem.

[000530] O componente de limite dinâmico dynTh2 pode ser determinado com base em algumas características da imagem. Por exemplo, em uma modalidade, dynTh2 pode ser determinado com o uso de dados empíricos armazenados em relação ao tempo de integração de exposição e/ou sensor. Os dados empíricos podem ser determinados durante a calibração do sensor de imagem (por exemplo, 90) e podem associar os valores de componente de limite dinâmico que podem ser selecionados para dynTh2 a cada um dos vários pontos de dados. Portanto, com base no valor de tempo de integração de exposição e/ou sensor atual, que pode ser determinado durante processamentos de estatística na lógica de front-end de ISP 80, dynTh2 pode ser determinado ao selecionar o valor de componente de limite dinâmico a partir dos dados empíricos que correspondem ao valor de tempo de integração de exposição e/ou sensor atual. Adicionalmente, se o valor de tempo de integração de exposição e/ou sensor atual não corresponder diretamente a um dos pontos de dados empíricos, então dynTh2 pode ser determinado ao interpolar os valores de componente de limite dinâmico associados aos pontos de dados entre os quais o valor de tempo de integração de exposição e/ou sensor atual cai. Ademais, como o componente de limite fixo dynTh1, o componente de limite dinâmico dynTh2 pode ter valores diferentes para cada componente de cor. Portanto, o valor limite compósito dynTh pode variar para cada componente de cor (por exemplo, R, B, Gr, Gb).

[000531] Conforme mencionado acima, para cada pixel, uma contagem C do número de gradientes para pixels vizinhos dentro dos limites da imagem que estão em ou abaixo do limite dynTh é determinada. Por exemplo, para cada pixel vizinho no quadro bruto 310, a contagem acumulada C dos gradientes Gk que estão em ou abaixo do limite dynTh pode ser computada conforme segue:

para 0<k<7 (apenas para k no quadro bruto)

[000532] A seguir, se a contagem acumulada C for determinada como sendo menor ou igual a uma contagem máxima, denotada pela variável dynMaxC, então o pixel pode ser considerado como um defeito dinâmico. Em uma modalidade, valores diferentes para dynMaxC podem ser fornecidos para as condições N=3 (canto), N=5 (borda) e N=8. Essa lógica é expressa abaixo:

[000533] Conforme mencionado acima, a localização dos pixels defectivos pode ser armazenada na tabela de defeito estático. Em algumas modalidades, o valor de gradiente mínimo (min(Gk)) calculado durante a detecção de defeito dinâmico para o pixel atual pode ser armazenado e pode ser usado para classificar os pixels defectivos, de modo que um valor de gradiente mínimo maior indique uma "gravidade" maior de defeito e deva ser corrigido durante a correção de pixel antes que defeitos menos graves sejam corrigidos. Em uma modalidade, um pixel pode precisar ser processado através de quadros de imageamento múltiplo antes de serem armazenados na tabela de defeito estático, como pela filtragem dos locais de pixels defectivos através do tempo. Na modalidade posterior, o local do pixel defectivo pode ser armazenado na tabela de defeito estático apenas se o defeito aparecer em um número particular de imagens consecutivas na mesma localização. Ademais, em algumas modalidades, a tabela de defeito estático pode ser configurada para classificar as localizações de pixel defectivo classificado com base nos valores de gradiente mínimos. Por exemplo, o valor de gradiente mínimo mais alto pode indicar um defeito de maior "gravidade". Ao ordenar as localizações dessa maneira, a prioridade de correção de defeito estático pode ser configurada, de modo que os defeitos mais graves ou importantes possam ser corrigidos primeiro. Adicionalmente, a tabela de defeito estático pode ser atualizada através do tempo ara incluir include defeitos estáticos recentemente detectados e ordená-los em conformidade, com base em seus respectivos valores de gradiente mínimos.

[000534] A detecção de mancha, que pode ocorrer paralelamente ao processo de detecção de defeito dinâmico descrito acima, pode ser realizada ao determinar se o valor Gav (Equação 52b) está cima de um limite de detecção de mancha spkTh. Como o limite de defeito dinâmico dynTh, o limite de mancha spkTh também pode incluir componentes fixos e dinâmicos, chamados de spkTh1 e spkTh2, respectivamente. Em geral, os componentes fixos e dinâmicos spkTh1 e spkTh2 podem ser configurados mais "agressivamente" se comparados aos valores dynTh1 e dynTh2, para evitar a detecção falsa de mancha em áreas da imagem que podem ser mais texturizadas e outras, como texto, folhagem, certos padrões de tecido etc. Em conformidade, em uma modalidade, o componente de limite de mancha dinâmico spkTh2 pode ser aumentado para áreas de alta textura da imagem e diminuído para áreas mais "planas" ou mais uniformes. O limite de detecção de mancha spkTh pode ser computado conforme mostrado abaixo:

[000535] em que spkTh1 representa o componente limite fixo e em que spkTh2 representa o componente de limite dinâmico. A detecção de mancha pode, então, ser determinada de acordo com a seguinte expressão:

[000536] Uma vez que pixels defectivos foram identificados, a lógica de DPDC 932 pode aplicar operações de correção de pixel, dependendo do tipo de defeito detectado. Por exemplo, se o pixel defectivo foi identificado como um defeito estático, o pixel é substituído pelo valor de substituição armazenado, conforme discutido acima (por exemplo, o valor do pixel anterior do mesmo componente de cor). Se o pixel foi identificado ou como um defeito dinâmico ou como uma mancha, então a correção de pixel pode ser realizada conforme segue. Primeiro, os gradientes são computados como a soma da diferença absoluta entre o pixel central e um primeiro e segundo pixels vizinhos (por exemplo, a computação de Gk da Equação 51) para quatro direções, uma direção horizontal (h), uma direção vertical (v), uma direção diagonal-positiva (dp) e uma direção diagonal-negativa (dn), conforme mostrado abaixo:

[000537] A seguir, o valor de pixel corretivo PC pode ser determinado através de interpolação linear dos dois pixels vizinhos associados ao gradiente direcional Gh, Gv, Gdp e Gdn que tem o valor menor. Por exemplo, em uma modalidade, a declaração de lógica abaixo pode expressão o cálculo de PC:

[000538] As técnicas de correção de pixel implantadas pela lógica de DPDC 932 também podem dar conta de exceções em condições de limite. Por exemplo, se um dos dois pixels vizinhos associados à direção de interpolação selecionada estiver fora do quadro bruto, então o valor do pixel vizinho que está no quadro bruto é substituído. Portanto, com o uso dessa técnica, o valor de pixel corretivo será equivalente ao valor do pixel vizinho no quadro bruto.

[000539] Deve-se notar que as técnicas de detecção/correção de pixel defectivo aplicadas pela lógica de DPDC 932 durante o processamento de pipe de ISP são mais robustas, se comparadas à lógica de DPDC 738 na lógica de front-end de ISP 80. Conforme discutido na modalidade acima, a lógica de DPDC 738 realiza apenas a detecção de defeito dinâmico e a correção com o uso de pixels vizinhos apenas na direção horizontal, enquanto a lógica de DPDC 932 fornece a detecção e a correção de defeitos estáticos, defeitos dinâmicos, assim como mancha, com o uso de pixels vizinhos em ambas as direções horizontal e vertical.

[000540] Conforme será constatado, o armazenamento da localização dos pixels defectivos com o uso da tabela de defeito estático pode fornecer o temporização de filtro de pixels defectivos com menos exigências de memória. Por exemplo, se comparada a muitas técnicas convencionais que armazenam imagens inteiras e aplicam temporização de filtro para identificar defeitos estáticos através do tempo, as modalidades da presente técnica apenas armazena as localizações de pixels defectivos, que podem, tipicamente, ser realizadas com o uso de apenas uma fração da memória exigida para armazenar todo um quadro de imagem. Ademais, conforme discutido acima, o armazenamento de um valor de gradiente mínimo (min(Gk)), permite um uso eficiente da tabela de defeito estático, priorizando a ordem das localizações nas quais os pixels defectivos são corrigidos (por exemplo, iniciando com aqueles que serão mais visíveis).

[000541] Adicionalmente, o uso de limites que incluem um componente dinâmico (por exemplo, dynTh2 e spkTh2) pode ajudar a reduzir detecções de feito falsas, um problema frequentemente encontrado em sistemas de processamento de imagem convencionais quando áreas de textura de alto processamento de uma imagem (por exemplo, texto, folhagem, certos padrões de tecido etc.). Ademais, o uso de gradientes direcionais (por exemplo, h, v, dp, dn) para a correção de pixel pode reduzir a aparência de artefatos visuais se uma detecção de defeito falsa ocorrer. Por exemplo, a filtragem na direção de gradiente mínima pode resultar em uma correção que ainda rende resultados aceitáveis na maioria dos caos, mesmo em casos de detecção falsa. Adicionalmente, a inclusão do pixel atual P no calculo de gradiente pode melhorar a precisão da detecção de gradiente, particularmente no caso de pixels quentes.

[000542] Técnicas de detecção e correção de pixel defectivo discutidas acima implantadas pela lógica de DPDC 932 podem ser resumidas por uma série de fluxogramas fornecidos nas Figuras 101 a 103. Por exemplo, com referência, primeiramente, à Figura 101, um processo 960 para detectar defeitos estatísticos é ilustrado. Iniciando na etapa 962, um pixel de entrada P é recebido em um primeiro tempo, T0. A seguir, na etapa 964, a localização do pixel P é comparada aos valores armazenados em uma tabela de defeito estático. A lógica de decisão 966 determina se a localização do pixel P é encontrada na tabela de defeito estático. Se a localização de P estiver na tabela de defeito estático, então o processo 960 continua para a etapa 968, em que o pixel P é marcado como um defeito estativo e um valor de substituição é determinado. Conforme discutido acima, o valor de substituição pode ser determinado com base no valor do pixel anterior (em ordem de varredura) do mesmo componente de cor. O processo 960 continua, então, para a etapa 970, na qual o processo 960 prossegue para o processo de detecção dinâmica e de mancha 980, ilustrado na Figura 102. Adicionalmente, se na lógica de decisão 966, a localização do pixel P for determinada como não estando na tabela de defeito estático, então o processo 960 prossegue para a etapa 970 sem a realização da etapa 968.

[000543] Continuando para a Figura 102, o pixel de entrada P é recebido no tempo T1, conforme mostrado pela etapa 982, para o processamento para determinar se um defeito dinâmico ou mancha está presente. O tempo T1 pode representar um deslocamento de tempo em relação ao processo de detecção de defeito estático 960 da Figura 101. Conforme discutido acima, a o processo de detecção de defeito dinâmico e mancha pode começar após o processo de detecção de defeito estático analisar duas linhas de varredura (por exemplo, fileiras) de pixels, permitindo, assim, que o tempo para a identificação de defeitos estáticos e seus respectivos valores de substituição sejam determinados antes que a detecção dinâmica/de mancha ocorra.

[000544] A lógica de decisão 984 determina se o pixel de entrada P foi previamente marcado como um defeito estático (por exemplo, pela etapa 968 do processo 960). Se P for marcado como um defeito estático, então o processo 980 pode continuar para o processo de correção de pixel mostrado na Figura 103 e pode desviar do resto das etapas mostradas na Figura 102. Se a lógica de decisão 984 determinar que o pixel de entrada P não é um defeito estático, então o processo continua para a etapa 986 e os pixels vizinhos que podem ser usados no processo de defeito dinâmico e mancha são identificados. Por exemplo, de acordo com a modalidade discutida acima e ilustrada na Figura 100, os pixels vizinhos podem incluir os 8 vizinhos imediatos do pixel P (por exemplo, P0 a P7), formando, assim, uma área de pixel 3x3. A seguir, na etapa 988, os gradientes pixel a pixel são calculados em relação a cada pixel vizinho no quadro bruto 310, conforme descrito na Equação 51 acima. Adicionalmente, um gradiente médio (Gav) pode ser calculado como a diferença entre o pixel atual e a média de seus pixels circundantes, conforme mostrado nas Equações 52a e 52b.

[000545] O processo 980 se ramifica, então, para a etapa 990 para a detecção de defeito dinâmico e a lógica de decisão 998 para a detecção de mancha. Conforme indicado acima, a detecção de defeito dinâmico e a detecção de mancha podem, em algumas modalidades, ocorrer paralelamente. Na etapa 990, uma contagem C do número de gradientes que são menores ou iguais ao limite dynTh é determinada. Conforme descrito acima, o limite dynTh pode incluir componentes fixos e dinâmicos e, em uma modalidade, podem ser determinados de acordo com a Equação 53 acima. Se C for menor ou igual a uma contagem máxima, dynMaxC, então o processo 980 continua para a etapa 996 e o pixel atual é marcado como sendo um defeito dinâmico. Posteriormente, o processo 980 pode prosseguir para o processo de correção de pixel mostrado na Figura 103, que será discutido abaixo.

[000546] De volta à ramificação após a etapa 988, para a detecção de mancha, a lógica de decisão 998 determina se o gradiente médio Gav é maior que um limite de detecção de mancha spkTh, que também pode incluir um componente fixo e dinâmico. Se Gav for maior que o limite spkTh, então o pixel P é marcado como contendo mancha na etapa 1000 e, posteriormente, o processo 980 continua para a Figura 103 para a correção do pixel manchado. Ademais, se a saída de ambos os blocos de lógica de decisão 992 e 998 for "NÃO", então isso indica que o pixel P não contém defeitos dinâmicos, mancha ou mesmo defeitos estáticos (lógica de decisão 984). Portanto, quando as saídas da lógica de decisão 992 e 998 são ambas "NÃO"o processo 980 pode ser concluído na etapa 994, através do qual o pixel P passa não modificado, já que nenhum defeito (por exemplo, estático, dinâmico ou mancha) foi detectado.

[000547] Continuando para a Figura 103, um processo de correção de pixel 1010 de acordo com técnicas descritas acima é fornecido. Na etapa 1012, o pixel de entrada P é recebido a partir do processo 980 da Figura 102. Deve-se notar que o pixel P pode ser recebido pelo processo 1010 a partir da etapa 984 (defeito estático) ou a partir das etapas 996 (defeito dinâmico) e 1000 (defeito de mancha). A lógica de decisão 1014 determina, então, se o pixel P é marcado como um defeito estático. Se o pixel P for um defeito estático, então o processo 1010 continua e termina na etapa 1016, através da qual o defeito estático é corrigido com o uso do valor de substituição determinado na etapa 968 (Figura 101).

[000548] Se o pixel P não for identificado como um defeito estático, então o processo 1010 continua a partir da lógica de decisão 1014 para a etapa 1018 e os gradientes direcionais são calculados. Por exemplo, conforme discutido acima com referência às Equações 58 a 61, os gradientes podem ser computados como a soma da diferença absoluta entre o pixel central e os primeiro e segundo pixels vizinhos para quatro direções (h, v, dp e dn). A seguir, na etapa 1020, o gradiente direcional que tem o menor valor é identificado e, posteriormente, a lógica de decisão 1022 avalia se um ou dois pixels vizinhos associados ao gradiente mínimo estão localizados fora do quadro de imagem (por exemplo, quadro bruto 310). Se ambos os pixels vizinhos estiverem no quadro de imagem, então o processo 1010 continua para a etapa 1024 e um valor de correção de pixel (PC) é determinado pela aplicação de interpolação linear aos valores de dois pixels vizinhos, conforme ilustrado pela Equação 62. Depois disso, o pixel de entrada P pode ser corrigido com o uso do valor de correção de pixel interpolado PC, conforme mostrado na etapa 1030.

[000549] Voltando à lógica de decisão 1022, se for determinado que um de dois pixels vizinhos estão localizados fora do quadro de imagem (por exemplo, quadro bruto 165), então em vez de usar o valor do pixel externo (Pout), a lógica de DPDC 932 pode substituir o valor de Pout pelo valor do outro pixel vizinho que está dentro do quadro de imagem (Pin), conforme mostrado na etapa 1026. Posteriormente, na etapa 1028, o valor de correção de pixel PC é determinado pela interpolação dos valores de Pin e o valor substituído de Pout. Em outras palavras, nesse caso, PC pode ser equivalente ao valor de Pin. Concluindo na etapa 1030, o pixel P é corrigido com o uso do valor PC. Antes de continuar, deve-se compreender que os processos particulares de detecção e correção de pixel defectivo discutidos no presente documento com referência à lógica de DPDC 932 são destinados a refletir apenas uma modalidade possível da presente técnica. De fato, dependendo das restrições de projeto e/ou custo, um número de variações é possível e as características podem ser adicionadas ou removidas de modo que a complexidade e robustez geral da lógica de detecção/correção de defeito está entre a lógica de detecção/correção mais simples 738 implantada no bloco de front-end de ISP 80 e a lógica de detecção/correção de defeito discutida aqui com referência à lógica de DPDC 932.

[000550] Com referência, novamente, à Figura 99, os dados de pixel corrigidos são emitidos a partir da lógica de DPDC 932 e, então, recebidos pela lógica de redução de ruído 934 para processamento adicional. Em uma modalidade, a lógica de redução de ruído 934 pode ser configurada para implantar a filtragem de passa baixa adaptativa de borda bidimensional para reduzir o ruído nos dados de imagem enquanto mantém detalhes e texturas. Os limites adaptativos de borda podem ser ajustados (por exemplo, pela lógica de controle 84) com base nos níveis de iluminação presentes, de modo que a filtragem possa ser reforçada sob condições de luz baixa. Ademais, conforme mencionado brevemente acima em relação à determinação dos valores de dynTh e spkTh, a variância de ruído pode ser determinada antes da hora para um dado sensor de modo que os limites de redução de ruído possam ser ajustados logo acima da variância de ruído, de modo que, durante a redução de ruído processamento, o ruído seja reduzido sem afetar significativamente as texturas e detalhes da cena (por exemplo, evitar/reduzir detecções falsas). Presumindo uma implantação de filtro de cor de Bayer, a lógica de redução de ruído 934 pode processar cara componente de cor Gr, R, B e Gb independentemente com o uso de um filtro de 7 toque separável horizontal e um filtro de 5 taps vertical. Em uma modalidade, o processo de redução de ruído pode ser realizado ao corrigir a não uniformidade nos componentes de cor de verde (Gb e Gr) e, então, realizar filtragem horizontal e filtragem vertical.

[000551] A não uniformidade verde (GNU) é, em geral, caracterizada por uma leve diferença de claridade entre os pixels de Gr e Gb dada uma superfície plana iluminada uniformemente. Sem corrigir ou compensar essa não uniformidade, certos artefatos, como um artefato de "labirinto", podem aparecer na imagem de cor completa após interpolação. O processo de não uniformidade de verde pode incluir a determinação, para cada pixel verde nos dados de imagem de Bayer brutos, se a diferença absoluta entre um pixel verde atual (G1) e o pixel verde à direita e abaixo (G2) do pixel atual é menor que um limite de correção de GNU (gnuTh). A Figura 104 ilustra a localização dos pixels G1 e G2 em uma área de 2x2 de um padrão de Bayer. Conforme mostrado, a cor dos pixels limítrofes com G1 pode depender de se o pixel verde atual é um pixel Gb ou Gr. Por exemplo, se G1 for Gr, então G2 é Gb, o pixel à direita de G1 é R (vermelho) e o pixel abaixo de G1 é B (azul). Alternativamente, se G1 for Gb, então G2 é Gr e o pixel à direita de G1 é B, enquanto o pixel abaixo G1 é R. se a diferença absoluta entre G1 e G2 for menor que o valor limite de correção de GNU, então o pixel verde atual G1 é substituído pela média de G1 e G2, conforme mostrado pela lógica abaixo:

[000552] Conforme pode ser constatado, a aplicação de correção de não uniformidade de verde, dessa maneira, pode ajudar a evitar que os pixels G1 e G2 sejam ponderados através das bordas, melhorando e/ou preservando, assim, a nitidez.

[000553] A horizontalização de filtro é aplicada subsequentemente à correção de não uniformidade de verde e pode, em uma modalidade, fornecer um filtro horizontal de 7 taps. Os gradientes através da borda de cada tap de filtro são computados e, se estiver acima de um limite de borda horizontal (horzTh), o tap de filtro é dobrado para o pixel central, conforme será ilustrado abaixo. Em certas modalidades, a filtragem de ruído pode ser adaptativa de borda. Por exemplo, o filtro horizontal pode ser um filtro de resposta de impulso finita (FIR) em que os taps de filtro são usados apenas se a diferença entre o pixel central e o pixel no tap for menor que um limite que depende da variância de ruído. O filtro horizontal pode processar os dados independentemente para cada componente de cor (R, B, Gr, Gb) e pode usar valores não filtrados como valores de entrada.

[000554] A título de exemplo, A Figura 105 shows a representação gráfica de um conjunto de pixels horizontais P0 a P6, com um tap central posicionado em P3. Com base nos pixels mostrados na Figura 105, gradientes de borda para cada tap de filtro podem ser calculados conforme segue:

[000555] Os gradientes de borda Eh0 a Eh5 podem, então, ser utilizados pelo componente de filtro horizontal para determinar uma saída e horizontalização de filtro, Phorz, com o uso da fórmula mostrada na Equação 70 abaixo:

[000556] em que horzTh[c] é o limite de borda horizontal para cada componente de cor c (por exemplo, R, B, Gr e Gb) e em que C0 a C6 são os coeficientes de tap de filtro correspondentes aos pixels P0 a P6, respectivamente. A saída de filtro horizontal Phorz pode ser aplicada na localização de pixel central P3. Em uma modalidade, os coeficientes de tap de filtro C0 a C6 podem ser valores complementares de duplas de 16 bits com 3 bits inteiros e 13 bits fracionais (3.13 em ponto de flutuação). Ademais, deve-se notar que os coeficientes de tap de filtro C0 a C6 não precisam ser necessariamente simétricos em relação ao pixel central P3.

[000557] A filtragem vertical também é aplicada pela lógica de redução de ruído 934 subsequente aos processos de correção de não uniformidade de verde e horizontalização de filtro. Em uma modalidade, a operação de filtro vertical pode fornecer um filtro de 5 taps, conforme mostrado na Figura 106, com o tap central do filtro vertical localizado em P2. O processo de filtragem vertical pode ocorrer de maneira similar ao processo de horizontalização de filtro descrito acima. Por exemplo, os gradientes através da borda de cada tap de filtro são computados e, se estiver acima de um limite de borda vertical (vertTh), o tap de filtro é dobrado para o pixel central P2. O filtro vertical pode processar os dados de imagem independentemente para cada componente de cor (R, B, Gr, Gb) e pode usar valores não filtrados como valores de entrada.

[000558] Com base nos pixels mostrados na Figura 106, os gradientes de borda vertical para cada tap de filtro podem ser calculados conforme segue:

[000559] Os gradientes de borda Ev0 a Ev5 podem, então, ser utilizados pelo filtro vertical para determinar uma saída de filtragem vertical, Pvert, com o uso da fórmula mostrada na Equação 75 abaixo:

[000560] em que vertTh[c] é o limite de borda vertical para cada componente de cor c (por exemplo, R, B, Gr e Gb) e em que C0 a C4 soa os coeficientes de tap de filtro correspondentes aos pixels P0 a P4 da Figura 106, respectivamente. A saída de filtro vertical Pvert pode ser aplicada na localização de pixel central P2. Em uma modalidade, os coeficientes de tap de filtro C0 a C4 podem ser os valores de complemento da dupla de 16 bits com 3 bits inteiros e 13 bits fracionais (3.13 em ponto de flutuação). Ademais, deve-se notar que os coeficientes de tap de filtro C0 a C4 não precisam necessariamente ser simétricos em relação ao pixel central P2.

[000561] Adicionalmente, em relação às condições de limite, quando os pixels vizinhos estiverem fora do quadro bruto 310 (Figura 23), os valores dos pixels fora do limite são replicados com o valor do pixel de mesma cor na borda do quadro bruto. Essa convenção pode ser implantada para ambas as operações de filtragem horizontal e vertical. A título de exemplo, com referência, novamente, à Figura 105, no caso de horizontalização de filtro, se o pixel P2 for um pixel de borda na borda mais à esquerda do quadro bruto e os pixels P0 e P1 estiverem fora do quadro bruto, então os valores dos pixels P0 e P1 são substituídos pelo valor do pixel P2 para a filtração horizontal.

[000562] Com referência, novamente, ao diagrama de bloco da lógica de processamento bruto 900 mostrado na Figura 99, a saída output da lógica de redução de ruído 934 é subsequentemente enviada para a lógica de correção de sombreamento de lente (LSC) 936 para processamento. Conforme discutido acima, as técnicas de correção de sombreamento de lente podem incluir a aplicação de um ganho apropriado em uma base por pixel para compensar a intensidade de quedas de luz, que pode ser o resultado da óptica geométrica da lente, imperfeições na fabricação, desalinhamento da matriz de microlentes e do filtro de matriz de cor e assim por diante. Ademais, o filtro de infravermelho (IR) em algumas lentes pode fazer com que o descarte seja dependente de iluminador e, portanto, os ganhos de sombreamento de lente podem ser adaptados, dependendo da fonte de luz detectada.

[000563] Na modalidade retratada, já lógica de LSC 936 do pipe de ISP 82 pode ser implantada de maneira similar e fornece, assim, em geral, as mesmas funções que a lógica de LSC 740 do bloco de frontend de ISP 80, conforme discutido acima com referência às Figuras 71 a 79. Em conformidade, para evitar a redundância, deve-se compreender que a lógica de LSC 936 da modalidade aqui ilustrada é configurada para operar, em geral, da mesma maneira que a lógica de LSC 740 e, sendo assim, a descrição das técnicas de correção de sombreamento de lente fornecida acima não será repetida aqui. Entretanto, pra resumir, em geral, deve-se compreender que a lógica de LSC 936 pode processar cada componente de cor do fluo de dados de pixel brutos independentemente para determinar um ganho para aplicar ao pixel atual. De acordo com as modalidades discutidas acima, o ganho de correção de sombreamento de lente pode ser determinado com base em um conjunto de pontos de grade de ganho definido distribuído através do quadro de imageamento, em que o intervalo entre cada ponto de grade é definido por um número de pixels (por exemplo, 8 pixels, 16 pixels etc.). Se a localização do pixel atual corresponde a um ponto de grade, então o valor de ganho associado àquele ponto de grade é aplicado ao pixel atual. Entretanto, se a localização do pixel atual estiver entre pontos de grade (por exemplo, G0, G1, G2 e G3 da Figura 74), então o valor de ganho de LSC pode ser calculado pela interpolação dos pontos de grade entre os quais o pixel atual está localizado (Equações 13a e 13b). esse processo é demonstrado pelo processo 772 da Figura 75. Ademais, conforme mencionado acima em relação à Figura 73, em algumas modalidades, o ponto de grades pode ser distribuído de maneira não uniforme (por exemplo, de modo logarítmico), de modo que os pontos de grade estejam menos concentrados no centro da região de LSC 760, mas mais concentrados em direção aos cantos da região de LSC 760, tipicamente onde a distorção de sombreamento de lente é mais notável.

[000564] Adicionalmente, conforme discutido acima com referência às Figuras 78 e 79, a lógica de LSC 936 também pode aplicar um componente de ganho radial com os valores de ganho de grade. O componente radial de ganho pode ser determinado com base na distância do pixel atual do centro da imagem (Equações 14 a 16). Conforme mencionado, o uso de um ganho radial permite o uso de grade de ganho comum única para todos os componentes de cor, que pode reduzir enormemente o espaço de armazenamento total exigido para o armazenamento de grades de ganho separadas para cada componente de cor. Essa redução nos dados de ganho de grade pode diminuir os custos de implantação, já que as tabelas de dados de ganho de grade podem dar conta uma porção significativa da memória ou área de chip no hardware de processamento de imagem.

[000565] A seguir, com referência, novamente, ao diagrama de bloco da lógica de processamento bruto 900 da Figura 99, a saída da lógica de LSC 936 é, então, passada para um segundo bloco de ganho, deslocamento e clamping (GOC) 938. A lógica de GOC 938 pode ser aplicada anteriormente à interpolação (pelo bloco de lógica 940) e pode ser usada para realizar um auto-equilíbrio de branco na saída da lógica de LSC 936. Na modalidade retratada, a lógica de GOC 938 pode ser implantada da mesma maneira que a lógica de GOC 930 (e a lógica de BLC 739). Portanto, de acordo com a Equação 11 acima, a entrada recebida ela lógica de GOC 938 é primeiro desviada por um valor assinado e, então, multiplicada por um ganho. O valor resultante é, então, recortado para uma faixa de mínimo e máximo de acordo com a Equação 12.

[000566] Posteriormente, a saída da lógica de GOC 938 é encaminhada para a lógica de interpolação 940 para o processamento para produzir uma imagem de cor total (RGB) com base nos dados de entrada de Bayer brutos. Conforme será constatado, a saída bruta de um sensor de imagem com o uso de uma matriz de filtro de cor, como um filtro de Bayer está "incompleta" no sentido de que cada pixel é filtrado para adquirir apenas um único componente de cor. Portanto, os dados coletados para um pixel individual é insuficiente para determinar cor. Em conformidade, as técnicas de interpolação podem ser usadas para gerar uma imagem de cor completa a partir dos dados de Bayer brutos ao interpolar os dados de cor ausentes para cada pixel.

[000567] Com referência, agora, à Figura 107, um fluxo de processo gráfico 692 que fornece uma visão geral em relação a como a interpolação pode ser aplicada um padrão de imagem de Bayer bruta 1034 para produzir um RGB de cor total é ilustrado. Conforme mostrado, uma porção 4x4 1036 da imagem de Bayer bruta 1034 pode incluir canais separados para cada componente de cor, incluindo um canal verde 1038, um canal vermelho 1040 e um canal azul 1042. Porque cada pixel de imageamento em um sensor de Bayer adquire apenas dados para uma cor, os dados de cor para cada canal de cor 1038, 1040 e 1042 podem estar incompletos, conforme indicado pelos símbolos de "?". Ao aplicar uma técnica de interpolação 1044, as amostras de cor faltosas de cada canal podem ser interpoladas. Por exemplo, conforme mostrado pelo número de referência 1046, os dados G’ interpolados podem ser usados para preencher as amostras faltosas no canal de cor verde. De modo similar, os dados interpolados R’ podem (em combinação com os dados interpolados G’ 1046) ser usados para preencher as amostras faltosas no canal de cor vermelho 1048 e os dados interpolados B’ podem (em combinação com os dados interpolados G’ 1046) ser usados para preencher as amostras faltosas no canal de cor azul 1050. Portanto, como resultado do processo de interpolação, cada canal de cor (R, G, B) terá um conjunto de dados de cor completo, que pode, então, ser usado para reconstruir uma imagem de RGB de cor total 1052.

[000568] Uma técnica de interpolação que pode ser implantada pela lógica de interpolação 940 será, agora, descrita de acordo com uma modalidade. No canal de cor verde, amostras de cor faltosas podem ser interpoladas com o uso de um filtro passa baixa em amostras verdes conhecidas e um filtro passa alta (ou gradiente) nos canais de cor adjacentes (por exemplo, vermelho e azul). Para os canais de cor vermelho e azul, as amostras de cor faltosas podem ser interpoladas de maneira similar, mas pelo uso de filtragem de passa baixa em valores de vermelho ou azul conhecidos e filtragem de passa alta em valores de verde interpolados. Ademais, em uma modalidade, a interpolação no canal de cor verde pode utilizar um filtro de borda adaptativa de bloco de pixel 5x5 com base nos dados de cor de Bayer originais. Conforme será adicionalmente discutido abaixo, o uso de um filtro de borda adaptativa pode fornecer a pesagem contínua com base em gradientes de valores filtrados horizontais e verticais, que reduzem a aparência de certos artefatos, como artefatos de aliasing, "xadrez," ou "arco-íris", comumente encontrados em técnicas de interpolação convencionais.

[000569] Durante interpolação no canal de verde, os valores originais para os pixels verdes (pixels Gr e Gb) do padrão de imagem de Bayer são usados. Entretanto, para obter um conjunto de dados completo para o canal verde, valores de pixel verdes podem ser interpolados nos pixels vermelho e azul do padrão de imagem de Bayer. De acordo com a presente técnica, componentes de energia horizontal e vertical, respectivamente chamados de Eh e Ev, são primeiramente calculados em pixels vermelhos e azuis com base no bloco de pixel 5x5 supracitado. Os valores de Eh e Ev podem ser usados para obter um valor filtrado pesado em borda a partir das etapas de filtragem horizontal e vertical, conforme discutido adicionalmente abaixo.

[000570] A título de exemplo, a Figura 108 ilustra a computação dos valores Eh e Ev para um pixel vermelho centralizado no bloco de pixel 5x5 na localização (j, i), em que j corresponde a uma fileira e i corresponde a uma coluna. Conforme mostrado, o cálculo de Eh considera as três fileiras do meio (j-1, j, j+1) do bloco de pixel 5x5 e o cálculo de Ev considera as três colunas do meio (i-1, i, i+1) do bloco de pixels 5x5. Para computar Eh, o valor absoluto da soma de cada um dos pixels nas colunas vermelhas (i-2, i, i+2) multiplicado por um coeficiente correspondente (por exemplo, -1 para as colunas i-2 e i+2; 2 para a coluna i) é somado ao valor absoluto da soma de cada um dos pixels nas colunas de azul (i-1, i+1) multiplicado por um coeficiente correspondente (por exemplo, 1 para a coluna i-1; -1 para a coluna i+1). Para computar Ev, o valor absoluto da soma de cada um dos pixels nas fileiras vermelhas (j-2, j, j+2) multiplicado por um coeficiente correspondente (por exemplo, -1 para as fileiras j-2 e j+2; 2 para a fileira j) é somado ao valor absoluto da soma de cada um dos pixels nas fileiras de azul (j-1, j+1) multiplicado por um coeficiente correspondente (por exemplo, 1 para a fileira j-1; -1 para a fileira j+1). Essas computações são ilustradas pelas Equações 76 e 77 abaixo:

[000571] Portanto, a soma de energia total pode ser expressa como: Eh + Ev. Ademais, embora o exemplo mostrado na Figura 108 ilustre a computação de Eh e Ev para um pixel de centro vermelho em (j, i), deve- se compreender que os valores de Eh e Ev podem ser determinados de maneira similar para os pixels de centro azul.

[000572] A seguir, a filtragem horizontal e vertical pode ser aplicada ao padrão Bayer para obter os valores filtrados horizontais e verticais Gh e Gv, que podem representar valores de verde interpolados nas direções horizontal e vertical, respectivamente. os valores filtrados Gh e Gv podem ser determinados com o uso de um filtro passa baixa em amostras verdes vizinhas conhecidas além do uso de gradientes direcionais da color adjacente (R ou B) para obter um sinal de alta frequência nas localizações das amostras verde faltosas. Por exemplo, com referência à Figura 109, um exemplo de interpolação horizontal para a determinação Gh será agora ilustrado.

[000573] Conforme mostrado na Figura 109, cinco pixels horizontais (R0, G1, R2, G3 e R4) de uma linha vermelha 1060 da imagem de Bayer, em presume-se que R2 seja o pixel central em (j, i), podem ser considerados na determinação de Gh. Os coeficientes de filtragem associados a cada um desses cinco pixels são indicados pelo número de referência 1062. Em conformidade, a interpolação de um valor de verde, chamado de G2’, para o pixel central R2, pode ser determinada conforme segue:

[000574] Várias operações matemáticas podem, então, ser utilizadas para a produção da expressão para G2’ mostrada nas Equações 79 e 80 abaixo:

[000575] Portanto, com referência à Figura 109 e às Equações 78 a 80 acima, a expressão geral para a interpolação horizontal para o valor de verde em (j, i) pode ser derivada como:

[000576] O componente de filtragem vertical Gv pode ser determinado de maneira similar a Gh. Por exemplo, com referência à Figura 110, cinco pixels verticais (R0, G1, R2, G3 e R4) de uma coluna vermelha 1064 da imagem de Bayer e seus respectivos coeficientes de filtragem 1068, em que se presume que R2 seja o pixel central em (j, i), podem ser considerados na determinação de Gv. Com ouso de filtragem de passa baixa nas amostras verdes conhecidas e filtragem de passa alta no canal de vermelho na direção vertical, a expressão a seguir pode ser derivada para Gv:

[000577] Embora as amostras discutidas aqui tenham mostrado a interpolação de valores de verde em um pixel vermelho, deve-se compreender que as expressões apresentadas nas Equações 81 e 82 também podem ser usadas na interpolação horizontal e vertical de valores de verde para pixels azuis.

[000578] O valor de verde interpolado final G’ para o pixel central (j, i) pode ser determinado ao pesar as saídas de filtro horizontal e vertical (Gh e Gv) pelos componentes de energia (Eh e Ev) discutidos acima para render a equação a seguir:

[000579] Conforme discutido acima, os componentes de energia Eh e Ev podem fornecer a pesagem adaptativa de boda das saídas de filtro horizontal e vertical Gh e Gv, que podem ajudar a reduzir artefatos de imagem, como arco-íris, aliasing ou xadrez, na imagem de RGB reconstruída. Adicionalmente, a lógica de interpolação 940 pode fornecer uma opção de desviar a característica de pesagem adaptativa de borda ao configurar os valores Eh e Ev, cada, para 1, de modo que Gh e Gv sejam pesados igualmente.

[000580] Em uma modalidade, os coeficientes de pesagem horizontal e vertical, mostrados na Equação 51 acima, podem ser quantizados para reduzir a precisão dos coeficientes de pesagem a um conjunto de valores "grossos". Por exemplo, em uma modalidade, os coeficientes de pesagem podem ser quantizados para oito possíveis razões de peso: 1/8, 2/8, 3/8, 4/8, 5/8, 6/8, 7/8 e 8/8. Outras modalidades podem quantizar os coeficientes de pesagem em valores de 16 (por exemplo, 1/16 a 16/16), valores de 32 (1/32 a 32/32), e assim por diante. Conforme pode ser constatado, quanto comparada ao uso de valores de precisão completa (por exemplo, valores de ponto de flutuação de 32 bits), a quantização dos coeficientes de peso podem reduzir a complexidade de implantação ao determinar e aplicar os coeficientes de peso a saídas de filtro horizontais e verticais.

[000581] Em modalidades adicionais, as técnicas aqui descritas, além e determinar e usar componentes de energia horizontal e vertical para aplicar os coeficientes de pesagem aos valores filtrados horizontal (Gh) e vertical (Gv), também pode determinar e utilizar componentes de energia nas direções diagonal-positiva e diagonal-negativa. Por exemplo, em tais modalidades, a filtragem também pode ser aplicada nas direções diagonal-positiva e diagonal-negativa. A pesagem das saídas de filtro pode incluir a seleção dos dois componentes de energia mais altos e o uso dos componentes de energia selecionados para pesar suas respectivas saídas de filtro. Por exemplo, presumindo que os dois componentes de energia mais altos correspondem às direções vertical e diagonal-positive, os componentes de energia vertical e diagonal-positivos são usados para pesar as saídas de filtro vertical e diagonal-positivas para determinar o valor verde interpolado (por exemplo, em uma localização de pixel vermelha ou azul no padrão Bayer).

[000582] A seguir, a interpolação nos canais de cor vermelho e azul pode ser realizada por interpolação dos valores de vermelho e azul nos pixels verdes do padrão de imagem de Bayer, interpolando os valores de vermelho nos pixels azuis do padrão de imagem de Bayer e interpolando os valores de azul nos pixels vermelhos do padrão de imagem de Bayer. De acordo com as técnicas aqui discutidas, valores de vermelho e azul faltosos podem ser interpolados com o uso de filtragem de passa baixa com base em pixels vermelhos e azuis conhecidos e filtragem de passa alta com base em valores de pixel verde colocalizados, que podem ser valores originais ou interpolados (a partir do processo de interpolação de canal verde discutido acima), dependendo da localização do pixel atual. Portanto, em relação a tais modalidades, deve-se compreender que a interpolação de valores de verde faltosos pode ser realizada primeiramente, de modo que um conjunto de valores de verde completo (ambos valores originais e interpolados) esteja disponível ao interpolar as amostras de vermelho e azul faltosas.

[000583] A interpolação dos valores de pixel vermelho e azul pode ser descrita com referência à Figura 111, que ilustra vários blocos 3x3 do padrão de imagem de Bayer ao qual a interpolação de vermelho e azul pode ser aplicada, assim como os valores de verde interpolados (chamados G’) que podem ser obtidos durante a interpolação no canal verde. Com referência primeiro ao bloco 1070, o valor de vermelho interpolado, R’11, para o pixel de Gr (G11) pode ser determinado conforme segue:

[000584] em que G’10 e G’12 representa os valores de verde interpolados, conforme mostrado pelo número de referência 1078. De modo similar, o valor de azul interpolado, B’11, para o pixel de Gr (G11) pode ser determinado conforme segue:

[000585] em que G’01 e G’21 representam valores de verde interpolados (1078).

[000586] A seguir, com referência ao bloco de pixel 1072, no qual o pixel central é um pixel Gb (G11), o valor de vermelho interpolado, R’11, e o valor de azul B’11, podem ser determinados conforme mostrado nas Equações 86 e 87 abaixo:

[000587] Ademais, com referência ao bloco de pixel 1074, a interpolação de um valor de vermelho em um pixel azul, B11 pode ser determinada conforme segue:

[000588] em que G’00, G’02, G’11, G’20, e G’22 representam valores de verde interpolados, conforme mostrado pelo número de referência 1080. Finalmente, a interpolação de um valor azul em um pixel vermelho, conforme mostrado pelo bloco de pixel 1076, pode ser calculada conforme segue:

[000589] Embora a modalidade discutida acima contasse com diferenças de cor (por exemplo, gradientes) para a determinação de valores interpolados de vermelho e azul, outra modalidade pode fornecer valores de vermelho e azul com o uso de razões de cor. Por exemplo, os valores de verde interpolados (blocos 1078 e 1080) podem ser usados para obter uma razão de cor em localizações de vermelho e azul do padrão de imagem de Bayer, e a interpolação linear das razões podem ser usadas para determinar uma razão de cor interpolada para a amostra de cor faltosa. O valor verde, que pode ser interpolado ou um valor original, pode ser multiplicado pela razão de cor interpolada para obter um valor de cor interpolado final. Por exemplo, a interpolação de valores de pixel vermelho e azul com o uso de razões de cor pode ser realizada de acordo com as fórmulas abaixo, em que as Equações 90 e 91 mostram a interpolação de valores de vermelho e azul para um pixel Gr, as Equações 92 e 93 mostram a interpolação dos valores de vermelho e azul para um pixel Gb, a Equação 94 mostra a interpolação de um valor de vermelho em um pixel azul, e a Equação 95 mostra a interpolação de um valor de azul em um pixel vermelho:

(R’ 11 interpolado quando G 11 é um pixel Gr)
(B’ 11 interpolado quando G 11 é um pixel Gr)
(R’ 11 interpolado quando G 11 é um pixel Gb)
(B’ 11 interpolado quando G 11 é um pixel Gb)
(R’ 11 interpolado em um pixel azul B 11 )

(B’ 11 interpolado em m pixel vermelho R 11 )

[000590] Uma vez que as amostras de cor faltosas foram interpoladas para cada pixel de imagem a partir do padrão de imagem de Bayer, uma amostra completa de valores de cor para cada um dentre os canais de cor vermelho, azul e verde (por exemplo, 1046, 1048 e 1050 da Figura 107) pode ser combinada para produzir uma imagem de RGB de cor completa. Por exemplo, com referência novamente às Figuras 98 e 99, a saída 910 da lógica de processamento de pixel bruto 900 pode ser um sinal de imagem de RGB nos formatos de 8, 10, 12 ou 14 bits.

[000591] Com referência, agora, às Figuras 112 a 115, vários fluxogramas que ilustram os processos para a interpolação de um padrão de imagem de Bayer bruto de acordo com as modalidades apresentadas são ilustrados. Especificamente, o processo 1082 da Figura 112 mostra a determinação da qual os componentes de cor devem ser interpolados para um dado pixel de entrada P. com base na determinação pelo processo 1082, um ou mais do processo 1100 (Figura 113) para a interpolação de um valor de verde, o processo 1112 (Figura 114) para a interpolação de um valor de vermelho, ou o processo 1124 (Figura 115) para a interpolação de um valor de azul pode ser realizado (por exemplo, pela lógica de interpolação 940).

[000592] Iniciando na Figura 112, o processo 1082 começa na etapa 1084 quando um pixel de entrada P é recebido. A lógica de decisão 1086 determina a color do pixel de entrada. Por exemplo, isso pode depender da localização do pixel no padrão de imagem de Bayer. Em conformidade, se P for identificado como sendo um pixel verde (por exemplo, Gr ou Gb), o processo 1082 prossegue para a etapa 1088 para obter os valores de vermelho e azul interpolados para P. Isso pode incluir, por exemplo, a continuação dos processos 1112 e 1124 das Figuras 114 e 115, respectivamente. Se P for identificado como sendo um pixel vermelho, então o processo 1082 prossegue para a etapa 1090 para obter valores de verde e azul interpolados para P. Isso pode incluir a realização adicional dos processos 1100 e 1124 das Figuras 113 e 115, respectivamente. Adicionalmente, se P for identificado como sendo um pixel azul, então o processo 1082 prossegue para a etapa 1092 para obter valores de verde e vermelho interpolados para P. Isso pode incluir a realização adicional dos processos 1100 e 1112 das Figuras 113 e 114, respectivamente. Cada um dos Processos 1100, 1112 e 1124 são descritos adicionalmente abaixo.

[000593] O processo 1100 para a determinação de um valor de verde interpolado para o pixel de entrada P é ilustrado na Figura 113 e inclui as etapas 1102 a 1110. Na etapa 1102, o pixel de entrada P é recebido (por exemplo, do processo 1082). A seguir, na etapa 1104, um conjunto de pixels vizinhos que forma um bloco de pixel 5x5 é identificado, sendo que P é o centro do bloco 5x5. Posteriormente, o bloco de pixel é analisado para determinar componentes de energia horizontal e vertical na etapa 1106. Por exemplo, os componentes de energia horizontal e vertical podem ser determinados de acordo com as Equações 76 e 77 para calcular Eh e Ev, respectivamente. Conforme discutido, os componentes de energia Eh e Ev podem ser usados como coeficientes de pesagem para fornecer filtragem adaptativas de borda e, portanto, reduzir a aparência de certos artefatos de interpolação na imagem final. Na etapa 1108, a filtragem de passa baixa e a filtragem de passa alta, são aplicadas nas direções horizontal e vertical para determinar as saídas de filtragem horizontal e vertical. Por exemplo, as saídas de filtragem horizontal e vertical, Gh e Gv, podem ser calculadas de acordo com as Equações 81 e 82. A seguir, o processo 1082 continua para a etapa 1110, na qual o valor de verde interpolado G’ é interpolado com base nos valores de Gh e Gv pesados com os componentes de energia Eh e Ev, conforme mostrado in Equação 83.

[000594] A seguir, em relação ao processo 1112 da Figura 114, a interpolação dos valores de vermelho pode começar na etapa 1114, na qual o pixel de entrada P é recebido (por exemplo, do processo 1082). Na etapa 1116, um conjunto de pixels vizinhos que forma um bloco de pixel 3x3 é identificado, sendo que P é o centro do bloco 3x3. Posteriormente, a filtragem de passa baixa é aplicada em pixels vermelhos vizinhos no bloco 3x3 na etapa 1118, e a filtragem de passa alta é aplicada (etapa 1120) em valores vizinhos verdes colocalizados, que podem ser valores de verde originais capturados pelo sensor de imagem de Bayer, ou valores interpolados (por exemplo, determinados através do processo 1100 da Figura 113). O valor de vermelho interpolado R’ para P pode ser determinado com base nas saídas de filtragem de passa baixa e de passa alta, conforme mostrado na etapa 1122. Dependendo da cor de P, R’ pode ser determinado de acordo com uma das Equações 84, 86 ou 88.

[000595] Em relação à interpolação dos valores de azul, o processo 1124 da Figura 115 pode ser aplicado. As etapas 1126 e 1128 são, em geral, idênticas às etapas 1114 e 1116 do processo 1112 (Figura 114). Na etapa 1130, a filtragem de passa baixa é aplicada a pixels azuis vizinhos dentro de 3x3 e, na etapa 1132, a filtragem de passa alta é aplicada em valores vizinhos de verde colocalizados, que podem ser valores de verde originais capturados pelo sensor de imagem de Bayer, ou valores interpolados (por exemplo, determinados através do processo 1100 da Figura 113). O valor de azul interpolado B’ para P pode ser determinado com base nas saídas de filtragem de passa baixa e de passa alta, conforme mostrado na etapa 1134. Dependendo da cor de P, B’ pode ser determinado de acordo com uma das Equações 85, 87 ou 89. Ademais, conforme mencionado acima, a interpolação de valores de vermelho e azul pode ser determinada com o uso de diferenças de cor (Equações 84 a 89) ou razões de cor (Equações 90 a 95). Novamente, deve-se compreender que a interpolação de valores de verde faltosos pode ser realizada primeiramente, de modo que um conjunto de valores de verde completo (ambos os valores original e interpolado) esteja disponível ao interpolar as amostras de vermelho e de azul faltosas. Por exemplo, o processo 1100 da Figura 113 pode ser aplicado para interpolar todas as amostras de cor de verde antes de realizar os processos 1112 e 1124 das Figuras 114 e 115, respectivamente.

[000596] Com referência às Figuras 116 a 119, os exemplos de desenhos coloridos das imagens processadas pela lógica de processamento de pixel bruto 900 no pipe de ISP 82 são fornecidos. A Figura 116 mostra uma cena de imagem original 1140, que pode ser capturada pelo sensor de imagem 90 do dispositivo de imageamento 30. A Figura 117 mostra uma imagem de Bayer bruta 1142 que pode representar os dados de pixel brutos capturados pelo sensor de imagem 90. Conforme mencionado acima, as técnicas de interpolação convencionais podem não fornecer a filtragem adaptativa com base na detecção de bordas (por exemplo, bordas entre as áreas de duas ou mais cores) nos dados de imagem, que podem, indesejavelmente, produzir artefatos na imagem de RGB de cor total reconstruída. Por exemplo, a Figura 118 mostra uma imagem de RGB 1144 reconstruída com o uso de técnicas de interpolação convencionais, e pode incluir artefatos, como artefatos de "xadrez" 1146 na borda 1148. Entretanto, comparando a imagem 1144 à imagem de RGB 1150 da Figura 119, que pode ser um exemplo de uma imagem reconstruída com o uso de técnicas de interpolação descritas acima, pode-se ver que os artefatos de xadrez 1146 presentes na Figura 118 não estão presentes, ou pelo menos sua aparência é substancialmente reduzida na borda 1148. Portanto, as imagens mostradas nas Figuras 116 a 119 são destinadas a ilustrar pelo menos uma vantagem que a técnicas de interpolação apresentadas no presente documento têm sobre métodos convencionais.

[000597] De acordo com certo aspecto das técnicas de processamento de imagem apresentadas no presente documento, os vários blocos de lógica de processamento do subsistema de ISP 32 podem ser implantados com o uso de um conjunto de armazenamento temporário em linha, que pode ser configurado para passar dados de imagem através dos vários blocos, conforme mostrado acima. Por exemplo, em uma modalidade, a lógica de processamento de pixel bruto 900 discutida acima na Figura 99 pode ser implantada com o uso de uma configuração de armazenamento temporário em linha disposto conforme mostrado nas Figuras 120 a 123. Particularmente, a Figura 120 mostra toda a disposição de armazenamento temporário em linha que pode ser usada para implantar a lógica de processamento de pixel bruto 900, enquanto a Figura 121 mostra uma vista mais aproximada de um primeiro subconjunto do armazenamento temporário em linha, conforme mostrado na região encerrada 1162 da Figura 120, a Figura 122 mostra uma vista mais próxima de um filtro vertical que pode ser parte da lógica de redução de ruído 934, e a Figura 123 mostra uma vista de um segundo subconjunto do armazenamento temporário em linha, conforme mostrado na região encerrada 1164 da Figura 120.

[000598] Conforme é ilustrado em geral na Figura 120, a lógica de processamento de pixel bruto 900 pode incluir um conjunto de dez armazenamentos temporário em linha numerados 0 a 9 e marcados como números de referências 1160a-1160j, respectivamente, assim como a fileira de lógica 1160k, que inclui a entrada de dados de imagem 908 (que pode ser a partir do sensor de imagem ou a partir da memória) para a lógica de processamento bruto 900. Portanto, a lógica mostrada na Figura 120 pode incluir 11 fileiras, das quais 10 fileiras incluem armazenamento temporário em linha (1160a a 1160j). Conforme discutido abaixo, o armazenamento temporário em linha pode ser utilizado de maneira compartilhada pelas unidades de lógica da lógica de processamento de pixel bruto 900, incluindo os blocos de lógica de ganho, deslocamento, clamping 930 e 938 (chamados de GOC1 e GOC2, respectivamente, na Figura 120), a lógica de detecção e correção de pixel defectivo (DPC) 932, a lógica de redução de ruído 934 (mostrada na Figura 120 como incluindo a lógica de correção de não uniformidade de verde (GNU) 934a, um filtro horizontal de 7 taps 934b e um filtro vertical de 5 taps 934c), a lógica de correção de sombreamento de lente (LSC) 936, e a lógica de interpolação (DEM) 940. Por exemplo, na modalidade mostrada na Figura 120, o subconjunto de armazenamento temporário em linha inferior representado pelo armazenamento temporário em linha 6 a 9 (1160g a 1160j) pode ser compartilhado entre a lógica de DPC 932 e porções da lógica de redução de ruído 934 (incluindo lógica de GNU 934a, filtro horizontal 934b, e parte do filtro vertical 934c). O subconjunto de armazenamento temporário em linha superior representado pelo armazenamento temporário em linha 0 a 5 (1160a a 1160f) pode ser compartilhado entre uma porção da lógica de filtragem vertical 934c, a lógica de correção de sombreamento de lente 936, a lógica de ganho, compensação e fixação 938 e a lógica de interpolação 940.

[000599] Para descrever, em geral, o movimento dos dados de imagem através do armazenamento temporário em linha, os dados de imagem brutos 908, que podem representar a saída da lógica de processamento de front-end de ISP 80, são primeiramente recebidos e processados pela lógica de GOC1 930, em que os parâmetros de ganhos, deslocamento apropriados são aplicados. A saída da lógica de GOC1 930 é, então, fornecida à lógica de DPC 932. Conforme mostrado, o processamento da detecção e correção de pixel defectivo pode ocorrer através do armazenamento temporário em linha 6 a 9. Uma primeira saída da lógica de DPC 932 é fornecida à lógica de correção de não uniformidade de verde 934a (da lógica de redução de ruído 934), que ocorre no armazenamento temporário em linha 9 (1160j). Portanto, o armazenamento em linha 9 (1160j), na presente modalidade, é compartilhado entre ambas a lógica de DPC 932 e a lógica de correção e GNU 934a.

[000600] A seguir, a saída do armazenamento em linha 9 (1160j), chamada, na Figura 121, de W8, é fornecida à entrada de armazenamento em linha 8 (1160i). Conforme mostrado, o armazenamento em linha 8 é compartilhado entre a lógica de DPC 932, que fornece o processamento de detecção e correção de pixel defectivo adicional e a lógica de horizontalização de filtro (934b) do bloco de redução de ruído 934. Conforme mostrado na presente modalidade, o filtro horizontal 934b pode ser um filtro de 7 taps, conforme indicado pelos taps de filtro 1165a a 1165g na Figura 121, e pode ser configurado como um filtro de reposta de impulso finito (FIR). Conforme discutido acima, em certas modalidades, a filtragem de ruído pode ser adaptativa de borda. Por exemplo, o filtro horizontal pode ser um filtro de FIR, mas onde os taps de filtro são usados apenas se a diferença entre o pixel central e o pixel no tap for menor que um limite que depende pelo menos parcialmente da variância de ruído.

[000601] A saída 1163 (Figura 121) da lógica de horizontalização de filtro 934b pode ser fornecida para a lógica de filtragem vertical 934c (ilustrada com mais detalhes na Figura 122) e para a entrada de armazenamento em linha 7 (1160h). Na modalidade ilustrada, o armazenamento em linha 7 é configurado para fornecer um atraso (w) antes de passar sua entrada W7 para o armazenamento em linha 6 (1160g) como a entrada W6. Conforme mostrado na Figura 121, o armazenamento em linha 6 é compartilhado entre a lógica de DPC 932 e o filtro de redução de ruído vertical 934c.

[000602] A seguir, com referência, simultaneamente, às Figuras 120, 122 e 123, o subconjunto de armazenamento temporário em linha superior, a saber, armazenamento temporário em linha 0 a 5 (1160a a 1160f) é compartilhado entre o filtro vertical de redução de ruído 934c (mostrado na Figura 122), a lógica de correção de sombreamento de lente 936, a lógica de GOC2 938 e a lógica de interpolação 940. Por exemplo, a saída do armazenamento em linha 5 (1160f), que fornece um atraso (w), é alimentada ao armazenamento em linha 4 (1160e). a filtragem vertical é realizada no armazenamento em linha 4, e a saída W3 da porção do filtro vertical 934c no armazenamento em linha 4 é alimentada ao armazenamento em linha 3 (1160d), assim como a jusante das porções da lógica de correção de sombreamento de lente 936, lógica de GOC2 938 e lógica de interpolação 940 compartilhadas pelo armazenamento em linha 4. Na presente modalidade, a lógica de filtragem vertical 934c pode incluir cinco taps 1166a a 1166e (Figura 122), mas pode ser configurável para operar em ambos os modos parcialmente recursivo (resposta de impulso infinita (IIR)) e não recursivo (FIR). Por exemplo, quando todas as cinco taps são utilizadas, de modo que a tap 1166c seja a tap central, a lógica de filtragem vertical 934c opera em um modo parcialmente IIR recursivo. A presente modalidade também pode escolher utilizar três das cinco taps, a saber, as taps 1166c a 1166e, com até 1166d sendo uma tap central, para operar a lógica de filtragem vertical 934c em um modo não recursivo (FIR). O modo de filtragem vertical, em uma modalidade, pode ser especificado com o uso de um registro de configuração associado à lógica de redução de ruído 934.

[000603] A seguir, o armazenamento em linha 3 recebe o sina de entrada W3 e fornece um atraso (w) antes de emitir W2 para o armazenamento em linha 2 (1160c), assim como a jusante das porções da lógica de correção de sombreamento de lente 936, da lógica de GOC2 938 e da lógica de interpolação 940 compartilhadas pelo armazenamento em linha 3. Conforme mostrado, o armazenamento em linha 2 também é compartilhado entre o filtro vertical 934c, a lógica de correção de sombreamento de lente 936, a lógica de GOC2 938 e a lógica de interpolação 940, e fornece a saída W1 para o armazenamento em linha 1 (1160b). De modo similar, o armazenamento em linha 1 também é compartilhado entre o filtro vertical 934c, a lógica de correção de sombreamento de lente 936, a lógica de GOC2 938 e a lógica de interpolação 940 e fornece a saída W1 para o armazenamento em linha 0 (1160a). A saída 910 da lógica de interpolação 940 pode ser fornecida a jusante da lógica de processamento de RGB 902 para processamento adicional, conforme será adicionalmente discutido abaixo.

[000604] Deve-se compreender que a modalidade ilustrada que mostra a disposição do armazenamento temporário em linha de maneira compartilhada de modo que diferentes unidades de processamento possam utilizar o armazenamento temporário em linha compartilhado simultaneamente pode reduzir significativamente o número de armazenamento temporário em linha necessário para implantar a lógica de processamento bruto 900. Conforme pode ser constatado, isso pode reduzir o estado real de hardware exigido para a implantação do conjunto de circuitos de processamento de imagem 32 e, portanto, reduzir os custos de fabricação e projeto. A título de exemplo, a técnica aqui ilustrada para compartilhar armazenamento temporário em linha entre componentes de processamento diferentes pode, em certas modalidades, reduzir o número de armazenamento temporário em linha necessário quando comparado a uma modalidade convencional que não compartilha armazenamento temporário em linha por tanto quanto 40 a 50 por cento ou mais. Ademais, embora a modalidade aqui ilustrada da lógica de processamento de pixel bruto 900 mostrada na Figura 120 utilize 10 armazenamentos temporários em linha, deve-se constatar que menos ou mais armazenamentos temporários em linha podem ser utilizados em outras modalidades. Ou seja, a modalidade mostrada na Figura 120 é meramente destinada a ilustrar o conceito pelo qual o armazenamento temporário em linha é compartilhado através de múltiplas unidades de processamento e não deveria ser interpretada como limitadora da presente técnica para apenas a lógica de processamento de pixel bruto 900. De fato, os aspectos da apresentação mostrados na Figura 120 podem ser implantados em qualquer um dos blocos de lógica do subsistema de ISP 32.

[000605] A Figura 124 é um fluxograma que mostra um método 1167 para o processamento de dados de pixel brutos de acordo com a configuração de armazenamento em linha mostrada nas Figuras 120 a 123. Iniciando na etapa 1168, o armazenamento temporário em linha da lógica de processamento de pixel bruto 900 pode receber dados de pixel brutos (por exemplo, a partir da front-end de ISP 80, memória 108, ou ambos). Na etapa 1169, um primeiro conjunto de parâmetros de ganho, deslocamento e clamping (GOC1) é aplicado aos dados de pixel brutos. A seguir, na etapa 1170, a detecção e correção de pixel defectivo é realizada com o uso de um primeiro subconjunto de armazenamento temporário em linha (por exemplo, armazenamento temporário em linha 6 a 9 na Figura 120). Posteriormente, na etapa 1171, a correção de não uniformidade de verde (GNU) é aplicada com o uso de pelo menos um armazenamento em linha (por exemplo, armazenamento em linha 9) a partir do primeiro subconjunto de armazenamento temporário em linha. A seguir, conforme mostrado na etapa 1172, a horizontalização do filtro para a redução de ruído é aplicada, também usando pelo menos um armazenamento em linha do primeiro subconjunto. Na modalidade mostrada na Figura 120, o(s) armazenamento(s) em linha do primeiro subconjunto que é usado para realizar a correção de GNU e a horizontalização de filtro pode ser diferente.

[000606] O método 1167 continua, então, para a etapa 1173, na qual a filtragem vertical para a redução de ruído é aplicada com o uso de pelo menos um armazenamento em linha a partir do primeiro subconjunto, assim como pelo menos uma porção de um segundo subconjunto do armazenamento temporário em linha (por exemplo, armazenamento temporário em linha 0-5) da lógica de processamento de pixel bruto 900. Por exemplo, conforme discutido acima, dependendo do modo de filtragem vertical (por exemplo, recursivo ou não recursivo), ou uma porção ou todo o segundo subconjunto de armazenamento temporário em linha pode ser usado. Ademais, em uma modalidade, o segundo subconjunto pode incluir o armazenamento temporário em linha restante não incluído no primeiro subconjunto de armazenamento temporário em linha a partir da etapa 1170. Na etapa 1174, o segundo subconjunto de armazenamento temporário em linha é usado para aplicar a correção de sombreamento de lente aos dados de pixel brutos. A seguir, na etapa 1175, o segundo subconjunto de armazenamento temporário em linha é usado para aplicar um segundo conjunto de parâmetros de ganho, deslocamento e clamping (GOC2) e, subsequentemente, o segundo conjunto de armazenamento temporário em linha também é usado para a interpolação dos dados de imagem brutos, conforme mostrado na etapa 1176. Os dados de cor de RGB interpolados podem, então, ser enviados a jusante na etapa 1177 ara o processamento adicional pela lógica de processamento de RGB 902, conforme discutido com mais detalhes abaixo.

[000607] Com referência novamente à Figura 98, tendo agora descrito a fundo a operação da lógica de processamento de pixel bruto 900, que pode emitir um sinal de imagem de RGB 910, a presente discussão focará, agora, na descrição do processamento do sinal de imagem de RGB 910 pela lógica de processamento de RGB 902. Conforme mostrado, o sinal de imagem de RGB 910 pode ser enviado para a lógica de seleção 914 e/ou para a memória 108. A lógica de processamento de RGB 902 pode receber o sinal de entrada 916, que podem ser dados de imagem de RGB do sinal 910 ou a partir da memória 108, conforme mostrado pelo sinal 912, dependendo da configuração da lógica de seleção 914. Os dados de imagem de RGB 916 podem ser processados pela lógica de processamento de RGB 902 para realizar as operações de ajustes de cor, incluindo correção de cor (por exemplo, com o uso de uma matriz de correção de cor), a aplicação de ganhos de cor para o auto-equilíbrio de branco, assim como mapeamento de tom global e assim por diante.

[000608] Um diagrama de bloco que mostra uma vista mais detalhada de uma modalidade da lógica de processamento de RGB 902 é ilustrada na Figura 125. Conforme mostrado, a lógica de processamento de RGB 902 inclui a lógica de ganho, deslocamento e clamping (GOC) 1178, a lógica de correção e cor de RGB 1179, a lógica de GOC 1180, a lógica de ajuste de gama RGB e a lógica de conversão de espaço de cor 1182. O sinal de entrada 916 é primeiramente recebido através da lógica de ganho, deslocamento e clamping (GOC) 1178. Na modalidade ilustrada, a lógica de GOC 1178 pode aplicar ganhos para realizar o auto- equilíbrio de branco em um ou mais dentre os canais de cor R, G ou B antes do processamento pela lógica de correção de cor 1179.

[000609] A lógica de GOC 1178 pode ser similar à lógica de GOC 930 da lógica de processamento de pixel bruto 900, exceto pelo fato de que os componentes de cor do domínio de RGB são processados, em vez de os componentes R, B, Gr e Gb dos dados de imagem de Bayer. Em operação, o valor de entrada para o pixel atual é o primeiro desvio por um valor assinado O[c] e multiplicado por um ganho G[c], conforme mostrado na Equação 11 acima, em que c representa R, G e B. Conforme discutido acima, o ganho G[c] pode ser um membro não assinado de 16 bits com 2 bits inteiros e 14 bits fracionados (por exemplo, representação de ponto de flutuação 2.14) e os valores para o ganho G[c] podem ser previamente determinados durante os processamentos de estatística (por exemplo, no bloco de front-end de ISP 80). O valor de pixel Y computado (com base na Equação 11) é, então, recortado para uma faixa mínima e máxima de acordo com a Equação 12. Conforme discutido acima, as variáveis min[c] e max[c] pode representar os "valores de recorte" de 16 bits assinado para os valores de saída mínimo e máximo, respectivamente. Em uma modalidade, a lógica de GOC 1178 também pode ser configurada para manter uma contagem do número de pixels que foram cortados acima e abaixo do máximo e do mínimo, respectivamente, para cada componente de cor R, G e B.

[000610] A saída da lógica de GOC 1178 é, então, encaminhada para a lógica de correção de cor 1179. De acordo com as técnicas aqui descritas, a lógica de correção de cor 1179 pode ser configurada para aplicar correção de cor aos dados de imagem de RGB com o uso de uma matriz de correção de cor (CCM). Em uma modalidade, a CCM pode ser uma matriz de transformada de RGB 3x3, embora as matrizes de outras dimensões também possam ser utilizadas em outras modalidades (por exemplo, 4x3, etc.). Em conformidade, o processo de realizar correção de cor em um pixel de entrada que tem componentes de R, G e B podem ser expressos conforme segue:

[000611] em que R, G e B representam os valores atuais de vermelho, verde e azul para o pixel de entrada, CCM00 a CCM22 representam os coeficientes da matriz de correção de cor e R’, G’ e B’ representam os valores de vermelho, verde e azul corrigidos para o pixel de entrada. Em conformidade, os valores de cor corretos podem ser computados de acordo com as Equações 97 a 99 abaixo:

[000612] Os coeficientes (CCM00 a CCM22) da CCM podem ser determinados durante processamentos de estatística no bloco de front-end de ISP 80, conforme discutido acima. Em uma modalidade, os coeficientes para um dado canal de cor pode ser selecionado de modo que a soma daqueles coeficientes (por exemplo, CCM00, CCM01 e CCM02 para a correção de cor vermelha) é igual a 1, o que pode ajudar a manter o equilíbrio entre claridade e cor. Ademais, os coeficientes são tipicamente selecionados de modo que um ganho positivo seja aplicado à cor sendo corrigida. Por exemplo, com correção da cor vermelha, o coeficiente CCM00 pode ser maior que 1, enquanto um ou ambos os coeficientes CCM01 e CCM02 podem ser menos que 1. Ajustar os coeficientes dessa maneira pode acentuar o componente vermelho (R) no valor de R’ corrigido resultante, enquanto subtrai parte dos componentes de blue (B) e verde (G). Conforme será constatado, isso pode tratar de questões com a sobreposição de cor que pode ocorrer durante aquisição da imagem de Bayer original, como uma porção de luz filtrada para um pixel colorido particular pode "sangrar" para um pixel vizinho de uma cor diferente. Em uma modalidade, os coeficientes da CCM podem ser fornecidos como números complementares da dupla de 16 bits com 4 bits inteiros e 12 bits fracionais (expressos no ponto de flutuação como 4.12). Adicionalmente, a lógica de correção de cor 1179 pode fornecer o recorte dos valores de cor corrigidos computados e os valores excederem um valor máximo ou estiverem abaixo de um valor mínimo.

[000613] A saída da lógica de correção de cor de RGB 1179 é, então, passada para outro bloco de lógica de GOC 1180. A lógica de GOC 1180 pode ser implantada de maneira idêntica à lógica de GOC 1178 e, portanto, uma descrição detalhada das funções de ganho, deslocamento e clamping fornecida não será repetida aqui. Em uma modalidade, a aplicação da lógica de GOC 1180 subsequente à correção de cor pode fornecer o auto-equilíbrio de branco dos dados de imagem com base nos valores de cor corrigidos e também pode ajustar variações de sensor das razões de vermelho para verde e azul para verde.

[000614] A seguir, a saída da lógica de GOC 1180 é enviada para a lógica de ajuste de gama de RGB 1181 para processamento adicional. Por exemplo, a lógica de ajuste de gama de RGB 1181 pode fornecer a correção de gama, mapeamento de tom, combinação de histograma e assim por diante. De acordo com as modalidades apresentadas, a lógica de ajuste de gama 1181 pode fornecer um mapeamento dos valores de entrada de RGB para valores de RGB de saída. Por exemplo, a lógica de ajuste de gama pode fornecer um conjunto de três tabelas de consulta, uma tabela para cada um dentre os componentes R, G e B. A título de exemplo, cada tabela de consulta pode ser configurada para armazenar 256 entradas de valores de 10 bits, sendo que cada valor representa um nível de saída. As entradas de tabela podem ser distribuídas de maneira uniforme na faixa do valor de pixel de entradas, de modo que quando o valor de entrada caia entre duas entradas, o valor de saída possa ser interpolado linearmente. Em uma modalidade, cada uma das três tabela de consultas para R, G e B pode ser duplicada, de modo que a tabela de consultas seja "duplamente temporariamente armazenada" na memória, permitindo, assim, que uma tabela seja usada durante processamento, enquanto sua duplicata está sendo atualizada. Com base nos valores de saída de 10 bits discutidos acima, deve-se notar que o sinal de imagem de RGB de 14 bits é efetivamente amostrado descendentemente para 10 bits como um resultado do processo de correção de gama na presente modalidade.

[000615] A saída da lógica de ajuste de gama 1181 pode ser envida para a memória 108 e/ou para a lógica de conversão de espaço de cor 1182. A lógica de conversão de espaço de cor (CSC) 1182 pode ser configurada para converter a saída de RGB a partir da lógica de ajuste de gama 1181 para o formato YCbCr, no qual Y representa um componente de luma, Cb representa um componente de croma de diferença de azul e Cr representa um componente de croma de diferença de vermelho, sendo que cada um pode estar em um formato de 10 bits como consequência da conversão de profundidade de bit dos dados de RGB a partir de 14 bits para 10 bits durante a operação de ajuste de gama. Conforme discutido acima, em uma modalidade, a saída de RGB da lógica de ajuste de gama 1181 pode ser amostrada descendentemente para 10 bits e, portanto, convertida para valores de YCbCr de 10 bits pela lógica de CSC 1182, que pode, então, ser encaminhada para a lógica de processamento de YCbCr 904, que será discutida adicionalmente abaixo.

[000616] A conversão do domínio de RGB para o espaço de cor YCbCr pode ser realizado com o uso de uma matriz de conversão de espaço de cor (CSCM). Por exemplo, em uma modalidade, a CSCM pode ser uma matriz de transformada 3x3. Os coeficientes da CSCM podem ser ajustados de acordo com uma equação de conversão conhecida, como os padrões BT.601 e BT.709. Adicionalmente, os coeficientes de CSCM podem ser flexíveis com base na faixa desejada de entradas e saídas. Portanto, em algumas modalidades, os coeficientes de CSCM podem ser determinados e programados com base em dados coletados durante o processamento de estatísticas no bloco de front-end de ISP 80.

[000617] O processo de realização da conversão do espaço de cor YCbCr em um pixel de entrada de RGB pode ser expresso conforme segue:

[000618] em que R, G e B representam os valores atuais de vermelho, verde e azul para o pixel de entrada em forma de 10 bits (por exemplo, conforme processado pela lógica de ajuste de gama 1181), CSCM00 a CSCM22 representa os coeficientes da matriz de conversão do espaço de cor e Y, Cb e Cr representam a luma e os componentes de croma resultantes para o pixel de entrada. Em conformidade, os valores para Y, Cb e Cr podem ser computados de acordo com as Equações 101 a 103 abaixo:

[000619] Seguindo a operação da conversão do espaço de cor, os valores de YCbCr resultantes podem ser emitidos a partir da lógica de CSC 1182 como o sinal 918, que pode ser processado pela lógica de processamento de YCbCr 904, conforme será discutido abaixo.

[000620] Em uma modalidade, os coeficientes da CSCM podem ser números de complemento de duplas de 16 bits com 4 bits inteiros e 12 bits fracionais (4.12). Em outra modalidade, a lógica de CSC 1182 pode ser adicionalmente configurada para aplicar um deslocamento a cada um dentre os valores de Y, Cb e Cr, e para recortar os valores resultantes para um valor mínimo e máximo. A título de exemplo, apenas, presumindo que os valores YCbCr estejam na forma de 10 bits, o deslocamento pode estar em uma faixa de -512 a 512 e os valores mínimo e máximo podem ser 0 e 1023, respectivamente.

[000621] Com referência, novamente, ao diagrama de bloco da lógica de pipe de ISP 82 na Figura 98, o sinal de YCbCr 918 pode ser enviado para a lógica de seleção 922 e/ou para a memória 108. A lógica de processamento de YCbCr 904 pode receber o sinal de entrada 924, que podem ser dados de imagem de YCbCr do sinal 918 ou da memória 108, conforme mostrado pelo sinal 920, dependendo da configuração da lógica de seleção 922. Os dados de imagem de YCbCr 924 podem, então, ser processados pela lógica de processamento de YCbCr 904 para um ajuste de nitidez de luma, supressão de croma, redução de ruído de croma, redução de ruído de croma, assim como claridade, contrastes e ajustes de cor e assim por diante. Ademais, a lógica de processamento de YCbCr 904 pode fornecer o mapeamento e o escalonamento de gama dos dados de imagem processados em ambas as direções horizontal e vertical.

[000622] Um diagrama de bloco que mostra uma vista mais detalhada de uma modalidade da lógica de processamento de YCbCr 904 é ilustrado na Figura 126. Conforme mostrado, a lógica de processamento de YCbCr 904 inclui a lógica de ajuste de nitidez de imagem 1183, a lógica 1184 para ajustar claridade, contraste e/ou cor, a lógica de ajuste de gama de YCbCr 1185, a lógica de decimação de croma 1186 e a lógica de escalonamento 1187. A lógica de processamento de YCbCr 904 pode ser configurada para processar os dados de pixel nos formatos 4:4:4, 4:2:2, ou 4:2:0 com o uso de configurações de memória de 1 plano, 2 planos ou 3 planos. Ademais, em uma modalidade, o sinal de entrada de YCbCr 924 pode fornecer informações de luma e croma como valores de 10 bits.

[000623] Conforme será constatado, a referência a 1 plano, 2 planos ou 3 planos se refere ao número de planos de imageamento utilizados na memória de imagem. Por exemplo, em um formato de 3 planos, cada um dentre os componentes Y, Cb e Cr pode utilizar planos de memória separados. Em um formato de 2 planos, um primeiro plano pode ser fornecido para o componente de luma (Y) e um segundo plano que intercala as amostras de Cb e Cr pode ser fornecido para os componentes de croma (Cb e Cr). Em um formato de 1 plano, um único plano na memória é intercalado com as amostras de luma e croma. Ademais, em relação aos formatos 4:4:4, 4:2:2 e 4:2:0, pode-se constatar que o formato 4:4:4 refere-se a um formato de amostragem no qual cada um dos três componentes YCbCr são amostrados na mesma taxa. Em um formato de 4:2:2, os componentes de croma Cb e Cr são subamostrados em metade da taxa de amostragem do componente de luma Y, reduzindo, assim, a resolução dos componentes de croma Cb e Cr pela metade na direção horizontal. De modo similar, o formato 4:2:0 subamostra os componentes de croma Cb e Cr em ambas as direções vertical e horizontal.

[000624] O processamento das informações de YCbCr pode ocorrer em uma região de fonte ativa definida em um armazenamento temporário de fonte, sendo que a região de fonte ativa contém dados de pixels "válidos". Por exemplo, com referência à Figura 127, um armazenamento temporário 1188 que tem definido no mesmo uma região de fonte ativa 1189 é ilustrado. No exemplo ilustrado, o armazenamento temporário de fonte pode representar formato de 1 plano de 4:4:4 que fornece pixels de fonte de valores de 10 bits. A região de fonte ativa 1189 pode ser especificada para as amostras de luma (Y) e amostras de croma (Cb e Cr). Portanto, deve-se compreender que a região de fonte ativa 1189 pode, na verdade, incluir múltiplas regiões de fonte ativas para as amostras de luma e croma. O início da região de fonte ativas 1189 para luma e croma pode ser determinado com base em um deslocamento a partir de um endereço base (0,0) 1190 do armazenamento temporário de fonte. Por exemplo, uma posição de início (Lm_X, Lm_Y) 1191 para a região de fonte ativa de luma pode ser definida por um deslocamento x 1193 e um deslocamento y 1196 em relação ao endereço de base 1190. De modo similar, uma posição de partida (Ch_X, Ch_Y) 1192 para a região de fonte ativa de croma pode ser definida por um deslocamento x 1194 e um deslocamento y 1198 em relação ao endereço base 1190. Deve-se notar que no presente exemplo, o deslocamento ys 1196 e 1198 para luma e croma, respectivamente, pode ser igual. Com base na posição de início 1191, a região de fonte ativa de luma pode ser definida por uma largura 1195 e uma altura 1200, sendo que cada uma pode representar o número de amostras de luma nas direções x e y, respectivamente. Adicionalmente, com base na posição de início 1192, a região de fonte ativa de croma pode ser definida por uma largura 1202 e uma altura 1204, sendo que cada uma pode representar o número de amostras de croma nas direções x e y, respectivamente.

[000625] A Figura 128 fornece, ainda, um exemplo que mostra como as regiões de fonte ativa para amostras de luma e croma podem ser determinadas em um formato de dois planos. Por exemplo, conforme mostrado, a região de fonte ativa de luma 1189 pode ser definida em um primeiro armazenamento temporário de fonte 1188 (que tem o endereço de base 1190) pela área especificada pela largura 1195 e altura 1200 em relação à posição inicial 1191. Uma região de fonte ativa de croma 1208 pode ser definida em um segundo armazenamento temporário de fonte 1206 (que tem o endereço base 1190) como a área especificada pela largura 1202 e altura 1204 em relação à posição inicial 1192.

[000626] Com os pontos acima em mente e com referência novamente à Figura 126, o sinal de YCbCr 924 é primeiramente recebido pela lógica de ajuste de nitidez de imagem 1183. A lógica de ajuste de nitidez de imagem 1183 pode ser configurada para realizar o ajuste de nitidez de foto e processamento de acentuação de borda para aumentar os detalhes de textura e borda na imagem. Conforme será constatado, ajustar a nitidez da imagem pode melhorar a resolução da imagem percebida. Entretanto, é desejável, em geral, que ruído existente na imagem não seja detectado como textura e/ou bordas e, portanto, não seja ampliado durante o processo de ajuste de nitidez.

[000627] De acordo com a presente técnica, a lógica de ajuste de nitidez de imagem 1183 pode realizar o ajuste de nitidez de foto com o uso de um filtro de máscara não nítido de múltiplas escalas no componente de luma (Y) do sinal de YCbCr. Em uma modalidade, dois ou mais filtros Gaussian de passa baixa de tamanhos de escala diferentes podem ser fornecidos. Por exemplo, em uma modalidade que fornece dois filtros Gaussian, a saída (por exemplo, desfoque Gaussian) de um primeiro filtro Gaussian que tem um primeiro raio (x) é subtraída da saída de m segundo filtro Gaussian que tem um segundo raio (y), em que x é maior que y, para gerar uma máscara não nítida. Máscaras não nítidas adicionais também podem ser obtidas ao subtrair as saídas dos filtros Gaussian da entrada Y. Em certas modalidades, a técnica também pode fornecer operações de comparação de limite de núcleo adaptativo que podem ser realizadas com o uso de máscaras não nítidas de modo que, com base nos resultados da(s) comparação(ões), as quantidades de ganho podem ser adicionadas a uma imagem base, que pode ser selecionada como a imagem de entrada Y original ou a saída de um dos filtros Gaussian, para gerar uma saída final.

[000628] Com referência à Figura 129, o diagrama de bloco que mostra a lógica exemplificadora 1210 para realizar o ajuste de nitidez da imagem de acordo com as modalidades das técnicas aqui descritas é ilustrado. A lógica 1210 representa uma máscara de filtragem não nítida de múltiplas escalas que pode ser aplicada a uma imagem luma de entrada Yin. Por exemplo, conforme mostrado, Yin é recebida e processada por dois filtros Gaussian de passa baixa 1212 (G1) e 1214 (G2). No presente exemplo, o filtro 1212 pode ser um filtro 3x3 e o filtro 1214 pode ser um filtro 5x5. Deve-se constatar, entretanto, que em modalidades adicionais, mais que dois filtros Gaussian, incluído filtros de escalas diferentes também podem ser usados (por exemplo, 7x7, 9x9, etc.). Conforme será constatado, devido ao processo de filtragem de passa baixa, os componentes de alta frequência, que, em geral, correspondem a ruído, podem ser removidos das saídas de G1 e G2 para produzir imagens "não nítidas"(G1out e G2out). conforme será discutido abaixo, o uso de uma imagem de entrada não nítida como uma imagem base permite a redução de ruído como parte do filtro de ajuste de nitidez.

[000629] O filtro Gaussian 3x3 1212 e o filtro Gaussian 5x5 1214 pode ser definido conforme mostrado abaixo:

[000630] A título de exemplo apenas, os valores dos filtros Gaussian G1 e G2 podem ser selecionados em uma modalidade conforme segue:

[000631] Com base em Yin, G1out e G2out, três máscaras não nítidas, Sharp1, Sharp2, e Sharp3, podem ser gerados. Sharp1 pode ser determinada como a imagem não nítida G2out do filtro Gaussian 1214 subtraído da imagem não nítida G1out do filtro Gaussian 1212. Porque Sharp1 é essencialmente a diferença entre dois filtros passa baixa, pode ser chamado de uma máscara de "banda média", já que os componentes de ruído de frequência mais alta já estão filtrados nas imagens não nítidas G1out e G2out. Adicionalmente, Sharp2 pode ser calculado ao subtrair G2out da imagem de entrada de luma Yin e Sharp3 pode ser calculado ao subtrair G1out da imagem de luma de entrada Yin. Conforme será discutido abaixo, um esquema de núcleo de limite adaptativo pode ser uado com o uso de máscaras não nítidas Sharp1, Sharp2 e Sharp3.

[000632] Com referência à lógica de seleção 1216, uma imagem base pode ser selecionada com base em um sinal de controle UnsharpSel. Na modalidade ilustrada, a imagem base pode ser ou uma imagem de entrada Yin, ou as saídas filtradas G1out ou G2out. Conforme será constatado, quando imagens originais têm uma variância de ruído alta (por exemplo, quase tão alta quanto a variância de sinal), o uso da imagem original Yin como a imagem base em um ajuste de nitidez pode não fornecer suficientemente a redução dos componentes de ruído durante o ajuste de nitidez. Em conformidade, quando um limite particular de teor de ruído é detectado na imagem de entrada, a lógica de seleção 1216 pode ser adaptada para selecionar uma das saídas filtradas de passa baixa G1out ou G2out a partir das quais o teor de alta frequência, que pode incluir ruído, foi reduzido. Em uma modalidade, o valor do sinal de controle UnsharpSel pode ser determinado pela análise dos dados estatísticos adquiridos durante processamentos de estatística no bloco de front-end de ISP 80 para determinar o teor de ruído da imagem. A título de exemplo, se a imagem de entrada Yin tiver um baixo teor de ruído, de modo que o ruído aparente provavelmente não aumentará como consequência do processo de ajuste de nitidez, a imagem de entrada Yin pode ser selecionada como a imagem base (por exemplo, UnsharpSel = 0). Se a imagem de entrada Yin for determinada para conter um nível notável de ruído, de modo que o processo de ajuste de nitidez possa ampliar o ruído, uma das imagens filtradas G1out ou G2out pode ser selecionada (por exemplo, UnsharpSel = 1 ou 2, respectivamente). Portanto, ao aplicar uma técnica adaptativa para selecionar uma imagem base, a lógica 1210 fornece, essencialmente, uma função de redução de ruído.

[000633] A seguir, os ganhos podem ser aplicados a um ou mais dentre as máscaras Sharp1, Sharp2 e Sharp3 de acordo com um esquema de limite de núcleo adaptativo, conforme descrito abaixo. A seguir, os valores não nítidos Sharp1, Sharp2 e Sharp3 podem ser comparados a vários limites SharpThd1, SharpThd2 e SharpThd3 (não necessariamente respectivamente) a título dos blocos comparadores 1218, 1220, e 1222. Por exemplo, o valor Sharp1 é sempre comparado a SharpThd1 no bloco comparador 1218. Em relação ao bloco comparador 1220, o limite SharpThd2 pode ser comparado ou contra Sharp1 ou Sharp2, dependendo da lógica de seleção 1226. Por exemplo, a lógica de seleção 1226 pode selecionar Sharp1 ou Sharp2, dependendo do estado de um sinal de controle SharpCmp2 (por exemplo, SharpCmp2 = 1 seleciona Sharp1; SharpCmp2 = 0 seleciona Sharp2). Por exemplo, em uma modalidade, o estado de SharpCmp2 pode ser determinado dependendo da variância/teor de ruído da imagem de entrada (Yin).

[000634] Na modalidade ilustrada, é preferível, em geral, configurar os valores de SharpCmp2 e SharpCmp3 para selecionar Sharp1, a não ser que seja detectado que os dados de imagem têm quantidades relativamente baixas de ruído. Isso ocorre porque Sharp1, sendo a diferença entre as saídas dos filtros Gaussian de passa baixa G1 e G2, é, em geral, menos sensível a ruído e, portanto, pode ajudar a reduzir a quantidade à qual os valores SharpAmt1, SharpAmt2 e SharpAmt3 variam devido a flutuações de nível de ruído em dados de imagem com muito ruído. Por exemplo, se a imagem original tiver uma alta variância de ruído, alguns dos componentes de frequência alta podem não ser pegos com o uso de limites fixos e, portanto, tem que ser ampliada durante o processo de ajuste de nitidez. Em conformidade, se o teor de ruído da imagem de entrada for alto, então parte do conteúdo de ruído pode estar presente em Sharp2. Em tais casos, SharpCmp2 pode ser configurado para 1 para selecionar a máscara de banda média Sharp1 que, conforme discutido acima, tem teor de alta frequência reduzido devido ao fato de que é a diferença entre duas saídas de filtro de passa baixa e é, portanto, menos sensível a ruído.

[000635] Conforme será constatado, um processo similar pode ser aplicado à seleção ou de Sharp1 ou Sharp3 pela lógica de seleção 1224 sob o controle de SharpCmp3. Em uma modalidade, SharpCmp2 e SharpCmp3 podem ser configurados para 1 por padrão (por exemplo, uso de Sharp1) e ajustados para 0 apenas para aquelas imagens de entrada que são identificadas como tendo variâncias de ruído em geral baixas. Isso fornece, essencialmente, um esquema de limite de núcleo adaptativo no qual a seleção do valor de comparação (Sharp1, Sharp2 ou Sharp3) é adaptativa com base na variância de ruído de uma imagem de entrada.

[000636] Com base nas saídas dos blocos comparadores 1218, 1220 e 1222, a imagem de saída de nitidez ajustada Ysharp pode ser determinada ao aplicar máscaras não nítidas de ganho à imagem base (por exemplo, selecionada através da lógica 1216). Por exemplo, com referência ao primeiro bloco comparador 1222, SharpThd3 é comparado à entrada B fornecida pela lógica de seleção 1224, que deve ser referida aqui como "SharpAbs," e pode ser igual ou a Sharp1 ou a Sharp3, dependendo do estado de SharpCmp3. Se SharpAbs for maior que o limite SharpThd3, então um ganho SharpAmt3 é aplicado a Sharp3 e o valor resultante é adicionado à imagem base. Se SharpAbs for menor que o limite SharpThd3, então um ganho atenuado Att3 pode ser aplicado. Em uma modalidade, o ganho atenuado Att3 pode ser determinado conforme segue:

[000637] em que, SharpAbs é ou Sharp1 ou Sharp3, conforme determinado pela lógica de seleção 1224. A seleção da imagem base somada ou ao ganho total (SharpAmt3) ou ao ganho atenuado (Att3) é realizada pela lógica de seleção 1228 com base na saída do bloco de computador 1222. Conforme será constatado, o uso de um ganho atenuado pode tratar de situações nas quais SharpAbs não é maior que o limite (por exemplo, SharpThd3), mas a variância de ruído da imagem não está, ainda assim, próxima do dado limite. Isso pode ajudar a reduzir transições notáveis entre um pixel nítido e um pixel não nítido. Por exemplo, se os dados de imagem são passados sem o ganho atenuado em tal circunstância, o pixel resultante pode aparecer com um pixel defectivo (por exemplo, um pixel preso).

[000638] A seguir, um processo similar pode ser aplicado em relação ao bloco comparador 1220. Por exemplo, dependendo do estado de SharpCmp2, a lógica de seleção 1226 pode fornecer ou Sharp1 ou Sharp2 como a entrada no bloco de comparador 1220 que é comparada em relação ao limite SharpThd2. Dependendo da saída do bloco comparador 1220, ou o ganho SharpAmt2 ou um ganho atenuado com base em SharpAmt2, Att2, é aplicado a Sharp2 e adicionado à saída da lógica de seleção 1228 discutida acima. Conforme será constatado, o ganho atenuado Att2 pode ser computado de maneira similar à Equação 104 acima, exceto pelo fato de que o ganho SharpAmt2 e o limite SharpThd2 são aplicados em relação a SharpAbs, que pode ser selecionado como Sharp1 ou Sharp2.

[000639] Posteriormente, um ganho SharpAmt1 ou um ganho atenuado Att1 é aplicado a Sharp1 e o valor resultante é somado à saída da lógica de seleção 1230 para produzir a saída de pixel com ajuste de nitidez Ysharp (a partir da lógica de seleção 1232). A seleção de aplicação ou do ganho SharpAmt1 ou do ganho atenuado Att1 pode ser determinada com base na saída do bloco comparador 1218, que compara Sharp1 com o limite SharpThd1. Novamente, o ganho atenuado Att1 pode ser determinado de maneira similar à Equação 104 acima, exceto pelo fato de que o ganho SharpAmt1 e o limite SharpThd1 são aplicados em relação a Sharp1. Os valores de pixel com ajuste de nitidez resultante escalados com o uso de cada uma das três máscaras são adicionados ao pixel de entrada Yin para gerar a saída de ajuste de nitidez Ysharp que, em uma modalidade, pode ser recortada para 10 bits (presumindo que o processamento de YCbCr ocorra a uma precisão de 10 bits).

[000640] Conforme será constatado, quando comparadas a técnicas de mascaramento não nítidas convencionais, as técnicas de ajuste de nitidez de imagem apresentadas nessa descrição podem fornecer a melhoria do acentuação de texturas e bordas enquanto também reduz o ruído na imagem de saída. Em particular, as presentes técnicas podem ser adequadas em aplicações nas quais as imagens capturadas com o uso, por exemplo, de sensores de imagem de CMOS, exibem uma razão de sinal para ruído pobre, como imagens adquiridas sob condições de baixa iluminação com o uso de câmeras de resolução mais baixas integradas a dispositivos portáteis (por exemplo, telefones móveis). Por exemplo, quando a variância de ruído e a variância de sinal são comparáveis, é difícil usar um limite fixo para ajustar uma nitidez, já que alguns dos componentes de ruído teria a nitidez ajustada junto com textura e bordas. Em conformidade, as técnicas fornecidas aqui, conforme discutido acima, podem filtrar o ruído a partir da imagem inserida com o uso de filtros Gaussian de múltiplas escalas para extrair características das imagens não nítidas (por exemplo, G1out e G2out) para fornecer uma imagem de nitidez ajustada que também exibe teor de ruído reduzido.

[000641] Antes de continuar, deve-se compreender que a lógica ilustrada 1210 é destinada a fornecer apenas uma modalidade exemplificadora da presente técnica. Em outras modalidades, menos ou mais características podem ser fornecidas pela lógica de ajuste de nitidez de imagem 1183. Por exemplo, em algumas modalidades, em vez de aplicar um ganho atenuado, a lógica 1210 pode simplesmente passar o valor base. Adicionalmente, algumas modalidades podem não incluir os blocos de lógica de seleção 1224, 1226 ou 1216. Por exemplo, os comparadores de bloco 1220 e 1222 podem simplesmente receber os valores Sharp2 e Sharp3, respectivamente, em vez de uma seleção emitida a partir dos blocos de lógica de seleção 1224 e 1226, respectivamente. Embora tais modalidades possam não fornecer características de ajuste de nitidez e/ou redução de ruído que são tão robustas quanto a implantação mostrada na Figura 129, deve-se constatar que tais escolhas de projeto podem ser o resultado de limitações relacionadas a custo e/ou negócios.

[000642] Na presente modalidade, a lógica de ajuste de nitidez de imagem 1183 também pode fornecer características de acentuação de borda e supressão de croma uma vez que a saída de imagem de nitidez ajustada YSharp é obtida. Cada uma dessas características adicionais será agora discutida abaixo. Com referência à Figura 130, a lógica exemplificadora 1234 para realizar acentuação de borda que pode ser implantada a jusante a partir da lógica de ajuste de nitidez 1210 da Figura 129 é ilustrada de acordo com uma modalidade. Conforme mostrado, o valor de entrada original Yin é processado por um filtro Sobel 1236 para a detecção de borda. O filtro Sobel 1236 pode determinar um valor de gradiente YEdge com base no bloco de pixel 3x3 (chamado de "A" abaixo) da margem original, sendo que Yin é o pixel central do bloco 3x3. Em uma modalidade, o filtro Sobel 1236 pode calcular YEdge ao torcer os dados de imagem originais para detectar as mudanças nas direções horizontal e vertical. Esse processo é mostrado abaixo nas Equações 105 a 107.

[000643] em que Sx e Sy são operadores de matriz representantes para a detecção de força de borda nas direções horizontal e vertical, respectivamente, e em que Gx e Gy representam imagens gradientes que contêm derivados de mudança horizontal e vertical, respectivamente. Em conformidade, a saída YEdge é determinada como o produto de Gx e Gy.

[000644] YEdge é, então, recebido pela lógica de seleção 1240 ao longo da máscara Sharp1 de banda média, conforme discutido acima na Figura 129. Com base no sinal de controle EdgeCmp, ou Sharp1 ou YEdge é comparado a um limite, EdgeThd, no bloco comparador 1238. O estado de EdgeCmp pode ser determinado, por exemplo, com base no teor de ruído de uma imagem, fornecendo, portanto, um esquema de limite de núcleo adaptativo para a detecção e acentuação de borda. A seguir, a saída do bloco comparador 1238 pode ser fornecida à lógica de seleção 1242 e ou um ganho total ou um ganho atenuado pode ser aplicado. Por exemplo, quando a entrada B selecionada para o bloco comparador 1238 (Sharp1 ou YEdge) está acima de EdgeThd, YEdge é multiplicado por um ganho de borda, EdgeAmt, para determinar a quantidade de acentuação de borda que deve ser aplicada. Se a entrada B no bloco comparador 1238 for menor que EdgeThd, então um ganho de borda atenuado, AttEdge, pode ser aplicado para evitar transições notáveis entre a borda acentuada e o pixel original. Conforme será constatado, AttEdge pode ser calculado de maneira similar, conforme mostrado na Equação 104 acima, mas em que EdgeAmt e EdgeThd são aplicados a "SharpAbs," que pode ser Sharp1 ou YEdge, dependendo da saída da lógica de seleção 1240. Portanto, o pixel de borda, acentuado com o uso ou do ganho (EdgeAmt) ou do ganho atenuado (AttEdge) pode ser adicionado a YSharp (saída da lógica 1210 da Figura 129) para obter o pixel de saída de borda acentuada Yout que, em uma modalidade, pode ser recortado para 10 bits (presumindo que o processamento YCbCr ocorra na precisão de 10 bits).

[000645] Em relação às características de supressão de croma fornecidas pela lógica de ajuste de nitidez de imagem 1183, tais características podem atenuar croma em bordas de luma. Em geral, a supressão de croma pode ser realizada ao aplicar um ganho de croma (fator de atenuação) menor que 1 dependendo do valor (YSharp, Yout) obtido a partir do ajuste de nitidez e/ou etapas de acentuação de borda discutidas acima. A título de exemplo, a Figura 131 mostra um gráfico 1250 que inclui uma curva 1252 que representa ganhos de croma que podem ser selecionados para o ajuste de nitidez correspondente de valores de luma (YSharp). Os dados representados pelo gráfico 1250 podem ser implantados como uma tabela de consulta dos valores YSharp e ganhos de croma correspondentes entre 0 e 1 (um fator de atenuação). As tabelas de consulta são usadas para aproximar a curva 1252. Para valores YSharp que estão co-localizados entre dois fatores de atenuação na tabela de consulta, a interpolação linear pode ser aplicada aos dois fatores de atenuação correspondentes a valores YSharp acima e abaixo do valor YSharp atual. Ademais, em outras modalidades, o valor de luma de entrada também pode ser selecionado como um dentre os valores de Sharp1, Sharp2 ou Sharp3 determinados pela lógica 1210, conforme discutido acima na Figura 129 ou o valor YEdge determinado pela lógica 1234, conforme discutido na Figura 130.

[000646] A seguir, a saída da lógica de ajuste de nitidez de imagem 1183 (Figura 126) é processada pela lógica de ajuste de claridade, contraste e cor (BCC) 1184. Um diagrama de bloco funcional que mostra uma modalidade da lógica de ajuste de BCC 1184 é ilustrado na Figura 132. Conforme mostrado, a lógica 1184 inclui um bloco de processamento de claridade a contraste 1262, bloco de controle de tom global 1264 e um bloco de controle de saturação 1266. A modalidade aqui ilustrada fornece o processamento dos dados YCbCr na precisão de 10 bits, embora outras modalidades possam utilizar profundidades de bits diferentes. As funções de cada um dos blocos 1262, 1264 e 1266 são discutidas abaixo.

[000647] Com referência primeiramente ao bloco de processamento de claridade e contraste 1262 um deslocamento, YDeslocamento, é primeiramente subtraído dos dados de luma (Y) para configurar o nível de preto para zero. Isso é realizado para garantir que o ajuste de contraste não altera os níveis e preto. A seguir, valor de luma é multiplicado por um valor de ganho de contraste ara aplicar o controle de contraste. A título de exemplo, o valor de ganho de contraste pode ser um não assinado de 12 bits com 2 bits inteiros e 10 bits fracionais, fornecendo, assim, uma variação de ganho de contraste de até 4 vezes o valor de pixel. Depois disso, o ajuste de claridade pode ser implantado pela adição (ou subtração) de um valor de deslocamento de claridade dos dados de luma. A título de exemplo, o deslocamento de claridade na presente modalidade pode ser um valor de complemento de dois de 10 bits que tem uma faixa entre -512 e +512. Ademais, deve-se notar que o ajuste de claridade é realizado subsequentemente ao ajuste de contraste para evitar a variação do deslocamento de DC ao mudar o contraste. Depois disso, o YOffset inicial é adicionado novamente aos dados de luma ajustados para reposicionar o nível de preto.

[000648] Os blocos 1264 e 1266 fornecem o ajuste de cor com base nas características de tom dos dados de Cb e Cr. Conforme mostrado, um deslocamento de 512 (presumindo um processamento de 10 bits) é primeiramente subtraído dos dados de Cb e Cr para posicionar a faixa para aproximadamente zero. O tom é, então, ajustado de acordo com as seguintes equações:

[000649] em que Cbadj e Cradj representam valores de Cb e Cr, e em que θ representa um ângulo de tom, que pode ser calculado conforme segue:

[000650] As operações acima são mostradas pela lógica no bloco de controle de tom global 1264 e podem ser representadas pela operação de matriz a seguir:

[000651] em que, Ka = cos(θ), Kb = sin(θ) e θ é definido acima na Equação 110.

[000652] A seguir, o controle de saturação pode ser aplicado aos valores de Cbadj e Cradj, conforme mostrado pelo bloco de controle de saturação 1266. Na modalidade ilustrada, o controle de saturação é realizada pela aplicação de um multiplicador de saturação global e um multiplicador de saturação com base em tom para cada um dos valores Cb e Cr. O controle de saturação com base em tom pode melhorar a reprodução de cores. O tom da cor pode ser representado no espaço de cor YCbCr, conforme mostrado pelo gráfico de roda de cor 1270 na Figura 133. Conforme será constatado, a roda de cor de saturação e tom YCbCr 1270 pode ser derivado pelo deslocamento da roda de cor idêntica no espaço de cor HSV (tom, saturação e intensidade) em aproximadamente 109 graus. Conforme mostrado, o gráfico 1270 inclui valores circunferenciais que representam o multiplicador de saturação (S) em uma faixa de 0 a 1, assim como valores angulares que representam θ, conforme definido acima, em uma faixa entre 0 a 360°. Cada θ pode representar uma cor diferente (por exemplo, 49° = magenta, 109° = vermelho, 229° = verde, etc.). o tom da cor em um ângulo de tom particular θ pode ser ajustado ao selecionar um multiplicador de saturação apropriado S.

[000653] Com referência, novamente, à Figura 132, o ângulo de tom θ (calculado no bloco de controle de tom global 1264) pode ser usado como um índice para uma tabela de consulta de saturação Cb 1268 e uma tabela de consulta de saturação Cr 1269. Em uma modalidade, as tabelas de consulta de saturação 1268 e 1269 podem conter 256 valores de saturação distribuídos de modo uniforme n faixa de tom de 0 a 360° (por exemplo, a primeira entrada da tabela de consulta está em 0° e a última entrada está em 360°) e o valor de saturação S em um dado pixel pode ser determinado através da interpolação linear de valores de saturação na tabela de consulta logo abaixo e acima do ângulo de tom atual θ. Um valor de saturação final para cada um dos componentes Cb e Cr é obtido pela multiplicação de um valor de saturação global (que pode ser uma constante global para cada um dentre Cb e Cr) com o valor de saturação à base de tom determinado. Portanto, os valores Cb’ e Cr’ finais corrigidos podem ser determinados pela multiplicação de Cbadj e Cradj com seus respectivos valores de saturação, conforme mostrado no bloco de controle de saturação à base de tom 1266.

[000654] Posteriormente, a saída da lógica de BCC 1184 é passada para a lógica de ajuste de gama YCbCr 1185, conforme mostrado na Figura 126. Em uma modalidade, a lógica de ajuste de gama 1185 pode fornecer funções de mapeamento não linear para os canais Y, Cb e Cr. Por exemplo, os valores de entrada Y, Cb e Cr são mapeados para valores de saída correspondentes. Novamente, presumindo que os dados de YCbCr são processados em 10 bits, luma tabela de consulta de entradas de 10 bits interpolados 256 pode ser utilizada. Três das tais tabelas de consulta podem ser fornecidas com um para cada um dos canais Y, Cb e Cr. Cada uma das entradas de inserção 256 podem ser distribuídas uniformemente e uma saída pode ser determinada por interpolação linear dos valores de saída mapeados nos índices logo acima e abaixo do índice de entrada atual. Em algumas modalidades, uma tabela de consulta não interpolada que tem 1024 entradas (para dados de 10 bits) também pode ser usada, mas pode ter exigências de memória significativamente maiores. Conforme será constatado, ao ajustar o valor de saídas da tabela de consultas, a função de ajuste de gama YCbCr também pode ser usada para realizar certos efeitos de filtro de imagem, como preto e branco, em tom de sépia, imagens em negativo, solarização e assim por diante.

[000655] A seguir, a decimação de croma pode ser aplicada pela lógica de decimação de coma 1186 à saída da lógica de ajuste de gama 1185. Em uma modalidade, a lógica de decimação de croma 1186 pode ser configurada para realizar a decimação horizontal para converter os dados de YCbCr a partir de um formato de 4:4:4 em um formato de 4:2:2, no qual as informações de croma (Cr e Cr) são subamostradas em meia taxa dos dados de luma. A título de exemplo, apenas, a decimação pode ser realizada através da aplicação de um filtro de passa baixa de 7 taps, como um filtro lanczos de meia banda, a um conjunto de 7 pixels horizontais, conforme mostrado abaixo:

[000656] em que in(i) representa o pixel de entrada (Cb ou Cr), e C0 a C6 representam os coeficientes de filtragem do filtro de 7 taps. Cada pixel de entrada tem um coeficiente de filtro independente (C0-C6) para permitir o deslocamento de fase flexível para as amostras filtradas de croma.

[000657] Ademais, a decimação de coma também pode, em alguns casos, ser realizada sem filtragem. Isso pode ser útil quando a imagem de fonte foi originalmente recebida no formato de 4:2:2, mas foi amostrada ascendentemente para um formato 4:4:4 para o processamento de YCbCr. Nesse caso, a imagem 4:2:2 decimada resultante é idêntica à imagem original.

[000658] Subsequentemente, os dados de saída YCbCr a partir da lógica de decimação de croma 1186 podem ser escalados com o uso da lógica de escala 1187 anteriormente a serem emitidos do bloco de processamento YCbCr 904. A função da lógica de escala 1187 pode ser similar à funcionalidade da lógica de escala 709, 710 no filtro de compensação de compartimentalização 652 da unidade de processamento de pixel de front-end 150, conforme discutido acima com referência à Figura 59. Por exemplo, a lógica de escala 1187 pode realizar o escalonamento horizontal e vertical como duas etapas. Em uma modalidade, um filtro polifásico de 5 taps pode ser usado para o escalonamento vertical e um filtro polifásico de 9 taps pode ser usado para o escalonamento horizontal. Os filtros polifásicos de múltiplos taps podem multiplicar pixels selecionados da imagem de fonte por um fator de pesagem (por exemplo, coeficiente de filtro) e, então, somar as saídas para formar o pixel de destino. Os pixels selecionados podem ser escolhidos, dependendo da posição de pixel atual e o número de taps de filtros. Por exemplo, com um filtro vertical de 5 taps, dois pixels vizinhos em cada lado vertical de um pixel atual podem ser selecionados e, com um filtro horizontal de 9 taps, quatro pixels vizinhos em cada lado horizontal do pixel atual podem ser selecionados. Os coeficientes de filtragem podem ser fornecidos a partir de uma tabela de consulta e podem ser determinados pela posição fracional entre pixel atual. A saída 926 da lógica de escala 1187 é, então, emitida a partir do bloco de processamento YCbCr 904.

[000659] Voltando para a Figura 98, o sinal de saída processado 926 pode ser enviado para a memória 108 ou, de acordo com a modalidade do conjunto de circuitos de processamento de imagem 32 mostrado na Figura 7, pode ser emitido a partir da lógica de processamento de pipe de ISP 82 como o sinal de imagem 114 para o hardware de visor (por exemplo, visor 28) para a visualização por um usuário, ou a um mecanismo de compressão (por exemplo, encodificador 118). Em algumas modalidades, o sinal de imagem 114 pode ser adicionalmente processado por uma unidade de processamento de gráficos e/ou um mecanismo de compressão e armazenado antes de ser descomprimido e fornecido a um visor. Adicionalmente, um ou mais armazenamentos temporários também podem ser fornecidos para controlar o armazenamento temporário dos dados de imagem sendo emitidos para um visor, particularmente em relação aos dados de imagem. Ademais, em uma modalidade em que a lógica de processamento de back-end de ISP 120 é fornecida (por exemplo, Figura 8), o sinal de imagem 114 pode ser enviado a jusante para as etapas de pós-processamento adicionais, conforme será discutido na seção a seguir.

Lógica de processamento de back-end de ISP

[000660] Tendo descrito a lógica de front-end de ISP 80 e pipeline de ISP 82 com detalhes acima, a presente discussão se deslocará, agora, para a lógica de processamento de back-end de ISP 120, que é mostrada acima na Figura 8. Conforme discutido acima, a lógica de back-end de ISP 120 funciona, em geral, para receber dados de imagem processados fornecidos pela pipeline de ISP 82 ou a partir da memória 108 (sinal 124), e para realizar operações de pós-processamento de imagem adicionais, isto é, anteriormente à emissão dos dados de imagem para o dispositivo de exibição 28.

[000661] Um diagrama de bloco que mostra uma modalidade da lógica de back-end de ISP 120 é mostrado na Figura 134. Conforme ilustrado, a lógica de processamento de back-end de ISP 120 pode incluir a lógica de detecção de característica 2200, a lógica de mapeamento de tom local (LTM) 2202, claridade, contraste e lógica de ajuste de cor 2204, lógica de escalonamento 2206 e uma unidade de estatísticas de backend 2208. A lógica de detecção de característica 2200 pode incluir a lógica de detecção de face em uma modalidade e pode ser configurada para identificar a(s) localização(ões) de faces/características faciais em um quadro de imagem, mostrada aqui pelo número de referência 2201. Em outras modalidades, a lógica de detecção de característica 2200 também pode ser configurada para detectar as localizações de outros tipos de características, como cantos de objetos no quadro de imagem. Por exemplo, esses dados podem ser usados para identificar a localização de características nos quadros de imagem consecutivos para determinar uma estimativa de movimento global entre quadros, que pode, então, ser usada para realizar certas operações de processamento de imagem, como registro de imagem. Em uma modalidade, a identificação de características de canto e similares pode ser particularmente útil para algoritmos que combinam quadros de imagem múltiplos, como em certos algoritmos de imageamento de faixa dinâmica alta (HDR), assim como certos algoritmos de união panorâmica.

[000662] Para fins de simplicidade, a lógica de detecção de característica 2200 será chamada, na descrição abaixo, de lógica de detecção de face. Deve-se compreender, entretanto, que a lógica 2200 não é destinada a ser limitada apenas à lógica de detecção de face e pode ser configurada para detectar outros tipos de características, em vez de ou além de características faciais. Por exemplo, em uma modalidade, a lógica 2200 pode detectar características de canto, conforme discutido acima e a saída 2201 da lógica de detecção de característica 2200 pode incluir características de canto.

[000663] A lógica de detecção de face 2200 pode ser configurada para receber dados de imagem de YCC 114 fornecidos pela pipeline de ISP 82 ou pode receber uma imagem de resolução reduzida (representada pelo sinal 2207) a partir da lógica de escala 2206 e para detectar a localização e as posições de faces e/ou características faciais no quadro de imagem correspondente aos dados de imagem selecionados. Conforme mostrado na Figura 134, a entrada na lógica de detecção de face 2200 pode incluir um circuito de seleção 2196 que recebe os dados de imagem de YCC 114 a partir da pipeline de ISP 82 e a imagem de resolução reduzida 2207 a partir da lógica de escala 2206. Um sinal de controle, que pode ser fornecido pela lógica de controle de ISP 84 (por exemplo, um firmware que executa processador), pode determinar qual entrada é fornecida à lógica de detecção de face 2200.

[000664] A localização detectada de faces/características faciais, representada aqui pelo sinal 2201, pode ser fornecida como dados de retroalimentação a uma ou mais unidades de processamento a montante, assim como uma ou mais unidades a jusante. A título de exemplo, os dados 2201 podem representar as localizações nas quais as faces ou características faciais aparecem no presente quadro de imagem. Em algumas modalidades, os dados 2201 podem incluir uma imagem de transformada de resolução reduzida, que pode fornecer informações adicionais para a detecção de face. Ademais, a lógica de detecção de face 2200, em algumas modalidades, pode utilizar um algoritmo de detecção facial, como o algoritmo de detecção facial/de objeto Viola-Jones, ou pode utilizar qualquer outro algoritmo, transformada ou técnicas de detecção/combinação de padrão adequada para a detecção de características faciais em uma imagem.

[000665] Na modalidade ilustrada, os dados de detecção de face 2201 podem ser retroalimentados para a lógica de controle 84, que pode representar um processador que executa firmware para controlar o conjunto de circuitos de processamento de imagem 32. A lógica de controle 84, em uma modalidade, pode fornecer os dados 2201 para o laço de controle de estatísticas de front-end (por exemplo, incluindo as unidades de processamento de estatísticas de front-end (142 e 144) da lógica de front-end de ISP 80 da Figura 10), através do qual as unidades de processamentos de estatística 142 ou 144 podem utilizar os dados de retroalimentação 2201 para posicionar a(s) janela(s) apropriada(s) e/ou selecionar azulejos particulares para o processamento de auto- equilíbrio de branco, auto-exposição e autofoco. Conforme será constatado, a melhoria da precisão de cor e/ou tom para áreas de uma imagem que contêm características faciais pode resultar em uma imagem que parece mais esteticamente agradável a um visualizador. Conforme será adicionalmente discutido abaixo, os dados 2201 também podem ser fornecidos à lógica de LTM 2202, à unidade de estatísticas de back-end 2208, assim como ao bloco encodificador/decodificador 118.

[000666] A lógica de LTM 2202 também pode receber os dados de imagem de YCC 114 a partir da pipeline de ISP 82. Conforme discutido acima, a lógica de LTM 2202 pode ser configurada para aplicar o mapeamento de tom aos dados de imagem 114. Conforme será constatado, as técnicas de mapeamento de tom podem ser utilizadas em aplicações de processamento de imagem para mapear valores de conjunto de pixel uns aos outros. Em casos em que as imagens de entrada e saída têm a mesma precisão de bit, o mapeamento de tom pode não ser necessário, embora algumas modalidades possam aplicar o mapeamento de tom sem a compressão para melhorar as características de contraste na imagem de saída (por exemplo, para fazer com que áreas claras pareçam mais escuras e áreas escuras pareçam mais claras). Entretanto, quando as imagens de entrada e saída têm precisões de bit diferentes, o mapeamento de tom pode ser aplicado para mapear os valores de imagem de entrada a valores correspondentes da faixa de saída da imagem de entrada. Por exemplo, as cenas podem ter uma faixa dinâmica de 25.000:1 ou mais, enquanto os padrões de compressão podem permitir uma faixa muito mais baixa (por exemplo, 256:1) para gins de visor e, algumas vezes, uma faixa inferior de par (por exemplo, 100:1) para a impressão.

[000667] Portanto, a título de exemplo, apenas, o mapeamento de tom pode ser útil em uma situação, como quando os dados de imagem expressos como para uma precisão de 10 bits ou mais devem ser emitidos em um formato de precisão inferior, como uma imagem JPEG de 8 bits. Adicionalmente, o mapeamento de tom pode ser particularmente útil quando aplicado a imagens de faixa dinâmica alta (HDR). No processamento de imagem digital, imagens em HDR podem ser geradas através da aquisição de uma cena em níveis de exposição diferentes e combinando ou compondo as imagens para gerar fuma imagem que tem uma faixa dinâmica que é mais alta do que pode ser alcançado com o uso de uma única exposição. Ademais, em alguns sistemas de imageamento, um sensor de imagem (por exemplo, sensor 90a, 90b) pode ser configurado para adquirir imagens em HDR sem a necessidade de combinar múltiplas imagens para gerar uma imagem em HDR compósita.

[000668] A lógica de LTM 2202 da modalidade ilustrada pode utilizar operadores de mapeamento de tom local (por exemplo, variando espacialmente), que podem ser determinados com base nas características locais no quadro de imagem. Por exemplo, os operadores de mapeamento de tom local podem ser baseados em região e podem mudar localmente com base no teor em uma região particular do quadro de imagem. A título de exemplo, apenas, os operadores de mapeamento de tom local podem ser baseados na compressão em HDR de domínio de gradiente, reprodução de tom fotográfico ou processamento de imagem Retinex®.

[000669] Conforme pode ser constatado, as técnicas de mapeamento de tom local, quando aplicadas a imagens, podem produzir, em geral, imagens de saída que têm características de contraste e podem parece mais agradáveis, esteticamente, a um visualizador em relação às imagens processadas com o uso de mapeamento de tom global. As Figuras 135 e 136 ilustram algumas das desvantagens associadas a um mapeamento de tom global. Por exemplo, com referência à Figura 135, o gráfico 2400 representa o mapeamento de tom de imagem de entrada que tem uma faixa de entrada 2401 para uma faixa de saída 2403. A faixa de tom da imagem de entrada é representada pela curva 2402, em que os valores 2404 representam áreas claras da imagem e os valores 2406 representam áreas escuras da imagem.

[000670] A título de exemplo, em uma modalidade, a faixa 2401 da imagem de entrada pode ter uma precisão de 12 bits (0-4095) e pode ser mapeada para uma faixa de saída 2403 que tem uma precisão de 8 bits (0-255, por exemplo, uma imagem JPEG). A Figura 135 mostra um processo de mapeamento de tom linear, no qual a curva 2402 é mapeada linearmente à curva 2410. Conforme ilustrado, o resultado do processo de mapeamento de tom mostrado na Figura 135 resulta na faixa 2404 correspondente a áreas coladas da imagem de entrada sendo comprimida para uma faixa menor 2412, e também resulta na faixa 2406 correspondente a áreas escuras da imagem de entrada sendo comprimida para uma faixa menor 2414. A redução na faixa de tom para áreas escuras (por exemplo, sombras) e áreas claras pode impactar negativamente propriedades de contraste e pode parecer esteticamente desagradáveis a um visualizador.

[000671] Com referência à Figura 136, um método para tratar dos problemas associados à compressão da faixa "clara" 2404 (comprimida para a faixa 2412) e a faixa "escura" 2406 (comprimida para a faixa 2414), conforme mostrado na Figura 176A, é usar uma técnica de mapeamento de tom não linear. Por exemplo, na Figura 136, a curva de tom 2402 que representa a imagem de entrada é mapeada com o uso de uma curva em formato de "S"não linear (ou curva em S) 2422. Como consequência do mapeamento não linear, a porção clara da faixa de entrada 2404 é mapeada para a porção clara da faixa de saída 2424 e, similarmente, a porção escura da faixa de entrada 2406 é mapeada para a porção escura da faixa de saída 2426. Conforme mostrado, as faixas clara e escura 2424 e 2426 da imagem de saída da Figura 136 são maiores que as faixas clara e escura 2412 e 2414 da imagem de saída da Figura 135 e, portanto, preserva mais do teor claro e escuro da imagem de entrada. Entretanto, devido ao aspecto não linear (por exemplo, curva em S) da técnica de mapeamento da Figura 136, os valores de faixa média 2428 da imagem de saída podem parecer mais planos, o que também pode ser esteticamente desagradável para um visualizador.

[000672] Em conformidade, as modalidades da presente descrição podem implantar as técnicas mapeamento de tom local com o uso de operadores de mapeamento de tom local para processar seções distintas do quadro atual de imagem, que pode ser dividido em regiões com base em características locais na imagem, como características de claridade. Por exemplo, conforme mostrado na Figura 137, uma porção 2430 do quadro de imagem recebido pela lógica de back-end de ISP 120 pode incluir fuma região clara 2432 e uma região escura 2434. A título de exemplo, a região clara 2432 pode representar uma área clara da imagem, como um céu ou horizonte, enquanto uma área escura pode representar uma área relativamente mais escura da imagem, como um plano da frente ou paisagem. O mapeamento de tom local pode ser aplicado separadamente para cada uma das regiões 2432 e 2434 para produzir uma imagem de saída que preserva mais de uma faixa dinâmica da imagem de entrada em relação às técnicas de mapeamento de tom global discutidas acima, melhorando, portanto, o contraste local e fornecendo uma imagem que é mais esteticamente agradável a um visualizador.

[000673] Um exemplo de como o mapeamento de tom local pode ser implantado na presente modalidade é mostrado a título de exemplo nas Figuras 138 e 139. Particularmente, a Figura 138 mostra uma técnica de mapeamento de tom local convencional que pode, em alguns casos, resultar em uma faixa de saída limitada e a Figura 139 mostra um processo de mapeamento de tom local adaptativo que pode ser implantado pela lógica de LTM 2202 que pode usar da faixa de saída total, mesmo que uma porção da faixa de entrada não seja usada pelo quadro de imagem.

[000674] Com referência, primeiramente, à Figura 138, o gráfico 2440 representa a aplicação do mapeamento de tom local a uma imagem de entrada de precisão de bit mais alta para produzir uma imagem de saída de precisão de bit mais baixa. Por exemplo, no exemplo ilustrado, os dados de imagem de entrada de precisão de bit alta podem ser dados de imagem de 12 bits (com valores de entrada 4096 (por exemplo, valores 0 a 4095)), conforme representado pela faixa 2442, que é um tom mapeado para produzir uma saída de 8 bits (com 256 valores de saída (por exemplo, 0 a 255)), representado aqui pela faixa 2444. Deve- se compreender que a profundidade de bits é simplesmente destinada a fornecer exemplos e não deveria ser interpretada como limitadora de nenhuma forma. Por exemplo, em outras modalidades, a imagem de entrada pode ser de 8 bits, 10 bits, 14 bits ou 16 bits, etc e a imagem de saída pode ter uma profundidade de bit que é maior ou menor que a precisão de 8 bits.

[000675] Aqui, pode-se presumir que a região da imagem na qual o mapeamento de tom local é aplicado utiliza apenas uma porção da faixa dinâmica de entrada completa, como a faixa 2448 representada pelos valores 0 a 1023. Por exemplo, esses valores de entrada podem corresponder aos valores da região escura 2434 mostrada na Figura 137. A Figura 138 mostra um mapeamento linear dos valores de entrada 4096 (12 bits) para os valores de saída de 256 (8 bits). Portanto, enquanto os valores que variam de 0 a 4095 são mapeados aos valores 0 a 255 da faixa dinâmica de saída 2444, a porção não usada 2450 (valores 1024 a 4095) da faixa de entrada total 2442 é mapeada à porção 2454 (valores 64 a 255) da faixa de saída 2444, deixando, assim, apenas o valor de saídas 0 a 63 (porção 2452 da faixa de saída 2444) disponível para a representação da porção utilizada 2448 (valores 0 a 1023) da faixa de entrada. Em outras palavras, essa técnica de mapeamento de tom local linear não leva em consideração se os valores não usados ou faixas de valores são mapeadas. Isso resulta em uma porção (por exemplo, 2454) do valor de saídas (por exemplo, 2444) sendo alocada para a representação de valores de entrada que não estão realmente presentes na região (por exemplo, 2434) do quadro de imagem no qual a presente operação de mapeamento de tom local (por exemplo, gráfico 2440) está sendo aplicada, reduzindo, por meio disso, os valores de saída disponíveis (por exemplo, 2452) que podem ser usados para expressar os valores e entrada (por exemplo, range 2448) presentes na região atual sendo processada.

[000676] Com o anterior em mente, a Figura 139 ilustra uma técnica de mapeamento de tom local que pode ser implantada de acordo com modalidades da presente descrição. Aqui, anteriormente à realização do mapeamento da faixa de entrada 2442 (por exemplo, 12 bits) à faixa de saída 2444 (por exemplo, 8 bits), a lógica de LTM 2202 pode ser configurada para primeiramente determinar uma faixa utilizada da faixa de entrada 2442. Por exemplo, presumindo que a região seja uma região em geral mais escura, os valores de entrada correspondentes à cor naquela região pode apenas utilizar uma subfaixa, como 2448 (por exemplo, os valores 0 a 1023), da faixa total 2442. Ou seja, a subfaixa 2448 representa a faixa dinâmica real presente na região particular do quadro de imagem sendo processado. Portanto, já que os valores 1024 a 4095 (subfaixa não usada 2450) não estão sendo utilizados nessa região, a faixa utilizada 2448 pode primeiramente ser mapeada e expandida para utilizar a faixa total 2442, conforme mostrado pelo processo de expansão 2472. Ou seja, porque os valores 1024 a 4095 não estão sendo utilizados na região atual da imagem sendo processada, eles podem ser usados para expressar a porção utilizada (por exemplo, 0 a 1023). Como consequência, a porção utilizada 2448 da faixa de entrada pode ser expressa com o uso de valores adicionais, aqui aproximadamente três vezes mais que valores de entrada adicionais.

[000677] A seguir, conforme mostrado pelo processo 2474, a faixa de entrada utilizada expandida (expandida para os valores 0 a 4095) pode ser subsequentemente mapeada para o valor de saídas 0 a 255 (faixa de saída 2444). Portanto, conforme mostrado na Figura 139, como consequência da primeira expansão, a faixa utilizada 2448 dos valores de entrada para usar a faixa de entrada completa (0 a 4095), a faixa utilizada 2448 de valores de entrada podem ser expressos com o uso da faixa de saída total 2444 (valores 0 a 255), em vez de apenas uma porção da faixa de saída, conforme mostrado na Figura 138.

[000678] Antes de continuar, deve-se notar que, embora chamado de um bloco de mapeamento de tom local, a lógica de LTM 2202 também pode ser configurada para implantar o mapeamento de tom global em alguns casos. Por exemplo, em que o quadro de imagem inclui uma cena de imagem com características em geral uniformes (por exemplo, uma cena do céu), a região na qual o mapeamento de tom é aplicado pode incluir todo o quadro. Ou seja, o mesmo operador de tom pode ser aplicado a todos os pixels do quadro. Voltando à Figura 134, a lógica de LTM 2202 também pode receber os dados 2201 da lógica de detecção de face 2200 e, em alguns casos, pode utilizar esses dados para identificar uma ou mais áreas locais no quadro atual de imagem ao qual o mapeamento de tom é aplicado. Portanto, o resultado final a partir da aplicação de uma ou mais técnicas locais de mapeamento de tom descritas acima pode ser uma imagem que é mais esteticamente agradável a um visualizador.

[000679] A saída da lógica de LTM 2202 pode ser fornecida para a lógica de claridade, contraste e ajuste de cor (BCC) 2204. Na modalidade retratada, a lógica de BCC 2204 pode ser implantada de modo, em geral, idêntico à lógica de BCC 1184 da lógica de processamento de YCbCr 904 da pipeline de ISP, conforme mostrado na Figura 132, e pode oferecer, em geral, funcionalidade similar para fornecer o controle de claridade, contraste, tom e/ou saturação. Portanto, para evitar a redundância, a lógica de BCC 2204 da presente modalidade não foi novamente descrita aqui, mas deveria ser compreendida como sendo idêntica à lógica de BCC previamente descrita 1184 da Figura 132.

[000680] A seguir, a lógica de escala 2206 pode receber a saída da lógica de BCC 2204 e pode ser configurada pra escalar os dados de imagem que representam o quadro atual de imagem. Por exemplo, quando o tamanho real ou resolução do quadro de imagem (por exemplo, em pixels) é diferente de um tamanho de saída esperado ou desejado, a lógica de escala 2206 pode escalar a imagem digital em conformidade para alcançar uma imagem de saída do tamanho ou resolução desejados. Conforme mostrado, a saída 126 da lógica de escala 2206 pode ser enviada para o dispositivo de exibição 28 para a visualização por um usuário ou para a memória 108. Adicionalmente, a saída 126 também pode ser fornecida para um mecanismo de compressão/descompressão 118 para encodificar/decodificar os dados de imagem. Os dados de imagem encodificados podem ser armazenados em um formato comprimido e, então, posteriormente descomprimidos anteriormente a serem exibidos no dispositivo de visor 28.

[000681] Ademais, em algumas modalidades, a lógica de escala 2206 pode escalar os dados de imagem com o uso de resoluções múltiplas. A título de exemplo, quando a resolução da imagem de saída desejada é 720p (1280 x 720 pixels), a lógica de escala pode escalar o quadro de imagem em conformidade para fornecer uma imagem de saída de 720p, e também pode fornecer uma imagem de resolução mais baixa que pode funcionar como uma prévia ou imagem de thumbnail. Por exemplo, uma aplicação sendo executada no dispositivo, como a aplicação "Photos"disponível nos modelos do iPhone® ou as aplicações iPhoto® e iMovie®, disponíveis em certos modelos dos computadores iPhone®, MacBook® e iMac®, todos disponíveis junto à Apple Inc., pode permitir que usuários visualizem uma listagem de versões prévias de vídeo ou imagens armazenadas no dispositivo eletrônico 10. Mediante a seleção de uma imagem ou vídeo armazenado, o dispositivo eletrônico pode exibir e/ou reproduzir a imagem vídeo selecionado em resolução completa.

[000682] Na modalidade ilustrada, a lógica de escala 2206 também pode fornecer informações 2203 ao bloco de estatísticas de back-end 2208, que pode utilizar a lógica de escala 2206 para processamentos de estatística de back-end. Por exemplo, em uma modalidade, a lógica de estatísticas de back-end 2208 pode processar as informações de imagem escalada 2203 para determinar um ou mais parâmetros para modular aos parâmetros de quantização associados ao encodificador 118 (por exemplo, parâmetros de quantização por macrobloco), que pode ser um encodificador/decodificador H.264/JPEG em uma modalidade. Por exemplo, em uma modalidade, a lógica de estatísticas de back-end 2208 pode analisar a imagem por macroblocos para determinar um parâmetro de teor de frequência ou classificação para cada macrobloco. Por exemplo, em algumas modalidades, a lógica de estatísticas de back-end 2206 pode determinar uma classificação de frequência para cada macrobloco com o uso de técnicas como compressão de onduleta, transformadas de Fourier rápidas ou transformadas de cosseno distintas (DCTs). Com o uso das classificações de frequência, o encodificador 118 também pode ser capaz de modular parâmetros de quantização para alcançar, por exemplo, uma qualidade de imagem em geral uniforme através dos macroblocos que constituem o quadro de imagem. Por exemplo, se uma variância alta no teor de frequência estiver presente em um macrobloco particular, a compressão pode ser aplicada àquele macrobloco mais agressivamente. Conforme mostrado na Figura 134, a lógica de escala 2206 também pode fornecer uma imagem de resolução reduzida, representada aqui pelo número de referência 2207, para a lógica de detecção de face 2200 por meio de uma entrada para o conjunto de circuitos de seleção 2196, que pode ser um multiplexador ou algum outro tipo adequado de lógica de seleção. Portanto, a saída 2198 do conjunto de seleção de circuitos 2196 pode ou ser a entrada de YCC 114 da pipeline de ISP 82 ou a imagem de YCC escalonada descendentemente 2207 a partir da lógica de escala 2206.

[000683] Em algumas modalidades, os dados de estatísticas de backend e/ou o encodificador 118 podem ser configurados para prever e detectar mudanças de cenário. Por exemplo, a lógica de estatísticas de back-end 2208 pode ser configurada para adquirir estatísticas de movimento. O encodificador 118 pode tentar prever mudanças de cenário ao comparar estatísticas de movimento fornecidas pela lógica de estatísticas de back-end 2208, que podem incluir certas medidas (por exemplo, claridade), de um quadro atual para um quadro anterior. Quando a diferença na métrica for maior que um limite particular, uma mudança de cenário é prevista, a lógica de estatísticas de back-end 2208 pode sinalizar uma mudança de cena. Em algumas modalidades, as previsões ponderadas podem ser usadas, já que um limite fixo pode nem sempre ser ideal devido à diversidade das imagens que podem ser capturadas e processadas pelo dispositivo 10. Adicionalmente, múltiplos valores de limite também podem ser usados, dependendo de certas características dos dados de imagem sendo processados.

[000684] Conforme discutido acima, os dados de detecção facial 2201 também podem ser fornecidos à lógica de estatísticas de back-end 2208 e ao encodificador 118, conforme mostrado na Figura 134. Aqui, os dados de estatísticas de back-end e/ou o encodificador 118 pode utilizar os dados de detecção facial 2201 junto com as informações de frequência de macrobloco durante o processamento de back-end. Por exemplo, a quantização pode ser reduzida para macroblocos que correspondem à localização de faces no quadro de imagem, conforme determinado com o uso dos dados de detecção facial 2201, melhorando, assim, a aparência visual e a qualidade geral de faces e características faciais encodificadas presentes em uma imagem exibida com o uso do dispositivo de exibição 28.

[000685] Com referência, agora, à Figura 140, um diagrama de bloco que mostra uma vista mais detalhada da lógica de LTM 2202 é ilustrado de acordo com uma modalidade. Conforme mostrado, o mapeamento de tom é aplicado após primeiramente converter os dados de imagem de YC1C2 114 da pipeline de ISP 82 em um espaço de cor linear de RGB corrigido de gama. Por exemplo, conforme mostrado na Figura 140, a lógica 2208 pode primeiramente converter os dados de YC1C2 (por exemplo, YCbCr) em um espaço de cor de RGB não linear. Na presente modalidade, a lógica de LTM 2202 pode ser configurada para receber dados de imagem de YCC que têm características de subamostragem diferentes. Por exemplo, conforme mostrado pelas entradas 114 a uma lógica de seleção 2205 (por exemplo, um multiplexador), a lógica de LTM 2202 pode ser configurada para receber os dados completos de YCC 4:4:4, dados subamostrados de croma YCC 4:2:2), ou dados subamostrados de croma YCC 4:2:0. Para os formatos de dados de imagem de YCC subamostrados, a lógica de conversão ascendente 2209 pode ser aplicada para converter os dados de imagem de YCC subamostrados ao formato YCC 4:4:4 antes da conversão pela lógica 2208 no espaço de cor de sRGB.

[000686] Os dados de imagem de sRGB convertidos, representados aqui pelo número de referência 2210, podem, então, ser convertidos no espaço de cor de RGBlinear, que é um espaço linear corrigido de gama, pela lógica 2212. Posteriormente, os dados de imagem de RGBlinear convertidos 2214 são fornecidos à lógica de LTM 2216, que pode ser configurada para identificar as regiões (por exemplo, 2432 e 2434 da Figura 137) no quadro de imagem que compartilham claridade similar e para aplicar mapeamento de tom local àquelas regiões. Conforme mostrado na presente modalidade, a lógica de LTM 2216 também pode receber parâmetros 2201 a partir da lógica de detecção de face 2200 (Figura 134) que pode indicar a localização e as posições no quadro atual de imagem em que faces e/ou características faciais estão presentes.

[000687] Após o mapeamento de tom local ser aplicado aos dados de RGBlinear 2214, os dados de imagem processados 2220 são, então, convertidos de volta para o espaço de cor YC1C2 ao, primeiramente, usar a lógica 2222 para converter os dados de imagem de RGBlinear processados 2220 de volta para o espaço de cor de sRGB, e, então, com o uso da lógica 2226 para converter os dados de imagem de sRGB 2224 de volta para o espaço de cor YC1C2. Portanto, os dados de YC1C2 convertidos 2228 (com mapeamento de tom aplicado) podem ser emitidos para a lógica de LTM 2202 e fornecidos para a lógica de BCC 2204, conforme discutido acima na Figura 134. Conforme será constatado, a conversão dos dados de imagem 114 nos vários espaços de cor utilizados no bloco de lógica de ISP LTM de back-end 2202 pode ser implantada com o uso de técnicas similares à conversão dos dados de imagem de RGB interpolados no espaço de cor YC1C2 na lógica de processamento de RGB 902 da pipeline de ISP 82, conforme discutido acima na Figura 125. Ademais, nas modalidades em que o YCC é convertido ascendentemente (por exemplo, com o uso da lógica 2209), os dados de YC1C2 podem ser convertidos descendentemente (subamostrados) pela lógica 2226. Adicionalmente, em outras modalidades, essa subamostragem/conversão descendente também pode ser realizada pela lógica de escala 2206 em vez de pela lógica 2226.

[000688] Embora a presente modalidade mostre um processo de conversão que converte a partir do espaço de cor YCC para o espaço de cor sRGB e, então, para o espaço de cor sRGBlinear, outras modalidades podem utilizar conversões de espaço de cor de diferença ou podem aplicar uma transformada aproximada com o uso de uma função de potência. Ou seja, em algumas modalidades, a conversão a um espaço de cor aproximadamente linear pode ser suficiente para fins de mapeamento de tom local. Portanto, com o uso de uma função de transformada aproximada, a lógica de conversão de tais modalidades pode ser pelo menos parcialmente simplificada (por exemplo, ao remover a necessidade por tabelas de consulta de conversão de espaço de cor). Em uma modalidade adicional, o mapeamento de tom local também pode ser realizado em um espaço de cor que é percentualmente melhor ao olho humano, como um espaço de cor Lab.

[000689] As Figuras 141 e 142 mostram fluxogramas que mostram métodos para o processamento dados de imagem com o uso da lógica de processamento de back-end de ISP 120, de acordo com a modalidade apresentada. Com referência primeiramente à Figura 141, um método 2230 que ilustra, em geral, o processamento dos dados de imagem pela lógica de processamento de back-end de ISP 120 é mostrado. Começando na etapa 2232, o método 2230 recebe dados de imagem de YCC da pipeline de ISP 82. Por exemplo, conforme discutido acima, os dados de imagem de YCC recebidos podem estar no espaço de cor de luma e croma YCbCr. A seguir, o método 2232 pode ramificar para cada uma das etapas 2234 e 2238. Na etapa 2234, os dados de imagem de YCC recebidos podem ser processados para detectar as posições/localizações de faces e/ou características faciais em um quadro atual de imagem. Por exemplo, com referência à Figura 134, essa etapa pode ser realizada com o uso da lógica de detecção de face 2200, que pode ser configurada para implantar um algoritmo de detecção facial, como o de Viola-Jones. Posteriormente, na etapa 2236, os dados de detecção de face (por exemplo, dados 2201) podem ser fornecida à lógica de controle de ISP 84 como retroalimentação para as unidades de processamento de estatística de front-end de ISP 142 ou 144), assim como ao bloco de lógica de LTM 2202, a lógica de estatísticas de back-end 2208 e a lógica de encodificador/decodificador 118, conforme mostrado na Figura 134.

[000690] Na etapa 2238, que pode ocorrer pelo menos parcialmente ao mesmo que a etapa 2234, os dados de imagem de YCC recebidos a partir da pipeline de ISP 82 são processados para aplicar o mapeamento de tom. Posteriormente, o método 2230 continua para a etapa 2240, através do qual os dados de imagem de YCC (por exemplo, 2228) é adicionalmente processado para claridade, contraste e ajustes de cor (por exemplo, com o uso da lógica de BCC 2204). Subsequentemente, na etapa 2242, a escala é aplicada aos dados de imagem a partir da etapa 2240 para escalonar os dados de imagem a um ou mais tamanhos ou resoluções desejados. Adicionalmente, conforme mencionado acima, em algumas modalidades, a conversão do espaço de cor ou a subamostragem também pode ser aplicada (por exemplo, em modalidades em que os dados de YCC são amostrados ascendentemente para o mapeamento de tom local) para produzir fuma imagem de saída que tem uma amostragem desejada. Finalmente, na etapa 2244, os dados de imagem de YCC escalonados podem ser exibidos para a visualização (por exemplo, com o uso do dispositivo de exibição 28) ou podem ser armazenados na memória 108 para a visualização posterior.

[000691] A Figura 142 ilustra a etapa de mapeamento de tom 2238 da Figura 141 com mais detalhes. Por exemplo, a etapa 2238 pode começar com a subetapa 2248, na qual os dados de imagem de YCC recebidos na etapa 2232 são primeiramente convertidos para o espaço de cor de sRGB. Conforme discutido acima e mostrado na Figura 140, algumas modalidades podem fornecer a conversão ascendente dos dados de imagem de YCC subamostrados antes da conversão para o espaço de sRGB. Posteriormente, os dados de imagem de sRGB são convertidos em um espaço de cor linear corrigido por gama, RGBlinear, na subetapa 2250. A seguir, na subetapa 2252, o mapeamento de tom é aplicado aos dados de RGBlinear pela lógica de mapeamento de tom 2216 do bloco de lógica de back-end de ISP LTM 2202. Os dados de imagem mapeados de tom a partir da subetapa 2252 podem, então, ser convertidos do espaço de cor RGBlinear para o espaço de cor sRGB, conforme mostrado na subetapa 2254. Posteriormente, na subetapa 2256, os dados de imagem de sRGB podem ser convertidos novamente para o espaço de cor de YCC e a etapa 2238 do método 2230 pode continuar para a etapa 2240, conforme discutido na Figura 141. Conforme mencionado acima, o processo 2238 mostrado na Figura 142 é meramente destinado a ser um processo para aplicar a conversão de espaço de cor de maneira adequada para o mapeamento de tom local. Em outras modalidades, as conversões lineares aproximadas também podem ser aplicadas no lugar das etapas de conversão ilustradas.

[000692] Conforme será compreendido, as várias técnicas de processamento de imagem descritas acima e que se refém à detecção e correção de pixel defectivo, correção de sombreamento de lente, interpolação e ajuste de nitidez da imagem, dentre outras, são fornecida aqui a título de exemplo, apenas. Em conformidade, deve-se compreender que a presente descrição não deve ser interpretada como estando limitada apenas a exemplos fornecidos acima. De fato, a lógica exemplificadora retratada no presente documento, pode ser submetida a um número de variações e/ou características adicionais em outras modalidades. Ademais, deve-se constatar que as técnicas discutidas acima podem ser implantadas de qualquer maneira adequada. Por exemplo, os componentes do conjunto de circuitos de processamento de imagem 32 e particularmente o bloco de front-end de ISP 80 e o bloco de pipe de ISP 82 podem ser implantados com o uso de hardware (por exemplo, conjunto de circuitos configurados adequadamente), software (por exemplo, através de um programa de computador que inclui código executável armazenado em um ou mais meio legível de computador tangível) ou através do uso de uma combinação de ambos os elementos de hardware e software.

[000693] As modalidades específicas descritas acima foram mostradas a título de exemplo, e devem ser compreendidas de modo que essas modalidades possam ser suscetíveis a várias modificações e formas alternativas. Deve-se compreender, ainda, que as concretizações não são destinadas a serem limitadas às formas particulares apresentadas, mas, em vez disso, a cobrirem todas as modificações, equivalentes e alternativas na essência e escopo dessa descrição.

Claims

1. Método, caracterizado pelo fato de que compreende as etapas de: receber, em um processador front-end (80) dentro de um sistema de processamento de sinal de imagem (32), um primeiro sinal de temporização que é atrasado por um primeiro intervalo (584) em relação a um sinal de temporização do sensor (556) associado à aquisição de quadros de imagem (570, 572) usando um sensor de imagem digital (90a, 90b), em que o sinal de temporização do sensor (556) indica intervalos de tempo nos quais os quadros da imagem (570, 572) são adquiridos e em que o primeiro intervalo (584) corresponde ao tempo necessário para transmitir dados entre o sensor de imagem digital (90a, 90b) e o processador front-end (80); em um controlador de flash (550) dentro do sistema de processamento de sinal de imagem (32), determinar se deve aplicar uma iluminação de flash durante a aquisição de um quadro de imagem- alvo dos quadros de imagem (570, 572) adquiridos pelo sensor de imagem digital (90a, 90b); se a iluminação de flash deve ser fornecida ao quadro de imagem-alvo, identificar uma primeira vez (tVSYNC_fd0) que corresponde ao final de um quadro de imagem anterior (570) imediatamente anterior ao quadro de imagem-alvo (572) com base no primeiro sinal de temporização (596); adicionar um intervalo de supressão vertical (600) entre o quadro de imagem-alvo (572) e o quadro de imagem anterior (570) ao primeiro tempo (tVSYNC_fd0) para obter um segundo tempo (tVSYNC_rd1); subtrair o primeiro intervalo (584) do segundo tempo (tVSYNC_rd1) para obter um terceiro tempo (tVSYNC_ra1); subtrair um segundo intervalo (602) do terceiro tempo (tVSYNC_ra1) para obter um quarto tempo (604), em que o segundo intervalo de tempo se baseia em uma quantidade de tempo suficiente para permitir que um módulo flash (552) inicialize após a ativação; e ativar o módulo flash (552) no quarto tempo (604).

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende desativar o módulo de flash (552) após o final do quadro-alvo em um tempo baseado pelo menos parcialmente em um quinto tempo, sendo que o quinto tempo é identificado como correspondente ao final do quadro-alvo, conforme indicado pelo segundo sinal de temporização atrasado (580).

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que desativar o módulo de flash (552) após o final do quadro-alvo compreende desativar o módulo de flash (552) no quinto tempo.

4. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que desativar o módulo de flash (552) após o final do quadro-alvo compreende: adicionar um desvio ao quinto tempo para obter um sexto tempo, em que o sexto tempo ocorre antes do início de um quadro de imagem subsequente imediatamente após o quadro de imagem-alvo, conforme indicado pelo sinal de temporização de sensor (556); e desativar o módulo de flash (552) no sexto tempo.

5. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que desativar o módulo de flash (552) após o final do quadro-alvo compreende: subtrair um desvio do quinto tempo para obter um sétimo tempo, em que o desvio corresponde a uma quantidade de tempo que é menor do que um atraso no sinal de temporização de sensor (556) através da interface do sensor de imagem (94a, 94b); e desativar o módulo de flash (552) no sétimo tempo.

6. Sistema de processamento de sinal de imagem (32), caracterizado pelo fato de que compreende: uma interface de sensor de imagem (94a, 94b) configurada para receber dados de imagem adquiridos de um sensor de imagem (90a, 90b) como uma pluralidade de quadros de imagem (570, 572) com base em um sinal de temporização de sensor (556) fornecido pelo sensor de imagem (90a, 90b); um processador front-end (80) configurado para receber um primeiro sinal de temporização que é atrasado por um primeiro intervalo (584) em relação ao sinal de temporização de sensor (556), e em que o primeiro intervalo (584) corresponde ao tempo necessário para transmitir dados entre o sensor de imagem digital e a lógica de processamento de sinal de imagem (84) do processador frontend configurada para receber os dados de imagem da interface de sensor de imagem (94a, 94b) e processar os dados de imagem adquiridos pelo sensor de imagem (90a, 90b); um dispositivo de flash (552) configurado para, quando ativado, iluminar uma cena de imagem sendo capturada pelo sensor de imagem(90a, 90b); e um controlador de flash (550) configurado para determinar quando ativar o dispositivo de flash (552) para iluminar um quadro de imagem-alvo da pluralidade de quadros de imagem (570, 572) ao: identificar um primeiro tempo (tVSYNC_fd0) que corresponde a um final de um quadro de imagem anterior (570) imediatamente anterior ao quadro de imagem-alvo (572) com base no uso de um primeiro sinal de temporização (596); adicionar um intervalo de supressão vertical (600) entre o quadro de imagem-alvo (572) e o quadro de imagem anterior (570) no primeiro tempo (tVSYNC_fd0) para determinar um segundo tempo (tVSYNC_rd1); subtrair o primeiro intervalo (584) do segundo tempo (tVSYNC_rd1) para determinar um terceiro tempo (tVSYNC_ra1); subtrair um segundo intervalo (602) do terceiro tempo (tVSYNC_ra1) para determinar um quarto tempo (604), em que o segundo intervalo (602) se baseia em uma quantidade de tempo necessária para que o dispositivo flash (552) inicialize após ativação; e ativar o dispositivo de flash (552) no quarto tempo (604).

7. Sistema de processamento de sinal de imagem (32), de acordo com a reivindicação 6, caracterizado pelo fato de que ativar o dispositivo de flash (552) no quarto tempo compreende ativar o dispositivo de flash (552) à luminosidade total antes que um primeiro pixel do quadro de imagem selecionado seja adquirido pelo sensor de imagem (90a, 90b).

8. Sistema de processamento de sinal de imagem (32), de acordo com a reivindicação 6, caracterizado pelo fato de que o dispositivo de flash (552) compreende pelo menos um dentre uma lâmpada de xenônio, um diodo emissor de luz (LED) ou alguma combinação dos mesmos.

9. Sistema de processamento de sinal de imagem (32), de acordo com a reivindicação 6, caracterizado pelo fato de que a lógica de processamento de imagem (84) é configurada para determinar se o dispositivo de flash (552) deve ser ativado para o quadro de imagem- alvo e fornecer um sinal ao controlador de flash (550) para indicar que o dispositivo de flash (552) deve ser ativado para o quadro de imagem- alvo.

10. Sistema de processamento de sinal de imagem (32), de acordo com a reivindicação 9, caracterizado pelo fato de que determinar se o dispositivo de flash (552) deve ser ativado para o quadro de imagem selecionado compreende: determinar se um nível de exposição-alvo para o quadro de imagem selecionado pode ser alcançado ao variar pelo menos um dentre um tempo de integração associado ao sensor de imagem (90a, 90b) e ganhos fornecidos pelo sensor de imagem (90a, 90b); e fornecer o sinal ao controlador de flash (550) para indicar que o dispositivo de flash (552) deve ser ativado para o quadro de imagem- alvo se o nível de exposição-alvo não puder ser alcançado.

11. Dispositivo eletrônico caracterizado pelo fato de que compreende: um sensor de imagem (90a, 90b) configurado para adquirir quadros de dados de imagem (570, 572) que correspondem a uma cena de imagem e fornecer um sinal de temporização de sensor (556); uma interface de sensor de imagem (94a, 94b) configurada para receber os quadros de dados de imagem (570, 572) adquiridos pelo sensor de imagem (90a, 90b) com base em um sinal de temporização de sensor (556) fornecido pelo sensor de imagem (90a, 90b); um processador front-end (80) configurado para receber um primeiro sinal de temporização que é atrasado em um primeiro intervalo (584) em relação ao sinal de temporização de sensor (556), e em que o primeiro intervalo (584) corresponde ao tempo necessário para transmitir dados entre o sensor de imagem digital e a lógica de processamento de sinal de imagem (84) do processador front-end configurado para receber quadros de dados de imagem (570, 572) de interface do sensor de imagem (94a, 94b) e para processar os dados de imagem adquiridos pelo sensor de imagem (90a, 90b); um dispositivo flash (552) configurado para, quando ativado, iluminar uma cena de imagem que está sendo capturada pelo sensor de imagem (90a, 90b); e um controlador flash (550) configurado para determinar quando ativar o flash (552) para iluminar um quadro de imagem-alvo da pluralidade de quadros de imagem (570, 572) ao: identificar um primeiro tempo (tVSYNC_fd0) que corresponde ao final de um quadro de imagem anterior (570) imediatamente anterior ao quadro da imagem-alvo (572) com base em um primeiro sinal de temporização (596); adicionar um intervalo de supressão vertical (600) entre o quadro de imagem-alvo (572) e o quadro de imagem anterior (570) no primeiro tempo (tVSYNC_fd0) para determinar um segundo tempo (tVSYNC_rd1); subtrair o primeiro intervalo (584) do segundo tempo (tVSYNC_rd1) obter um terceiro tempo(tVSYNC_ra1); subtrair um segundo intervalo de tempo (602) do terceiro tempo (tVSYNC_ra1) para obter um quarto tempo (604), em que o segundo intervalo (602) se baseia no tempo necessário para que o dispositivo flash (552) seja inicializado após a ativação; e ativar o dispositivo flash (552) pelo controlador de flash (550) no quarto tempo (604).

12. Dispositivo eletrônico, de acordo com a reivindicação 11, caracterizado pelo fato de que o controlador de flash (550) é configurado para desativar o dispositivo de flash (552) em um quinto tempo que corresponde ao final do quadro de imagem-alvo, porém, antes do início de um quadro de imagem subsequente, conforme indicado pelo sinal de temporização de sensor (580).

13. Dispositivo eletrônico, de acordo com a reivindicação 11, caracterizado pelo fato de que o sensor de imagem (90a, 90b) compreende pelo menos um dentre uma câmera digital integrada ao dispositivo eletrônico, uma câmera digital externa acoplada ao dispositivo eletrônico por meio da interface do sensor de imagem (90a, 90b) ou alguma combinação dos mesmos.

14. Dispositivo eletrônico, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende pelo menos um dentre um computador de mesa, um computador do tipo laptop, um computador do tipo tablet, um telefone celular móvel, um tocador de mídia portátil ou qualquer combinação dos mesmos.