Discrete Cosine Transform - Implementação em JavaScript da DCT/IDCT (Parte 2)

Algoritmo 4.10 Implementação em JavaScript da DCT/IDCT (Parte 2)

4.5 Discrete Cosine Transform

A DCT faz uso de números reais e é muito utilizada em processamento digital de imagem/vídeo e compressão de dados. Expressa uma sequência finita de pontos de dados em termos de uma soma de funções do cosseno oscilando em frequências diferentes, onde pequenos componentes de alta frequência podem ser descartados [62]. O olho humano é mais sensível a mudanças no brilho do que a mudanças de cor, por isso, a representação de cores é convertida de RGB para YCbCr, consistindo em uma componente de brilho Y e duas componentes de cores Cb e Cr (b de blue e r de red), isso significa que os dados da imagem são divididos em uma componente de luminância e em duas de crominância. A DCT reduz as componentes espaciais de altas- frequências da imagem, uma vez que o observador humano é mais sensível a erros de reconstrução de componentes de baixas frequências. Diante da afirmação, a DCT permite que os dados sejam representados em termos de coeficientes de frequência dos seus componentes [63].

Existem vários formatos de imagem, é muito difícil decidir qual é o melhor para cada tipo de aplicação, principalmente quando é necessário armazenar a imagem em um banco de dados. Cada uma das extensões possui características próprias, sendo indicadas para situações diferentes, o JPEG (Joint Photographic Experts Group) é mais utilizado na web por seu pequeno tamanho, mas o PNG (Portable Network Graphics) é mais versátil e recomendado para quando se deseja melhor qualidade [63].

Levando em consideração esses fatos, foi escolhido o formato PNG para o canvas do HTML [64], e o JPEG para o armazenamento e aplicação da transformada discreta do cosseno. Para aplicar a DCT em uma imagem, é necessário, a fim de otimizar os cálculos e melhorar a taxa de compressão, dividir a imagem original em blocos, 4x4, 8x8 ou 16x16, podendo usar até blocos de 32x32 ou 64x64. O padrão para JPEG são blocos de 8x8, como visualizado na Figura 4.7. O tamanho dos blocos tem grande impacto na taxa de compressão, sendo que quanto maiores os blocos, menor será a taxa de compressão.

Capítulo 4. Algoritmo/Equações 117

Figura 4.7 – Exemplo de uma imagem/quadro em blocos 8x8 (adaptado de [63]).

Assim, foi desenvolvido o Algoritmo 4.9 (Parte 1) e Algoritmo 4.10 (Parte 2) que realiza a compressão JPEG utilizando a linguagem de programação JavaScript para a versão web e para a local, foi utilizado o mesmo padrão de implementação, usando o Lisp, ele interpreta o HTML/JavaScript e converte para o Java, como na subseção 3.1.2.4. Algorithm 4.9Implementação em JavaScript da DCT/IDCT (Parte 1).

functionDiscreteCosineTransform(){

this.main =function(){

vardctHelper = DiscreteCosineTransformHelper;

varsamplesNormalizedAndMinMax = dctHelper .samplesNormalize(samplesOriginal);

varsamplesNormalized = samplesNormalizedAndMinMax[0];

varsampleMin = samplesNormalizedAndMinMax[1];

varsampleMax = samplesNormalizedAndMinMax[2];

varsamplesInFrequencyDomain = dctHelper

.samplesSpatialToFrequencyDomain(samplesNormalized);

varsamplesInSpatialDomain = dctHelper

.samplesFrequencyToSpatialDomain(samplesInFrequencyDomain);

varsamplesDenormalized = dctHelper.samplesDenormalize (samplesInSpatialDomain, sampleMin, sampleMax);

DisplayHelper.samplesDraw("Original", displaySize, samplesOriginal); DisplayHelper.samplesDraw("Normalizado", displaySize,

samplesNormalized);

DisplayHelper.samplesDraw("DCT", displaySize, samplesInFrequencyDomain);

DisplayHelper.samplesDraw("IDCT", displaySize, samplesInSpatialDomain);

DisplayHelper.samplesDraw("Desnormalizado", displaySize, samplesDenormalized);

} }

Capítulo 4. Algoritmo/Equações 118

Algorithm 4.10Implementação em JavaScript da DCT/IDCT (Parte 2).

