Хотя я бы повторил то, что сказал Ганс, я думаю, что вы можете сделать это, но CRC - плохой алгоритм для использования.
Вместо этого вы можете создать хэш MD5 байтов сгенерированного растрового изображения.По моим расчетам, ваши изображения должны быть размером не менее 2 КБ.Чтобы сгенерировать хеш, вы можете либо вычислить его по всему растровому изображению, либо вы можете быть хитрым и делать это для каждого n -го байта - что будет быстрее на стороне хеша, но, вероятно, будет тяжелее при использовании памяти, поскольку выВам придется извлечь эти байты в новый массив.
Если вы собираетесь пропустить каждый n-й байт, я бы использовал 4 или 2 - 4 означает, что вы читаете один компонент из каждого последовательного пикселя, используя два средствавы читаете два компонента из каждого последовательного пикселя.
Однако MD5 очень быстр * , и вы можете обнаружить (и я бы показал это в модульном тесте), что просто хэширование по всему растровому изображению будетБыстрее.
Единственное, что есть , я не могу понять, как вы можете заранее проверить, должен ли генерировать заданное растровое изображениене зная заранее, что это хеш, и единственный способ узнать, что это хеш, - генерировать его.В этом случае к этому моменту вы можете просто сохранить новое изображение.Дополнительный элемент в вашем массиве кэша изображений не нарушит вселенную.
Что вам действительно нужно сделать, чтобы реально сэкономить место и время запуска, это знать заранее, нужно ли создавать образэто будет так же, как другой.Учитывая, что эти изображения генерируются динамически, это тот случай, когда, когда генерируются два одинаковых изображения, они генерируются одним и тем же вызовом метода с одинаковыми параметрами?
Если это так, вы можете вместо этого взглянуть на тегирование каждого сгенерированногоimage с одним или несколькими хеш-кодами (используя object.GetHashCode()) для MethodInfo метода, который генерирует изображение (вы можете получить это внутри самого метода, вызвав MethodBase.GetCurrentMethod() вместе с каждым хеш-кодом для каждого параметра, который был передан вХеш-код для метода достаточно надежен, поскольку он использует дескриптор метода среды выполнения (который уникален для каждого метода) - единственное сжатие хеш-кода, которое может произойти, существует на 64-битных машинах, где дескриптор 64-битный, но хешкод 32. Однако на практике такое столкновение встречается редко, поскольку вам нужно иметь огромное количество кода в приложении, чтобы первые 32 бита двух отдельных дескрипторов метода были одинаковыми.
Хеш-коды отдельных параметров, конечно, гораздо меньшенадежный, если эти типы параметров не имеют хороших функций хеш-кода.
Это решение ни в коем случае не будет идеальным (в худшем случае вы все равно получите несколько дубликатов), но я считаю, что это ускорит процесс.Как я уже сказал, это зависит от того, что ваши дублированные изображения всегда генерируются одними и теми же вызовами.