Por fim, todas as imagens digitais não são apenas valores de pixel entre 0 e 255?

Eu tenho algumas perguntas incrivelmente básicas (estúpidas?) Sobre imagens; especificamente, formatos de imagem e valores de pixel.

Perdoe-me, não sou fotógrafo. Sou apenas alguém que trabalha com imagens e, para mim, são apenas linhas e colunas de números.

Minhas perguntas são:

Se no centro, as fotos são apenas 3 canais de valores de pixel [0, 255] X RBG, então como é possível haver alguma diferença entre dois formatos de imagem? Quero dizer, o que torna um RAW diferente de um TIFF - não estão todos limitados a valores entre 0 e 255? Um número é um número - não deveria haver apenas um formato definido? Ou não devem ser bloqueadas duas imagens com a mesma altura e largura e o mesmo tamanho de arquivo?

Além disso, do ponto de vista numérico, o que torna algo como imagens de 16 bits diferente de imagens de 32 bits? Novamente, uma imagem é apenas uma matriz com valores inteiros entre 0 e 255.

Continuando com essa perspectiva de que uma imagem no sistema de arquivos de um computador é apenas uma matriz de 3 canais de números inteiros entre 0 e 255, qual é o sentido de compactar uma imagem em um formato com perdas como, por exemplo, JPG? Digamos que o algo de compressão altere alguns valores de pixel de 254 para 255 ou o que for. Assim? Como isso proporciona economia no tamanho do arquivo ou afeta a qualidade visual?

Eu sei que existem várias maneiras diferentes de armazenar dados de imagem. Mas não estou perguntando nada além de uma imagem básica de RBC de 3 canais. Tudo o que sei é que, se alguém me entrega uma dessas, agora tenho uma série de números. Não tenho motivos para saber por que uma matriz de números pode ser diferente de outra matriz de 0 a 255. Espero que isso faça sentido. Esta questão não se limita ao formato RAW! Pelo contrário, trata-se de qualquer matriz de valores de pixel

Desculpe, mas sua premissa básica está errada: uma imagem pode ser codificada como uma matriz de pixels RBG com 8 bits por valor, mas existem várias outras maneiras:

• um canal com um bit / canal (preto e branco puro),
• um canal com x bit / canal (formatos em escala de cinza, x geralmente será 8 ou 16, fornecendo valores 256 ou 65536),
• vários formatos baseados em paleta (cf. GIF)
• cores com (pelo menos em teoria) quantos canais você desejar com a profundidade de bits necessária.

E isso é para a imagem armazenada na RAM do computador durante a edição / visualização. Estou ignorando os vários formatos de imagem RAW que existem (aqui e no restante deste post).

Para a fotografia , os mais comuns são 3 canais com 8, 16 ou 32 bits / canal (geralmente inteiros, mas pelo menos alguns programas funcionam internamente com números de ponto flutuante de 32 bits). Muitas vezes, existe um quarto canal (alfa), especialmente quando o programa permite o uso de camadas. E em algum lugar, as dimensões da matriz da imagem precisam ser armazenadas.

Existem várias razões para esses diferentes formatos. Para o formato na memória, uma consideração importante costumava ser o tamanho dos dados e a velocidade (muito mais rápido para manipular um canal de 8 bits do que 4 canais de 32 bits). Hoje em dia, isso é menos importante, mas temos um gerenciamento de cores completo com vários espaços de cores. Alguns deles (por exemplo, prophoto RGB) precisam de pelo menos 16 bits / canal para manter as diferenças entre cores vizinhas pequenas o suficiente para evitar faixas visíveis. E, à medida que os tratamentos se tornam mais complicados, há vantagens em usar números de ponto flutuante de 32 bits (em que as cores são codificadas com valores entre 0,0 e 1,0 e o tratamento permite valores intermediários fora desse intervalo).

Se você quiser armazenar a imagem em um arquivo e recarregá-la nos mesmos dados da memória, precisará usar pelo menos o número de bits por canal que o formato da memória e deverá armazenar informações sobre dimensões da imagem, profundidade de bits e espaço de cores.

Os usuários dessas imagens também gostam de armazenar algumas informações adicionais sobre a imagem (legenda, título, quem tirou a imagem, etc ...). Novamente, várias maneiras de armazenar essas informações.

Depois, existem diferentes maneiras de compactar os dados da imagem para armazenamento de arquivos. Um dos mais simples é o RLE (Run Length Encoding), onde você armazena uma contagem e um valor de pixel sempre que encontrar um valor de pixel repetido. Outros, como o JPEG, são muito mais complicados, mas também oferecem muito mais compactação. Por exemplo, o jpeg usa uma transformação de cosseno e joga fora as informações de alta frequência (menos visíveis), fornecendo altas taxas de compressão ao custo da perda de informações (há mais, mas isso está demorando muito).

Isso já oferece várias maneiras de armazenar as informações no disco, mas seja qual for o modo escolhido, o formato deve ser bem especificado para permitir uma interpretação correta ao carregar a imagem.

Depois, há um desenvolvimento constante em, por exemplo, técnicas de compactação sem perdas, com as quais os formatos existentes nem sempre conseguem lidar.

Portanto, terminamos com uma variedade de formatos de arquivo, com várias compensações entre fidelidade das informações armazenadas, espaço em disco ocupado e velocidade de leitura, gravação e transmissão (compare o tamanho de um TIFF não compactado e um jpg de qualidade decente) .

Se você manipular uma imagem na memória, ela será na forma de uma ou mais matrizes. Nesse ponto, o formato do arquivo original não deve mais desempenhar um papel . Presumo que você lide com seus dados com 8 bits / canal.

Mas você precisará saber se possui uma imagem processada ou uma imagem bruta, pois há duas diferenças importantes entre elas:

• as imagens brutas normalmente têm 1 cor por pixel , e os pixels são geralmente organizados em uma matriz Bayer com 2 pixels verde, 1 vermelho e 1 pixel azul por quadrado de 4 pixels. Os valores são proporcionais à intensidade da cena (exceto valores muito baixos e muito altos).
• as imagens processadas podem ser organizadas como uma matriz 2D de registros contendo 3 valores numéricos ou como planos de cores (3 matrizes 2D, uma para cada R, G, B). Além disso, os valores geralmente não são proporcionais às intensidades da cena . Pior ainda, a relação exata entre os valores de pixel e as intensidades da cena depende do processamento da imagem. E o equilíbrio entre as cores foi ajustado para corresponder à resposta do olho humano (balanço de branco, vermelho e azul são amplificados em relação ao verde).

Portanto, se você obtiver uma imagem não processada com três valores de cores por pixel, ela já terá algum tratamento (pelo menos desmoldagem ou simples agrupamento de 4 pixels não processados ​​a 1 pixel de imagem). Se isso é aceitável, dependerá do seu aplicativo.

Se no centro, as fotos tiverem apenas 3 canais de valores de pixel [0, 255] X RBG,

Mas as fotos não são "apenas três canais de valores de pixel", nem "no centro". As telas de computador geralmente são compostas por uma matriz de pixels RGB; portanto, se você deseja exibir uma imagem na tela do computador, em algum momento deve mapear os dados de imagem existentes em uma matriz de pixels RGB, mas esses dados são apenas uma renderização específica dos dados da imagem. Os dados na imagem podem não consistir em um fluxo de valores de pixel. Para obter valores de pixel de uma imagem, você deve saber como os dados são formatados.

então como poderia haver alguma diferença entre dois formatos de imagem? Quero dizer, o que torna um RAW diferente de um TIFF - não estão todos limitados a valores entre 0 e 255?

Esses são dois bons exemplos, porque nenhum desses formatos necessariamente contém uma matriz retangular de valores RGB.

RAW não é um formato único - é uma espécie de nome genérico para arquivos que contêm dados gravados diretamente de um sensor de imagem. Portanto, um arquivo RAW pode conter uma sequência de valores que representam as tensões lidas nos vários locais do sensor. Esses sites são como os pixels da imagem, mas eles são não pixels RGB. Para obter pixels RGB de um arquivo RAW, você deve interpretar esses dados no contexto de informações sobre o sensor, as configurações da câmera no momento, etc. Em outras palavras, você pode abrir um arquivo RAW em um editor hexadecimal e procure tudo o que quiser, mas você não encontrará um único valor RGB.