functionDiscreteCosineTransformHelper(){}{

DiscreteCosineTransformHelper.samplesDenormalize =function

(samplesToDenormalize, sampleMin, sampleMax){

varreturnValues = [];

varsampleRange = sampleMax - sampleMin;

for(vars =0; s < samplesToDenormalize.length; s++){

varsampleNormalized = samplesToDenormalize[s];

varsampleDenormalized = (sampleNormalized +1)/2 * sampleRange + sampleMin;

returnValues[s] = sampleDenormalized; }returnreturnValues; }

DiscreteCosineTransformHelper.samplesNormalize =function

(samplesToNormalize){

varsamplesMinAndMax = MathHelper

.minAndMaxOfNumbers(samplesToNormalize);

varsampleMin = samplesMinAndMax[0];

varsampleMax = samplesMinAndMax[1];

varsampleRange = sampleMax - sampleMin;

varsamplesNormalized = [];

for(vars =0; s < samplesToNormalize.length; s++){

varsample = samplesToNormalize[s];

varsampleNormalized = (sample - sampleMin)/sampleRange*2-1; samplesNormalized[s] = sampleNormalized;

}varreturnValues = [samplesNormalized, sampleMin, sampleMax];

returnreturnValues; }

DiscreteCosineTransformHelper.samplesSpatialToFrequencyDomain =

function(samplesToConvert){varsamplesTransformed = [];

varnumberOfSamples = samplesToConvert.length;

for(vari =0; i < numberOfSamples; i++){

varsampleTransformed =0;

for(varj =0; j < numberOfSamples; j++){

sampleTransformed += samplesToConvert[j]*Math

.cos(Math.PI* i* (j +.5)/numberOfSamples); } samplesTransformed[i] = sampleTransformed; }returnsamplesTransformed; }

DiscreteCosineTransformHelper.samplesFrequencyToSpatialDomain =

function(samplesToConvert){varsamplesTransformed = [];

varnumberOfSamples = samplesToConvert.length;

for(vari =0; i < numberOfSamples; i++){

varsampleTransformed = samplesToConvert[0] /2;

for(varj =1; j < numberOfSamples; j++){

sampleTransformed += samplesToConvert[j]*2*Math

.cos(Math.PI* (i +.5)* (j)/ numberOfSamples); } sampleTransformed /= numberOfSamples;

samplesTransformed[i] = sampleTransformed; }returnsamplesTransformed; }

Capítulo 4. Algoritmo/Equações 119

cia em inúmeras matrizes, cada uma com o tamanho de 8x8 pixels. Portanto, tem-se as várias matrizes compostas de 64 pixels, conhecidas como sample values. Sobre estas matrizes é aplicado a DCT, gerando outras matrizes, denominadas de “Coeficientes de DCT”, cuja maioria dos elementos tem valores próximos a zero, esse processo trans- lada a informação do domínio do espaço para o domínio da frequência, utilizando uma normalização dos valores, apresentado na Equação 4.30, que é, aplicar um conjunto de regras que visa, principalmente, a organização dos dados para reduzir a redundância, aumentar a integridade e o desempenho alcançado no armazenamento [62].

Z = X−α

θ (4.30)

Onde, o X é o valor a ser normalizado, α é a média aritmética da distribuição e θé o desvio padrão da distribuição. A DCT para uma matriz (ou seja, uma imagem/- quadro) de tamanho NxM é apresentado na Equação 4.31.

F(µ, ϑ) = 2 N 1₂ 2 M 1₂ N−1

∑

i=0 M−1

∑

j=0 ∆(i)∆(j)coshπµ 2N(2i+1) i cos πϑ 2M(2j+1) f(i, j) (4.31) No qual, F(µ, ϑ)representa o coeficiente no domínio da transformada, µ é o eixo horizontal no domínio da transformada, o ϑ é o eixo vertical no domínio da transfor- mada, ∆(x) = √1

2 para x = 0, ∆(x) = 1 para x 6= 0, x = µ|ϑ, f(i, j) é a amplitude no

domínio do tempo, o i é eixo horizontal no domínio do tempo e o j é o eixo vertical no domínio do tempo. A inversa (Inverse Discrete Cosine Transform - IDCT), é apresentada na Equação 4.32.

F−1(µ, ϑ) (4.32)

Fazendo a aplicação da Equação 4.31, a DCT ocupa mais espaço do que a sua matriz original, já que, os valores da matriz original são do tipo byte, ou inteiro, e os coeficientes da DCT são reais. Para reduzir esses valores, é realizada a quantização, que é o processo de reduzir o número de bits necessários para armazenar um valor reduzindo a precisão de um inteiro. É neste processo de quantização, que acontece a

Capítulo 4. Algoritmo/Equações 120

perda da informação, ou seja, os valores dos coeficientes que eram reais, agora passam a ser inteiros, perdendo a parte decimal, mas reduzindo o número de bits necessários para armazenar os valores [62]. Para o formato JPEG, a quantização é apresentada pela Equação 4.33.

Q[i] [j] =1+ (1+i+j)δ (4.33)

Onde o δ é um valor para a qualidade da imagem, sendo de 1 a 25. Valores mai- ores do que 25 comprometem em muito a qualidade da imagem, perdendo completa- mente as informações nela existente. Na Tabela 4.5, é apresentado os valores de qualidade aplicados a uma imagem de 400x400 pixels, resultando em uma dada compressão.

Tabela 4.5 – Fatores de Qualidade (baseado em [62]).

Qualidade (δ) 2 5 10 15 20 25

Taxa de Compressão (%) 20.59 10.38 5.82 4.22 3.43 3.00 Perda de Informação (%) 8.39 10.07 11.55 12.23 12.49 13.84

Identificador (id) 1 2 3 4 5 6

Após o procedimento de quantização, a imagem/quadro é armazenada no banco de dados com um tamanho reduzido, podendo voltar para as aplicações desenvolvidas quando for necessário executar um PDI/V, utilizando a IDCT. Para o sistema de armazenamento das imagens/quadros foram utilizados comandos da linguagem SQL (Structured Query Language) implementada juntamente ao JavaScript, com uma linguagem de script PHP (Hypertext Preprocessor) para fazer toda a comunicação entre as apli- cações, web/local e o banco de dados [65]. O driver utilizado foi o MySQL, que é um SGBD (Sistema de Gerenciamento de Banco de Dados), que utiliza a linguagem SQL como interface [66].

Aplicando a Equação 4.32, é visto que, quando recuperado os pixels da imagem, os valores foram bem próximos dos originais, provando que as perdas são desprezí- veis, somente as altas frequências foram descartadas, como visualizado na Figura 4.8. Todos os resultados obtidos com esses algoritmos e técnicas serão apresentados no ca- pítulo 5.

Capítulo 4. Algoritmo/Equações 121

122

5 Resultados

5.1 Partial Differential Equation

O primeiro teste da Partial Differential Equation [67] foi para medir o tempo de processamento de três imagens/quadros na etapa de filtragem de um ruído, como visualizado na Figura 5.1. A razão entre o sinal-ruído (SNR - Signal to Noise Ratio) é uma maneira útil e universal de comparar as quantidades relativas de sinal e ruído para qualquer sistema eletrônico, no qual, razões altas terão pouco ruído visível enquanto o oposto vale para baixas razões. Sendo assim, foi utilizado um SNR de grau interme- diário, ou seja, ruído aleatório, que é caracterizado por flutuações de intensidade e tom de cor em relação a imagem/quadro original, deixando menos nítido.

Figura 5.1 – Comparativo do tempo de processamento da filtragem: (A) Algoritmo 1; e (B) Algoritmo 2.

Como resultado, o “Algoritmo 1” (representado como a técnica padrão de filtragem com uso de máscara e análise de pixels por vizinhança [10]) gerou em média a matriz MxN das três imagens/quadros em 73,1 segundos e a análise e padronização do histograma em 42 segundos, enquanto o “Algoritmo 2” (representado como a téc-

Capítulo 5. Resultados 123

nica apresentada na pesquisa) em 58 segundos e 32,4 segundos, respectivamente. Em relação as três imagens/quadros (Figura 5.2, Figura 5.3 e Figura 5.4), o tempo médio de processamento no “Algoritmo 1” foi de 24,6 segundos, enquanto no “Algoritmo 2” foi de 20,13 segundos, com isso, gerou uma economia em tempo de 4,47 segundos.

O segundo teste gerado, é para analisar o perfil em termos de qualidade dos pixels, para isso, as três imagens/quadros (Figura 5.2, Figura 5.3 e Figura 5.4) foram matricialmente comparadas a nível de pixel. Para essa análise comparativa foram utilizadas três placas de vídeo NVIDIA GeForce GTX 1070 Ti e dois processadores Intel Core i9-8950HK, demorando 37 horas, 14 minutos e 02 segundos para conclusão. Como resultado, o “Algoritmo 2” atingiu em média 91% de qualidade e precisão nos pixels gerados, enquanto o “Algoritmo 1” atingiu 83%.

Para calcular o valor médio do PSNR (Peak Signal to Noise Ratio), que é usado para definir a relação entre a máxima energia de um sinal e o ruído que afeta sua represen- tação fidedigna, se faz a formulação do MSE (Mean Squared Error) (representado na Equação 5.1) e depois aplica a relação sinal-ruído (representado na Equação 5.2).

MSE = 1 MN M−1

∑

i=0 N−1

∑

j=0

k Imagem1(i, j) −Imagem2(i, j)) k2 (5.1)

