Rotacionador de imagens gratuito

90/180/270 vs. todo o resto: a linha do sem perdas

Existem dois tipos completamente diferentes de rotação de imagem. As rotações de exatamente 90°, 180° ou 270° são sem perdas: cada pixel de origem cai em exatamente um pixel de destino inteiro, o bitmap é permutado em vez de recalculado, e não há interpolação, nem mesclagem, nem perda de qualidade alguma. Uma rotação de 90° no sentido horário mapeia o pixel (x, y) em uma imagem W × H para a posição (H − 1 − y, x) na nova saída H × W. Uma rotação de 180° mapeia (x, y) para (W − 1 − x, H − 1 − y). Essas são operações puras de embaralhamento de memória.

Qualquer outro ângulo exige reamostragem: para cada pixel de destino, o algoritmo calcula de onde ele teria vindo na origem (por rotação inversa), descobre que a localização de origem é geralmente fracionária, e combina os pixels de origem ao redor usando um kernel de interpolação. Os kernels comuns:

• Vizinho mais próximo: escolhe o único pixel de origem mais próximo. Rápido, preserva as bordas duras, mas produz «serrilhados» visíveis ao longo das linhas giradas.
• Bilinear: média ponderada dos quatro pixels de origem mais próximos. Suave, rápido, o padrão para a maioria das implementações de canvas dos navegadores.
• Bicúbico: média ponderada dos 16 pixels de origem mais próximos usando um kernel cúbico suave. Mais nítido do que o bilinear; o padrão nas opções bicúbicas do Photoshop.
• Lanczos: função sinc janelada sobre uma vizinhança de 6×6 ou 8×8. O kernel de mais alta qualidade em uso comum; significativamente mais lento; pode produzir artefatos de ringing em bordas nítidas.

Cada kernel faz uma troca entre a preservação de detalhes e o ringing ou o desfoque, e todos compartilham uma verdade: qualquer rotação que não seja de 90 descarta alguma informação da origem. Detalhes finos de alta frequência (linhas de um pixel, bordas de texto posicionadas em subpixel, pixel art com aliasing limpo) não conseguem sobreviver a uma rotação de 30° ou 45° por nenhum kernel sem algum amaciamento. Intuição útil: gire 1°, depois volte −1°, e você não obtém o original, obtém uma cópia mais suave. Gire 90° e depois −90° e você recupera o bitmap original exato.

Orientação EXIF: a razão silenciosa pela qual sua foto estava de lado

O problema do «navegador mostra minha foto de cabeça para baixo» tem uma causa específica. Os smartphones modernos não giram fisicamente a imagem quando você tira uma foto segurando o telefone de lado: eles armazenam a orientação original do sensor e acrescentam uma tag de Orientação EXIF (introduzida pela JEIDA por volta de 1995) que diz aos visualizadores como a imagem deve ser exibida. A tag tem 8 valores possíveis: 1=normal, 3=180°, 6=90° no sentido horário, 8=90° no sentido anti-horário, mais quatro variantes espelhadas.

Antes de cerca de 2010, os dispositivos gravavam pixels girados e Orientação = 1; a partir de então, os telefones modernos armazenam os pixels originais com a Orientação definida, o que economiza armazenamento e bateria. O problema: os navegadores historicamente não respeitavam a Orientação EXIF fora dos elementos <img>. Arraste a foto de um telefone em retrato para uma ferramenta baseada em canvas, e o canvas a desenharia de lado a menos que a ferramenta lesse e aplicasse explicitamente a tag de Orientação. A propriedade CSS image-orientation, acrescentada em 2017, corrigiu isso para o HTML; o moderno createImageBitmap() com imageOrientation: 'from-image' corrige isso para o canvas. O Chrome 81 (abril de 2020) tornou image-orientation: from-image o padrão para os elementos <img>.

Se você já girou uma foto no seu navegador e ela apareceu «já girada», ou girada duas vezes: você esbarrou nisso. A correção honesta é a ferramenta de rotação ler a tag EXIF, aplicar mentalmente essa orientação primeiro, depois adicionar a rotação escolhida pelo usuário por cima.

Como o canvas faz isso

O método rotate(angle) do canvas gira o sistema de coordenadas em torno da origem do canvas (0, 0). Como a origem é o canto superior esquerdo, chamar ingenuamente ctx.rotate(angle) seguido de ctx.drawImage(img, 0, 0) gira a imagem em torno do seu canto superior esquerdo, enviando a maioria dos pixels girados para fora do canvas, para o canto superior esquerdo. A receita padrão corrige isso com um sanduíche de transladar-girar-transladar:

ctx.save();
ctx.translate(canvas.width / 2, canvas.height / 2);
ctx.rotate(angle * Math.PI / 180);   // canvas takes radians
ctx.translate(-image.width / 2, -image.height / 2);
ctx.drawImage(image, 0, 0);
ctx.restore();

Para uma rotação de 90/180/270, a tela de destino precisa ser dimensionada para caber nas dimensões trocadas (90/270) ou originais (180). Para um ângulo arbitrário, o retângulo delimitador da imagem girada é maior do que qualquer uma das dimensões de origem: para uma imagem W × H girada por θ, a nova caixa delimitadora tem |W·cos(θ)| + |H·sin(θ)| de largura e |W·sin(θ)| + |H·cos(θ)| de altura. Uma imagem de 1000 × 800 girada 45° precisa, portanto, de uma tela de cerca de 1273 × 1273 para conter cada pixel girado. O botão «Recortar na forma» decide se deve expandir a tela (preservando cada pixel, com cantos triangulares transparentes ou brancos) ou recortar de volta às dimensões originais (cortando o conteúdo girado).