TIFF significa formato de arquivo de imagem marcado , e é um formato muito interessante porque pode conter muitas representações diferentes de uma imagem. Um único arquivo TIFF pode conter a imagem "mesma" em vários tamanhos, como uma miniatura, imagem com resolução de tela e imagem com resolução de impressão, e também pode ter versões em cores e em escala de cinza. Você sabia que os aparelhos de fax normalmente enviam seus dados como arquivos TIFF? Para obter pixels RGB de um arquivo TIFF, é necessário entender não apenas o formato TIFF, mas também o formato da representação de imagem específica nesse arquivo.

Um número é um número - não deveria haver apenas um formato definido?

Não . Existem muitos formatos de imagem diferentes porque cada pessoa atende a um conjunto diferente de necessidades. A compactação com perda de JPEG é ótima para obter arquivos de imagem muito pequenos, mas não é bom para imagens que precisarão ser editadas várias vezes. Alguns formatos usam entrelaçamento , o que facilita a leitura da imagem em várias resoluções diferentes. E assim por diante ... cada formato oferece seu próprio mix de vantagens e compromissos.

Ou não devem ser bloqueadas duas imagens com a mesma altura e largura e o mesmo tamanho de arquivo?

Não, isso seria terrível. Se o tamanho de cada arquivo de imagem tivesse que ser essencialmente width * height * 3(assumindo cores de 24 bits), você perderia muito espaço de armazenamento. A maioria das fotos contém muita redundância, ou seja, regiões onde a mesma cor é repetida várias vezes. Para economizar espaço de armazenamento, geralmente faz sentido eliminar essas informações redundantes. Uma maneira de fazer isso, por exemplo, é a codificação do comprimento da execuçãoou RLE. Por exemplo, se você tem uma região de 4195 pixels consecutivos todos brancos, é muito mais eficiente codificar isso como "os próximos 4195 pixels são todos {255, 255, 255}" em vez de simplesmente armazenar tantos pixels brancos em o arquivo. O RLE é realmente usado em alguns formatos de imagem, mas muitos formatos têm esquemas muito mais sofisticados que economizam muito mais espaço, e isso significa que você pode armazenar muito mais imagens em um disco rígido ou cartão de memória. Também torna muito mais rápido o envio da imagem para outra pessoa.

Continuando com essa perspectiva de que uma imagem no sistema de arquivos de um computador é apenas uma matriz de 3 canais de números inteiros entre 0 e 255, qual é o sentido de compactar uma imagem em um formato com perdas como, por exemplo, JPG?

O ponto é que torna o arquivo muito menor. A compactação JPEG freqüentemente reduz o tamanho de um arquivo em um fator de 10 ou mais. Isso significa que você pode ajustar mais imagens em um determinado dispositivo de armazenamento, copiá-las mais rapidamente, abri-las mais rapidamente e fazer upload e download delas mais rapidamente. Armazenar a mesma imagem (ou quase) em um espaço muito menor utiliza os recursos com mais eficiência e, portanto, reduz os custos. Pense nisso em larga escala: é provável que uma porcentagem muito grande da informação disponível na Internet consista em imagens e filmes e, sem compressão, precisaríamos de mais ou maiores data centers e consumiríamos muito mais energia.

Digamos que o algo de compressão altere alguns valores de pixel de 254 para 255 ou o que for. Assim? Como isso proporciona economia no tamanho do arquivo ou afeta a qualidade visual?

Considere o meu exemplo de RLE acima. Digamos que você tenha uma foto que inclua uma grande parede em branco; portanto, grandes áreas da sua foto são da mesma cor, exceto que há uma dispersão de pixels um pouco mais escuros, quase imperceptíveis na imagem. Esses pixels reduzem a eficácia da compactação. Em vez de poder apenas dizer "os próximos 500.000 pixels são todos {243, 251, 227}", é necessário executar o comprimento codificado em muito mais pedaços muito menores, porque de vez em quando você se depara com um desses pixels ligeiramente diferentes. Se você permitir que o algoritmo de compactação faça pequenas alterações, talvez alterando apenas qualquer pixel em não mais de 1% ou 2%, é possível obter uma taxa de compactação muito maior sem alterar perceptivelmente a imagem. É uma troca: você ' renunciar a uma pequena quantidade de informações na imagem original em troca de uma grande redução no tamanho do arquivo. O local exato em que você deseja desenhar essa linha pode mudar; portanto, formatos com perdas como o JPEG permitem que o usuário escolha o nível de compactação que deseja.

Além da fantástica resposta da @ remco , quero acrescentar por que existem codecs diferentes para (aproximadamente) o mesmo objetivo.

Codecs são projetados para:

• Seja sem perdas vs. com perdas
• Codifique rapidamente vs. reduza o tamanho do arquivo
• En- / decodificação assimétrica vs. simétrica
• Seja compatível com o software
• Perceba quase sem perdas em diferentes níveis / situações de compressão
• Possui recursos que outros codecs não oferecem, incluindo:
  • sendo livre de royalties
  • suporte para camadas
  • suporte para canal alfa (por exemplo, RGBA) / transparência
  • oferecer uma visualização rápida da web
  • suporta alta (er) profundidade de bits
  • suporta vários espaços de cores (RGB / CMYK)
  • suporte para metadados / versionamento / ...

Algumas dessas coisas são mutuamente exclusivas. E por isso, somos deixados com uma infinidade de codecs.

Alguns exemplos

Nota: nem a lista de codecs está completa, nem todos os seus recursos (ou a falta dele) mencionados. Se esta resposta for útil para alguém, posso adicionar mais algumas informações (e ser um pouco mais preciso).

Talvez o formato mais conhecido seja o JPEG . É um formato muito amplo, mas antigo. Ele usa DCT (Discrete Cosine Transformation), portanto, embora ofereça uma qualidade muito boa nas configurações de qualidade mais alta, o bloqueio aparecerá com os mais baixos.

O JPEG 2000 surgiu para substituir o JPEG: ele é baseado na Wavelet-Transformation, portanto, embora ofereça aproximadamente a mesma qualidade do JPEG nas configurações de qualidade mais alta, oferece qualidade muito melhor nas configurações de qualidade mais baixa (os blocos estão um pouco embaçados) ) Além disso, o JPEG 2000 oferece regiões de interesse (alta qualidade em uma área da imagem, menor qualidade em outro lugar) e suporte de 16 bits. (Além disso, algumas outras coisas.) Infelizmente (?), Porque é mais caro do que o JPEG e devido a algumas preocupações de licenciamento, o JPEG 2000 não é tão amplamente aceito quanto o JPEG.

PNG é outro formato amplamente conhecido - é sem perdas e suporta canais alfa, mas não oferece suporte para espaços de cores não RGB (como CMYK). Portanto, é um formato "somente online".

Depois, existem os formatos VFX como o OpenEXR . Todos eles giram em torno de qualidade e velocidade: o OpenEXR é sem perdas, suporta até 64 bits e codifica / decodifica rapidamente. É usado principalmente na indústria de efeitos visuais como formato intermediário.

TIFF é outro formato sem perdas que é bastante popular entre os fotógrafos. Para compactação, ele oferece nenhum / ZIP / RLE / LZW / JPEG. Ele suporta até 32 bits. Com sua compactação selecionável, é bastante adaptável, mas, devido à sua ausência de perdas, é mais um formato offline.

O HEIF é um dos mais recentes codecs de imagem. Ele usa a mesma compactação que HEVC / h.265 e, portanto, espera-se fornecer uma melhor taxa de compactação que o JPEG. No entanto, por ser bastante nova e por estar sujeita a patentes, não é tão amplamente suportada quanto qualquer uma das opções acima.

Imagens RAW ^{Veja também} , na verdade, não são imagens reais: elas são mais um contêiner para os dados brutos (daí o nome) da leitura do sensor. Somente com software que sabe interpretar os dados é possível obter uma imagem. É também por isso que os conversores RAW como o Lightroom / Capture One / DarkTable / ... precisam de atualizações para oferecer suporte a novas câmeras que usam contêineres já especificados como * .CR2 para Canon. É também a razão pela qual um RAW de 14 bits oferece mais opções de edição do que um TIFF de 32 bits que você exportou do mesmo RAW.

