Y a-t-il une meilleure façon que de les examiner pixel par pixel?
3 Réponses :
Si vous avez besoin d'une réponse précise, non. Si vous avez besoin d'une approximation, vous pouvez probablement vérifier une sélection de pixels. Mais si vous souhaitez savoir si les deux bitmaps sont exactement identiques, vous devez comparer toutes les données de format pixel et pixel.
Vous pouvez enregistrer à la fois des bitmaps à tmemorysrstream et comparer à l'aide de CompeMemem: Je n'ai pas compris ce code x Scanline, si vous le faites, veuillez nous faire savoir lequel est le plus rapide.
Quelques commentaires: 1) Le code n'est pas sûr d'exception. 2) J'y retournerais immédiatement si la largeur ou la hauteur des bitmaps diffèrent. Ou peut-être même si les formats de pixels diffèrent, mais la question est trop vague à raconter.
Belles commentaires mcghie. Je changerai le code pour tester la hauteur et la largeur.
Je ne pense pas que je puisse "permettre" d'autres d'éditer mes messages, si je peux, s'il vous plaît laissez-moi savoir comment. Si vous postez ici vos suggestions, je peux éditer et mentionner dans mon message.
Je viens de l'éditer, mais je voulais vous alerter avant. +1 pour la réponse BTW.
Merci mghie. BTW, êtes-vous l'auteur de la flamerobine?
Eh bien, l'un d'entre eux. Ni l'auteur original ni le principal.
Le commentaire de Mghie ci-dessus demande si le format de pixel correspondant est une spécification, mais il est facile d'ajouter comme illustré dans la réponse de Rruz.
Strictement parlant, de tels comparons peuvent se tromper lorsque l'un des bitmaps a un peu déchets dans les octets d'alignement / bits entre les lignes. Par conséquent, nous comparons toujours les PixelData avec comparamemem sur une base de ligne.
Il serait également intéressant de le comparer à la carrelage en boucle. Voir un exemple pour faire pivoter à Stackoverflow.com/questions/848025/RoTating- Bitmaps-in-Code à l'époque, j'ai été assez surpris par le speed-up, mais cet exemple écrit également à une image.
Le débordement de la pile n'aurait pas fourni d'option pour les utilisateurs de modifier les réponses des autres utilisateurs s'il n'était pas autorisé. C'est en fait très encouragé.
Utilisation de Scanline, sans tmemorystream. BYE.
+1 très bien composé. Il serait intéressant de comparer la vitesse de cette solution de César. Cela a plus de comparaisons, mais économise du temps en n'allocie pas la mémoire. Le titre de la question a spécifié le plus rapide , après tout.
@Rruz: Je conviens que c'est une bonne solution si le même bitmap signifie la même mise en page de mémoire, +1. Je considérerais une vérification rapide des bitmaps égaux dans des formats éventuellement différents pour être un problème plus intéressant, cependant. Si un bitmap PF244BIT ou PF32BIT a moins de 256 couleurs, il peut être logique de l'enregistrer dans PF8bit, mais le même bitmap sera toujours affiché.
Je n'utilise généralement que pf8bit et pour cela, ce serait bien. Je me demande si si les bits d'alignement sont vérifiés si vous avez PF12bit et une largeur impairée. Même chose pour le BPP inférieur à 8, mais ceux-ci sont planifiés Afaik.
Veuillez préciser: S'ils ont des formats de pixels différents (par exemple PF24bit et PF8bit) et donc différentes tailles en mémoire, mais contiennent exactement les mêmes pixels, sont-ils identiques ou non?