Поиск недокачанных изображений

Skif_off

Скрипт обновлён:

- поправлена отмена создания cmd-файлов для копирования и удаления;
- поправлено имя функции.

Hisly · Сообщение **Hisly** » Пн янв 30, 2017 01:14

Может напишите для тех кто не в курсе куда это скрипт вставлять и как запускать. Что-то у меня ничего не выходит

Avada · Сообщение **Avada** » Пн янв 30, 2017 08:35

Hisly
В подфоруме "Автоматизация" наверху прикреплена памятка по скриптам, где уже давно наиболее важные рекомендации расписаны. А о том, что AutoIt-скрипт в натуральном нескомпилированном виде (*.au3) для своего запуска как исполняемого файла требует наличия в системе установленного AutoIt, несложно прочитать и за пределами этого форума. Объяснять подобные вещи специально в каждой теме, где есть подобные скрипты, никто не будет.

BeardFury78

Avada
А может лучше эту тему перенести в раздел "Автоматизация", ИМХО, там ей самое место

Skif_off

Выше в теме был пример моей кнопки, не стал повторяться (важно: параметр recurs заменён на --recurs). Сейчас допишу в пост со скриптом подробности.

Avada
В памятке большей частью общая информация и детали использования VBScript, в то время как использование других языков, требующих стороннего интерпретатора (AutoIt, AutoHotkey, Python, KiXtart и прочее) без инсталляции с файловыми ассоциацияии, всё-таки может вызвать вопросы.

Avada · Сообщение **Avada** » Пн янв 30, 2017 10:04

Skif_off
А это и есть общая информация. Вопросы же, как показывает практика, может вызвать абсолютно что угодно, независимо от детализации пояснений. Предлагается добавить в памятку фрагмент, где явным образом написано в общем виде, как быть, если для работы скрипта нужен сторонний интерпретатор? Можно написать в тему с её обсуждением.

BeardFury78
Вполне разумное предложение, учитывая конкретное содержание темы. Сделано.

Skif_off

Avada
Это да, уровень детализации - тот ещё вопрос, но влезать в обсуждение памятки что-то не хочется...

Добавил в пост со скриптом необходимый минимум для запуска и примеры, проверку скриптом наличия jpegtran exe рядом по просьбе добавлял ранее.

Hisly · Сообщение **Hisly** » Пн янв 30, 2017 23:06

Skif_off

У меня нет слов это то что я долго искал. СПАСИБО!!! Работает супер, "разобрал" фотоархив после вируса 36 000 файлов.

Если бы он еще RAWы и NEF просматривал.

Skif_off

Hisly
Строго говоря, NEF - это и есть RAW, только Nikon'овский. По идее есть конвертер из ImageMagick и можно конвертить во что-нибудь, что хранит так же много дополнительных данных (типа DNG, может быть?), многие RAW он читает, но не нагуглил коды возврата и сообщения об ошибках, надо пробовать.

Skif_off

Наткнулся нечаянно на libjpeg-turbo, полез потестить, натравил на 1069 штук, 3,24 Гб:

Код: Выделить всё

JPEGclub.org   10,56 мин
VS 2010 x86     7,81 мин
VS 2010 x64     7,36 мин
GCC x86         7,92 мин
GCC x64         7,52 мин

GCC-версия не поддерживает префикс "\\?\", со всеми вытекающими, VS - тянет с собой msvcp100.dll/msvcr100.dll.

Как бы всё это совместить?

Skif_off

Похоже, оптимизация таблицы Хаффмана получается побыстрее за счёт SSE2.
Пока структура такая

Код: Выделить всё

\jpegtran.exe                     обычная версия JPEGclub.org
\libjpeg-turbo-vc\jpegtran.exe    libjpeg-turbo x86
\libjpeg-turbo-vc64\jpegtran.exe  libjpeg-turbo x64

и галочка "libjpeg-turbo" с автовыбором разрядности.

Предложения приветствуются.

Skif_off

У кого-нибудь есть время и возможность проверить разницу по скорости между обычной версией и libjpeg-turbo с процессором без поддержки SSE2? Комплект.

P.S. Наткнулся по случаю на "VBoxManage modifyvm --cpuid", но не понял значение параметров, проверить пока нет возможности.