Intermissão: sem perdas vs. com perdas

Ainda não tenho certeza do que você realmente está perguntando, então pensei que não faria mal adicionar uma pequena explicação sobre sem perdas versus com perdas.

A compactação sem perdas funciona executando a codificação de comprimento de execução (RLE) / Huffman / ... para compactar os dados. Os dados em si não são alterados, mas salvos em um pacote menor. Por exemplo, considere o RLE: digamos, temos um fluxo de bits do canal R (de pixel 0,0para pixel 0,11) de 255,255,255,255,255,215,215,235,100,000,000,000- o RLE codificaria isso como 52552215123511003000- isso é muito menor e, já que sabemos que ele é salvo em grupos de 4 dígitos e que o primeiro dígito é o contador e os últimos três dígitos são o valor, podemos reconstruir o total 255,255,255,255,255,215,215,235,100,000,000,000.

A compactação com perdas , por outro lado, tenta compactar ainda mais do que as sem perdas. Para fazer isso, codecs com perdas geralmente tentam remover coisas que nossa percepção não recebe. Tomemos, por exemplo, os YUV( YCbCr, realmente) modelo JPEG (e quase todos os codecs de vídeo) usos: Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Um humano não pode distinguir a diferença entre uma imagem codificada 4:2:0(cada pixel tem um valor de luminância, mas as cores são salvas em blocos de 2x2 alternadamente) e uma 4:4:4imagem codificada (todo pixel tem luminância e ambos os canais de cor). Isto é devido à fisiologia do nosso olho : não podemos ver diferenças de cor, assim como podemos ver diferenças de luminância.

Isso funciona bem na maioria das vezes, mas compare-o com um arquivo MP3: quase ninguém consegue distinguir diferenças entre 192kbps e 320kbps, mas fica abaixo de 64kbps e as coisas ficam feias rapidamente. Além disso, a recodificação reduzirá ainda mais a qualidade, pois poderão aparecer artefatos indesejados (por exemplo, em JPEG, pequenos blocos de codificações de alta qualidade serão considerados detalhes da imagem em codificações adicionais).

Bottom line

Se você não se importa com os formatos de imagem ou seus recursos, qualquer um deles ficará bem. Com configurações de qualidade suficientemente altas, é possível e esperado que você nem veja a diferença entre elas.

Se, no entanto, você precisar de algum recurso específico, pode haver (e quase certamente: haverá) um codec que o tenha coberto.

Se no centro, as fotos são apenas 3 canais de valores de pixel [0, 255] X RBG

Essa é uma suposição seriamente quebrada e o restante da sua pergunta simplesmente não é responsável sem se afastar dela.

Quero dizer, o que torna um RAW diferente de um TIFF - não estão todos limitados a valores entre 0 e 255?

O termo "não processado" pode se referir a duas coisas diferentes, uma imagem "não processada pela câmera" ou um arquivo que contém dados de imagem não processados, sem cabeçalhos.

Uma imagem "camera raw" armazena os dados brutos à medida que saem do sensor. A maioria dos sensores de câmera modernos possui ADCs com mais de 8 bits, mas eles também coletam apenas dados de intensidade para um componente de cor em cada local. A geometria pode ficar distorcida pelas lentes, os valores de intensidade do ADC podem não refletir bem a percepção de intensidade dos seres humanos, os componentes de cores podem não ser mapeados exatamente para os utilizados pelo monitor e assim por diante.

É necessário um processo de mapeamento complicado que envolve interpolação para transformar os dados brutos do sensor em uma imagem RGB de boa qualidade e não existe uma maneira correta de fazê-lo. Além disso, devido à necessidade de interpolar os componentes de cores, a imagem RGB pode acabar maior que os dados brutos.

A conversão pode ser (e geralmente é) feita na câmera, mas muitos fotógrafos aperfeiçoam para salvar os dados brutos para que possam ajustar o processamento após o fato.

Tiff é um formato de arquivo complexo que pode armazenar imagens em uma ampla variedade de formatos diferentes, com uma grande variedade de metadados. Na prática, embora seja geralmente usado para armazenar imagens RGB ou CMYK sem compressão ou sem perdas de compressão.

Arquivos que contêm dados de imagem brutos sem cabeçalhos raramente são usados ​​porque você precisa conhecer o formato e as dimensões antes de poder lê-los. Algumas ferramentas de processamento de imagem as suportam.

Além disso, do ponto de vista numérico, o que torna algo como imagens de 16 bits diferente de imagens de 32 bits?

Infelizmente, "n bit" pode significar duas coisas diferentes. Isso pode significar que todos os componentes de cores estão amontoados em um número de bits (por exemplo, 5 bits para vermelho, 5 bits para azul e 6 bits para verde por 16 bits ou 8 bits de vermelho, 8 bits de verde, 8 bits de azul e 8 bits). de alfa para 32 bits) ou em pode significar que cada componente de cor possui n bits de informação em cada local de pixel.

Continuando com essa perspectiva de que uma imagem no sistema de arquivos de um computador é apenas uma matriz de 3 canais de números inteiros entre 0 e 255

Novamente, essa perspectiva está totalmente errada.

Um arquivo é uma sequência de bytes, mas esses bytes quase nunca são "apenas uma matriz de 3 canais de números inteiros entre 0 e 255"

Você pode armazenar uma imagem assim. Algumas ferramentas até oferecem suporte à leitura e gravação desses arquivos, mas o problema é que isso significa que você precisa conhecer o arquivo antes de poder lê-lo. Suponha que você tenha um arquivo com tamanho de 3000 bytes, possui 1000 pixels RGB de 24 bits? 3000 pixels em escala de cinza de 8 bits? 3000 pixels de 8 bits de um pallete? Em que ordem estão os componentes de cor? que forma é a imagem? os componentes de cores estão na ordem RGB ou BGR? A menos que você saiba as respostas para essas perguntas, não poderá ler significativamente esse arquivo.

Portanto, formatos de imagem práticos geralmente começam com um ou mais cabeçalhos que identificam o tipo de arquivo, as dimensões da imagem e como os dados reais da imagem são armazenados. Eles também podem conter metadados opcionais.

qual é o sentido de compactar uma imagem em um formato com perdas, como, por exemplo, JPG? Digamos que o algo de compressão altere alguns valores de pixel de 254 para 255 ou o que for. Assim? Como isso proporciona economia no tamanho do arquivo ou afeta a qualidade visual?

Os algoritmos de compressão não apenas "alteram valores", eles codificam as informações de uma maneira totalmente diferente, por exemplo, o JPEG pode ser descrito como

• Converta os dados de RGB para YUV
• (opcionalmente) reduza a resolução dos canais de croma em um fator de 2 em uma ou ambas as dimensões
• Divida os dados de cada canal em blocos 8x8.
• Converta os blocos no domínio da frequência usando uma transformação discreta de cosseno
• Quantize os resultados, preservando informações de baixa frequência e reduzindo a precisão das informações de alta frequência.
• Codifique os números resultantes como uma sequência de bytes usando um esquema de codificação de comprimento variável (codificação de Huffman ou codificação aritmética)
• Salve esses bytes no arquivo junto com os cabeçalhos apropriados.

Os formatos compactados sem perdas, por outro lado, geralmente se baseiam em algoritmos de compactação de dados de uso geral, mas às vezes complementam com pré-processamento específico da imagem, como o PNG.

• Converta os dados em um dos formatos suportados (por exemplo, um bit cada para vermelho, verde e azul nessa ordem)
• Para cada linha da imagem executar um processo de "filtragem", existem opções de filtragem de servidor (incluindo nenhuma filtragem), mas o objetivo geral é coletar as informações específicas da imagem de que um pixel provavelmente será semelhante a seus vizinhos e codificar de uma maneira que "desinflar" possa lidar.
• Compacte os dados filtrados usando o algoritmo de compressão de uso geral "desinflar".
• Salve esses bytes no arquivo junto com os cabeçalhos apropriados.

Há várias razões pelas quais essa suposição está incorreta e todas se resumem a uma coisa:

Qual escala você realmente está usando?

E isso pode ser dividido um pouco mais:

