Se uma imagem é girada sem perdas, por que o tamanho do arquivo é alterado?

Eu estava procurando por métodos de rotação de imagem sem perdas e me deparei com essa pergunta, que explica muito bem:

As rotações do "Windows Photo Viewer" não têm perdas?

Então, criei um JPEG de 256 × 256 com pixels aleatórios (filtro de nuvem do Photoshop) e o girei usando o Windows Picture Viewer. Após a rotação, o tamanho do arquivo aumentou, mas apenas na primeira rotação. A cada rotação subsequente, o tamanho do arquivo permanecia estático. Eu sei que está girando sem perdas porque eu a girei várias vezes sem perda de qualidade perceptível, enquanto uma imagem 257 × 257 sendo girada 20 vezes se tornou muito com perdas.

Provavelmente, isso é causado pela codificação de entropia , que é o estágio final sem perdas da compactação JPEG, depois que os dados da imagem foram quantizados para reduzir seu tamanho.

Quando uma imagem JPEG é rotacionada sem perdas, essa camada final de codificação sem perdas deve ser desfeita, os coeficientes DCT descompactados são embaralhados e os coeficientes embaralhados precisam ser codificados novamente pela entropia. Como a eficiência da camada de codificação da entropia depende da ordem dos coeficientes DCT dentro de cada bloco, o que muda a rotação da imagem, não deve surpreender que o arquivo de imagem rotacionado seja um pouco menor ou maior que o original.

Também existem várias maneiras diferentes de executar a etapa de codificação da entropia; portanto, é bem possível que o tamanho do arquivo da mesma imagem JPEG exata possa variar dependendo do software que faz a codificação. Algumas das possíveis diferenças entre codificadores incluem:

• escolha de codificação aritmética (rara, mas potencialmente mais eficiente, costumava ser patenteada) vs. codificação de Huffman (mais simples, padrão);
• escolha da ordem de codificação sequencial (cada bloco de 8x8 pixels é codificado um de cada vez) vs. progressiva (componentes de baixa frequência de todos os blocos são codificados antes da ordem de codificação dos componentes de alta frequência, geralmente um pouco mais compactos);
• escolha de usar as tabelas de símbolos Huffman padrão (mais rápidas, mais simples, podem ser mais eficientes para imagens muito pequenas) vs. tabelas personalizadas otimizadas para cada imagem (geralmente mais eficientes para imagens grandes, mais lentas e mais complexas para codificar);
• se forem usadas tabelas Huffman personalizadas, codificadores diferentes podem gerar tabelas diferentes para os mesmos dados de imagem;
• vários detalhes de baixo nível do próprio processo de codificação, como se e quando incluir marcadores de reinicialização no fluxo de dados, também podem variar entre os codificadores.

Além disso, os "arquivos JPEG" com os quais as pessoas normalmente trabalham contêm dados de imagem compactados em JPEG agrupados em um contêiner JFIF ou Exif , que combina os dados da imagem com um ou mais blocos de metadados e apresenta seu próprio conjunto de complicações. Mesmo que o software que gira a imagem não faça alterações substanciais nos metadados JFIF / Exif, simplesmente reorganizar os dados pode afetar o tamanho do arquivo em alguns bytes.

Em particular, os metadados JFIF / Exif podem conter uma ou mais miniaturas da imagem em tamanho real, e o software que gira as imagens realmente deve regenerar (ou também girar sem perdas!) As miniaturas para que correspondam à nova orientação da imagem completa. tamanho da imagem. Isso por si só poderia facilmente explicar a diferença de tamanho observada.

Fui em frente e repeti o experimento para ver se conseguia descobrir o que estava acontecendo.

Procedimento

Gerei uma imagem RGB aleatória de 256 por 256 pixels usando o filtro "Ruído sólido" no GIMP (Filtros> Renderização> Nuvens> Ruído sólido ...) usando as configurações padrão (mostradas abaixo):

E o resultado:

Em seguida, salvei a imagem como JPEG usando as configurações padrão:

