Свежие комментарии
| Title | Comment |
|---|---|
| Хуже. В C++ есть перегрузка и неявные преобразования типов. |
Хуже. В C++ есть перегрузка и неявные преобразования типов. И если разрешить передавать по ссылке временные объекты, то в функцию может уйти совсем не тот объект и совсем не в ту функцию. Молча. С потерей результата. Собственно, чтобы избежать таких проблем, в C++ и ввели константные ссылки. А дальше константные указатели, методы и т.п. |
| Это старый известный баг MSVC. Хорошая новость в последних |
Это старый известный баг MSVC. Хорошая новость в последних версиях таки можно специальным ключиком заставить его действовать по Стандарту. Плохая по умолчанию это отключено, иначе перестанет собираться куча старого кривого кода, и это ведёт к появлению нового кривого кода. |
| Ну, проблема в отображалке. |
Ну, проблема в отображалке. |
| Да фиг бы с этим MD5, ты просто файлы побайтово сравни. |
Да фиг бы с этим MD5, ты просто файлы побайтово сравни. |
| Ага. Утомил меня Qmake. |
Ага. Утомил меня Qmake. |
| "что у двух разных файлов может быть разная MD5" - сорри, на |
"что у двух разных файлов может быть разная MD5" - сорри, наверное "одинаковая MD5"? |
| Поправил, спасибо. |
Поправил, спасибо. |
| Они, кстати, действительно прыгают на пиксель или около того |
Они, кстати, действительно прыгают на пиксель или около того. Что для одинаковых до бита файлов - весьма удивительно |
| ссылочка на Витуса кривая |
ссылочка на Витуса кривая |
| Мой поинт был исключительно в том, что ACDSee показывает <i> |
Мой поинт был исключительно в том, что ACDSee показывает нечто И как выясняется, это нечто для двух одинаковых файлов может быть разным. |
| Скорей всего дело в экранном муаре - "сетки" (линии) наклад |
Скорей всего дело в экранном муаре - "сетки" (линии) накладываются на регулярную структуру монитора со сдвигом давая разный рисунок муара. |
| ну а если взять и посмотреть не ACDSee, а скажем Irfanview, |
ну а если взять и посмотреть не ACDSee, а скажем Irfanview, или XnView |
| Я имею ввиду, что может накладываться какой-то фильтр самой |
Я имею ввиду, что может накладываться какой-то фильтр самой программой, который не заметен вот так сразу. Не знаю какой. |
| не, это же 20Mpix на 4-Mpix мониторе. С учетом рамок - 35% ( |
не, это же 20Mpix на 4-Mpix мониторе. С учетом рамок - 35% (и одинаково для двух файлов) |
| Интересная ситуация. С |
Интересная ситуация. С похожим сталкивался многократно когда сидел на вин ХП. Там в штатном просмотрщике если так же колесиком метаться между картинкой и её копией(т.е. 1 в 1 должно быть!) часто возникал баг, что у одной из 2 картинок в центре было на 1 пиксель меньше по горизонтали, т.е. как буд-то вырезан столбец шириной в 1 пиксель и высотой на всю картинку. До сих пор не понимаю как такое могло быть. |
| Скорее всего я пишу глупость, но может так быть, что второй |
Скорее всего я пишу глупость, но может так быть, что второй файл отображается в масштабе 100.01% или к нему применен фильтр "удаление искажений линз" какой-нибудь, ты сделал это случайно горячей кнопкой и не заметил? А сама программа хранит память об этом в недрах собственной базы. |
| Скриншот и в фотошоп слоями |
Скриншот и в фотошоп слоями клацать. |
| С точки зрения уверенности что они одинаковые - мне MD5 дост |
С точки зрения уверенности что они одинаковые - мне MD5 достаточно. |
| Баг асдси. Первый запускаемый файл отображается по одному. В |
Баг асдси. Первый запускаемый файл отображается по одному. Второй - по другому. Если отскейлить файл - то он уже назад в неотскейленное состояние точно также не вернется, и т.п. Проще всего засунуть файлы в шоп, применить диффренс и выкрутить уровни на максимум. |
| ПЯТНИЦА! |
ПЯТНИЦА! |
| Ну блин. Что значит "должны быть"? Если они есть в наличии, |
Ну блин. Что значит "должны быть"? Если они есть в наличии, что мешает fc /b на них натравить (по "ACDSee" предполагаю винду)? Или речь о всяких "дополнительных потоках данных"? Так их можно оторвать, скопировав файлы туда-обратно на флэшку с FAT. И вопрос. Если "выше" и "ниже" в каталоге положить ещё по паре файлов - будет ли зависимость отображения от, тсзть, направления пролистывания и от предыстории пролистывания? А если переименовать, чтобы они шли в обратном порядке? Я, вроде бы, замечал, что при первой отрисовке файла, и то-ли при повторной отрисовке "из буфера" (пролистали вперёд, вернулись), то ли при ещё какой-то хитрой последовательности "туда-сюда" - ACDSee почему-то интерполирует картинку по разному (отдельный вопрос, почему - ну, "они так написали"). Может быть, это тот же эффект?... |
| Похоже либо на какой-то |
Похоже либо на какой-то расширенный атрибут, либо на запись в кэше отображения просмотрщика, которые влияют на настройки, типа чуть зашарпенить или чуть заблурить. |
| Если открывать-закрывать, то я разницу хрен увижу. При быстр |
Если открывать-закрывать, то я разницу хрен увижу. |
| Интересная загадка. У меня пока даже нет вариантов :) Напиши |
Интересная загадка. У меня пока даже нет вариантов :) |
| Обзови их 1.ppm и 2.ppm. И ещё 3.ppm и 4.ppm. Может оно на и |
Обзови их 1.ppm и 2.ppm. И ещё 3.ppm и 4.ppm. Может оно на имя дёргается. А может памяти на что-нибудь во второй раз молча не хватило. |
| Ой. Перед постом коммента |
Ой. Перед постом коммента нажимал решфреш, что бы посмотреть, что написали -- там был 1 комментарий от _slw. Запостил своё -- а тут OVER 9000! |
| А что с SHA-256? ;-) |
А что с SHA-256? ;-) |
| Кривая Acdsee |
Кривая Acdsee |
| Ну если fc /b, то тогда, конечно. Но тут выясняется что с |
Ну если fc /b, то тогда, конечно. Но тут выясняется что с точки зрения NTFS у одного расширение .ppm, а у второго - .PPM Может последовать совету Славы и переменовать их в 1.ppm и 2.ppm? |
| Ну естественно, последовательность левых байт одинаковой дли |
Ну естественно, последовательность левых байт одинаковой длины должна быть прилеплена к обоим файлам. |
Pages
