Удивительное рядом, но оно запрещено

Есть два файла, одинаковых до бита, вот их MD5:
6c3544c90fa4eb2b65a37426ba7dd56f  E5D2hMULTII00050.CR2.eta.ppm
6c3544c90fa4eb2b65a37426ba7dd56f  E5D2hMULTII00050.CR2.eta2.ppm

Это мишенька с Imaging Resource, там всякие Resolution Targets, CC24 и так далее.

Смотрю на них в ACDSee, задумчиво крутя колесико мыши (отчего оная ACDSee меняет файлы, один на второй) и вижу, что они существенно разные на глаз. Вот например (это кусочки скриншотов, видно что алиасинг разный совсем):

Понятное дело, все настройки одинаковые, файлы (повторяю) тоже одинаковые, размер на экране не меняется, вообще все одинаковое. Однако ж.

Интерполяция стояла Bicubic, но для двух других вариантов - аналогичная фигня.

Нахожусь в недоумении.

Update: подозрение на какие-то кэши превьюшек, больше не на что.

Comments

переложить в другие каталоги.
переименовать.

В разных каталогах не получится так быстро свитчиться.

Я, собственно, к тому, что никому верить нельзя. Кроме меня, конечно.

что значит не получится?
какая разница в каком каталоге файл лежит?

ACDSee колёсиком только в пределах одного каталога быстро картинки переключает
или имеется в виду оба файла перекинуть в другой каталог?

В интерфейсе разница.
Быстро переключаться можно только между соседями.

ничего страшного, в другой каталог их скопируй под другими именами и переключайся.

кстати, если просто открывать файлы по отдельности, каждый раз закрывая программу -- фифект сохраняется?

Если открывать-закрывать, то я разницу хрен увижу.
При быстром переключении видно разницу, а при медленном - хрен ее разберет.

Скриншот и в фотошоп слоями клацать.

Коллизию MD5 нашел? Ну это вообще-то не слишком удивительно. Нынче эта коллизия часов за 8 на приличном десктопе генерится.
Хотя, вообще это добрая первоапрельская шутка - подсунуть человеку два РАЗНЫХ файла с одинаковыми MD5: выдав их за одинаковые.

Ну, в общем, да, шутка прикольная, но всётки одно дело - найти коллизию, а другое - найти такую коллизию, один вариант которой даёт муар картинки, а другой - нет. Чо-то мне подсказывает, что тут 8 часами уже не обойдёшься, не?

2ТС : Там реально одинаковые файлы или действительно коллизия?

Стандратная искалка коллизий в MD5 работает так - берем два файла, обладающих требуемыми свойствами (например неподпписанные заготовки для сертификата на разные публичные ключи, или pdf-документы с разным осмысленным содержанием), задаем диапазон байт, который можно заполнять случайным мусором, и, подбирая этот мусор добиваемся чтобы получилась одинаковая MD5.

Так что если там действительно коллизия, то к хвосту PPM-файла (размер которого должен однозначно определяться по заголовку, там формат очень простой) должна быть прилеплена дополнительная последовательность байт, с помощью которой и обеспечивается совпадение md5.

Фига.. Понятно. Не знал, спасибо :)

-rw-r--r-- 1 lexa Administ 63433223 Apr 6 15:56 E5D2hMULTII00050.CR2.eta.ppm
-rw-r--r-- 1 lexa Administ 63433223 Apr 6 15:57 E5D2hMULTII00050.CR2.eta2.ppm

fc /b E5D2hMULTII00050.CR2.eta.ppm E5D2hMULTII00050.CR2.eta2.ppm
Comparing files E5D2hMULTII00050.CR2.eta.ppm and E5D2HMULTII00050.CR2.ETA2.PPM
FC: no differences encountered

Ну если fc /b, то тогда, конечно.

Но тут выясняется что с точки зрения NTFS у одного расширение .ppm, а у второго - .PPM

Может последовать совету Славы и переменовать их в 1.ppm и 2.ppm?

Ну естественно, последовательность левых байт одинаковой длины должна быть прилеплена к обоим файлам.
Вот сравнить длину файла с данными заголовка ppm - это другое дело.
Но проще - посчитать хэш-суммы по более другим алгоритмам sha1sum, sha256sum