O que é 255?

"Cor" não é uma propriedade do universo físico. É uma sensação que surge na mente. E isso inclui coisas como "azul", "verde" e "vermelho". Uma escala de 0 que significa "nenhum azul" a 255 que significa "todo o azul!" Na verdade, o 255 não pode representar o ideal platônico do azul , porque ... não existe uma coisa tão perfeita no mundo real. Então, isso significa:

• o tipo de coisa mais azul que você pode fazer no dispositivo à sua frente?
• o mais próximo da combinação ideal do azul puro do ponto de vista do sistema de visão humana, mesmo que a maioria das telas e combinações de impressora / tinta / papel não o representem?
• um azul muito bom que provavelmente será representado razoavelmente em uma ampla variedade de dispositivos?
• um azul que está fora do alcance da visão humana, mas que permite que seu RGB triplique a maioria das cores que estão dentro do alcance?

Som artificial? Não! Estes são realmente exemplos reais . Confira essas representações de cada escolha. A área curva é uma fatia 2D do espaço de cores da visão humana e o triângulo mostra a área que pode ser representada, dada uma opção específica para vermelho, verde ou azul.

Primeiro, aqui está o perfil da tela do meu laptop, que é bastante representativo dos atuais dispositivos de gama média:

Agora, aqui está o espaço Adobe RGB. Observe o quanto isso é maior do que minha tela pode mostrar!

Então, aqui está o sRGB - o padrão padrão e o espaço padrão normalmente assumido quando nada é especificado. Ele deve ser "bom o suficiente" na maioria das situações.

E, finalmente, o ProPhoto RGB, que usa cores imaginárias como primárias, para tornar o triângulo grande o suficiente para caber em quase toda a visão humana.

Agora jogue a cor da própria luz e a adaptação cromática - a capacidade do sistema de visão humana de ajustar a percepção ao meio ambiente. De fato, não apenas habilidade: coisa que acontece se você quer ou não . "Azul puro" significa que a coisa parece tão azul quanto possível sob essa luz incandescente? Qual seria o valor se fotografássemos à luz do sol?

Então "255" pode significar muitas coisas diferentes.

O que é 0?

Isso é bastante simples - como preto você precisa que o 0 seja? É preto vantajoso ? Se for, mas todas as tonalidades reais da sua cena são muito menos extremas , você realmente deseja "desperdiçar" vários valores potenciais para um intervalo dinâmico que não está na sua cena - e que, como a cor, pode será representado por algum dispositivo ou impressora a que você tenha acesso?

Qual é a sua curva?

Então, depois de ter seus pontos de extremidade, como você passa de um para outro? A percepção humana do brilho é decididamente não linear . Na sua escala de 0 a 255, 100 deve ser duas vezes mais brilhante que 50 ou deve ser um fator maior? A diferença de percepção entre, digamos, 3 e 4, deve ser a mesma que entre 203 e 204?

Se você decidir usar um sistema de armazenamento de log, essa curva deve ser otimizada para corresponder à visão humana, ou para otimização de dados, ou para outra coisa?

Existem muitas possibilidades, para muitas necessidades diferentes.

Na compressão

Você pergunta.

Digamos que o algo de compressão altere alguns valores de pixel de 254 para 255 ou o que for. Assim? Como isso proporciona economia no tamanho do arquivo ou afeta a qualidade visual?

Os algoritmos de compactação modernos são mais complicados que isso, mas isso fornece um bom exemplo. Vou usar hexadecimal FFpara representar 255 e FE254, e imagine que estamos usando a codificação de comprimento de execução como uma forma de compactação. E, por simplicidade, vamos assumir o preto e o branco em vez da cor. Com isso, se tivermos uma linha de dados assim:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

podemos comprimir isso de uma forma muito simples

16×FF 

... o que é uma economia bastante óbvia. Basicamente, podemos armazenar 16 bytes em dois (um para a contagem, dois para os dados). Mas digamos que temos:

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

Agora, a codificação de comprimento de execução nos fornece:

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

... o que não significa economia e, de fato, poderia ter aumentado o tamanho do arquivo. Mas se arredondarmos todos os FEvalores FF, voltaremos ao primeiro caso, com uma redução significativa de tamanho, com um impacto pequeno, mas provavelmente difícil de notar, na qualidade do arquivo.

É claro que esse é um exemplo trivial e artificial, mas todos os algoritmos de compactação com perda compartilham essa característica básica: a perda de dados facilita o uso de um formato de armazenamento mais compacto, com, esperançosamente, pouca alteração percebida .

Em profundidade de bits

Além disso, do ponto de vista numérico, o que torna algo como imagens de 16 bits diferente de imagens de 32 bits? Novamente, uma imagem é apenas uma matriz com valores inteiros entre 0 e 255.

Então ..... uma matriz de valores inteiros entre 0-255 é uma matriz de oito bits . (2⁸ = 256.) Com três canais, esta é uma imagem de 24 bits; alguns formatos também têm um canal de transparência ("alfa") para 32 bits. Pode-se também usar um valor mais alto por canal, que geralmente é o que queremos dizer quando dizemos "profundidade de 16 bits". Isso significa que a matriz passa de 0-65535 (2¹⁶ = 65536) em vez de 0-255. Geralmente, em um esquema como esse, é basicamente apenas um multiplicador, em que o valor mais alto representa a mesma coisa em cada escala, mas a profundidade de bits mais alta fornece mais nuances possíveis. (Consulte esta resposta para obter mais informações sobre isso.) Existem também alguns formatos de arquivo especializados que usam flutuadores de 64 bits (!) Em vez de números inteiros para os valores ou outros tipos de dados, dependendo do caso de uso, mas o conceito básico é o mesmo .

Não, uma imagem não é apenas valores RGB no intervalo de 0 a 255. Mesmo se você ignorar os formatos de armazenamento, há várias maneiras de descrever as cores. aqui estão alguns exemplos:

• Componentes vermelhos, verdes e azuis (RGB)
• Componentes ciano, magenta, amarelo e preto (CMYK)
• Matiz, saturação e luminosidade / valor (HSL / HSV)
• A quantidade de luz que atinge um grupo de sensores em uma câmera
• A quantidade de luz e sua direção quando ele atinge os sensores (em uma câmera de campo de luz )

Os dois primeiros são os mais usados ​​para exibição em monitores e impressão, respectivamente.

Além disso, uma imagem não é apenas pixels, mas também metadados. Pode ser algo como a largura em número de pixels, a largura física se você quiser imprimi-la, uma imagem em miniatura ou até a localização geográfica da câmera quando a imagem foi tirada.

Sua premissa não está errada: qualquer imagem pode ser representada usando uma matriz N-dimensional de valores finitos. Pessoalmente, generalizo isso usando geometria discreta em vez de matriz, mas a essência é a mesma. Mas esse é o conteúdo, não o arquivo.

No entanto, os formatos de arquivo são diferentes. Basicamente, existem várias maneiras diferentes de representar a mesma imagem, como as pessoas mencionadas: bmp, png, jpg, etc. É claro que, depois de decodificá-las, duas versões codificadas sem perdas da mesma imagem levarão às mesmas matrizes.
Pense nisso como um arquivo .txt que você compactou com zip. Com a estranheza adicional de que uma codificação sem perdas retornaria um texto que não é o mesmo que o original, mas muito próximo, quase como uma versão embaçada do texto.

Mantendo a analogia do texto, digamos que você tenha o mesmo texto, salvo como .txt, .docx, .pdf, etc. Por que todos os arquivos não são exatamente iguais, se o conteúdo é o mesmo? (Ok, txt não tem formatação, mas os outros).

A propósito, confira como a codificação Netpbm é realmente diferente do JPEG .

Para os formatos RAW e TIFF, até onde sei, a resposta (como já foi dito) é que eles nem sempre usam os mesmos espaços de cores (por exemplo, arquivos RAW podem usar mais bits por pixel para armazenar informações de cores mais refinadas) .

Mas, para chegar ao cerne da sua pergunta - às vezes, há imagens armazenadas em diferentes formatos, mas cada uma representa exatamente a mesma matriz de números.

Um bom exemplo de uma razão para isso são as diferenças na compactação entre um arquivo PNG e um arquivo TIFF.