Saída PNG vs. JPG: o problema dos cantos

Quando uma rotação que não seja de 90 expande a tela, os quatro cantos triangulares precisam ser preenchidos com alguma coisa. O PNG pode renderizar essas lacunas como pixels totalmente transparentes (alpha = 0), perfeito para sobrepor a imagem girada a outro fundo. O JPG não tem canal alpha e renderiza quaisquer pixels não preenchidos com a cor de limpeza da tela, que o JPEG achata para preto opaco. Um usuário que baixa um JPG de uma foto girada e se surpreende com cunhas pretas nos cantos esbarrou exatamente nesse problema.

Esta ferramenta compõe a saída JPG sobre um fundo branco antes de codificar para evitar o problema dos cantos pretos. A saída PNG preserva a transparência. A escolha entre os formatos: PNG para qualquer coisa com transparência ou que você vá editar mais, JPG para fotos que vão para um destino final onde o tamanho do arquivo importa.

Há mais uma nuance para JPGs. A rotação JPEG sem perdas é tecnicamente possível: o utilitário jpegtran rearranja os limites dos blocos JPEG (os blocos de coeficientes DCT de 8×8) sem redecodificar a imagem, então uma rotação de 90/180/270 pode deixar os dados comprimidos subjacentes intactos e emitir um JPEG bit-idêntico em qualidade ao original. O problema é uma restrição de borda de iMCU: as dimensões da imagem devem ser um múltiplo do tamanho do bloco, caso contrário a rotação ou corta alguns pixels de borda ou deixa um bloco parcial. Esta página usa a API canvas em vez da manipulação de blocos no estilo do jpegtran, então a saída JPG aqui é sempre recodificada, na qualidade máxima, mas com a pequena perda de geração inerente a qualquer recodificação de JPEG.

Quando você recorreria a um rotacionador de navegador

• Fotos de smartphone que foram importadas de lado para um aplicativo de desktop que não respeita a Orientação EXIF.
• Documentos digitalizados que vieram girados 90° porque a detecção automática do scanner estava errada.
• Orientação de impressão: preparar uma imagem para impressão em retrato vs. paisagem.
• Composição de arte e design: girar uma fotografia para testar diferentes orientações visuais.
• Correções rápidas antes de enviar para redes sociais quando a rotação automática da plataforma se confunde.
• Conteúdo sensível: documentos de trabalho, fotos de documentos, fotos de família, que você prefere não enviar para um serviço de terceiros.

Mais perguntas

Minha foto vai perder qualidade se eu apenas girá-la 90°?

Não, não na etapa de rotação em si: as rotações de 90/180/270 são permutações sem perdas. O risco de qualidade é o codificador. Se você envia um JPEG, esta ferramenta o decodifica, gira o array de pixels, depois recodifica o resultado. A recodificação adiciona uma pequena quantidade de perda de geração (tipicamente invisível na qualidade máxima) porque o JPEG é com perdas. Para evitar até isso, baixe como PNG, ou use uma ferramenta dedicada como o jpegtran que rearranja os blocos DCT sem redecodificar.

Por que girar um SVG mantém a imagem nítida?

Porque o SVG é vetorial: ele armazena formas como caminhos matemáticos em vez de como uma grade de pixels. Girar um SVG via transform="rotate(angle)" apenas modifica as coordenadas do caminho; não há etapa de reamostragem nem perda de qualidade em qualquer ângulo. O navegador rerasteriza os caminhos girados toda vez que redesenha, sempre no nível de zoom atual. Esta ferramenta opera em imagens raster (PNG, JPG, WebP) e por isso enfrenta o custo da reamostragem; os SVGs são melhor girados editando o atributo transform diretamente ou usando um editor vetorial como o Inkscape ou o Illustrator.

Por que os cantos estão brancos em vez de transparentes?

Você está baixando a saída JPG. O JPG não tem canal alpha, então as lacunas triangulares deixadas por uma rotação que não seja de 90 são preenchidas com branco antes de codificar (ou preto, em ferramentas que não compõem sobre um fundo, a surpresa de cantos escuros tão comum). Mude para o download em PNG e os cantos ficarão devidamente transparentes.

Posso girar em incrementos de 1°?

Sim. O controle deslizante acima se move em passos de 1°; o campo de entrada aceita qualquer decimal (45,5° funciona bem). Para um trabalho de alinhamento muito preciso (endireitar um horizonte inclinado em uma foto, por exemplo), a precisão de fração de grau pode importar. Cada rotação que não seja de 90 custa uma pequena quantidade de qualidade, então, para ajustes finos repetidos, considere fazer uma única rotação pelo ângulo-alvo final em vez de vários ajustes incrementais.

Algo é enviado a um servidor?

Não. A imagem é decodificada pelo seu navegador, desenhada em um canvas via a API Canvas 2D, e recodificada para download, tudo no processo do seu navegador. O arquivo nunca sai do seu dispositivo. A ferramenta também funciona offline depois que a página é carregada.