PSNR=20log10(255) −10log10(MSE) (5.2)

Para o “Algoritmo 1” o valor médio do PSNR atingido foi de 31,90dB, mas no “Algoritmo 2” o valor foi de 45,09dB, com isso, gerou um ganho de 13,19dB. E o úl- timo teste realizado foi a nível de histograma, comparando as três imagens/quadros (Figura 5.2, Figura 5.3 e Figura 5.4), como visualizado na Figura 5.5, classificando o “Algoritmo 2” como melhor a nível de qualidade de histograma, apresentando em cada camada RGB um número maior de pixels localizados na zona de tons médios. O “Algoritmo 1”, por sua vez, teve uma concentração maior de pixels nas zonas de sombras e luzes altas.

Capítulo 5. Resultados 124

Figura 5.2 – Aplicação da técnica de filtragem - Exemplo 1: (A) Imagem Original 4K; (B) Imagem com ruído; (C) Filtragem Normal (31,92dB); e (D) Partial

Capítulo 5. Resultados 125

Figura 5.3 – Aplicação da técnica de filtragem - Exemplo 2: (A) Imagem Original 4K; (B) Imagem com ruído; (C) Filtragem Normal (32,57dB); e (D) Partial

Capítulo 5. Resultados 126

Figura 5.4 – Aplicação da técnica de filtragem - Exemplo 3: (A) Imagem Original 4K; (B) Imagem com ruído; (C) Filtragem Normal (31,23dB); e (D) Partial

