Semelhante às imagens em allrgb.com , crie imagens em que cada pixel tenha uma cor única (nenhuma cor é usada duas vezes e nenhuma cor está faltando).
Forneça um programa que gere essa imagem, juntamente com uma captura de tela ou arquivo da saída (faça o upload como PNG).
Crie a imagem puramente por algoritmo.
A imagem deve ter 256 × 128 (ou grade que pode ser capturada e salva em 256 × 128)
Use todas as cores de 15 bits *
Nenhuma entrada externa permitida (também não há consultas na Web, URLs ou bancos de dados)
Não são permitidas imagens incorporadas (o código fonte que é uma imagem é bom, por exemplo , Piet )
O pontilhamento é permitido
Este não é um concurso de código curto, embora possa ganhar votos.
Se você está realmente pronto para um desafio, faça 512 × 512, 2048 × 1024 ou 4096 × 4096 (em incrementos de 3 bits).
A pontuação é por voto. Vote nas imagens mais bonitas criadas pelo código mais elegante e / ou algoritmo interessante.
É claro que algoritmos de duas etapas, nos quais você primeiro gera uma boa imagem e depois ajusta todos os pixels a uma das cores disponíveis, são permitidos, mas não lhe renderão pontos de elegância.
* As cores de 15 bits são as 32768 cores que podem ser produzidas misturando 32 vermelhos, 32 verdes e 32 azuis, todos em etapas equidistantes e intervalos iguais. Exemplo: em imagens de 24 bits (8 bits por canal), o intervalo por canal é 0..255 (ou 0..224), portanto, divida-o em 32 tons igualmente espaçados.
Para ser bem claro, a matriz de pixels da imagem deve ser uma permutação, porque todas as imagens possíveis têm as mesmas cores, apenas em locais diferentes dos pixels. Vou dar uma permutação trivial aqui, que não é nada bonita:
Porque os 7 dias acabaram, eu estou declarando um vencedor
No entanto, de maneira alguma, pense que isso acabou. Eu, e todos os leitores, sempre saúdo projetos incríveis. Não pare de criar.
Vencedor: fejesjoco com 231 votos
Quando você diz "O pontilhamento é permitido", o que você quer dizer? Isso é uma exceção à regra "cada pixel é uma cor única"? Caso contrário, o que você está permitindo, o que de outra forma era proibido?
Isso significa que você pode colocar as cores em um padrão; assim, quando vistas com os olhos, elas se misturam em uma cor diferente. Por exemplo, veja a imagem "claramente todo RGB" na página allRGB e muitas outras lá.
— 22614 Mark Jeronimus
Na verdade, acho seu exemplo trivial de permutação bastante agradável aos olhos.
@ Zom-B Man, eu adoro esse post. Obrigado!
Belos resultados / respostas!
— EthanB 28/02
Coloquei um pixel aleatório no meio e depois comecei a colocar pixels aleatórios em um bairro que mais se assemelha a eles. Dois modos são suportados: com seleção mínima, apenas um pixel vizinho é considerado por vez; com seleção média, todos (1..8) são calculados como média. A seleção mínima é um pouco barulhenta, a seleção média é obviamente mais desfocada, mas ambas parecem pinturas na verdade. Após algumas edições, aqui está a versão atual, um tanto otimizada (ela ainda usa processamento paralelo!):
256x128 pixels, começando no meio, seleção mínima:
256x128 pixels, começando no canto superior esquerdo, seleção mínima:
256x128 pixels, começando no meio, seleção média:
Aqui estão dois animgifs de 10 quadros que mostram como a seleção mínima e média funciona (parabéns ao formato gif por poder exibi-lo apenas com 256 cores):
O modo de seleção mínima cresce com uma pequena frente de onda, como um blob, preenchendo todos os pixels à medida que avança. No modo médio, no entanto, quando dois ramos coloridos diferentes começam a crescer um ao lado do outro, haverá uma pequena lacuna preta porque nada estará perto o suficiente para duas cores diferentes. Devido a essas lacunas, a frente de onda será uma ordem de magnitude maior, portanto o algoritmo será muito mais lento. Mas é legal porque parece um coral em crescimento. Se eu abandonasse o modo médio, poderia ser um pouco mais rápido, porque cada nova cor é comparada a cada pixel existente cerca de 2-3 vezes. Não vejo outras maneiras de otimizá-lo, acho que é bom o suficiente.
E a grande atração, aqui está uma renderização de 512x512 pixels, início do meio, seleção mínima:
Eu simplesmente não consigo parar de brincar com isso! No código acima, as cores são classificadas aleatoriamente. Se não classificamos nem ordenamos por hue ( (c1, c2) => c1.GetHue().CompareTo(c2.GetHue())), obtemos esses itens respectivamente (início do meio e seleção mínima):
Outra combinação, onde a forma de coral é mantida até o final: matiz ordenada com seleção média, com um animgif de 30 quadros:
ATUALIZAÇÃO: ESTÁ PRONTO !!!
Você queria oi-res, eu queria oi-res, você estava impaciente, eu mal dormi. Agora, estou animado para anunciar que está finalmente pronto, com qualidade de produção. E estou lançando com um big bang, um incrível vídeo em 1080p do YouTube! Clique aqui para o vídeo , vamos torná-lo viral para promover o estilo geek. Também estou postando coisas no meu blog em http://joco.name/ , haverá uma postagem técnica sobre todos os detalhes interessantes, as otimizações, como eu fiz o vídeo, etc. E, finalmente, estou compartilhando a fonte código sob GPL. Tornou-se enorme, de modo que uma hospedagem adequada é o melhor lugar para isso, não editarei mais a parte acima da minha resposta. Certifique-se de compilar no modo de lançamento! O programa se adapta bem a muitos núcleos da CPU. Uma renderização de 4Kx4K requer cerca de 2-3 GB de RAM.
Agora posso renderizar imagens enormes em 5 a 10 horas. Eu já tenho algumas renderizações 4Kx4K, eu as publicarei mais tarde. O programa avançou bastante, houve inúmeras otimizações. Também o tornei fácil de usar, para que qualquer pessoa pudesse usá-lo facilmente, com uma boa linha de comando. O programa também é deterministicamente aleatório, o que significa que você pode usar uma semente aleatória e gerará a mesma imagem todas as vezes.
Aqui estão algumas grandes renderizações.
Meu favorito 512:
(fonte: joco.name )
Os anos 2048 que aparecem no meu vídeo :
Os primeiros 4096 são processados ​​(TODO: eles estão sendo carregados, e meu site não pode lidar com o grande tráfego, por isso são temporariamente realocados):
Agora isso é legal!
Muito bom :-D Agora faça alguns maiores!
Você é um verdadeiro artista! :)
Estou trabalhando em renderizações enormes e um vídeo em 1080p. Vai levar horas ou dias. Espero que alguém consiga criar uma impressão a partir de uma grande renderização. Ou até uma camiseta: código de um lado, imagem do outro. Alguém pode organizar isso?
— 28414 FeFejjoco
Atualizar! 4096x4096 imagens!
Mesclei meu segundo post neste, combinando os dois programas.
Uma coleção completa de imagens selecionadas pode ser encontrada aqui, no Dropbox . (Observação: o DropBox não pode gerar visualizações para as imagens de 4096 x 4096; basta clicar nelas e clicar em "Download").
Se você olhar apenas um olhar para este (inclinável)! Aqui está reduzido (e muitos mais abaixo), original 2048x1024:
Esse programa funciona percorrendo caminhos de pontos selecionados aleatoriamente no cubo de cores e desenhando-os em caminhos selecionados aleatoriamente na imagem. Existem muitas possibilidades. As opções configuráveis ​​são:
Comprimento máximo do caminho do cubo de cores.
Etapa máxima para executar o cubo de cores (valores maiores causam uma variação maior, mas minimizam o número de pequenos caminhos no final quando as coisas ficam apertadas).
Mosaico da imagem.
Atualmente, existem dois modos de caminho de imagem:
Modo 1 (o modo desta postagem original): localiza um bloco de pixels não utilizados na imagem e é renderizado nesse bloco. Os blocos podem ser localizados aleatoriamente ou ordenados da esquerda para a direita.
Modo 2 (o modo do meu segundo post que eu mesclei neste): Seleciona um ponto de início aleatório na imagem e caminha ao longo de um caminho através de pixels não utilizados; pode andar pelos pixels usados. Opções para este modo:
Conjunto de instruções para entrar (ortogonal, diagonal ou ambos).
Se deve ou não alterar a direção (atualmente no sentido horário, mas o código é flexível) após cada etapa, ou apenas mudar de direção ao encontrar um pixel ocupado.
Opção para alterar a ordem das mudanças de direção (em vez de no sentido horário).
Funciona para todos os tamanhos de até 4096x4096.
O esboço completo de Processamento pode ser encontrado aqui: Tracer.zip
Colei todos os arquivos no mesmo bloco de código abaixo apenas para economizar espaço (mesmo todos em um arquivo, ainda é um esboço válido). Se você deseja usar uma das predefinições, altere o índice na gPresetatribuição. Se você executar isso em Processamento, poderá pressionar renquanto estiver em execução para gerar uma nova imagem.
Atualização 1: código otimizado para rastrear a primeira cor / pixel não utilizado e não pesquisar os pixels usados ​​conhecidos; reduziu o tempo de geração de 2048x1024 de 10 a 30 minutos para 15 segundos e 4096x4096 de 1 a 3 horas para 1 minuto. Fonte da caixa de depósito e fonte abaixo atualizadas.
Atualização 2: Corrigido o erro que impedia a geração de imagens de 4096x4096.
Aqui está um conjunto completo de imagens de 256x128 que eu gosto:
Meu favorito do conjunto original (max_path_length = 512, path_step = 2, aleatório, exibido 2x, link 256x128 ):
Outros (dois esquerdos ordenados, dois aleatórios à direita, dois caminhos superiores limitados, dois inferiores não limitados):
Este pode ser lado a lado:
Estes podem ser lado a lado:
Seleções de 512 x 512:
Diamantes tileable, meu favorito do modo 2; você pode ver neste exemplo como os caminhos percorrem os objetos existentes:
Etapa maior e comprimento máximo do caminho, inclinável:
Modo aleatório 1, inclinável:
Mais seleções:
Todas as renderizações de 512x512 podem ser encontradas na pasta da caixa de depósito (* _64.png).
2048x1024 e 4096x4096:
Eles são muito grandes para serem incorporados e todos os hosts de imagem que encontrei os derrubam para 1600x1200. No momento, estou processando um conjunto de imagens de 4096 x 4096, para que mais estejam disponíveis em breve. Em vez de incluir todos os links aqui, basta vê-los na pasta dropbox (* _128.png e * _256.png, observe: os 4096x4096 são grandes demais para o visualizador do dropbox, basta clicar em "baixar"). Aqui estão alguns dos meus favoritos:
2048x1024 diamantes grandes e inclináveis (o mesmo ao qual vinculei no início deste post)
2048x1024 diamantes (eu amo este!), Reduzidos :
Diamantes grandes e inclináveis ​​de 4096 x 4096 (finalmente! Clique em 'download' no link do Dropbox; é muito grande para o visualizador), em escala reduzida:
4096x4096 modo aleatório 1 :
4096x4096 outro legal
Atualização: o conjunto de imagens predefinidas de 2048x1024 está concluído e na caixa de depósito. O conjunto de 4096 x 4096 deve ser feito dentro de uma hora.
Há muitos bons, estou tendo muita dificuldade em escolher quais postar, então confira o link da pasta!
Isso me lembra de vistas em close de alguns minerais.
— Morwenn 27/02
Não faz parte do concurso, mas achei que isso era legal ; Eu apliquei um grande borrão gaussiano e o aprimoramento automático do contraste em uma das fotos do modo aleatório 1 no photoshop e isso fez uma espécie de coisa bacana no ambiente de trabalho.
whoa, essas são fotos legais!
— 28414
Me lembra as texturas de Gustav Klimt.
Você sabia que pode vincular imagens no Dropbox? Basta copiar o URL de download, remova a dl=1ea token_hash=<something>parte e fazer um link para sua imagem como esta: [![Alt text of my small preview image](https://i.stack.imgur.com/smallpreview.png)](https://dl.dropbox.com/linktoyourfullsiz‌​eimage.png). Outra dica: você pode compactar suas imagens (obtenho bons resultados com TruePNG ( Download )). Consegui salvar 28,1% do tamanho do arquivo nesta imagem .
Python com PIL
Isto é baseado em um Fractal Newtoniano , especificamente para z → z 5 - 1 . Como existem cinco raízes e, portanto, cinco pontos de convergência, o espaço de cores disponível é dividido em cinco regiões, com base no Hue. Os pontos individuais são classificados primeiro pelo número de iterações necessárias para atingir seu ponto de convergência e, em seguida, pela distância a esse ponto, com valores anteriores sendo atribuídos a uma cor mais luminosa.
Atualização: renderizações grandes de 4096 x 4096 , hospedadas em allrgb.com .
Um close do centro (tamanho real):
Um ponto de vista diferente usando estes valores:
E outro usando estes:
Por solicitação, compilei uma animação em zoom.
Ponto focal: ( 0.50051 , -0.50051 )
Fator de zoom: 2 1/5
O ponto focal é um valor um pouco estranho, porque eu não queria ampliar um ponto preto. O fator de zoom é escolhido de forma a dobrar a cada 5 quadros.
Um teaser de 32 x 32:
Uma versão de 256x256 pode ser vista aqui:
Pode haver pontos que aumentem matematicamente "sobre si mesmos", o que permitiria uma animação infinita. Se eu conseguir identificar algum, vou adicioná-lo aqui.
Finalmente um fractal :) Ame aqueles. Além disso, esse verde a 144 graus é a minha cor favorita (em oposição ao verde puro a 120 graus, o que é apenas chato).
Não sei, eu meio que gosto mais das versões do AllRGB; a necessidade de usar todo o espaço de luminância enfatiza muito bem os gradientes.
+1 Finalmente alguns bons fractais! O último é o meu favorito. Você deve fazer um vídeo ampliando! (@Quincunx: Viu a sua também, que teve o meu voto do dia 1!)
@JasonC Adicionei uma animação;)
@primo Eu sei que estou atrasado, mas eu só queria dizer que essas imagens são espetaculares.
Eu peguei essa idéia do algoritmo do usuário fejesjoco e queria jogar um pouco, então comecei a escrever meu próprio algoritmo do zero.
Estou publicando isso porque sinto que, se posso fazer algo melhor * do que o melhor de vocês, acho que esse desafio ainda não terminou. Para comparar, existem alguns designs impressionantes no allRGB que considero muito além do nível alcançado aqui e não tenho idéia de como eles fizeram isso.
*) ainda será decidido por votos
Comece com uma (poucas) sementes, com cores o mais próximo possível do preto.
Mantenha uma lista de todos os pixels não visitados e conectados a um ponto visitado.
Selecione um ponto aleatório ** nessa lista
Calcular a cor média de todos os pixels calculados [Editar ... em um quadrado 9x9 usando um kernel Gaussiano] 8 conectados a ele (esta é a razão pela qual parece tão suave) Se nenhum for encontrado, use preto.
em um cubo 3x3x3 em torno dessa cor, procure uma cor não utilizada.
Quando várias cores forem encontradas, escolha a mais escura.
Quando várias cores igualmente escuras forem encontradas, escolha uma aleatória.
Quando nada for encontrado, atualize o intervalo de pesquisa para 5x5x5, 7x7x7 etc. Repita de 5.
Traçar pixel, atualizar a lista e repetir a partir de 3
Também experimentei diferentes probabilidades de escolher pontos candidatos com base na contagem de quantos vizinhos visitados o pixel selecionado possui, mas apenas diminuiu a velocidade do algoritmo sem torná-lo mais bonito. O algoritmo atual não usa probabilidades e escolhe um ponto aleatório da lista. Isso faz com que pontos com muitos vizinhos sejam preenchidos rapidamente, tornando-se apenas uma bola sólida em crescimento com uma borda difusa. Isso também evita a indisponibilidade de cores vizinhas se as fendas forem preenchidas posteriormente no processo.
A imagem é toroidal.
Download: com.digitalmodularbiblioteca
1 semente original
lado a lado para 1920 × 1080 desktop
negativo no photoshop
40 sementes aleatórias
As estrias ficam significativamente mais nítidas (pois parecem que podem cortar um peixe em sashimi)
Parecia que terminou em 20 minutos, mas ... não conseguiu terminar por algum motivo, agora estou executando 7 instâncias em paralelo durante a noite.
** Descobri que meu método de escolha de pixels não era totalmente aleatório. Eu pensei que ter uma permutação aleatória do espaço de pesquisa seria aleatório e mais rápido que o aleatório real (porque um ponto não será escolhido duas vezes por acaso. No entanto, de alguma forma, substituindo-o por um aleatório real, eu sempre recebo mais manchas de ruído na minha imagem.
[código da versão 2 removido porque eu estava acima do limite de 30.000 caracteres]
Aumento do cubo de pesquisa inicial para 5x5x5
Ainda maior, 9x9x9
Acidente 1. Desabilitou a permutação para que o espaço de pesquisa seja sempre linear.
Acidente 2. Tentei uma nova técnica de pesquisa usando uma fila do fifo. Ainda tenho que analisar isso, mas achei que valia a pena compartilhar.
Sempre escolhendo dentro de X pixels não utilizados do centro
X varia de 0 a 8192 em etapas de 256
A imagem não pode ser carregada: "Ops! Algo ruim aconteceu! Não é você, somos nós. A culpa é nossa." A imagem é grande demais para imgur. Tentando em outro lugar ...
Experimentei um pacote do agendador que encontrei na digitalmodularbiblioteca para determinar a ordem em que os pixels são manipulados (em vez de difusão).
Flor (5, X), em que X varia de 0,5 a 20 nas etapas de X = X × 1,2
Espiral (X), em que X varia de 0,1 a 200 nas etapas de X = X × 1,2
Você pode ver que ele varia entre Radial e Angular (5)
Nova comida para os olhos
Efeito da seleção de cores por max(r, g, b)
Efeito da seleção de cores por min(r, g, b)
Observe que este possui exatamente os mesmos recursos / detalhes que o acima, apenas com cores diferentes! (mesma semente aleatória)
Efeito da seleção de cores por max(r, min(g, b))
Efeito da seleção de cores pelo valor de cinza 299*r + 436*g + 114*b
Efeito da seleção de cores por 1*r + 10*g + 100*b
Efeito da seleção de cores por 100*r + 10*g + 1*b
Acidentes felizes quando 299*r + 436*g + 114*bsobrecarregados em um número inteiro de 32 bits
Variante 3, com valor cinza e agendador radial
Eu esqueci como eu criei isso
O CRT Scheduler também teve um feliz erro de excesso de número inteiro (atualizou o ZIP), o que fez com que ele iniciasse no meio do caminho, com imagens 512 × 512, em vez de no centro. É assim que deve parecer:
InverseSpiralScheduler(64) (Novo)
Outro XOR
Primeira renderização 4096 bem-sucedida após a correção do bug. Eu acho que esta era a versão 3 SpiralScheduler(1)ou algo assim
(50MB !!)
Versão 1 4096, mas deixei acidentalmente os critérios de cores em max()
4096, agora com min()
Tempo: esqueceu de gravá-lo, mas o registro de data e hora do arquivo é de 3 minutos após a imagem antes
Legal. Sua imagem final é semelhante a uma segunda idéia que eu tenho divulgado, embora eu tenha a sensação de que a minha não será tão boa quanto isso. BTW, existe um interessante similar em allrgb.com/diffusive .
Era para ser apenas um teaser, mas eu editei com medo de ser sinalizado, o que aparentemente aconteceu :)
Até os acidentes parecem agradáveis ​​:). O cubo de cores parece uma ótima ideia e as velocidades de renderização são incríveis, comparadas às minhas. Alguns designs no allrgb têm uma boa descrição, por exemplo, allrgb.com/dla. Eu gostaria de ter mais tempo para fazer mais experimentos, há tantas possibilidades ...
Eu quase esqueci, acabei de enviar algumas das minhas grandes renderizações. Eu acho que um deles, a fumaça do arco-íris / tinta derramada, é melhor do que qualquer coisa no allrgb :). Eu concordo, os outros não são tão impressionantes, é por isso que eu fiz um vídeo para fazer algo mais com eles :).
— 22714
Adicionado código fonte eo link para a biblioteca Digisoft, assim você pode realmente compilar meu código
C ++ com Qt
Eu vejo você versão:
usando distribuição normal para as cores:
ou primeiro classificados por vermelho / matiz (com um desvio menor):
ou algumas outras distribuições:
Distribuição Cauchy (hsl / vermelho):
colunas classificadas por leveza (hsl):
código fonte atualizado - produz a 6ª imagem:
Bem feito. No entanto, pode não image.pixel(x, y) == 0falhar e substituir o primeiro pixel colocado?
@ Zom-B: ele pode, mas, em seguida, o último será preto, por isso é dentro das regras ..
Nenhum problema de regra embora. Eu apenas pensei que você poderia ter perdido. Também pode contar a partir de 1. Eu amo seus outros!
@ Zom-B: obrigado, devo adicionar mais alguns, eu meio que gosto: P
Aquele com dois círculos e o que está abaixo, juntos, parecem uma cara de macaco.
e uma imagem de entrada:
Eu gero algo como isto:
versão não compactada aqui: https://www.mediafire.com/?7g3fetvaqhoqgh8
O computador demora aproximadamente 30 minutos para fazer uma imagem 4096 ^ 2, o que é uma grande melhoria nos 32 dias que minha primeira implementação levaria.
ai; 32 dias não funcionavam soou engraçado ..... o algoritmo da média em fejesjocos responder em 4k antes de otimizar teria tomado provavelmente vários meses
Eu amo as sobrancelhas punk dele!
Java com BubbleSort
(geralmente o Bubblesort não gosta muito disso, mas, para esse desafio, finalmente foi útil) gerou uma linha com todos os elementos em 4096 passos separados e depois a embaralhou; a classificação passou e cada um recebeu 1 adicionado ao seu valor enquanto estava sendo classificado; assim, você obteve os valores classificados e todas as cores
Atualizado o código fonte para remover essas listras grandes
(é necessário um pouco de mágica em bits: P)
Já existe uma versão do QuickSort na página allRGB.
@ Zom-B Quicksort é um algoritmo diferente do que Bubblesort
Cria um vórtice, por razões que não compreendo, com quadros pares e ímpares contendo vórtices completamente diferentes.
Essa é uma prévia dos 50 primeiros quadros ímpares:
Imagem de amostra convertida do PPM para demonstrar a cobertura de cores completa:
Mais tarde, quando tudo estiver misturado ao cinza, você ainda poderá vê-lo girando: sequência mais longa .
Código da seguinte maneira. Para executar, inclua o número do quadro, por exemplo:
Usei isso para obter um GIF animado:
converte o atraso 10 `ls * .ppm | classificar -n | xargs` -loop 0 vortex.gif
Você sabe que é C quando as coisas acontecem por "razões que eu não entendo".
Sim, geralmente eu sei o que esperar, mas aqui estava eu ​​apenas brincando para ver que padrões eu poderia obter, e essa sequência interminável de ordem dentro do caos surgiu.
Agita no vórtice porque a sua função de comparação não segue a desigualdade do triângulo. Por exemplo, r> b, b> g, g> r. Eu não posso nem portá-lo para Java porque o mergesort depende dessa propriedade, então recebo a exceção "O método de comparação viola seu contrato geral!"
Vou tentar, p->b * 6 - q->g;mas se destruir o vórtice, não o consertará!
+1 por razões que não compreendo.
Variações de um seletor de cores em 512x512. Código elegante, não é , mas eu gosto das fotos bonitas:
Como está escrito, ele gera:
Se você executá-lo shuffle_block = true, ele embaralha as cores em cada bloco de 64x64:
Senão, se você executá-lo shuffle_radius > 0, ele embaralha cada pixel com um pixel aleatório shuffle_radiusem x / y. Depois de jogar com vários tamanhos, gosto de um raio de 32 pixels, pois desfoca as linhas sem mover muito as coisas:
ooh estas imagens são o mais bonito
Estes são realmente grande 😍
Estou apenas começando com C (tendo programado em outros idiomas), mas achei os gráficos no Visual C difíceis de seguir, então baixei este programa de processamento usado pelo @ace.
Aqui está o meu código e meu algoritmo.
Comece com quadrados 4x4 de todas as combinações possíveis de 32 valores de verde e azul, em x, y. formato, criando um quadrado de 128x128 Cada quadrado de 4x4 possui 16 pixels, então faça uma imagem espelhada ao lado para fornecer 32 pixels de cada combinação possível de verde e azul, conforme a imagem abaixo.
(estranhamente, o verde inteiro parece mais brilhante que o ciano completo. Isso deve ser uma ilusão de ótica. esclarecido nos comentários)
No quadrado esquerdo, adicione os valores vermelhos 0-15. Para o quadrado da direita, XOR esses valores com 16, para tornar os valores 16-31.
Saída 256x128
Isso fornece a saída na imagem superior abaixo.
No entanto, todo pixel difere da imagem no espelho apenas no bit mais significativo do valor em vermelho. Portanto, posso aplicar uma condição com a variável c, para reverter o XOR, que tem o mesmo efeito que a troca desses dois pixels.
Um exemplo disso é dado na imagem inferior abaixo (se descomentarmos a linha de código que está atualmente comentada).
512 x 512 - uma homenagem a Marylin de Andy Warhol
Inspirado pela resposta de Quincunx a essa pergunta com um "sorriso maligno" em círculos vermelhos à mão livre, aqui está minha versão da famosa foto. Na verdade, o original tinha 25 Marylins coloridos e 25 Marylins preto e branco e foi o tributo de Warhol a Marylin após sua morte prematura. Veja http://en.wikipedia.org/wiki/Marilyn_Diptych
Alterei para funções diferentes depois de descobrir que o Processing processa as que usei em 256x128 como semitransparentes. Os novos são opacos.
E embora a imagem não seja completamente algorítmica, eu gosto bastante.
512x512 Crepúsculo sobre um lago com montanhas ao longe
Aqui, uma imagem totalmente algorítmica. Eu brinquei com a mudança da cor que modulo com a condição, mas volto à conclusão de que o vermelho funciona melhor. Semelhante à imagem de Marylin, eu primeiro desenho as montanhas e depois escolho o brilho dessa imagem para substituir a imagem RGB positiva, enquanto copio para a metade negativa. Uma pequena diferença é que o fundo de muitas montanhas (porque todas são desenhadas do mesmo tamanho) se estende abaixo da área de leitura; portanto, essa área é simplesmente cortada durante o processo de leitura (o que, portanto, dá a impressão desejada de montanhas de tamanhos diferentes. )
Neste uso uma célula 8x4 de 32 vermelhos para o positivo e os 32 vermelhos restantes para o negativo.
Observe o comando expicit frameRate (1) no final do meu código. Descobri que, sem esse comando, o Processing usaria 100% de um núcleo da minha CPU, mesmo que tivesse terminado o desenho. Pelo que sei, não há função Sleep, tudo o que você pode fazer é reduzir a frequência das pesquisas.
Porque não é totalmente ciano. É (0,217,217). Todas as 32 combinações estão presentes, mas não são esticadas [0,255]. Editar: você está usando as etapas 7, mas não consigo encontrar isso no código. Deve ser uma coisa de processamento.
@steveverrill No processamento, você pode save("filename.png")salvar o buffer de quadro atual em uma imagem. Outros formatos de imagem também são suportados. Isso poupará o trabalho de tirar screenshots. A imagem é salva na pasta do esboço.
@ Jasonc obrigado pela dica, eu tinha certeza de que deveria haver um caminho, mas acho que não vou editá-los. Deixei o quadro ao redor das imagens parcialmente para separá-las (2 arquivos para imagens tão pequenas foram um exagero.) Quero fazer algumas imagens em 512x512 (e há uma em particular para a qual tenho uma ideia), para que eu as carregue no caminho você sugere.
@steveverrill Haha, os Warhols são um toque agradável.
O @ Zom-B Processing parece fazer muitas coisas que (irritantemente) não são mencionadas em sua documentação: não usar os 256 valores lógicos completos do canal de cores em sua saída física, misturar cores quando você não quiser, usando um núcleo completo de minha CPU mesmo depois de terminar o desenho. Ainda é simples para entrar e você pode contornar esses problemas quando você sabe que eles estão lá (exceto o primeiro, eu não resolvidos que ainda ...)
— Rio Nível St
Acabei de organizar todas as cores de 16 bits (5r, 6g, 5b) em uma curva de Hilbert em JavaScript.
Imagem anterior (não curva de Hilbert):
Edit : Acontece que houve um erro na minha função para calcular a curva de Hilbert e estava incorreto; ou seja, r.x = (p.x & s) > 0; r.y = (p.y & s) > 0;alterado parar.x = (p.x & s) > 0 ? 1 : 0; r.y = (p.y & s) > 0 ? 1 : 0;
Edit 2: Outro fractal:
Agradável! Bem-vindo ao PPCG.
— Jonathan Van Matre 03/03
Como é quando a caminhada pelo cubo de cores também faz uma curva de Hilbert 3D? Edite nm. alguém fez exatamente isso.
C #: otimização de similaridade local iterativa
Primeiro, começamos com um aleatório aleatório:
Em seguida, selecionamos aleatoriamente dois pixels e os trocamos. Se isso não aumentar a semelhança dos pixels com os vizinhos, trocamos de volta e tentamos novamente. Repetimos esse processo repetidamente.
Depois de apenas algumas gerações (5000), as diferenças não são tão óbvias ...
Mas quanto mais tempo ele for executado (25000), ...
... os padrões mais certos começam a surgir (100000).
Usando definições diferentes para vizinhança , podemos influenciar esses padrões e se eles são estáveis ​​ou não. A Kernelmatriz é semelhante à usada para filtros no processamento de imagens . Ele especifica os pesos de cada vizinho usado para o cálculo do delta RGB.
Aqui estão alguns dos resultados que eu criei. Os vídeos mostram o processo iterativo (1 quadro == 1000 gerações), mas infelizmente a qualidade não é a melhor (vimeo, YouTube etc. não suportam adequadamente dimensões tão pequenas). Mais tarde, posso tentar criar vídeos de melhor qualidade.
185000 gerações:
Vídeo (00:06)
243000 gerações:
Vídeo (00:07)
230000 gerações:
Este núcleo é interessante porque, devido à sua assimetria, os padrões não são estáveis ​​e toda a imagem se move para a direita à medida que as gerações passam.
2331000 gerações:
Vídeo (01:10)
Resultados grandes (512 x 512)
O uso dos kernels acima com uma dimensão de imagem maior cria os mesmos padrões locais, cobrindo uma área total maior. Uma imagem de 512x512 leva entre 1 e 2 milhões de gerações para se estabilizar.
OK, agora vamos falar sério e criar padrões maiores e menos locais com um kernel radial 15x15:
Isso aumenta drasticamente o tempo de computação por geração. 1,71 milhão de gerações e 20 horas depois:
Demora um pouco para chegar lá, mas o resultado final é bastante agradável.
— Primo4
Interessante coincidência, eu tenho um artigo sobre este mesmo tema: nayuki.io/page/simulated-annealing-demo
Com algumas variações na minha outra resposta, podemos obter resultados muito interessantes.
O código importante está aqui:
Saída (captura de tela):
Mude o comparador para isto:
E nós entendemos isso:
Ainda outra variação (me lembra autômatos celulares):
Ainda outra variação (novo favorito pessoal):
Parece tão fractal. XOR é tão bonito, especialmente closeup:
Outro close:
E agora o triângulo de Sierpinski, inclinado:
A primeira imagem parece uma foto de um dado de CPU ou memória
@NickT Aqui está um dado de memória (de acordo com o Google Images) para contraste: files.macbidouille.com/mbv2/news/news_05_10/25-nm-die.jpg
Direito, a memória é tão sem forma ... provavelmente um processador muito multi-core, então: extremetech.com/wp-content/uploads/2012/07/Aubrey_Isle_die.jpg
Eu realmente gosto desses últimos. De aparência muito arrogante, mas com uma estrutura organizacional subjacente. Eu quero um tapete tecido como esse design XOR!
Isso é muito legal; eles meio que me lembram um jogo de arcade quebrado ou um nes.
Na verdade, eu não tinha certeza de como criar cores de 15 ou 18 bits, então deixei o bit menos significativo do byte de cada canal para criar 2 ^ 18 cores diferentes de 24 bits. A maior parte do ruído é removida pela classificação, mas parece que a remoção eficaz do ruído exigiria comparação de mais do que apenas dois elementos por vez, como o Comparator. Vou tentar manipular usando kernels maiores, mas, enquanto isso, é o melhor que pude fazer.
Clique para a imagem HD # 2
Que segundo realmente merece ter uma versão de 24 bits 4096 x 4096 ...
Imgur processa a imagem há cerca de meia hora. Eu acho que provavelmente está tentando comprimir. De qualquer forma, eu adicionei um link: SSend.it/hj4ovh
Há um problema com o download.
I encomendar todas as cores, caminhando a 3-dimensional Curve Hilbert através de uma L-System . Passo os pixels na imagem de saída ao longo de uma Curva Hilbert bidimensional e esquematizo todas as cores.
Saída 512 x 512:
Aqui está o código. A maior parte cobre apenas a lógica e a matemática de se mover através de três dimensões via pitch / roll / yaw. Tenho certeza de que havia uma maneira melhor de fazer essa parte, mas tudo bem.
Uau, coisas muito legais neste desafio. Peguei isso em C # e gerei uma imagem de 4096x4096 em cerca de 3 minutos (CPU i7) usando todas as cores através da lógica Random Walk.
Ok, então o código. Depois de ficar frustrado com horas de pesquisa e tentar gerar todas as cores HSL usando loops de código, resolvi criar um arquivo simples para ler as cores HSL. O que eu fiz foi criar todas as cores RGB em uma lista, e então pedi por Hue, Luminosity e depois Saturation. Depois salvei a lista em um arquivo de texto. ColorData é apenas uma classe pequena que escrevi que aceita uma cor RGB e também armazena o equivalente a HSL. Este código é um comedor de RAM ENORME. Usado cerca de 4GB de RAM lol.
Com isso fora do caminho. Eu escrevi uma classe para obter a próxima cor do arquivo gerado. Permite definir o início e o final do matiz. Na realidade, isso poderia e provavelmente deveria ser generalizado para qualquer dimensão em que o arquivo fosse classificado primeiro. Também percebo que, para melhorar o desempenho aqui, eu poderia apenas colocar os valores RGB no arquivo e manter cada linha em um comprimento fixo. Dessa forma, eu poderia facilmente especificar o deslocamento de bytes, em vez de percorrer todas as linhas até chegar à linha em que queria começar. Mas não foi um grande sucesso para mim. Mas aqui está essa classe
Então, agora que temos o arquivo colorido e temos uma maneira de ler o arquivo, agora podemos criar a imagem. Usei uma classe que encontrei para aumentar o desempenho da configuração de pixels em um bitmap, chamado LockBitmap. Origem LockBitmap
Criei uma pequena classe Vector2 para armazenar localizações de coordenadas
E também criei uma classe chamada SearchArea, que foi útil para encontrar pixels vizinhos. Você especifica o pixel para o qual deseja encontrar vizinhos, os limites a serem pesquisados ​​e o tamanho do "quadrado vizinho" a ser pesquisado. Portanto, se o tamanho for 3, significa que você está pesquisando um quadrado de 3x3, com o pixel especificado bem no centro.
Aqui está a turma que realmente escolhe o próximo vizinho. Basicamente, existem 2 modos de pesquisa. A) O quadrado inteiro, B) apenas o perímetro do quadrado. Essa foi uma otimização que eu fiz para impedir a pesquisa no quadrado inteiro novamente depois de perceber que o quadrado estava cheio. O DepthMap era uma otimização adicional para impedir a busca repetida nos mesmos quadrados. No entanto, não otimizei totalmente isso. Todas as chamadas para GetNeighbors sempre fazem a pesquisa completa em primeiro lugar. Eu sei que poderia otimizar isso para fazer apenas a pesquisa de perímetro depois de concluir o quadrado completo inicial. Ainda não cheguei a essa otimização e, mesmo sem ela, o código é bem rápido. As linhas de "bloqueio" comentadas são porque eu estava usando Parallel.ForEach em um ponto, mas percebi que tinha que escrever mais código do que queria para esse lol.
Ok, ótimo. Agora, aqui está a classe que cria a imagem
E aqui está um exemplo de implementação:
Se RandomWalkSegments = 1, basicamente ele simplesmente começa a andar onde quer que você diga e começa na primeira primeira cor do arquivo.
Não é o código mais limpo que devo admitir, mas roda muito rápido!
Então, eu tenho aprendido sobre OpenGL e Shaders. Gerei 4096x4096 usando todas as cores rapidamente na GPU com 2 scripts simples de sombreamento. A saída é chata, mas achei que alguém poderia achar isso interessante e ter algumas ideias legais:
Editar (15/10/16): Só queria mostrar uma prova de conceito de um algoritmo genético. Ainda estou executando esse código 24 horas depois em um conjunto de 100x100 de cores aleatórias, mas até agora a saída é linda!
Editar (26/10/16): Estou executando o código do algoritmo genético há 12 dias ... e ainda está otimizando a saída. Basicamente, convergiu para algum mínimo local, mas aparentemente está encontrando mais melhorias ainda:
Edit: 12/8/17 - Eu escrevi um novo algoritmo de caminhada aleatória - basicamente, você especifica um número de "caminhantes", mas em vez de andar aleatoriamente - eles escolhem outro caminhante aleatoriamente e evitam-nos (escolha o próximo pixel disponível mais distante ) - ou caminhe em direção a eles (escolha o próximo pixel disponível mais próximo a eles). Um exemplo de saída em escala de cinza está aqui (executarei uma renderização em cores completa de 4096 x 4096 depois de ligar a coloração!):
Um pouco atrasado, mas bem-vindo ao PPCG! Este é um excelente primeiro post.
Obrigado! Estou ansioso para completar mais desafios! Eu tenho feito mais coisas imagem codificação ultimamente, é o meu novo hobby
Uau, isso é incrível; Estou feliz por ter voltado a este post hoje e verificado todas as coisas posteriores.
Obrigado! Na verdade, estou fazendo algum algoritmo genético de codificação agora para produzir gradientes interessantes. Basicamente, pegue 10.000 cores, formando uma grade 100x100. Para cada pixel, obtenha os pixels vizinhos. Para cada um, obtenha a distância CIEDE2000. Resuma isso. Resuma isso para todos os 10000 pixels. O algoritmo genético tenta reduzir essa soma total. Sua lento, mas para uma imagem de 20x20 sua saída é realmente interessante
Eu amo especialmente a saída desta solução.
— r_alex_hall 24/09
Tela HTML5 + JavaScript
Eu chamo isso de randoGraph e você pode criar quantos quiser aqui
Por exemplo, no Firefox, você pode clicar com o botão direito do mouse na tela (quando terminar) e salvá-la como imagem. Produzir uma imagem de 4096 x 4096 é um tipo de problema devido ao limite de memória de alguns navegadores.
A ideia é bastante simples, mas cada imagem é única. Primeiro, criamos a paleta de cores. Então, começando por X pontos, selecionamos cores aleatórias da paleta e posições para elas (cada vez que selecionamos uma cor, a excluímos da paleta) e registramos onde colocamos para não colocar na mesma posição no próximo pixel.
Para cada pixel tangente a isso, criamos um número (X) de cores possíveis e, em seguida, selecionamos as mais relevantes para esse pixel. Isso continua até que a imagem esteja completa.
E o JavaScript para randoGraph.js
Isso é legal, mas parece que a resposta em C # do fejesjoco . É apenas por acaso?
Os algoritmos estão aqui e qualquer um pode ler e entender que é realmente diferente. Esta resposta publicada após a resposta em C # de fejesjoco declarada como vencedora motivada por quão bom é seu resultado. Então pensei em uma abordagem totalmente diferente de processar e selecionar cores vizinhas, e é isso. É claro que ambas as respostas têm a mesma base, como a distribuição uniforme das cores usadas ao longo do espectro visível, o conceito de cores relevantes e os pontos de partida, talvez seguindo essa base. Alguém poderia pensar que as imagens produzidas têm semelhança em alguns casos.
Ok, desculpe se você pensou que eu estava criticando sua resposta. Eu apenas me perguntei se você foi inspirado pela resposta de fejesjoco, já que a saída resultante é semelhante.
"Definir métodos de uma classe dentro do construtor, em vez de usar a cadeia de protótipos, é realmente ineficiente, especialmente se essa classe for usada várias vezes." É um comentário muito interessante Patrick Roberts. Você tem alguma referência com o exemplo que valida isso? , Sinceramente, gostaria de saber se essa reivindicação tem alguma base (para parar de usá-la) e o que é.
Quanto ao uso do protótipo: ele funciona da mesma maneira que um método estático. Quando você tem a função definida no literal do objeto, todo novo objeto criado também deve criar uma nova cópia da função e armazená-los com essa instância do objeto (portanto, 16 milhões de objetos coloridos significam 16 milhões de cópias dessa mesma função exatamente em memória). Em comparação, o uso do protótipo o criará apenas uma vez, para ser associado à "classe" e não ao objeto. Isso tem benefícios óbvios de memória, além de potenciais benefícios de velocidade.
Então, aqui está minha solução em python, leva quase uma hora para criar uma, então provavelmente há alguma otimização a ser feita:
Aqui estão alguns exemplos de saídas:
Parece que algumas formas de onda parecer loucura
Eu decidi tentar este desafio. Eu fui inspirado por esta resposta a outro código de golfe. Meu programa gera imagens mais feias, mas elas têm todas as cores.
Além disso, minha primeira vez código de golfe. :)
(As imagens em 4k eram muito grandes para minha pequena velocidade de upload, tentei fazer upload de uma, mas após uma hora ela não foi carregada. Você pode gerar suas próprias.)
Fechar-se:
Gera uma imagem em 70 segundos na minha máquina, consome cerca de 1,5 GB de memória ao gerar
Resultado (2x):
Imagem original de 256 x 128
substituindo o Log10 [i] pelo Log10 [i] / 5, você obtém:
O código acima está relacionado ao recozimento simulado. Visto dessa maneira, a segunda imagem é criada com uma "temperatura" mais alta nas primeiras 10 ^ 6 etapas. A "temperatura" mais alta causa mais permutações entre os pixels, enquanto na primeira imagem a estrutura da imagem ordenada ainda é um pouco visível.
Ainda estudante e minha primeira postagem, então meus códigos provavelmente estão confusos e não tenho 100% de certeza de que minhas fotos têm todas as cores necessárias, mas eu fiquei super feliz com meus resultados, então achei que as postaria.
Eu sei que o concurso acabou, mas eu realmente amei os resultados e sempre gostei do visual dos labirintos gerados de retorno recursivo, então achei que seria legal ver como seria se ele colocasse pixels coloridos. Então, começo gerando todas as cores em uma matriz e, em seguida, faço o retorno recursivo enquanto retiro as cores da matriz.
Aqui está o meu JSFiddle http://jsfiddle.net/Kuligoawesome/3VsCu/
Imagem de 256x128, cores ordenadas em vermelho-> verde-> azul
Imagem de 256x128, cores ordenadas em azul-> verde-> vermelho
Imagem de 256x128, cores ordenadas matiz-> luminância-> saturação
E, finalmente, um GIF de um sendo gerado
Suas cores são cortadas nas regiões mais brilhantes, causando duplicatas. Mudar r * Math.ceil(255 / (colorSteps - 1)para r * Math.floor(255 / (colorSteps - 1), ou melhor ainda: r * 255 / (colorSteps - 1)(não testado, desde que você não fornecer uma jsFiddle)
Opa, sim, eu tinha um pressentimento que causaria problemas, espero que esteja consertado agora, e desculpe pela falta de jsfiddle (eu não sabia que existia!) Obrigado!
Eu amo a saída ordenada de caos / ruído desta e de outra solução que produz uma saída semelhante.
Então eu comecei a trabalhar nisso apenas como um exercício divertido e acabei com uma saída que, pelo menos para mim, parece bem legal. A principal diferença na minha solução para (pelo menos) a maioria das outras é que estou gerando exatamente o número de cores necessárias para começar e espaçando a geração de branco puro para preto puro. Também estou definindo cores trabalhando em uma espiral interna e escolhendo a próxima cor com base na média da diferença de cores entre todos os vizinhos que foram definidos.
Aqui está uma pequena amostra de saída que eu produzi até agora. Estou trabalhando em uma renderização em 4K, mas espero que demore mais de um dia para terminar.
Aqui está um exemplo da saída de especificação em 256x128:
Algumas imagens maiores com tempos de renderização ainda razoáveis:
A segunda execução a 360 x 240 produziu uma imagem muito mais suave
Depois de melhorar o desempenho, consegui executar uma renderização em HD que levou dois dias, ainda não desisti de um 4K, mas isso pode levar semanas.
Renderização em HD
Se alguém tiver alguma idéia de como melhorar o desempenho do algoritmo de seleção de cores, entre em contato, pois as renderizações 360 * 240 demoram cerca de 15 minutos. Não acredito que possa ser paralelo, mas me pergunto se haveria uma maneira mais rápida de obter a menor diferença de cores.
Como uma imagem de 360 ​​* 240 constitui 'todas as cores'? Como você está produzindo cbrt (360 * 240) = 44,208377983684639269357874002958 cores por componente?
Que língua é essa? Aleatorizar uma classificação de lista e Aleatório é uma má idéia, independentemente, porque dependendo do algoritmo e implementação, pode causar um resultado tendencioso ou uma exceção declarando isso "Comparison method violates its general contract!": porque o contrato declara isso (x.compareTo(y)>0 && y.compareTo(z)>0) implies x.compareTo(z)>0. Para randomizar uma lista, use o método Shuffle fornecido. ( colors.Shuffle()?)
@ MarkJeronimus Admito que perdi as especificações sobre a imagem de 256x128, farei as renderizações simples usando esses tamanhos, estava focado em cada pixel é um aspecto de cor exclusivo do desafio e em renderizações maiores, como outros envios.
@ MarkJeronimus Eu sei que o tipo aleatório é ruim, na verdade há um comentário dizendo isso. Este foi apenas um remanescente de outra abordagem que comecei a adotar e priorizava a realização de grandes renderizações, pois demoravam muito tempo.
Aqui está outro, acho que dá resultados mais interessantes:
Começa com o mesmo padrão que o gif na minha outra resposta . Em seguida, embaralha-o para o seguinte:
Quanto mais iterações eu executo o algoritmo de comparação de vizinhos não inspirado, mais aparente o padrão do arco-íris se torna.
Aqui está 16384:
E 65536:
+1 Eu gosto que um padrão emerge disso; você deve fazer uma animação disso!
Estas imagens são "arco-íris de Langton". Eles são desenhados de maneira bem simples: à medida que a formiga de Langton se move, uma cor é desenhada em cada pixel na primeira vez que o pixel é visitado. A cor a desenhar em seguida é simplesmente incrementada em 1, garantindo que sejam usadas 2 ^ 15 cores, uma para cada pixel.
EDIT: Criei uma versão que renderiza imagens 4096X4096, usando 2 ^ 24 cores. As cores também são 'refletidas', de modo a criar gradientes agradáveis ​​e suaves. Fornecerei links apenas para eles, pois eles são enormes (> 28 MB)
Arco-íris de Langton grande, regra LR
Arco-íris de Langton grande, regra LLRR
// Fim da edição.
Isto para o conjunto de regras LR clássico:
Aqui está o LLRR:
Por fim, este usa o conjunto de regras LRRRRRLLR:
Escrito em C ++, usando CImg para gráficos. Também devo mencionar como as cores foram selecionadas: Primeiro, uso um atalho não assinado para conter os dados de cores RGB. Toda vez que uma célula é visitada pela primeira vez, desloco os bits à direita por alguns múltiplos de 5, E por 31, e multiplico por 8. Em seguida, a cor curta não assinada é incrementada em 1. Isso produz valores de 0 a 248, no máximo. No entanto, subtraí esse valor de 255 nos componentes vermelho e azul; portanto, R e B estão em múltiplos de 8, a partir de 255, até 7:
No entanto, isso não se aplica ao componente verde, que é múltiplo de 8 de 0 a 248. De qualquer forma, cada pixel deve conter uma cor única.
De qualquer forma, o código fonte está abaixo:
Bem-vindo e faça parte do clube. Talvez seja interessante tentar outros turmites de code.google.com/p/ruletablerepository/wiki/... (I participaram dessa)
Os links de imagem estão inoperantes porque o Dropbox matou as Pastas Públicas.
Decidi ir em frente e criar o PNG do zero, porque achei que seria interessante. Esse código está literalmente emitindo a matéria prima dados binários em um arquivo.
Eu fiz a versão de 512x512. (O algoritmo é bastante desinteressante.) Ele termina em cerca de 3 segundos na minha máquina.
Saída (pol all_colors.png) (clique em qualquer uma dessas imagens para ampliá-las):
Saída gradiente-ish um pouco mais interessante (alterando a quarta para a última linha para }.shuffle }):
E alterando para }.shuffle }.shuffle, você obtém linhas de cores malucas:
Isso é muito legal. Existe uma maneira de torná-lo mais bonito? Talvez randomize os pixels? Scoring is by vote. Vote for the most beautiful images made by the most elegant code.
@LowerClassOverflowian Ok, editado
— Maçaneta da
Muito melhor!!!!!!!
O que acontecerá se você alterou a quarta para a última linha para }.shuffle }.shuffle }.shuffle ?
— John Odom 26/02
@ John Erm, erro de sintaxe, provavelmente?
Usando python para classificar as cores por luminância, gerando um padrão de luminância e escolhendo a cor mais apropriada. Os pixels são iterados em ordem aleatória, para que a luminância menos favorável corresponda ao que ocorre naturalmente quando a lista de cores disponíveis fica menor e distribuída uniformemente pela imagem.
Eu fui para 4096 por 4096 porque não conseguia descobrir como obter todas as cores sem fazê-lo.
Grande demais para caber aqui. Esta é uma captura de tela:
Com uma pequena alteração, podemos obter uma imagem mais bonita:
Adicione Collections.shuffle(points, new Random(0));entre gerar os pontos e fazer as cores:
Você chama uma grande bolha cinza de "linda"?
@Doorknob Sim. Eu chamo de muito bonito. Acho incrível que todas as cores possam ser organizadas em uma grande bolha cinza. Eu acho o blob mais interessante quando amplio o zoom. Com um pouco mais de detalhes, você pode ver como o rng do Java é aleatório. Quando aumentamos ainda mais o zoom, como na segunda captura de tela, fica claro quantas cores há nessa coisa. Quando amplio ainda mais, parece um programa Piet.
— 2626 Justin justin
Consegui as cores em versões menores, largando os bits mais baixos.
Sim, os bits mais baixos para r, ge bseparadamente, mas eu estava lidando com eles como um número.
— 2626 Justin
Vejo que você descobriu o b1t magicz na sua próxima resposta. No tópico, pode ser interessante experimentar sua própria Randomsubclasse que produz números aleatórios ainda menos ideais.
( Atualização: somente depois percebi que uma abordagem semelhante já havia sido tentada - com mais paciência em relação ao número de iterações.)
Para cada pixel, defino um conjunto de pixels vizinhos. Defino a discrepância entre dois pixels para ser a soma dos quadrados de suas diferenças de R / G / B. A penalidade de um determinado pixel é então a soma das discrepâncias entre o pixel e seus vizinhos.
Agora, primeiro giro uma permutação aleatória e começo a escolher pares aleatórios de pixels. Se a troca dos dois pixels reduzir a soma das multas totais de todos os pixels, a troca será realizada. Repito isso um milhão de vezes.
A saída está no formato PPM, que converti em PNG usando utilitários padrão.
Variando o passo dos vizinhos dá resultados diferentes. Isso pode ser ajustado na função Image :: pixelNeighbors (). O código inclui exemplos para quatro opções: (consulte a fonte)
Edit: outro exemplo semelhante ao quarto acima, mas com um kernel maior e mais iterações:
Mais um: usando
e dez milhões de iterações, obtive o seguinte:
Não é o código mais elegante, mas interessante em dois aspectos: calcular o número de cores a partir das dimensões (contanto que o produto das dimensões seja uma potência de duas) e fazer coisas espaciais no espaço de cores:
Algumas variações interessantes podem ser encontradas apenas alterando a cláusula OrderBy:
Eu gostaria de descobrir o que estava causando as linhas ímpares nos três primeiros
Essas linhas ímpares são, provavelmente, o viés de algum tipo ou método look-up (binary search / quicksort?)
Na verdade, eu realmente gosto das falas aqui.
Essa foi uma ideia muito melhor. Este é um código Java muito curto; o método principal tem apenas 13 linhas:
Gera blocos de "seletores de cores". Basicamente, no primeiro bloco, r=0no segundo r=1, etc. Em cada bloco, gincrementos em relação a xe bem relação ay .
Eu realmente gosto de operadores bit a bit. Deixe-me detalhar a setRGBdeclaração:
Como resultado dos operadores bit a bit, isso leva apenas 7 segundos para ser concluído. Se o r & 15for substituído r % 16, leva 9 segundos.
Eu escolhi o 4096 x 4096
Saída (captura de tela, grande demais caso contrário):
Saída com sorriso maligno desenhado por círculos à mão livre-vermelho:
Link para o original para que eu possa verificar o válido até (contagem cores)
Ri muito! Esqueci que posso executar o código Java. A primeira imagem passa, e eu não posso reproduzir o ☺ segunda imagem (lol)