Depois, transferi a imagem para o Windows e abri a imagem com o Windows Photo Viewer clicando com o botão direito do mouse na imagem no Explorador de Arquivos e escolhendo Visualizar no menu. Em seguida, girei a imagem usando os botões na parte inferior e salvei a imagem navegando para a próxima imagem usando as teclas de seta.

Para cada um dos testes abaixo, comecei com uma cópia da imagem original e girei (cliquei no botão girar) o número correspondente de vezes antes de salvar. Aqui estão os tamanhos de resltagem ( ls -l -r):

                    size in bytes    last-modified date 
                          VVVVV        VVVVV
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:24 original.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:30 cw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:30 cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:31 cw-cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:29 ccw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:29 ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:29 ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 ccw-ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 ccw-ccw-ccw-ccw-ccw.jpg

Observações imediatas

• O Windows Photo Viewer (WPV) aumenta drasticamente o tamanho; a quantidade de aumento é de cerca de quatro vezes neste teste!
• Todas as novas imagens aumentam para o mesmo tamanho, mas não são idênticas.
• O WPV não recodifica nem salva novamente a imagem quando é girada em um múltiplo de 360 ​​graus. (O registro de data e hora, 11:27, é quando os arquivos foram copiados pela primeira vez.)

Usar cmp -larquivos com conteúdo idêntico nos permite ver onde os arquivos diferem.

robert@unity ../jpeg-rotate-test % cmp -l cw.jpg ccw-ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  60  66
robert@unity ../jpeg-rotate-test % cmp -l cw-cw.jpg ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  62  64
robert@unity ..jpeg-rotate-test % cmp -l ccw.jpg cw-cw-cw.jpg
 2223  62  63
 2224  71  60
 2226  64  60
 2227  61  64
robert@unity ../jpeg-rotate-test % cmp -l cw.jpg cw-cw-cw-cw-cw.jpg
 2221  60  61
 2223  63  61
 2224  60  66
 2226  60  61
 2227  60  61
robert@unity ../jpeg-rotate-test % cmp -l ccw.jpg ccw-ccw-ccw-ccw-ccw.jpg
 2223  62  63
 2224  71  60
 2226  64  65
 2227  61  64

Esses arquivos diferem em apenas quatro bytes (na verdade, em um carimbo de data / hora), significando que o WPV está fazendo a mesma coisa todas as vezes; agora só precisamos descobrir o que é isso.

Observações detalhadas

Para isso, usei o JPEGsnoop para ver exatamente o que havia nas imagens.

Como as saídas são razoavelmente longas, eu as vinculei como uma essência . Aqui está um resumo das diferenças:

• O GIMP usa apenas um segmento APP0(JFIF) e COM(comentário) para metadados. O WPV deixa o APP0segmento intocado, mas, curiosamente, adiciona um byte nulo ao comentário (para que seja terminado por nulo).

• O WPV adiciona dois APP1segmentos, que são os metadados Exif e XMP. Esses segmentos são 4286 e 12726 bytes, respectivamente. Juntos, eles respondem por quase todo o aumento no tamanho do arquivo.

• O GIMP produz um JPEG progressivo, enquanto o WPV produz um JPEG de linha de base (não progressivo). Por esse motivo, a imagem do GIMP possui vários segmentos de digitalização, enquanto a imagem WPV possui apenas um. Na minha experiência, a imagem progressiva às vezes é um pouco menor.

• O GIMP usou subamostragem cromatográfica 1 × 1, enquanto o WPV usou subamostragem 2 × 2. Isso me leva a acreditar que o WPV não está usando a rotação sem perdas "verdadeira", a menos que seja capaz de detectar de alguma maneira que se trata de uma imagem em preto e branco.

Para resolver esses problemas, executei um segundo teste.

Procedimento

Eu segui etapas semelhantes ao primeiro teste. Criei uma imagem aleatória de 256 × 256 RGB usando o filtro de ruído RGB (Filtros> Nariz> Nariz RGB ...) com as seguintes configurações:

Aqui está o resultado:

Eu exportei o arquivo como JPEG usando as seguintes configurações:

