Desafio:
Aceite duas imagens em preto e branco (monocromáticas) e xe cada pixel do primeiro, com cada pixel do segundo, adicione-os a uma nova imagem e produza a nova imagem.
Alguns esclarecimentos:
O tamanho das fotos não importa. O formato de extensão / imagem não importa. Você pode fazer com que você receba qualquer extensão e produza qualquer extensão, desde que a extensão seja usada para armazenar imagens digitais. Você também pode usar gráficos para desenhar a saída em, por exemplo: uma caixa de imagem, se desejar. Caso contrário, salve a saída como um arquivo. A entrada pode ser tomada como um caminho para a imagem ou URL.
Uma coisa que você não pode fazer, no entanto, são matrizes de E / S, por exemplo. de trigêmeos (R, G, B).
NÃO adultere alfa . Não deve ser xored, deve ser 255 (valor máximo) para cada pixel.
Como assim xor cada pixel?
Você não precisa fazer isso dessa maneira, mas uma maneira de x ou dois pixels é pegar seus valores RGB e xor R1 com R2, G1 com G2, B1 com B2 e pegar o resultado, que é sua nova cor
Como temos apenas duas cores, obviamente, quando as cores forem iguais, o resultado seria (0,0,0) e quando elas forem diferentes (branco é 255.255.255 e preto é 0,0,0) nesse caso, o resultado seria 255.255.255.
Assim, quando dois pixels são diferentes, o resultado é um pixel branco, senão um pixel preto
Exemplo de E / S:
Entrada 1: Entrada 2:
Saída:
Isso é código-golfe, então o código mais curto vence.
fonte
Respostas:
A linguagem de expressão FX (ImageMagick),
84 bytesEDITS
u!=v
-4 bytesComo "Fx Expression Language" está aparentemente completo de Turing, eu re-perfilei minha resposta a ela (era Unix Shell + Image Magick).
Golfe
O Fx não suporta XOR bit a bit nem NOT bit a bit , então usei
!=
(o que funciona muito bem para as imagens BW puras).Entrada e saída estão implícitas (controladas pelo intérprete).
Uso
O utilitário de conversão ImageMagick , serve como intérprete "Linguagem de expressão de câmbio", quando chamado com
-fx
, conforme ilustrado abaixo:Os argumentos são:
Saída de amostra
fonte
Mathematica,
373415 bytesAgradecimentos a Ian Miller por reduzir o número de bytes em mais da metade!
No final, sempre há um builtin. Esta função recebe duas imagens como entrada e produz uma imagem; faz algo mais complicado para imagens coloridas, mas para preto e branco é exatamente XOR.
Submissões anteriores:
Obrigado a JungHwan Min por salvar 3 bytes!
Função sem nome que recebe um par ordenado de imagens (de dimensões compatíveis) como entrada e retorna uma imagem exibida.
ImageData
obtém apenas os dados de pixel sem todos os wrappers / metadados; infelizmente, ele retorna números reais, por issoChop
é necessário para ajudar a tratá-los como números inteiros.BitXor
faz exatamente o que diz na lata (eImage
passa por cima de listas aninhadas) e transforma o RGB resultante novamente em uma imagem.Envio original, que utilizou um par ordenado de URLs ou nomes de arquivos como entrada:
fonte
ImageDifference[#,#2]&
Java,
336335328 bytesUngolfed:
fonte
String[] y
. Apenas um pequeno pequeno golfe.public
public class M
.png
não deve ser necessáriaPython,
646057 bytesEu sou novo no golfe, então tenha piedade!
Obrigado ao @Blender e ao @ FlipTack por me salvarem 7 bytes!
fonte
from cv2 import*
deve cortar 4 caracteres.d=
:) também, fazendor=imread
e usandor
duas vezes pode ser mais curtoOitava,
433834 bytesGraças a flawr me salvou 5 bytes.
Graças a Luis Mendo me salvou 4 bytes sugeridos para uso em
a~=b
vez dexor(a,b)
.Uma função que assume como nome de arquivo de entrada das duas imagens de entrada
a,b
e mostra o resultado.Resposta anterior que grava em um arquivo:
Uma função que assume como nome do arquivo de entrada das duas imagens de entrada
a,b
e nome do arquivo da imagem de saídac
.Uso:
O resultado é salvo em
out.png
fonte
imshow()
vez deimwrite()
?imread(a)~=imread(b)
(ou+(imread(a)~=imread(b))
se a entrada lógica não é permitida porimshow
) em vez dexor(...)
?JavaScript (ES6),
333320308299297 bytes-
1220 bytes salvos por Ismael Miguel- 2 bytes salvos pelo usuário2428118
Espera imagens já carregadas, assume o tamanho da primeira entrada como tamanho de saída e retorna um elemento de tela.
Ungolfed
Ps: Primeira vez no code-golf, então provavelmente ele pode jogar mais e minha contagem pode estar errada.
PPs: o contexto 2D da tela possui um
xor
[modo de composição ( https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation ), mas funciona com valores alfa ...Pode ser ainda mais jogado (251 bytes) com um tamanho fixo de 300 * 150 px (o restante é preto), como na resposta de processamento
Mostrar snippet de código
fonte
c
porc=i=>{with(document.createElement('canvas')){width=i.width,height=i.height;return getContext`2d`}}
e você salvar 16 bytes.xor
um retângulo preto sobrexor
as duas imagens para voltar a 255 alfa?with
mas parece muito bom para jogar golfe ;-) Além disso, esqueci que o literal do modelo economiza 2 bytes ...(i,j)=>{c=i=>{with(document.createElement(C='canvas')){width=i.width,height=i.height;return getContext`2d`}},g=i=>{x=c(i);x.drawImage(i,0,0);return x.getImageData(0,0,i.width,i.height)},a=g(i),b=g(j).data,d=a.data,r=c(i);d.forEach((e,i)=>{d[i]=i%4>2?255:e^b[i]});r.putImageData(a,0,0);return r[C]}
Processando,
124118117 bytesUso:
Ungolfed
fonte
MATL , 10 bytes
Explicação
Esta é basicamente a mesma resposta, como a solução Octave existente : Pega os nomes dos arquivos ou URLs das duas imagens como entradas e exibe o resultado na tela.
Uso
fonte
Perl, 260 bytes
251 bytes de código + 9 bytes para
-MImager
.Não sei se o Perl é o melhor idioma para esse desafio, mas queria saber qual era a imagem do comentário do @ orlp. E isso me faz usar um pouco desses módulos gráficos, isso é uma coisa boa. E eu gostei de codificá-lo!
Uma versão mais legível:
Você precisará instalar o Imager se quiser experimentá-lo, mas é bem simples: basta executar
(echo y;echo) | perl -MCPAN -e 'install Imager'
no seu terminal.fonte
LÖVE2D , 199 bytes
Simples, pega dois arquivos de imagem na linha de comando e gera um arquivo chamado "Z" no diretório Love. Também funciona para imagens coloridas!
fonte
J, 54 bytes
Leva dois argumentos em que cada um é o caminho para uma imagem de entrada no
bmp
formato. Cada imagem é lida como uma matriz de números inteiros RGB de 24 bits e analisada em um trigêmeo de valores RGB de 8 bits, o sinal de cada um é obtido e as duas matrizes são XOR juntas. O resultado é redimensionado em 255, convertido novamente de um trigêmeo de 256 números base em um número inteiro e gravado em umbmp
arquivo de saída chamadoo
.fonte
C, 189 bytes
Opera em imagens PBM. Ligue
f(a, b, out)
com os nomes dos arquivos de entrada e do arquivo de saída.Suposições:
Os dois cabeçalhos da imagem de entrada são idênticos (espaço em branco incluído) e têm menos que
9 * sizeof(int)
caracteres.Estamos em um bom sistema operacional que libera e fecha os arquivos vazados.
EOF == -1
Sem golfe e explicado: (barras invertidas omitidas)
C (flexão de especificação), 149 bytes
Ainda usa arquivos PBM, mas agora:
A imagem deve ter um pixel de altura e 8 pixels de largura ou menos, porque o PBM comporta 8 pixels em um byte.
O cabeçalho deve ter 7 bytes (por exemplo,
P4 8 1
com um espaço à direita).Ambos os arquivos são procurados para a frente enquanto preenchem
t
o cabeçalho; os últimos bytes são lidos, xor'd e gravados novamente. Aproveitafread
efwrite
possui listas de parâmetros semelhantes para fatorar todas as três operações no cabeçalho atrás da mesma macro.fonte
R, 45 bytes
a
eb
represente os nomes dos dois arquivos de imagem.Exemplo:
Saída:
fonte
Processando, 82 bytes
Abusa das extensas funções de desenho do Processing para evitar a execução de qualquer XOR. Combina as duas imagens com o
DIFFERENCE
modo e as desenha na tela.Uso
Ungolfed
fonte
32
vez deDIFFERENCE
. Esta seria uma boa gorjeta para o golfe: codegolf.stackexchange.com/questions/26809/... :)C #, 233 bytes
Obrigado a Unknown6656 pela dica de que os argumentos da linha de comando não são necessários. O programa agora lê os arquivos "a" e "b" e grava no arquivo "c" no mesmo formato que "a". Desativado por um erro corrigido também.
Ele define cada pixel como preto se a cor for a mesma, caso contrário, branca.
Para salvar bytes, ele captura exceções fora dos limites, em vez de verificar as propriedades Largura e Altura dos Bitmaps. Cada vez que x sai dos limites, é redefinido para 0 e y é incrementado. Quando y sai dos limites, x é 0 e o loop é interrompido para salvar a imagem e sair.
Exemplo de compilação usando csc e execução usando mono:
fonte
(string[] v)
no interior do main-declaração, como C # não precisa explicitamente para executar um aplicativoClojure, 300 bytes
Rascunho flagrante da resposta Java . Eu não sabia como fazer o desafio, mas estava curioso para saber como a solução Java se traduzia no Clojure. Foi bem direto. O código não destruído é realmente bonito.
Este foi o primeiro desafio de código-golfe que fiz que incluiu importações. Provavelmente existe uma maneira de otimizá-los para economizar alguns bytes.
Ungolfed:
fonte
PHP,
246243 bytesProvavelmente posso jogar mais isso.
Execute-o na linha de comando da seguinte maneira:
fonte
$i=imagecreatefrompng;$a=$i($argv[1])
é um byte a mais que$a=($i=imagecreatefrompng)($argv[1])
. E você pode tentar imagens de paleta com uma paleta de duas cores.($f=func)(params)
requer PHP 7.for(;$k<$w*$h;)
porfor(;$y<$h;$y+=1/$w)
,$x=$k%$w, $y=$k++/$w
por$x, $y
e o último$x
por$x++
. (assumindo que não há erros de arredondamento para todos os tamanhos de imagem razoáveis)Node.js,
156135 bytesOs arquivos de imagem de entrada e saída devem estar no formato PBM (P1), onde está a primeira linha
P1 [width] [height]
e a segunda linha são os valores ascii em preto e branco sem espaços.Aqui estão as imagens de entrada seguidas pela saída xor (32x32 pixels):
fonte