Capítulo 5. Resultados 127

Figura 5.5 – Comparativo do histograma das imagens/quadros filtrados: (A) Algoritmo 1; e (B) Algoritmo 2.

Capítulo 5. Resultados 128

5.2 High Dynamic Range

O primeiro teste de High Dynamic Range [67] foi para medir o tempo de processamento na geração da imagem resultante, utilizando para isso a Figura 5.6.

Figura 5.6 – Imagem resultante HDR utilizada no primeiro teste.

Como resultado, o “Algoritmo 1” (representado como Debevec and Malik [44]) processou a imagem em 19,8 segundos, enquanto o “Algoritmo 2” (representado como a técnica apresentada na pesquisa) em 12,4 segundos, obtendo um ganho de 7,4 segundos do anterior, como visualizado na Figura 5.7.

Figura 5.7 – Comparativo do tempo de processamento HDR: (A) Algoritmo 1; e (B) Algoritmo 2.

O segundo teste realizado foi a nível de histograma, já que, o “Algoritmo 2” efetua uma padronização dos pixels da imagem resultante HDR, ou seja, faz uma aná- lise matricial e gráfica previamente, obtendo as melhores combinações dos pixels de vizinhança, sendo assim, a Figura 5.6 é comparada, como visualizado na Figura 5.8, classificando o “Algoritmo 2” como melhor a nível de qualidade de histograma, apresentando em cada camada RGB um número maior de pixels localizados na zona de

Capítulo 5. Resultados 129

tons médios. O “Algoritmo 1”, por sua vez, teve uma concentração maior de pixels nas zonas de sombras e luzes altas.

Figura 5.8 – Comparativo do histograma da imagem HDR: (A) Algoritmo 1; e (B) Algoritmo 2.

Capítulo 5. Resultados 130

xels na imagem resultante HDR, para isso, uma nova imagem resultante foi gerada matricialmente e comparadas a nível de pixel. Para essa análise comparativa foram utilizadas três placas de vídeo NVIDIA GeForce GTX 1070 Ti e dois processadores Intel Core i9-8950HK, demorando 7 horas, 12 minutos e 23 segundos para conclusão. Como resultado, o “Algoritmo 2” atingiu 93% de qualidade e precisão nos pixels gerados, enquanto o “Algoritmo 1” atingiu 77%, como visualizado na Figura 5.9.