Там реально одинаковые файлы, насколько я могу судить с помощью доступных мне инструментов.

Интересная загадка. У меня пока даже нет вариантов :)
Напишите, пожалуйста, если будет новая информация, тоже очень любопытно.

Вряд-ли.

С учетом того, что эти два файла получены из одного CR2 разными версиями одной программы - они все-таки должны быть побитово одинаковыми.

Ну блин. Что значит "должны быть"? Если они есть в наличии, что мешает fc /b на них натравить (по "ACDSee" предполагаю винду)? Или речь о всяких "дополнительных потоках данных"? Так их можно оторвать, скопировав файлы туда-обратно на флэшку с FAT.

И вопрос. Если "выше" и "ниже" в каталоге положить ещё по паре файлов - будет ли зависимость отображения от, тсзть, направления пролистывания и от предыстории пролистывания? А если переименовать, чтобы они шли в обратном порядке? Я, вроде бы, замечал, что при первой отрисовке файла, и то-ли при повторной отрисовке "из буфера" (пролистали вперёд, вернулись), то ли при ещё какой-то хитрой последовательности "туда-сюда" - ACDSee почему-то интерполирует картинку по разному (отдельный вопрос, почему - ну, "они так написали"). Может быть, это тот же эффект?...

Лёх, ну так выложи картинки то
мы ж тоже хотим колёсиком покрутить!!! ;)
у тебя Acdsee какая стоит???

твой компьютер взломан тонким троллем!

Кривая Acdsee

А что с SHA-256? ;-)

Ой. Перед постом коммента нажимал решфреш, что бы посмотреть, что написали -- там был 1 комментарий от _slw. Запостил своё -- а тут OVER 9000!

ПЯТНИЦА!

Обзови их 1.ppm и 2.ppm. И ещё 3.ppm и 4.ppm. Может оно на имя дёргается. А может памяти на что-нибудь во второй раз молча не хватило.

Похоже либо на какой-то расширенный атрибут, либо на запись в кэше отображения просмотрщика, которые влияют на настройки, типа чуть зашарпенить или чуть заблурить.

Баг асдси. Первый запускаемый файл отображается по одному. Второй - по другому. Если отскейлить файл - то он уже назад в неотскейленное состояние точно также не вернется, и т.п.

Проще всего засунуть файлы в шоп, применить диффренс и выкрутить уровни на максимум.

С точки зрения уверенности что они одинаковые - мне MD5 достаточно.

Скорее всего я пишу глупость, но может так быть, что второй файл отображается в масштабе 100.01% или к нему применен фильтр "удаление искажений линз" какой-нибудь, ты сделал это случайно горячей кнопкой и не заметил? А сама программа хранит память об этом в недрах собственной базы.

не, это же 20Mpix на 4-Mpix мониторе. С учетом рамок - 35% (и одинаково для двух файлов)

Я имею ввиду, что может накладываться какой-то фильтр самой программой, который не заметен вот так сразу. Не знаю какой.

Интересная ситуация. С похожим сталкивался многократно когда сидел на вин ХП. Там в штатном просмотрщике если так же колесиком метаться между картинкой и её копией(т.е. 1 в 1 должно быть!) часто возникал баг, что у одной из 2 картинок в центре было на 1 пиксель меньше по горизонтали, т.е. как буд-то вырезан столбец шириной в 1 пиксель и высотой на всю картинку. До сих пор не понимаю как такое могло быть.

ну а если взять и посмотреть не ACDSee, а скажем Irfanview, или XnView
ну в общем другой смотрелкой

Мой поинт был исключительно в том, что ACDSee показывает нечто

И как выясняется, это нечто для двух одинаковых файлов может быть разным.

Скорей всего дело в экранном муаре - "сетки" (линии) накладываются на регулярную структуру монитора со сдвигом давая разный рисунок муара.

Они, кстати, действительно прыгают на пиксель или около того.

Что для одинаковых до бита файлов - весьма удивительно

А это в быстром просмотре, или непосредственно в программе?
Там просто разные алгоритмы, хз, как она там файлы обрабатывает))

Я поэтому и отказался сейчас от эсидиси - слишком много в ней странностей. FastStone как-то попроще/надёжнее/шустрее выглядит.

Непосредственно в программе, quick view у меня выключен

Add new comment