Os arquivos PNG usam um algoritmo de compactação específico. Isso significa que uma imagem não será apenas armazenada como uma grande lista de números para cada pixel. Exemplo simplificado: ele pode armazenar algo que diz "neste bloco de 10 x 10 pixels, todos os pixels são da cor XYZ". Em vez de armazenar essas informações 100 vezes, ele as armazena uma vez, além de um pouco de informações sobre a região à qual as informações se aplicam.

O problema é recuperar a matriz original de números (representando cores), para que você possa mostrá-la ou editá-la ou o que for, precisa de um software que saiba interpretar essas informações compactadas.

Os arquivos PNG sempre usam o mesmo algoritmo de compactação, por isso é fácil para o software suportar todos os arquivos PNG válidos. Por outro lado, algumas imagens têm uma estrutura que não se presta ao algoritmo de compactação PNG, portanto, alguns de seus arquivos PNG podem acabar sendo muito grandes.

Os arquivos TIFF, por outro lado, suportam muitos algoritmos de compactação diferentes. De fato, ele pode até armazenar diferentes partes da imagem compactada de maneira diferente. E suporta 'extensões', para que você possa comprimir imagens usando maneiras proprietárias. Portanto, talvez a metade superior da sua imagem seja compactada usando um método semelhante ao PNG, mas isso não compactará muito bem a metade inferior; portanto, a metade inferior será compactada usando um método diferente.

Portanto, os arquivos TIFF são mais flexíveis - você pode armazenar exatamente a mesma matriz de números usando menos bytes. Mas o software necessário para decodificar a imagem será mais complicado e poderá não funcionar de maneira consistente com todos os arquivos TIFF que você lançar, por exemplo, você poderá salvar um arquivo TIFF em um software e não conseguir abri-lo usando um software diferente, embora ainda funciona no original.

Então você pergunta

Mas não estou perguntando nada além de uma imagem básica de RBC de 3 canais. Tudo o que sei é que, se alguém me entrega uma dessas, agora tenho uma série de números. Não tenho motivos para saber por que uma matriz de números pode ser diferente de outra matriz de 0 a 255.

Para entregar a você, alguém tinha que saber como a imagem era armazenada e como traduzir isso em uma série de números. (Ou possivelmente algum software está fazendo essa tradução para você sem o seu conhecimento).

Você pode tentar salvar uma imagem como PNG e novamente como TIFF ou GIF e visualizá- la em um visualizador hexadecimal para ver como cada uma representa a mesma matriz de números de maneira diferente. Ou leia os detalhes de como os arquivos PNG e TIFF são representados internamente para ter uma idéia do que precisa ser incorporado ao software para ler matrizes idênticas de números de maneira diferente.

Bitmaps

Um bitmap (BMP) é essencialmente o que você descreve, uma matriz de números que representam cores de pixel. Por exemplo, algo como

1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1

Compressão sem perdas

Agora, vamos definir um esquema de compactação. Em nosso esquema de compactação, teremos uma matriz de pares de números. Por exemplo

3, 1, 1, 0, 7, 1

Agora, a primeira coisa que quero destacar é que esse esquema de compactação representa os mesmos pixels da primeira matriz. A primeira matriz possui três 1s seguidos por um único 0 e depois sete 1s. E é isso que estamos representando aqui. Esse formato é mais curto, pois representa vários pixels com dois números. O formato de bitmap precisa usar um número para cada pixel.

Obviamente, essa é uma visão um pouco simplificada de uma imagem (por exemplo, é apenas uma linha) e um esquema de compactação. Mas espero que isso permita que você veja como um esquema de compactação altera o formato de uma imagem. É assim que um GIF se relaciona a um BMP. O GIF usa um esquema de compactação chamado Lempel-Ziv-Welch em vez deste simplista.

O que descrevemos aqui é um esquema de compactação sem perdas. Um problema com os esquemas de compactação sem perdas é que, para algumas entradas, o formulário codificado pode ser maior que o original. Por exemplo, para

1, 0, 1, 0, 1

A codificação é

1, 1, 1, 0, 1, 1, 1, 0, 1, 1

Bem, isso foi inútil. Fizemos a entrada duas vezes mais.

Outra compressão sem perdas

Agora, vamos considerar um esquema de compactação diferente. Nesta, representaremos a imagem como círculos sobrepostos. Para cada círculo, definiremos um centro, um raio e uma cor.

Nosso primeiro bitmap se tornaria

5, 5, 1, 3, 0, 0

Esse é o mesmo comprimento do nosso primeiro método de compactação.

E o nosso segundo poderia ser

2, 2, 1, 2, 1, 0, 2, 0, 1

São três círculos centralizados no elemento do meio (que na contagem de computadores é o número 2, quando os computadores começam a contar em 0). Um círculo tem raio 2 e cor 1. Em seguida, adicionamos um círculo de cor 0 e raio 1. Finalmente, temos um círculo de cor 1 e raio 0. Em etapas, isso seria

1, 1, 1, 1, 1
1, 0, 0, 0, 1
1, 0, 1, 0, 1

Ou

2, 2, 1, 1, 0, 0, 3, 0, 0

Este é o mesmo círculo inicial, mas coberto por dois círculos de pontos. Em etapas, seria

1, 1, 1, 1, 1
1, 0, 1, 1, 1
1, 0, 1, 0, 1

Ambos são um mais curto que a primeira versão codificada, mas ainda mais que o original.

Você pode se perguntar por que estou falando de círculos e não de intervalos. A principal razão é que os círculos estão mais próximos do que as imagens bidimensionais reais usam.

Compressão com perda

Também temos o conceito de esquemas de compactação com perdas. Esses esquemas de compactação sem perdas podem ser retornados à matriz de bitmap original. Esquemas de compactação com perdas podem não ser reversíveis.

Vamos considerar uma versão com perdas do nosso método de círculos. Nisso, usaremos uma regra simples. Não armazenaremos nenhum círculo com um raio menor que 1. Portanto, em nossas duas últimas codificações, teríamos

2, 2, 1, 2, 1, 0

e

2, 2, 1

que convertidos em pixels novamente são

1, 0, 0, 0, 1

e

1, 1, 1, 1, 1

A primeira versão é apenas um elemento mais longo que o original. A segunda versão é mais curta. Ambos são válidos, portanto o algoritmo é livre para desenvolver os dois e escolher o menor.

Descrevemos imagens com regras mais restritivas como sendo de qualidade inferior.

Essa representação de imagens como coleções sobrepostas de formas circulares é semelhante à maneira como o Joint Photographic Experts Group ou o formato JPEG funciona. Suas formas são elipses e não círculos, mas a idéia é semelhante. Em vez de usar nosso método simplista, ele usa a transformação discreta de cosseno para codificar imagens.

Ao contrário do GIF, o JPEG é realmente uma maneira diferente de representar a imagem. O GIF ainda é pixels. Eles são armazenados apenas de uma maneira diferente. JPEG é formas. Para visualizar um JPEG, convertemos as formas em pixels, porque é assim que as telas funcionam. Em teoria, poderíamos desenvolver uma tela que não funcionasse dessa maneira. Em vez de pixels, poderia produzir formas para corresponder melhor ao formato JPEG. Obviamente, essa tela não seria capaz de mostrar bitmaps. Para exibir um BMP ou GIF, teríamos que converter para JPEG.

Se você converter um GIF padrão, digamos 300 x 300 pixels, convertê-lo em JPEG e diminuir a qualidade, as formas básicas que ele usa deverão ficar visíveis. Muitos JPEGs evitam esses artefatos iniciando com uma imagem de resolução muito maior.

Os JPEGs são bem dimensionados porque são formas e não pixels. Portanto, se você começar com uma imagem de 8000 x 8000, converta-a em JPEG e exiba-a como uma imagem de 300 x 300, muitos dos detalhes perdidos teriam sido perdidos de qualquer maneira. Se você converteu o bitmap de 8000x8000 em um bitmap de 300x300 primeiro e depois em JPEG, os resultados geralmente serão de qualidade inferior.

MPEG