P.P.S. Удалось найти человека со старым процом: поддержка процессором SSE2 - не обязательно условие запуска утилиты, а профит есть и в таком случае, видимо, за счёт MMX.

BeardFury78

Заметил, что во время проверки файл jpegtest.jpg в папке Temp на системном диске C:\ постоянно меняет свой размер и дату. Кажется это сюда копируются изображения во время проверки. И компьютер у меня тормозит на стадии сканирования, особенно когда проверяются файлы на другом физическом диске. Думаю, это по причине плохих дисков, когда они не справляются с постоянным копированием файлов в папку Temp, особенно когда это длится долго и на папках с сотнями тысяч изображений. Если в этом состоит причина тормозов, можно ли как-нибудь этот подход изменить, чтобы проверялося прямо на месте, без копирования файлов в другое место? Скажем, выложить альтернативный вариант скрипта?

Skif_off

BeardFury78 писал(а):Заметил, что во время проверки файл jpegtest.jpg в папке Temp на системном диске C:\ постоянно меняет свой размер и дату. Кажется это сюда копируются изображения во время проверки.

Немного не так, Jpegtrun сжимает изображение и сохраняет в %Temp% результат, результирующее изображение будет поменьше размером, но, в общем, не очень значительно. Сделано так по простому соображению: если вам когда-нибудь приходилось сталкиваться с необходимостью восстановления данных с жёсткого диска, вероятно, вы знаете, что в таком случае нельзя ничего писать на носитель, только чтение.

Тут дело может быть не только в дисках, ведь идёт сжатие. Можете озвучить вашу конфигурацию? Процессор, диски, ОС? Для тестов в качестве слабого компа использовал HP Pavilion dm1-4000er, каких-то особых проблем не заметил.
Могу добавить, опционально, возможность писать в выбранный для тестирования каталог с изображениями, не могли бы вы проверить и сравнить поведение? Полагаю, вы используете версию отсюда, тогда так
[cut]

Код: Выделить всё

выпилил во избежание

[/cut]
Это набросок, надо подумать, как всё это аккуратно добавить, если что. Скрипт подсократил, убрал возможность генерировать батники и возможность протестировать файлы по списку, временный файл будет писаться в корень каталога, указанного в поле ввода (даже если отмечено "Рекурсивно"), лог-файл всё так же будет сохранён в %Temp%.

В планах есть:
- подсказали идею: попробовать результат отправлять в nul, тогда можно сэкономить ресурсы на запись его на жёсткий диск;
- попробовать использовать Jpeginfo, пользователь на Ру-борде предложил и скомпилировал версию для Windows с libjpeg проекта libjpeg-turbo: если результат проверки будет таким же, то можно немало выиграть;
- посмотреть, возможно ли использовать jpeg62.dll напрямую, с DllCall() (проблема не только в структуре).
Вот только никак руки не дойдут засесть

И у п.2 есть проблема: неизвестно, какие именно ошибки может найти, а что пропустит в сравнении с jpegtran (т.к. с jpegtran происходит оптимизация таблицы Хаффмана, то для сжатия потребуются всё содержимое файла). Возможно, есть смысл покопаться в исходниках и найти все сообщения об ошибках...
Опять же, охватить все возможные проблемные файлы не могу, для теста повреждённые JPEG'и получаю тривиально, в hex-редакторе.

BeardFury78

Skif_off
Моя конфигурация: ОС - Windows 7 64 bit, ЦП - AMD Phenom X3 8650, диски - ST3500418AS ATA Device (500 ГБ, 7200 RPM, SATA-II) и WD4000AAKS-00TMA0 ATA Device (373 ГБ, IDE). Сейчас еще раз запустил скрипт (и старый, и новый варианты) и не появилось никаких тормозов. Ни старый вариант, ни новый не нагружали систему. Возможно скрипт не виноват во вчерашних тормозах, может причина в других процессах, если так, прошу прощения за ложную тревогу. Просто вчера я только в первый раз использовал скрипт сразу на больших папках и где-то через полчаса начались тормоза. Новый вариант скрипта для меня можно не писать. Но в принципе хотелось чтобы было меньше нагрузки на жесткие диски, если это возможно, они у меня совсем старые.