A progressiva foi desativada, mas a subamostragem ainda está definida como 4: 4: 4 (que é outro nome para a subamostragem 1 × 1). A qualidade é aumentada para 98.

Copiei a imagem e girei a cópia no sentido horário; depois copiou a versão girada e girou essa cópia no sentido anti-horário, para que possamos comparar diretamente a qualidade entre a cópia processada original e a WPV.

Resultados

-rwxrwx--- 1 root vboxsf 159774 Nov  8 16:21 original-random.jpg
-rwxrwx--- 1 root vboxsf 222404 Nov  8 16:24 cw-random.jpg
-rwxrwx--- 1 root vboxsf 222467 Nov  8 16:24 cw-ccw-random.jpg

Embora o aumento desse tempo seja menor em termos relativos (em torno de 40%), o aumento absoluto é ainda maior - em torno de 62 kB. Isso sugere que o WMV está usando uma codificação menos eficiente.

Vou usar o ImageMagick para comparar as duas imagens:

robert@unity ../jpeg-rotate-test % compare -verbose -metric AE original-random.jpg cw-ccw-random.jpg null:
original-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 160KB 0.000u 0:00.009
cw-ccw-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 222KB 0.010u 0:00.010
Image: original-random.jpg
  Channel distortion: AE
    red: 0
    green: 0
    blue: 0
    all: 0
original-random.jpg=> JPEG 256x256 256x256+0+0 8-bit sRGB 0.050u 0:00.020

Existem zero pixels diferentes entre a cópia original e a girada. Portanto, mesmo que o WPV não esteja usando a rotação sem perdas "verdadeira", ele está fazendo um trabalho suficientemente bom. Suspeito que sei o que está acontecendo e, para explicar, vou desviar um pouco da matemática por trás da compressão JPEG.

O algoritmo de compactação JPEG divide uma imagem em blocos de 8 × 8 pixels. Cada um desses blocos é então submetido a uma transformação discreta de cosseno (DCT) . Os coeficientes DCT resultantes descrevem o bloco como uma soma de ondas de frequências diferentes. O algoritmo "joga fora" algumas informações nas ondas de alta frequência que correspondem a ruído e detalhes muito pequenos. O processo de decodificação reverte o DCT, adicionando as ondas armazenadas para recuperar o bloco.

É possível girar as "ondas" do DCT sem desfazer e refazer a transformação (basicamente, você transforma todas as ondas horizontais em ondas verticais e vice-versa). O que eu acho que acontece no WPV é que a imagem é decodificada, girada e recodificada. Durante o processo de recodificação, como o tamanho da imagem é um múltiplo de 8 em ambas as dimensões, cada um dos novos blocos corresponde a um dos blocos originais. Importante, como cada bloco não possui componentes de alta frequência, o algoritmo não descarta nenhuma informação e encontra exatamente os componentes DCT corretos que uma rotação sem perdas "verdadeira" teria.

Por fim, examinarei os componentes dos arquivos JPEG novamente. Os resultados são novamente vinculados como sugestões . Comparando os dois:

• A imagem WPV contém 4286 + 2 bytes extras de metadados Exif, 1 byte extra no comentário e 12.726 + 2 bytes de metadados XMP. Este é um total de 17.017 bytes de metadados adicionais. Para que servem todos esses dados? Examinei o arquivo com meu confiável editor hexadecimal e uma cópia dos padrões relevantes:

  • Os metadados Exif são estruturados como uma imagem TIFF, que contém várias tags (há muito mais complexidade, mas eu vou pular direto). A maioria dos bytes no segmento Exif está contida em duas tags idênticas com número de tag EA1C(59.932 decimal). Esse número de etiqueta não está documentado em nenhum lugar que eu pudesse encontrar. Ambas as tags contêm 2060 bytes do tipo "indefinido", que são todos bytes nulos, exceto os seis primeiros ( 1C EA 00 00 00 08). Não faço ideia do que são essas tags, por que existem duas e por que precisam ter 2 kB cada.

  • Os metadados XMP são, na verdade, um documento XML inteiro incorporado com namespacing e UUIDs longos, que contêm apenas a sequência de versões do WPV (que já estava nos metadados Exif). No entanto, isso representa apenas cerca de 400 bytes. O restante do segmento é de 122 repetições de 100 espaços seguidos por uma nova linha . São mais de 12.000 bytes de espaço totalmente desperdiçado.

