Cette image a été créée en superposant 7 rectangles de couleurs différentes les uns sur les autres:
Les rectangles noirs et marron ne sont pas obstrués , c'est-à-dire qu'aucun autre rectangle n'est au-dessus d'eux.
Écrivez un programme qui prend une image comme celle-ci et supprimez tout rectangle non obstrué, en sortie l'image résultante.
Exemple
Si vous avez exécuté votre programme sur l'image ci-dessus et l'avez continué à relancer sur la sortie, il pourrait progresser comme ceci.
Piste 1 - Noir retiré (aurait pu être marron):
Run 2 - Maroon supprimé (seul choix):
Run 3 - Jaune retiré (seul choix):
Run 4 - Blue supprimé (aurait pu être vert):
Course 5 - Vert retiré (seul choix):
Run 6 - Brown enlevé (seul choix):
Run 7 - Red supprimé (seul choix):
Tout essai supplémentaire devrait produire la même image blanche.
J'espère que Stack Exchange n'a compressé aucune de ces images avec perte.
L'image aura toujours un fond blanc et chaque rectangle aura une couleur RVB unique qui n'est pas blanche.
Vous pouvez supposer que l'image peut toujours être interprétée comme un ensemble de rectangles se chevauchant. Plus précisément, vous pouvez supposer que, pour une couleur particulière, le pixel dont la couleur est la plus proche du haut de l'image fait partie du bord supérieur du rectangle de cette couleur. Il en va de même pour les bords inférieur, gauche et droit.
Ainsi, par exemple, dans cette image, le bord supérieur du rectangle rouge serait juste en dessous du bord inférieur du rectangle jaune, car le rectangle orange recouvrait l'ancien bord supérieur rouge:
Dans cette image, le rectangle rouge pourrait être supprimé en premier (avec le noir / marron / orange / gris):
Lorsque l'ordre des rectangles inférieurs est ambigu, vous pouvez leur donner n'importe quel ordre.
Par exemple, l'image de gauche ici pourrait devenir le milieu ou la droite:
La sortie ne doit pas avoir de chevauchements paradoxaux (donc la rendre possible avec l' algorithme du peintre devrait être possible). Donc dans cette image ( merci user23013 ), il faudrait que ce soit vert sous le rectangle orange:
Détails supplémentaires
- L'image et les rectangles peuvent avoir n'importe quelle dimension.
- Les rectangles peuvent toucher la bordure de l'image.
- Il peut y avoir jusqu'à 256 rectangles 3 - 1.
- Si l'entrée est entièrement blanche, la sortie devrait l'être également.
- Vous pouvez utiliser des bibliothèques d'images.
- L'entrée doit être le nom du fichier image ou les données d'image brutes. Il peut provenir de stdin ou de la ligne de commande.
- La sortie peut être écrite dans le même fichier ou dans un autre fichier image, rejetée crue dans stdout ou simplement affichée.
- Tout format de fichier d'image truecolor sans perte commun est autorisé.
La soumission avec le moins d'octets est gagnante.
la source
Réponses:
CJam, 241 octets
(avec les nouvelles lignes supprimées.)
Il utilise le format de fichier ppm. Exemple d'utilisation (en utilisant ImageMagick):
Eh bien, c'est trop long et trop lent ... Exécute environ une minute pour l'exemple.
J'ai redimensionné les cas de test (et ajouté quelques autres) pour faciliter les tests.
Il semble que les informations de l'espace colorimétrique soient perdues, les couleurs sont donc légèrement différentes.
la source
Python,
690651610606594569 octetsLe script lit le nom de l'image depuis stdin.
Il détecte les bords de tous les rectangles, les trie par le nombre de couleurs différentes qu'ils contiennent (les rectangles non obstrués ne contiennent qu'une seule couleur, puis apparaissent à la fin de la liste)
Cette liste est utilisée pour redessiner une image. L'ordre de redessin est décidé en choisissant la permutation de la liste qui générerait une image de sortie qui aurait le moins de différence de pixels avec l'entrée.
la source
Java - 1483 octets
Je ne suis pas un grand golfeur de code, que ce soit clair; donc la verbosité n'est pas entièrement la faute de Java ;-) Néanmoins, cela semblait être un défi vraiment amusant. Je l'ai résolu d'une manière qui - je pense - est un peu ennuyeuse et verbeuse, mais bon. Ça marche, c'est (relativement) rapide et surtout c'était amusant!
L'idée est la suivante: Vérifiez chaque pixel en partant du coin supérieur gauche jusqu'en bas à droite. Est-ce un pixel blanc? Ignorer. Est-il coloré? Cool, suivons-le et essayons de déterminer ses limites (en haut à gauche, en haut à droite, en bas à gauche, en bas à droite).
Une fois cela fait, vérifiez la zone de chaque rectangle. Contient-il une couleur différente de celle du rectangle? Découvrez ensuite quel rectangle appartient à cette couleur et mettez à jour l'index z de ce rectangle qui se chevauchent de 1.
Et enfin, dessinez tous les rectangles en tenant compte des z-indices. Cela fonctionne en fait comme un z-index que vous connaissez de CSS et d'autres trucs 3D. Les rectangles avec le z-index le plus bas sont dessinés en premier, le z-index le plus élevé en dernier.
Le code complet qui est un peu - et c'est un euphémisme ;-) - écrit plus clairement, peut être trouvé ici: http://pastebin.com/UjxUUXRp
De plus, maintenant que je vois la soumission de Dieter, j'aurais pu rendre certaines parties plus faciles. Il n'est pas vraiment nécessaire de trouver le rectangle dont la couleur chevauche un autre rectangle. Je pourrais en effet juste compter le nombre de couleurs «envahissantes».
la source