As imagens SVG parecem mais reduzidas do que um png, jpg ou gif de alta resolução?


15

Sei que se você quiser ampliar uma imagem, um SVG é uma escolha sábia.

No entanto, minha situação é que tenho ícones que quero que os usuários possam enviar por meio de um CMS. Os SVGs são um pouco mais difíceis de criar e, portanto, jpg, gif ou png parecem o formato ideal para os administradores.

Se o upload for igual ou maior que o tamanho da tela e mantida na proporção correta, os jpgs, gifs ou pngs podem ter a qualidade mais alta que um SVG quando diminuídos?

Minha suposição seria que os navegadores também precisam antialiar um svg abaixo de um determinado tamanho, de modo que eles provavelmente serão borrados tanto quanto qualquer outro formato, embora os gifs pareçam parecer mais borrados.


4
Uma boa pergunta, mas acredito que a resposta é "depende do navegador".
precisa saber é o seguinte

Respostas:


7

(Observação: leia a resposta do OP antes desta, pois minha resposta é um comentário sobre a investigação do OP)

Este é um problema conhecido do Android Chrome. Em algumas de suas construções, eles desativaram o anti-aliasing, fazendo com que as formas do vetor fossem renderizadas com arestas nítidas. O motivo disso foi reduzir a sobrecarga criada pelos cálculos de anti-aliasing. Devido a reclamações, eles lançaram uma atualização que deveria ter ativado o anti-aliasing de volta.

Há vários threads no Stack Overflow discutindo esse problema. Aqui está um deles:
/programming/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

Não consegui encontrar uma referência para o mesmo problema no IPod Touch Safari, mas provavelmente é seguro extrapolar e assumir que o problema é o mesmo.

Existem maneiras de tentar forçar o anti-aliasing, mesmo quando ele está desativado, como esse truque que basicamente adiciona um pouco de preenchimento ao redor do elemento, causando o navegador, por algum motivo, a aplicar o anti-aliasing. Você também pode tentar definir o atributo de renderização de forma do elemento como algo diferente de bordas nítidas e ver se o navegador o respeita.


Adicionar -webkit-backface-visible: hidden significa que os não-svgs desfocam no iPod exatamente da mesma maneira que os svgs, e isso responde à minha pergunta - ou seja, não há necessidade de escolher um sobre o outro ao reduzir o tamanho. Estranhamente, a correção do Android não parece padronizar o comportamento de renderização na minha versão do Android Chrome / broswer nativo, mas esse é um problema diferente. Obrigado pela ajuda.
Richard B

13

Acabei de executar um teste e a única diferença parece estar em navegadores móveis.

Criei uma imagem de 990 x 900px do ícone do Twitter (esse ícone parece muito detalhado para um bom dimensionamento, tão bom para este teste). Salvei isso como SVG, JPG, GIF, GIF transparente (apenas a forma do pássaro, sem cor de fundo, em vez de adicioná-lo com CSS), PNG, PNG transparente.

Em seguida, reduzi-os para 15px, 25px, 50px, 100px e 150px.

Aqui estão os resultados no Firefox: insira a descrição da imagem aqui

Aqui estão os resultados no Chrome: insira a descrição da imagem aqui

Se aplicarmos zoom em uma captura de tela com os menores resultados, para que possamos ver quais pixels estão sendo gerados, o Firefox (em cima) escurece levemente as bordas das versões não transparentes, mas todos os outros resultados são muito semelhantes.

insira a descrição da imagem aqui

No entanto, em um navegador Safari do iPod Touch, a versão SVG parece bastante borrada e as outras bastante pixelizadas:

insira a descrição da imagem aqui

Um resultado semelhante também é visto no Android Chrome. Não tirei uma captura de tela disso.

Gostaria de saber se o motivo disso pode ter algo a ver com a densidade de pixels, que é a principal diferença na exibição, embora isso faria mais sentido para mim se todas as imagens fossem tratadas de maneira diferente no celular, em vez de apenas no SVG.

Se alguém puder explicar por que esse é o caso, transferirei o visto aceito. Caso contrário, acho que a resposta TL; DR é que depende se você preferir ícones desfocados ou pixelados (ou criar muitos ícones com tamanhos perfeitos de pixel para seus pontos de interrupção responsivos).