• Como no teste anterior, o GIMP e o WPV usam as mesmas tabelas de quantização do DCT. Isso significa que eles devem calcular exatamente os mesmos coeficientes de DCT, e é por isso que as imagens são exatamente as mesmas. Não tenho certeza se o WPV está usando as mesmas tabelas de quantização ou se ele copia as tabelas da entrada.

• Diferentemente do teste anterior, desta vez o WPV usa subamostragem 1 × 1, portanto, na verdade, é possível detectar que essa é uma imagem colorida (ou pelo menos que amostras mais altas são necessárias para recodificar a imagem sem perdas).

• O GIMP e o WPV usam tabelas diferentes de Huffman (parte da etapa de codificação da entropia). As tabelas para WPV são maiores em um total de 279 bytes e, em um caso, contêm 7 vezes mais códigos.

  Observando as estatísticas do JPEGsnoop, podemos ver que alguns desses códigos raramente são usados. Por exemplo, na ID: 1, Class: ACtabela, dos 119 códigos de 16 bits definidos, apenas 23 são realmente usados. No geral, o segmento de digitalização real é 28,5% maior na versão WPV.

Sumário

• O WPV pode não estar fazendo rotações sem perda "verdadeiras", mas as rotações parecem praticamente sem perda.

• O tamanho extra é parcialmente devido a uma quantidade fixa de metadados adicionados e parcialmente devido à codificação de entropia menos eficiente.

Versão informação:

• SO (Linux) ( uname -a):

  Linux unity 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
  

• SO (Windows):

  

• GIMP (Linux): 2.8.14 (do pacote gimp, versão 2.8.14-1+deb8u1)

  

• Visualizador de fotos da janela (de acordo com os metadados da imagem):

  Microsoft Windows Photo Viewer 10.0.10586.0
  

^{EDIT : Esta resposta foi publicada antes que eu soubesse que os arquivos tinham aumentado de tamanho em torno de 9 KiB (9055 bytes para a imagem 256 × 256, 9612 KiB para a imagem 512 × 512).}

Com toda a probabilidade, quando você girou a imagem pela primeira vez, o Windows Picture Viewer fez uma (ou ambas) das seguintes ações:

1. Adicionada uma tag EXIF ​​que não estava na imagem JPEG original (talvez a tag Orientation);
2. Informações modificadas / adicionadas a uma tag que já existia (talvez tags de software de processamento ou de software de imagem).

Isso aumentou o tamanho do arquivo devido à marca EXIF ​​adicional (e / ou dados adicionais às marcas existentes).

As rotações subsequentes não aumentaram o tamanho do arquivo porque todas as tags e / ou dados de tags que o WPV teria adicionado / modificado já estavam lá. Somente o valor da tag de orientação foi alterado (e talvez também os valores da tag de data / hora).

EDIT : É quase certo que esta explicação não pode ser responsável por cerca de 9 KiB de dados adicionais no arquivo. Além disso, na ausência de outras razões para o aumento de tamanho, essa explicação esperaria que o aumento de tamanho fosse mais ou menos constante (módulo algumas diferenças de comprimento entre representações de string de dados numéricos, provavelmente alguns bytes). Obviamente não é isso que está acontecendo aqui, pelo menos não a explicação completa.

Sem engenharia reversa, o jpeg en / decoder é impossível dizer com certeza. Na verdade, existem vários padrões jpeg e, contrariamente à crença popular, nem todos podem ser modificados sem recodificação.

É possível que o primeiro salvamento seja uma reescrita com perda para seu sabor jpeg preferido e as rotações subsequentes sejam um simples ajuste de metadados ou uma operação diretamente na tabela DCT (o que é possível para alguns esquemas de codificação).