Temos falado sobre imagens estáticas. O formato Moving Picture Experts Group ou MPEG usa o mesmo tipo de compactação que o JPEG, mas também faz outra coisa. Embora uma maneira simples de fazer vídeo seja enviar uma sequência de imagens estáticas, o MPEG envia um quadro, seguido por um número de quadros listando as alterações e finalizando com um quadro final. Como a maioria dos quadros é semelhante ao quadro anterior, a lista de alterações geralmente é menor que uma segunda imagem.

A sequência normalmente não é tão longa, digamos cinco quadros. Mas isso ajuda a tornar o fluxo menor do que seria.

Simplificações

Eu ignorei muito. Minhas imagens têm apenas duas cores (1 bit), não as 256 de uma imagem de 8 bits e certamente não as 4.294.967.296 de uma imagem de 32 bits. Mesmo com imagens de 8 bits, observe que muitas vezes você pode escolher paletas diferentes para a imagem. Portanto, dois bitmaps de 8 bits com as mesmas seqüências podem representar imagens com aparência diferente (mesma forma, mas cores diferentes).

Minhas imagens são linhas únicas, não bidimensionais. A maioria das imagens terá um tamanho de linha específico armazenado, tornando as matrizes bidimensionais.

Não tentei representar as codificações reais. Eles são muito mais complexos do que os simples que eu usei. Fiz isso porque queria poder descrever as codificações neste post. Não estou convencido de que poderia explicar Lempel-Ziv muito menos o refinamento mais complexo de Lempel-Ziv-Welch em uma única resposta. E eu não entendo que Fourier se transforma bem o suficiente para explicá-las de qualquer maneira.

Essa é uma versão simplificada do manuseio real de imagens. No entanto, sinto que, para fins didáticos, é mais fácil entender do que a realidade mais complexa, enquanto ainda atinge os pontos essenciais.

Digamos que era verdade que cada pixel tinha apenas três números (vermelho, verde e azul) cada um no intervalo de 0 a 255. Outros respondentes começaram desafiando (corretamente) essa suposição, mas, para simplificar, digamos que é verdade.

Lembro-me (mas infelizmente não consigo encontrar on-line) um desenho de um livro de linguística: dois antigos escultores de pedra egípcios estão sentados exaustos no fundo de uma parede maciça na qual esculpiram um número muito grande de figuras em marcha. Um está dizendo para o outro: "Certamente deve haver uma maneira mais fácil de escrever: 'O faraó tinha 100.000 soldados?'". Mantenha essa ideia em mente.

Agora, suponha que a primeira linha da sua imagem contenha 1800 pixels em preto. Como isso seria representado?

0 0 0    0 0 0     0 0 0   ....

Então, quanto espaço de armazenamento isso exigiria? Cada valor é um byte. Três bytes por pixel, 1800 pixels na linha e, portanto, 5400 bytes por linha. Portanto, uma imagem com dimensões de 1800 x 1200 deve consumir 1200 vezes mais, ou seja, mais de 6 megabytes. Então agora vamos fazer uma pesquisa de imagens no Google e baixar algumas imagens de 1800 x 1200 - digamos, uma .pngimagem e uma .jpgimagem. Veja o tamanho do arquivo: são 6 MB? De jeito nenhum, geralmente é muito menor que isso. E isso é desejável, é claro, todo esse espaço economizado e menor tempo de download ...

Então o que está acontecendo? A chave é que, mesmo se você tiver tantos números para armazenar, existem diferentes maneiras de representaresses números no arquivo. Há um exemplo de uma representação mais eficiente aqui na minha resposta, dois parágrafos atrás. Eu escrevi as palavras "1800 pixels pretos". São 17 caracteres e, portanto, não precisam ocupar mais que 17 bytes, mas descrevem perfeitamente as mesmas informações para as quais pensávamos precisar de 5400 bytes. E você certamente poderia fazer melhor que 17 bytes (e também poupar muito esforço na implementação de codificação / decodificação) se não usasse o idioma inglês para codificar essas informações, mas sim um idioma para fins mais especiais. Então, agora, já postamos mais de um formato de compactação de imagem: um que usa palavras em inglês e um que é mais eficiente que isso. Veja para onde isso está indo?

OK, você diz que funciona se um monte de pixels adjacentes tiver a mesma cor. Mas e se não o fizerem? Bem, claro, depende do conteúdo da imagem em particular: quanto mais redundância houver, mais fácil será compactar as informações. Redundância significa que partes da imagem podem ser previstas muito bem se você já conhece outras partes. Compactação significa apenas anotar o mínimo necessário para reconstruir as informações. Nem toda imagem possível tem redundância, mas qualquer imagem real que tenha significado para o olho e o cérebro humanos, apesar de ser mais complexa do que o meu exemplo de preto puro, ainda tenderá a ter bastante redundância. E há muitas maneiras diferentes de comprimir. Alguns métodos de compactação são sem perdas, o que significa que as informações podem ser reconstruídas para serem matematicamente idênticas às originais, como no meu exemplo de linha de pixels preta. A maioria dos .pngarquivos usa um método de compactação sem perdas. Alguns métodos são prejudiciais : a reconstrução não é perfeita, mas os erros são ocultos de maneira que o olho e o cérebro humanos dificilmente os notam. A maioria dos .jpgarquivos está com perdas.

Os detalhes de como você reconhece padrões complicados de redundância e como você escreve descrições compactadas eficientes deles são altamente matemáticos - e não triviais, e é por isso que há espaço para tantos formatos diferentes por aí, correspondentes a diferentes estratégias de compactação. Mas espero que você entenda o princípio.

Alguns comentadores acima fizeram suposições razoáveis ​​sobre onde pode ter surgido seu equívoco. Na sua pergunta, você parece pensar que a compactação apenas altera um pouco os valores de pixel (e, certamente, os métodos de compactação com perdas o fazem em alguns lugares, mas apenas como um efeito colateral indesejado) sem alterar o layout das informações. Quando você abre o arquivo e observa o conteúdo da imagem (por exemplo, como uma matriz de números no Matlab ou como uma imagem na tela no Photoshop), não está olhando para o conteúdo do arquivo compactado, mas para a reconstrução, que tem o mesmo layout que o original (não seria uma reconstrução muito grande se não recriasse o layout corretamente). O procedimento de abertura de arquivo descompactou as informações do arquivo em uma representação descompactada completa na memória. Se você comparar duas reconstruções não compactadas , na verdade não há nada para distinguir entre os dois formatos de imagem diferentes de onde eles vieram (exceto os erros de reconstrução, se houver).

Sim, mas como você alcança esses 1s e 0s é muito diferente.

Vou dar um exemplo, mas é falso e deve ilustrar mais do que ser preciso. Lembre-se de que todas as imagens digitais são representadas em binário em algum nível.

Para complicar, existem canais diferentes. CMYK, RGB, P&B, apenas para citar alguns. Nós não vamos entrar nisso. Também existem estágios diferentes, como captura, armazenamento e exibição. Nós entraremos nisso, embora, novamente, o exemplo deva demonstrar não ser preciso. Se você quiser exemplos precisos, precisará procurar uma tonelada de documentos técnicos.

Portanto, em nossa amostra, veremos uma imagem em preto e branco.

00067000
00067000
00567800
04056090
40056009

Os números representam o quão forte é o "preto". Foi assim que a câmera capturou a imagem. Como é uma câmera decente, também é assim que ela armazena a imagem.

Agora ela armazena a imagem em um computador, mas ocupa muito espaço, então vamos compactá-la. Além de esmagá-lo, também sabemos que a maioria das pessoas não consegue detectar uma diferença de 1 nível de preto, então vamos suavizar alguns.

302730
302730
204820
*04056090
1420262019

Agora é assim que armazenamos a imagem em disco. Isso ocupa menos espaço e permite produzir grande parte da imagem original.

Agora, digamos que queremos imprimi-lo em uma impressora. A impressora imprime apenas um nível de preto; portanto, um computador converte a imagem compactada armazenada em fala da impressora.

00011000
00011000
00111100
01011010
10011001

Isso imprime uma imagem de aparência razoável, mas você pode ver, mesmo no exemplo, uma falta de qualidade extream. Mas ei, a culpa é da impressora.

Finalmente, você imprime a imagem em uma boa impressora com 10 níveis de preto. O mesmo que sua câmera. Então você usa a imagem armazenada e compactada.