edit: desde então, observei que os svgs geralmente são muito mais claros em dispositivos apple - o pássaro do twitter pode ter sido muito detalhado para que isso apareça nos meus testes acima, então sinta que eles são o formato certo para os ícones.


O SVG é renderizado no momento da exibição e pode se beneficiar do AA, os outros são de resolução fixa e o único AA que eles podem ter é renderizado 2x; borrão; e reduzir, o que realmente não vai ajudar, exceto em situações de "descalcificação". Para o SVG, um método AA fixo (como em geral simples 4x FSAA) será agressivo demais quando você tiver apenas 8px de largura, e a amostragem para baixo sempre resultará em um borrão.
Yorik

Observe que o tipo de dimensionamento e reamostragem depende da implementação do software. A maioria prefere "rápido" ou "equilibrado" em vez de qualidade.
Yorik

3

Há uma distinção muito importante entre imagens vetoriais e imagens bitmap. As imagens vetoriais, se simplificarmos um pouco, são renderizadas pelo cliente enquanto as imagens de bitmap são renderizadas por você.

Isso significa que o aplicativo para o qual você está enviando a imagem tem mais a dizer sobre como ela se comporta. O resultado final é que você tem as seguintes desvantagens :

  • São necessários mais recursos para tornar a imagem apresentável
    • Nesse caso, o renderizado pode optar por diminuir a qualidade porque não possui recursos suficientes para melhorá-lo.
  • Cada sistema de imagem possui seu próprio conjunto de peculiaridades e falhas
    • Torna mais difícil ser consistente
    • Você recebe os problemas de um programador

Por outro lado, existem alguns benefícios disso:

  • A imagem pode ser dimensionada livremente e ter mais opções de manipulação.
    • Isso é simplesmente o resultado do trabalho realizado no final do cliente, para que eles possam gastar mais tempo na computação de pixels para obter uma imagem maior, se você enviar elementos que ele sabe escalar.
  • Os dados em muitos casos são menores que a imagem em pixel (embora não precise ser)

Não há muito o que fazer se um sistema tiver um renderizador de buggy. Você está dando uma opção ao aplicativo final e eles podem usá-la para tomar más decisões.

Qual é melhor

Depende de quão bem você pode renderizar sua imagem e quanta largura de banda você tem à sua disposição. Certamente é possível fazer uma renderização melhor do que o que os navegadores fazem. Não é de surpreender que se possa fazer um trabalho melhor do que o Illustrator também. Mas você perde todos os benefícios de ter uma renderização adiada.

Existe uma terceira opção.

Se você não estiver satisfeito com os resultados, sempre poderá tentar criar seu próprio mecanismo de renderização. Com plataformas que suportam webgl, você pode. Veja aqui um exemplo . Mas isso é bastante grave e não salva os detalhes da implementação do formulário.


2

(Ainda não há pontos suficientes para comentar diretamente a resposta de Richard B.)

Para responder sua pergunta, Richard B, geralmente vemos esse efeito em elementos que precisam de anti-aliasing em hardware de menor potência. Isso acontece mesmo em elementos DOM com cantos arredondados, quando o anti-aliasing é reduzido ou removido desses ambientes.

Em nossa empresa, temos alguns casos em que usamos hardware de menor potência e começamos a encontrar esse problema de "formas extremamente irregulares". Desabilitamos / reduzimos a quantidade de anti-aliasing para melhorar o desempenho. É provavelmente o mesmo motivo pelo qual seus testes no celular retornaram os resultados obtidos.


Faz sentido como uma razão. Porém, os SVGs de vergonha não parecem ter consistência com outros tipos de imagem.
21716 Richard B

11
@ RichardB, bem, eles são diferentes das imagens comuns. Você pode realmente interagir com eles como se fossem nós DOM. Seus caminhos e formas recebem eventos e propriedades CSS, assim como nós DOM reais, portanto, se meu entendimento estiver correto, eles seguirão o mesmo caminho de renderização que outros nós, e isso faz sentido nesse contexto. As imagens são caixas rasterizadas e passam por um canal de renderização diferente, às vezes abrindo espaço na GPU.
Brak
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.