O aumento no tamanho do arquivo também pode incluir alguns metadados adicionais, embora 9k pareça muito, é possível. O aumento também pode ser explicado pela adição de uma miniatura que pode não estar presente na saída do GIMP. Talvez possamos obter mais informações diretamente dos arquivos (antes do WPV e depois).

Em qualquer caso, tentar trabalhar sem o jpeg é realmente uma tarefa fácil, pois só é útil em determinados tamanhos de imagem; nem todos os decodificadores e codificadores são idênticos e exige que esses editores trabalhem diretamente com o conteúdo jpeg no qual você não pode confiar. o caso ... Só porque o faz agora, não significa que continuará no futuro.

Sua melhor aposta é trabalhar com um formato sem perdas e evitar a dor por completo.

A rotação JPEG sem perdas só é possível sem a introdução de artefatos de limite se as dimensões da imagem forem múltiplas do tamanho do bloco (normalmente [/ sempre?] 8). Consulte a página de manual do jpegtran (desculpe, não tenho um bom link canônico; fique à vontade para editar se encontrar um) para obter detalhes sobre o que está envolvido:

A transformação de transposição não tem restrições em relação às
dimensões da imagem . As outras transformações operam de maneira bastante estranha se as dimensões da imagem não forem múltiplas do tamanho do iMCU (geralmente 8 ou 16 pixels), porque elas só podem transformar blocos completos de dados do coeficiente DCT da maneira desejada.

O comportamento padrão do jpegtran ao transformar uma imagem de tamanho ímpar
é projetado para preservar a reversibilidade exata e a
consistência matemática do conjunto de transformação. Como afirmado, a transposição é
capaz de inverter toda a área da imagem. O espelhamento horizontal deixa intacta qualquer coluna parcial do iMCU, mas pode inverter todas as linhas da imagem. Da mesma forma, o espelhamento vertical deixa intacta qualquer linha parcial do iMCU, mas é capaz de inverter todas as colunas. As outras transformações podem ser construídas como sequências de operações de transposição e flip; por consistência, suas ações nos pixels da borda são definidas como iguais ao resultado final da sequência de transposição e flip correspondente.

Para uso prático, você pode preferir descartar todos os
pixels das bordas não transformáveis, em vez de ter uma faixa de aparência estranha ao longo das
bordas direita e / ou inferior de uma imagem transformada. Para fazer isso, adicione a opção -trim:

Suspeito que o Windows Photo Viewer esteja evitando esse problema executando descompactação e recompressão de extrema alta qualidade para simular o comportamento sem perdas quando as dimensões da imagem não são múltiplos de 8, em vez de realmente executar a rotação sem perdas. Um bom utilitário faria apenas artefatos sem perdas, tudo ou todos, ou eliminaria alguns pixels, em vez de arruinar a qualidade de toda a imagem (e aumentar o tamanho do arquivo).

Não tenho uma resposta definitiva, mas algumas teorias possíveis sobre por que isso aconteceu. Alguns tipos de arquivos funcionam de tal maneira que dois códigos diferentes para uma imagem desse tipo de arquivo não necessariamente produzem imagens diferentes. Por exemplo, o tipo de arquivo PNG funciona dessa maneira porque permite um plano de fundo transparente, mas uma imagem com um plano de fundo transparente e uma que é a mesma, exceto que o mesmo plano de fundo é branco e aparece exatamente da mesma maneira. Diz-se que um arquivo de imagem é compactado se ocupar menos de 3 bytes de memória por pixel. Acredito que, exceto aqueles com um plano de fundo transparente, nenhum arquivo PNG gere exatamente a mesma imagem. Sempre que você salva uma imagem como PNG, ela a converte em um código que gera a imagem original, exceto em imagens muito incomuns, como uma em que cada pixel é uma cor aleatória de todas as 2 ^ 24 cores, o código ocupará menos memória que 3 bytes por pixel, portanto, salvar como PNG é uma compactação sem perdas. Por outro lado, para economizar memória, apenas determinadas imagens podem ser geradas pelo código de um arquivo de imagem JPEG. Provavelmente, há mais de um tipo de arquivo JPEG e não sei se algum deles tem a propriedade de que duas imagens diferentes desse tipo de arquivo podem gerar exatamente a mesma imagem. Suponho que várias vezes você girou uma imagem e a salvou como JPEG e fornece uma explicação do que aconteceu sob a suposição de que foi isso que você fez e que eu não sei se é verdade. Uma rotação que você fez é sem perdas se houver uma maneira de recuperar exatamente o mesmo código de arquivo de imagem que você tinha antes de girá-lo e salvá-lo. Você pode não estar certo de que realmente fez uma rotação sem perdas. Se realmente não tivesse perdas,