00077000
00077000
00888800
04056090
40066009

Como você pode ver, a imagem é "melhor", mas foi um pouco alterada em relação ao original.

A qualquer momento, você está certo de que tudo é apenas a força de um canal. E, além da imagem compactada, que precisa ser descomprimida de qualquer maneira, permanece fiel a isso.

No entanto, o formato compactado perde muitas "informações". Essa informação é importante? Bem, isso depende do artista e do público. Existem várias vantagens entre economizar espaço, tempo de processamento, qualidade da imagem final / armazenada e necessidade. Digitalizo a maioria dos meus documentos em uma cor preta, porque é tudo o que preciso. No entanto, minhas fotos de casamento estão no formato HUGE RAW, porque eu nunca sei quando vou querer uma ótima reimpressão dessas. Dito isto, quando as transfiro (fotos) para uma moldura digital, as converto para JPEG para economizar espaço. Canais diferentes, filtros diferentes e métodos de compactação diferentes são todos uma série de compensações. É como uma versão digital do triângulo das impressoras.

Entro em contato com algumas informações suplementares, pois trabalhei com detecção e codificação / compactação de imagens, embora principalmente imagens em movimento.

Em sua forma básica, uma imagem (QUALQUER imagem) exibida em uma tela específica é de fato apenas uma matriz idêntica de números. Esses números podem ser todos de 0 a 255 ou 0 a 65535 ou 0 a qualquer 32 bits que eu tenha esquecido de ir ao google.

Mas existem muitas maneiras de armazenar e transportar essas informações, muitas delas são simplesmente produtos de tecnologias perdidas pelas brumas do tempo.

Além disso, um detalhe que eu não vi nenhum dos outros pedantes aqui mencionar é que os dados do sensor de imagem verdadeiramente RAW de uma câmera digital podem muito bem ser RGrGbB em um padrão bayer ou algo que precise ser processado pelo menos um pouco para fazer com que qualquer sentido para o globo ocular humano Mk.1. É provável que você nunca consiga isso, mesmo em um formato RAW salvo pelo seu DSLR, porque é inútil até convertê-lo em uma boa grade de pixels RGB ou YUV, com 8, 16, 32 ou onze milhões de bits de profundidade.

O material em que trabalhei usa o YUV internamente por qualquer motivo, presumo que seja mais facilmente processado pelos codecs, pois os seres humanos percebem o brilho com muito mais sensibilidade do que as cores.

Para uma leitura leve da hora de dormir, consulte a seção "formato da imagem da moldura": http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

Enfim ... de volta à sua pergunta original sobre a diferença entre arquivos de imagem não compactados, como TIFF / RAW / IFF / PNG.

Geralmente, a razão disso é que, há muitas luas, cada fabricante de computadores / SO / impressoras criou um conjunto de requisitos ligeiramente diferentes para alguma maneira de armazenar / enviar imagens.

Portanto, RAW, conforme discutido por outras pessoas neste segmento, é um termo genérico para várias coisas salvas por diferentes câmeras digitais, usando qualquer carga de dados que o fabricante da câmera considerasse importante, com base nos recursos que a câmera possui ou pode ter no futuro. Portanto, embora o bit principal de dados da imagem possa ser muito semelhante, a "embalagem" ao seu redor descreve a imagem e todas as configurações da câmera etc., para que um arquivo não seja entendido por outro fabricante.

Tradicionalmente, isso permite que você (ou, mais provavelmente, fotógrafos profissionais) use seu software proprietário (e às vezes caro) para processar essas imagens de alta qualidade; caso contrário, você poderá começar a usar o software caro de outras pessoas. Além disso, talvez o Adobe Photoshop queira oferecer suporte ao formato, para que eles possam cobrar o Adobe $$$ por essas informações, para que fotógrafos mais profissionais comprem PS e talvez comprem a marca da câmera porque o PS agora o suporta. Acolhedor!

O RAW também armazena informações sobre como transformar esse pacote específico de dados novamente em uma imagem visualizável por humanos, basta colocar todos os ajustes necessários nos dados para que a imagem pareça "correta".

O TIFF era um formato de imagem inicial que, entre outras coisas, era usado para enviar dados gráficos para impressoras (quando as impressoras com capacidade gráfica começaram a ficar acessíveis). Era bastante básico e fácil de processar no pequeno microprocessador barato dentro da impressora.

O IFF (sim, isso é uma coisa) era um formato semelhante usado nos computadores Amiga, acredito que inventado por eles ou por um dos populares pacotes de tinta. Mas estou usando aqui como exemplo, porque, embora armazene dados de imagem de mapa de bits como os outros, ele suportava dados não compactados ou RLE, profundidade de bits variável de 1 bit mono a 8 bits 256 cores (mas com uma paleta RGB de 3x8 bits para escolher para cada uma das cores), bem como modos especiais chamados Halftone e Hold-And-Modify, permitindo muito mais cores do que outras máquinas da época poderiam gerenciar. Ah, e também suportava animação (como GIF), para que um arquivo IFF pudesse armazenar qualquer número de quadros, com atrasos variáveis ​​entre os quadros, e cada quadro poderia ter sua própria paleta. Portanto, o IFF incluiria dados extras para lidar com tudo isso em comparação com, digamos, um arquivo TIFF.

PNG é outro formato de imagem sem perdas, armazenando novamente dados de bitmap, mas suportando alguns recursos descolados, como um canal alfa de 8 bits, para transparência variável em uma imagem (útil em páginas da web); portanto, a "carga útil" dos dados da imagem pode parecer muito semelhante mas o invólucro ao redor é diferente e a carga útil pode conter RGBA em vez de apenas dados RGB por pixel.

Portanto, são descritos quatro formatos de arquivo de imagem diferentes - você pode armazenar uma imagem em HD colorida de um gato em qualquer um dos 4 e parecer idêntico, cada pixel na tela terá o mesmo valor EXATO e NÃO haverá diferença de qualidade entre os 4 ... mas os 4 arquivos provavelmente seriam diferentes em tamanho, layout e seriam mais fáceis ou mais difíceis para o carregamento e o processamento do software.

Espero que ajude!

Apenas pensei em entrar aqui com as informações que deveriam estar na primeira resposta a essa pergunta.

Os pixels de uma imagem não são armazenados em um byte - a menos que a imagem seja monocromática, ou seja, somente preto e branco.

Se você tiver uma imagem de cor verdadeira, cada pixel será representado por 16 bits ou 2 bytes - como um valor. Se você tiver uma imagem de 32 bits, cada pixel precisará de 32 bits ou 4 bytes, novamente como um valor único.

Curiosamente, os arquivos de imagem e som e todos os outros tipos de dados em um computador se resumem a bits de 1s e 0s. É apenas interpretando-os nos pedaços de tamanho correto que o significado é extraído deles.

Por exemplo, uma imagem e um documento do word e um arquivo mp3 têm o mesmo conteúdo básico de dados (um monte de bytes) e qualquer um deles pode ser interpretado como um dos outros tipos - você pode interpretar um doc do documento como um som arquivo e você ouviria algo, mas não seria música. Definitivamente, você poderia interpretar um arquivo de som como uma imagem e exibiria algo, mas não seria uma imagem coesa.

Portanto, para resumir, um computador só conhece bits - um bit é 1 ou 0. Todas as imagens, sons, documentos, filmes, vídeos, gravações, jogos, telefonemas, mensagens de texto e qualquer outra coisa rotulada como digital têm o mesmo valor exato. conteúdo - um monte de 1 e 0. Os zeros e zeros tornam-se imagens, sons e documentos e tudo mais, porque o código que os lê sabe ler esses bits em grupos e processá-los adequadamente.

É por isso que temos coisas como imagens de 16 e 32 bits e arquivos de áudio de 16 e 24 bits. Quanto mais bits você usar para um pixel ou uma amostra de som, mais expressivo poderá ser - 16 bits podem definir apenas 64k cores exclusivas, mas 32 bits podem definir mais de 4 milhões de cores exclusivas. Uma imagem monocromática usa 1 bit por pixel - está ativada ou desativada.

Com arquivos de áudio, quanto mais bits você usa por amostra, mais detalhada e diferenciada a gravação pode ser.