Figura 5.9 – Comparativo na qualidade da Imagem HDR: (A) Algoritmo 1; e (B) Algoritmo 2.

Capítulo 5. Resultados 131

O último teste gerado leva em consideração a técnica de Tone Mapping [47], o primeiro passo foi medir o tempo de processamento na geração da técnica HDR/Tone Mapping. Como resultado, o “Algoritmo 2” desempenhou tempos mais baixos de processamento do que o “Algoritmo 1”, como visualizado na Figura 5.10, tendo como base seis imagens diferentes para esse teste.

Figura 5.10 – Comparativo do tempo de processamento da técnica HDR/Tone Mapping: (A) Algoritmo 1; e (B) Algoritmo 2.

O segundo passo, foi analisar o perfil em termos de qualidade dos pixels entre o Tone Mapping normal (“Algoritmo 1”) e o Tone Mapping resultante (“Algoritmo 2”), podendo perceber que no modelo resultante os pixels alcançaram um poder de visuali- zação quase igual ao da Imagem HDR (também gerado em “Algoritmo 2”), como visualizado na Figura 5.11, Figura 5.12, Figura 5.13, Figura 5.14, Figura 5.15 e Figura 5.16. Para esse feito, uma máscara de filtro “controle dinâmico de brilho e aproximação” desenvolvida juntamente com a técnica do “Algoritmo 2” na pesquisa, foi alocada na frente da imagem gerada para que o valor pixel seja aproximado ao valor real HDR, dando assim aos pixels de vizinhança um valor mais visível do que realmente é nos monitores comuns. Para a análise nas seis imagens comparativas foram utilizadas três placas de vídeo NVIDIA GeForce GTX 1070 Ti e dois processadores Intel Core i9-8950HK, demorando 86 horas, 34 minutos e 12 segundos para conclusão.

Capítulo 5. Resultados 132

Figura 5.11 – Aplicação da técnica HDR/Tone Mapping - Exemplo 1: (A) Tone Mapping normal; (B) Imagem HDR; e (C) Tone Mapping resultante.

Capítulo 5. Resultados 133

Figura 5.12 – Aplicação da técnica HDR/Tone Mapping - Exemplo 2: (A) Tone Mapping normal; (B) Imagem HDR; e (C) Tone Mapping resultante.

Capítulo 5. Resultados 134

Figura 5.13 – Aplicação da técnica HDR/Tone Mapping - Exemplo 3: (A) Tone Mapping normal; (B) Imagem HDR; e (C) Tone Mapping resultante.

Capítulo 5. Resultados 135

Figura 5.14 – Aplicação da técnica HDR/Tone Mapping - Exemplo 4: (A) Tone Mapping normal; (B) Imagem HDR; e (C) Tone Mapping resultante.

Capítulo 5. Resultados 136

Figura 5.15 – Aplicação da técnica HDR/Tone Mapping - Exemplo 5: (A) Tone Mapping normal; (B) Imagem HDR; e (C) Tone Mapping resultante.

Capítulo 5. Resultados 137

Figura 5.16 – Aplicação da técnica HDR/Tone Mapping - Exemplo 6: (A) Tone Mapping normal; (B) Imagem HDR; e (C) Tone Mapping resultante.

Capítulo 5. Resultados 138

5.3 Discrete Cosine Transform

O primeiro teste da Discrete Cosine Transform [67] foi para medir o tempo de processamento de duas imagens/quadros, como visualizado na Figura 5.17. Como resultado, o “Algoritmo 1” (representado como a técnica padrão da aplicação DCT/IDCT [62]) processou em média as duas imagens/quadros em 33,3 segundos, enquanto o “Algoritmo 2” (representado como a técnica apresentada na pesquisa) em 25,7 segundos, com isso, gerou uma economia em tempo de 7,6 segundos.

Figura 5.17 – Comparativo do tempo de processamento na DCT/IDCT: (A) Algoritmo 1; e (B) Algoritmo 2.

O segundo teste gerado, é para analisar o perfil em termos de qualidade dos pixels na imagem/quadro, para isso, as duas imagens/quadros (Figura 5.18 e Figura 5.19) foram matricialmente comparadas a nível de pixel. Para essa análise comparativa foram utilizadas três placas de vídeo NVIDIA GeForce GTX 1070 Ti e dois processadores Intel Core i9-8950HK, demorando 16 horas, 07 minutos e 14 segundos para conclusão. Como resultado, o “Algoritmo 2” atingiu em média 98% de qualidade e precisão nos pixels gerados, enquanto o “Algoritmo 1” atingiu 91%.