As razões por trás disso são algumas

a maneira como as imagens são codificadas e compactadas alterará o tamanho simplesmente por causa do algoritmo de compactação. você pode testar isso salvando-o como um bitmap e depois girando-o. Nesse formato ou em qualquer formato bruto, o tamanho deve permanecer o mesmo. Caso contrário, o programa que salva a imagem está adicionando novos dados, possivelmente alguns metadados ou algo assim.

Mas por que você está girando um jpeg 20 vezes?

Por causa de como a compactação de imagens funciona . Qualquer formato como PNG ou JPG em geral não preserva o tamanho do arquivo após a rotação.

Para o compressor, a imagem girada é apenas uma imagem diferente, devido à maneira como a compressão heurística funciona, não há garantia de que comprimirá uma imagem girada da mesma forma .

Obviamente, se a compactação for sem perdas, se você girar a imagem 4 vezes a quarta vez que a imagem será novamente a mesma (girada até ficar inclinada como o original): nesse caso, ela deverá voltar a ter o mesmo tamanho compactado, se não for o caso é porque um dos seguintes motivos :

• Metadados adicionados : o programa adicionou um pouco de texto por algum motivo
• Compressor alterado: o programa pode optar por salvar novamente a imagem como original, se não houver alterações, mas se você aplicar alguma alteração (mesmo 4 rotações de 90 graus), poderá decidir comprimir novamente a imagem usando sua própria compressor (o programa não sabe mais que ainda é a mesma imagem).
• Em geral, o mesmo compressor (libPNG ou libJPG) produz resultados muito diferentes em diferentes implementações, versões diferentes da mesma biblioteca e com parâmetros de compactação diferentes (também o sistema operacional e o compilador fazem diferença aqui às vezes).

A compactação de imagem funciona compactando imagens em pedaços de 4x4 ou de outros tamanhos. Em geral, um compressor vê uma imagem girada como uma imagem diferente, no entanto, como um pedaço de pixel compactado é apenas uma decomposição linear, se os pedaços da imagem forem os mesmos, é possível apenas transpor / espelhar as matrizes de decomposição linear efetivamente mantendo o mesmo qualidade:

Observe que isso deve ser implementado por recurso e isso também explica o aumento inicial no tamanho => na primeira rotação, apenas tenta compactar a imagem em pedaços que são rotativos:

• Se isso não ocorrer: a qualidade da imagem diminui

• Se for bem-sucedido, aumente o tamanho apenas uma vez, e cada rotação mantém a mesma qualidade.

• Essa operação é bem-sucedida apenas se a imagem for feita por partes iguais. (o tamanho da imagem é múltiplo do tamanho do pedaço).

O scottbb responde errado e você pode fazer um teste simples:

• Abra a imagem original: Screenshot it
• Gire a imagem 4 vezes com o WPV: Screenshot
• Compare as 2 capturas de tela

Você verá a imagem alterada (é recomprimida na primeira rotação). No entanto, essa mudança é limitada no tempo, agora você pode girá-la novamente sem perda de qualidade (se a imagem tiver um tamanho múltiplo de 8)

Para responder diretamente ao OP:

Eu sei que está girando sem perdas

Não está rodando sem perdas, perde qualidade pelo menos uma vez (na primeira rotação: porque deve comprimi-la primeiro de uma maneira que possa ser rotacionada), mantendo a sua qualidade.