Não li o tópico inteiro, mas parece-me que muitas pessoas estão esquecendo os formatos de imagem vetorizada. Essas não são matrizes de pixels, porque o conceito de pixel nem existe nesse formato. Cabe ao renderizador descobrir como produzir a imagem em uma tela ou em qualquer outro meio.

Mesmo sem mencionar domínios de cores, compactação, tamanhos de bits e formato de canal, há um conjunto de formatos de arquivo totalmente diferentes dos mapas de pixels. E, no entanto, os formatos vetoriais também são muito "melhores" para representar certos tipos de imagens, normalmente produzidos por um computador e não por uma câmera.

Esta pergunta foi respondida bastante detalhadamente antes. No entanto, apesar de haver muita teoria apresentada nas respostas, sinto que existem alguns assuntos básicos, geralmente relacionados à programação de computadores que exigem mais esclarecimentos. Devo declarar que sou engenheiro de software. Depois de ler a pergunta, percebi que havia um completo mal-entendido dos tipos básicos de dados de programação que geraram essa pergunta.

A primeira pergunta aqui é:

Além disso, do ponto de vista numérico, o que torna algo como imagens de 16 bits diferente de imagens de 32 bits? Novamente, uma imagem é apenas uma matriz com valores inteiros entre 0 e 255.

Como apresentado anteriormente: Não, não é. Uma imagem não é apenas uma matriz de valores inteiros entre 0 e 255. Na verdade, pode ser uma matriz única ou multidimensional de 0 a 65535 valores, uma matriz de 0 a 4294967295 ou mesmo uma matriz de bits (um bit pode conter 0 ou 1 valores, isso é tudo) que é convertido pelo software capaz de leia os arquivos de imagem em números inteiros de acordo com várias regras de codificação.

Para entender melhor, como afirmado anteriormente, acho que é necessária uma discussão sobre os tipos básicos de dados de programação. Vou tentar explicá-los da maneira mais simples possível, para que alguém entenda os problemas envolvidos no armazenamento de valores inteiros nos arquivos dos computadores.

Na programação de computadores, usamos alguns tipos de dados primitivos básicos para gravar valores em arquivos, lê-los dos arquivos na memória do computador, manipular esses valores usando vários tipos de dados de linguagens de programação específicas e, eventualmente, salvá-los em arquivos. Os números inteiros na programação de computadores não são apenas números inteiros. Há todo o tipo de números inteiros, depende da linguagem de programação que estamos usando e quanta memória precisamos para cada um. Normalmente, na maioria das linguagens de programação, temos os seguintes tipos de dados (e maneiras de manipulá-los):

• BIT - mantendo 0 ou 1
• UINT8 - número inteiro não assinado de 8 bits - eles podem conter valores entre o intervalo de [0 a 255].
• INT8 - número inteiro assinado de 8 bits - eles podem conter valores entre o intervalo [-126 a 127].
• UINT16 - número inteiro não assinado de 16 bits - eles podem conter valores entre o intervalo [0 a 65535].
• INT16 - número inteiro sem sinal de 16 bits - eles podem conter valores entre [–32768 a 32767].
• UINT32 - número inteiro não assinado de 32 bits - eles podem conter valores entre o intervalo [0 a 4294967295].
• INT32 - número inteiro não assinado de 32 bits - eles podem conter valores entre [-2147483648 a 2147483647].
• OU uma combinação de todos esses tipos de dados em um formato mais complexo. Por exemplo, um UINT16 (16 BIT) contendo 3 valores diferentes, os primeiros 4 BIT mantendo valores entre 0 e 127, o próximo BIT mantendo 0 ou 1 e assim por diante.

Além disso, há algo que os programadores precisam lidar ao ler ou escrever tipos de dados inteiros de arquivos. A endianess.Endianness refere-se à ordem seqüencial na qual os bytes (UINT8 da nossa tabela) são organizados em valores numéricos maiores quando armazenados na memória ou nos arquivos. O endianness interessa a ciência da computação porque dois formatos conflitantes e incompatíveis são de uso comum: os valores podem ser representados no formato big endian ou little endian, dependendo se os bits ou bytes ou outros componentes são ordenados a partir do big end (o mais significativo bit) ou o pequeno final (bit menos significativo). Simplificando, você pode armazenar um valor como este 0000000011011111 ou ... como este 1101111100000000 dependendo ou da ordem endian que você escolheu. E você tem a liberdade de escolher qualquer pedido que atenda ao seu objetivo. Não existem outras regras que você cria quando cria um formato de arquivo de imagem.

Observe que na programação de computadores números inteiros estão usando mais ou menos espaço, depende do valor. Como você precisa de mais papel para escrever 255255255, precisa de mais BITs para escrever um valor maior. Depois, quando você quiser ler o valor, deverá saber exatamente as regras que criou quando o escreveu. Caso contrário, é impossível descobrir como ler apenas uma matriz com valores inteiros entre 0 e 255, porque você simplesmente não sabe onde esses números estão armazenados e como esses números são armazenados, dadas as muitas opções que você tem (BIT, UINT8 , UINT16, UINT32 ou uma combinação de todos esses tipos de dados do computador). E não se esqueça, Endianness. Se você não souber que os dados foram gravados usando a ordem big endian ou little endian, não será possível ler o valor adequado.

Devido a essas imagens, NUNCA são apenas uma matriz com valores inteiros entre 0 e 255. Algumas delas são matrizes de UINT16 (imagens de 16 bits), outras são matrizes de UINT32 (imagens de 32 bits) ou outras são matrizes de UINT8 (imagens de 32 bits) ou outras são matrizes de UINT8 (imagens de 8 bits). Alguns programadores de computador muito criativos podem até usar tipos assinados que exibem matrizes do INT8, o que significa uma matriz de valores entre -126 e 127.

Na verdade, quando você lê um arquivo de imagem, um dos primeiros dados que você encontra são geralmente alguns BITs que representam a largura e a altura da imagem. E esses não são apenas alguns valores de 0 a 255. Esses também são alguns tipos de dados escolhidos pelo programador. Alguns programadores pensam que 16 bits são suficientes para armazenar uma largura máxima de imagem de 65535 pixels, porque eles estão projetando um formato de imagem usado em um jogo para manter algumas imagens de pequenos botões. Algum outro programador pode usar um valor de 32 bits aqui, permitindo que você armazene imagens com largura e altura de 4294967295. Alguns programadores malucos da NASA podem usar 64 bits para armazenar uma foto enorme da galáxia com até 18446744073709551615 pixels.Se você não conhece as regras, não pode ler esses "valores" como os chama. Porque você não sabe onde eles começam no arquivo de imagem e onde terminam. Então você acaba com um monte de BITs dos quais você não entende nada.

É por isso que o universo está cheio de tantos formatos de imagens diferentes. Porque não há solução padrão para gravar alguns valores inteiros em um arquivo. É a escolha do programador inteiramente baseada em muitos fatores, como a Endianess da máquina em que você está trabalhando, a linguagem de programação que você está usando para projetar a implementação original do formato de arquivo e muitas outras coisas como a finalidade do formato da imagem (conforme claramente indicado anteriormente por outras respostas).

Um formato de arquivo simples e prático de uma imagem em preto e branco que contém apenas um único valor 166 para representar uma imagem de pixels de 4x2:

A imagem (1 - pixel preto, 0 - pixel branco):

1010 
0110

Esse formato de arquivo usa 1 BIT por PIXEL armazenado como um valor inteiro ÚNICO de 8 bits 166 (10100110). Isso é tudo. Nenhuma matriz de valores de 0 a 255 é usada, mas 8 valores diferentes de 0 ou 1 armazenados como valor 166.

Se você usou uma matriz de valores de 0 a 255 para cada pixel * 3 vezes para RGB, a imagem será 24 vezes maior. Esse formato de arquivo economiza 24 vezes o espaço em disco necessário para salvar uma imagem como essa ou 24 vezes menos a memória do computador necessária para ler e manter essa imagem na RAM do computador quando você usa essa imagem, por exemplo, em seu mecanismo de jogo 3D de alto desempenho para desenhe algo na tela com ele (texturizar milhares de partículas de poeira voando por aí pode ser um bom candidato :)).