Capítulo 5. Resultados 139

Figura 5.18 – Comparativo na qualidade da imagem/quadro usando DCT/IDCT - Exemplo 1: (A) Original; (B) Algoritmo 1; e (C) Algoritmo 2.

Capítulo 5. Resultados 140

Figura 5.19 – Comparativo na qualidade da imagem/quadro usando DCT/IDCT - Exemplo 2: (A) Original; (B) Algoritmo 1; e (C) Algoritmo 2.

Capítulo 5. Resultados 141

O terceiro teste realizado foi a nível de histograma, comparando as duas imagens/quadros (Figura 5.18 e Figura 5.19), como visualizado na Figura 5.20, classificando o “Algoritmo 2” como melhor a nível de qualidade de histograma, apresentando em cada camada RGB um número maior de pixels localizados na zona de tons médios. O “Algoritmo 1”, por sua vez, teve uma concentração maior de pixels nas zonas de sombras e luzes altas.

Figura 5.20 – Comparativo do histograma das imagens/quadros com DCT/IDCT: (A) Algoritmo 1; e (B) Algoritmo 2.

O quarto teste realizado foi a visualização gráfica dos sessenta e quatro pixels ini- ciais da Figura 5.18 em cada fase da DCT/IDCT, aplicados com a técnica apresentada na pesquisa, comprovando que a imagem/quadro original que foi aplicado a DCT, depois de recuperar do armazenamento em banco de dados e aplicado a IDCT, voltou em quase 100% de igualdade, como visualizado na Figura 5.21.

Capítulo 5. Resultados 142

Capítulo 5. Resultados 143

O último teste realizado foi a demonstração/aplicação de duas imagens/quadros (Figura 5.22 e Figura 5.23), inserindo a IDCT na fase de armazenamento do banco de dados, podendo ser visualizado com dimensões de 4x2px à 2048x1024px. No caso, as duas aplicações (JavaScript e Java) utilizam as dimensões de 32x16 para armazenar no BD (que tem um tamanho médio de 1,55Kb, muito menor do que o tamanho da imagem/quadro original que tem em média 3,5Mb), já que de todos os testes feitos foram o de melhor proporção, gerando resultado de quase 100% com a imagem/quadro original.

Capítulo 5. Resultados 144

145

6 Conclusão

Em síntese, a pesquisa avalia o impacto na qualidade, tempo de processamento e o armazenamento de três técnicas/algoritmos desenvolvidas para o processamento digital de imagem/vídeo, que são: Partial Differential Equation, High Dynamic Range e Discrete Cosine Transform, com o uso máximo dos processadores (Central Process Unit e Graphics Processing Unit) e das threads. Para isso, foram criados modelos matemáticos e análises precisas dos pixels, baseado em sua matriz de vizinhança.

Sendo assim, as três técnicas/algoritmos desenvolvidas na pesquisa tiveram resultados melhores comparados aos modelos convencionais. Esse novo modelo permite a busca dos melhores pixels de forma matricial, permitindo que os pixels da vizinhança sejam padronizados, além do uso do histograma para avaliar a melhor posição dos pixels nas áreas médias.

Essa padronização é baseada na técnica MSAA (MultiSample Anti-Aliasing), no qual cria um processo inteligente de renderização de múltiplas cópias de cada pixel e a interpolação entre eles, recebendo um ganho de qualidade em até 2,3%.

Em relação aos ganhos das três técnicas/algoritmos desenvolvidas (Partial Dif- ferential Equation, High Dynamic Range e Discrete Cosine Transform), o valor médio do PSNR (Peak Signal to Noise Ratio) ficou em aproximadamente 8dB, comparando os ganhos de todos os testes feitos nas imagens/quadros durante a pesquisa.

A qualidade das imagens/quadros gerados, teve em média um aumento de 12% em relação a imagem/quadro original, isso em termos de precisão dos pixels, comparando todos os testes feitos durante a pesquisa, além do ganho significativo em tempo de execução. Todo o conteúdo será utilizado para trabalhos futuros na área de processamento digital de imagem/vídeo.

146

7 Trabalhos Futuros

No documento Eficiência, qualidade e compressão do processamento digital de imagem/vídeo (páginas 116-146)