JPGStrip, снять всё с .JPG файлов Опции

[-=CHE@TER=-]

Скачать программу: >>>JPGStrip<<<

Кто уже читал мой обзор вот тут, наверняка заметил, что я не очень доволен ситуацией сложившейся с JPG стрипперами. Так что я написал свой, что называется, from scratch (с нуля).
Вот оно:

АХТУНГ! Программа на стадии тестирования - так что, на всякий пожарный, делайте резервные копии ваших .JPG файлов! Вас предупредили.

Последняя версия лежит на сайте в CTPAX-X Soft.

История изменений

Version: 0.25 -> 0.26 (2008.11.22)
---------------------
Grom PE * -=CHE@TER=-: Added CMYK and arithmetic coded images support.

Version: 0.24 -> 0.25 (2008.03.27)
---------------------
-=CHE@TER=- * Filename doesn't output if file is already optimized
-=CHE@TER=- * Don't write to disk anything if nothing is stripped - a bit faster work
-=CHE@TER=- * Better support for .BAK: they won't created if nothing is stripped
-=CHE@TER=- * "File Access/Modification/Create Time" always restore for all files
(only if BTNoDatetime not specified), because file always readed for
JPEG signature which dropped "File Access Time" property

Version: 0.23 -> 0.24 (2008.01.21)
---------------------
Grom PE * New fancy make.bat
Grom PE * Smaller jpgstrip.ico
Grom PE * Removed double import of WriteFile (Write2 function)
Grom PE * Changed year to 2008

Version: 0.22 -> 0.23 (2008.01.21)
---------------------
-=CHE@TER=- * Create filelist before handling
-=CHE@TER=- * Fixed problem with two '\' characters in path

Version: 0.21 -> 0.22 (2007.12.01)
---------------------
-=CHE@TER=- * jTommy: Fixed bug with incorrect section size
-=CHE@TER=- * jTommy: Fixed filename output (CharToOEM)
-=CHE@TER=- * Replaced copyright Grom PE / -=CHE@TER=- to CTPAX-X Team

Version: 0.2 -> 0.21 (2007.10.24)
--------------------
Grom PE * Fixed incorrect file size counting
Grom PE * Tabbed output, looks better
Grom PE * Changed 'B' to 'bytes', added thousands separation

Version: 0.11 -> 0.2 (2007.10.24)
--------------------
-=CHE@TER=- * Added /R commandline option
-=CHE@TER=- * Added /J commandline option
-=CHE@TER=- * Fix problem with FFD9
-=CHE@TER=- * CR/LF output fixed

Version: 0.1 -> 0.11 (2007.10.14)
--------------------
Grom PE * Fixed some typos
Grom PE * Replaced SysUtils' functions by helpers.inc
Grom PE * Changed Write to Write2, used Int2Str, Int2StrSpaces from helpers.inc
Grom PE * Changed Delphi's file handling to WinAPI
Grom PE * Changed some Integers to Cardinals
Grom PE * Changed Internal dynamic array to simple memory dynamic array
Grom PE * Replaced lstrcmpi by helpers.inc's LowerCase

Version 0.1 (2007.10.11)
-----------
-=CHE@TER=- * Initial release

Предложения по программе (этакий to-do):
1) Не записывать в выходной файл дублирующиеся секции?
2) Оставлять Exif информацию (прога удаляет весь мусор, кроме Exif).

Объясню общий алгоритм работы программы. Значит так: JPG файл состоит из блоков, каждый из которых начинается на FF (255). Общая структура, такова:

FFD8 FFxxSZ... FFxxSZ... FFDASZ... FFD9

ВСЕ блоки, кроме FFD8 (сигнатура JPEG) и FFD9 (маркер конца файла) имеют поле SZ - размер этой самой структуры (в Big Endian, так что его нужно разворачивать, что и делается).
xx - это некий номер, определяющий, что за данные находятся в этом блоке.
Алгоритм моей программы тупой как бревно - читаются эти блоки, из них читается байт xx и сравнивается с массивом разрешённых байтов (см. константу JPEGAllowBlocks) - если этого байта там нет - значит это какой-нибудь thumbnail или ещё какая-нибудь хрень, так что мы её пропускаем и не записываем в выходной файл.

[Grom PE]

Сравнение ujpg и JPGStrip:

Я взял 3563 картинки JPG и прошелся по ним ujpg и JPGStrip'ом.
Обе программы справились за несколько секунд*, ujpg был немного быстрее.
3560 файлов оказались идентичными, а 3 файла были обработаны по-разному:

(1) ujpg достал из картинки thumbnail, JPGStrip оптимизировал правильно.

(2) ujpg достал из картинки thumbnail, JPGStrip оставил обрезок, как и в оригинале (картинка была недокачана).

(3) обе программы оптимизировали картинку, но ujpg сделал файл меньше (в конце каринки был мусор).

* - Честно говоря, меня удивила такая скорость обработки.

[-=CHE@TER=-]

О! Спасибо за тест!

(3) обе программы оптимизировали картинку, но ujpg сделал файл меньше (в конце каринки был мусор).

Это вот как раз проблема FFD9. В Интернете (раз (на Си), два (на VBS) и ещё пара ссылок по теме: одна, вторая) написано, что FFD9 ищется так: FFDA блок - пропускаются те 12 байт, которые к нему относятся, затем ТУПО ищется FF, причём пропускаются комбинации FF00 и FFFF. И вот, если найдено что-то, типа FFxx, где 0<xx<FF, то это считается началом нового маркера...
Тупость какая-то. Это что же получается - что при упаковке JPEG последовательность байт FFxx, удовлетворяющая приведённому выше условию не может встретиться? Неужели нет точного способа вычислить размер FFDA (SOS-блок (Start of Scan))?..

[Grom PE]

Мои эксперименты показали, что замена двух байтов на FF D9 в середине картинки обрезает ее (даже с использованием неофициального декодера), так что можно спокойно искать эти байты после FF DA.
Также, я проверил 250 мб больших фоток, ни в одном файле не встречается FF D9 именно в данных картинки.
ujpg ищет FF D9 с конца файла, поэтому иногда достает thumbnail'ы у недокачанных картинок (хотя бы на байт).
Поэтому он не справится с файлом, у которого в конце будет мусор с FF D9.
Хотя, может, это и правильно — пытаться достать "хоть что-то целое" у недокачанной картинки?

[-=CHE@TER=-]

Хотя, может, это и правильно — пытаться достать "хоть что-то целое" у недокачанной картинки?

Ага, спасибо.
Думаю, что нет. ИМХО, тогда нужно резать всё, что идёт после FFD9 и, если этот блок не найден, то файл считать недокачанным и переписывать всё что идёт после FFDA от начала и до конца.

Теперь насчёт профайлов. Мне, наконец-то, дали эту гадскую картинку.

Особенности:
1) Картинка в CMYK
2) Из моих программ (XnView / ACDSee 5.0) картинку правильно показывает только фотошоп - во всех остальных ярко ядовитый зелёный цвет.
3) Стрипать можно всё, кроме блока FFEE (сейчас он тоже стрипается), иначе картинку даже фотошоп неправильно отображает.
4) Судя по уже приведённой ссылочке EE - это "APP14 - Application Segment 14 - (Not common)". Т.е. не часто встречающийся. И вообще, начинается он со слов 'Adobe'+#0, что более чем прозрачно намекает на фотошоп. Как отличить нужный блок от мусора - пока что не знаю. Нужно подумать, потому что в других рисунках этот блок, почти со 100%-ой вероятность будет мусором.

Таким образом ToDo обновляется:

- сделать поддержку стрипанья с ReadOnly файлов и возможность их не трогать (/R - don't strip read-only files)
- сделать опцию вывода всех FF-секций в файле (не стрипать файл, а просто вывести, что там есть)
- сделать опцию ручного ввода секций, которые нужно "оставить в покое" (типа, стрипаешь всё, а потом, если рисунок получился битый, по одной секции включаешь назад и так, пока не находишь ту, которая нужна) --- по хорошему этот пункт было бы не плохо заменить автоопределением чего можно стрипать, а чего нельзя, но на данный момент непонятно как это реализовать... короче, этот пункт вообще, сейчас, под вопросом

Надо будет в ближайшее время заняться...

[Alex]

-=CHE@TER=- а графический вариант уже есть?
Просто нужно некоторые рисуночки подзажать, а прописывать всё вручную не особо хочеться.

[-=CHE@TER=-]

-=CHE@TER=- а графический вариант уже есть?

В смысле - графический?

[Alex]

Ну всмысле что бы не надо было прописывать всякую... Вообщем что бы всё просто было, раз кнопочку нажал, два кнопочку нажал. ))
Вообщем готовый вариан дай пожалуйста, а то мне по крайней мере не понятно что там наверху.

[-=CHE@TER=-]

Ну всмысле что бы не надо было прописывать всякую... Вообщем что бы всё просто было, раз кнопочку нажал, два кнопочку нажал. ))
Вообщем готовый вариан дай пожалуйста, а то мне по крайней мере не понятно что там наверху.

А, точно, ты же скомпилировать не можешь.
Ну, вообще-то:
а) программа на стадии разработки
б) она консольная (т.е. там нет кнопок)
В принципе, бета-версию можно выложить.
Ты умеешь с консольными утилитами работать?

[Alex]

А что там уметь?!))) Просто не очень люблю консольные программы, более склонен к графическим.

[-=CHE@TER=-]

Так, программу выложил (см. первый пост) и изменил ToDo (см. там же).
История изменений - в .DPR файле и первом посте этой темы.
Помимо всего прочего немного поменял make.bat, чтобы DVCLAL и PAKAGEINFO стрипались.
Просьба потестить, кто может.

[jTommy]

Потестировал немного. Все что нашел у себя на харде скинул в несколько каталогов. Там были фотки с цифровиков, высококачественные обои, также высококачественные и не очень снимки природы, животных и т.д. + всякие мелкие аватарки и смайлики.

Вот что получилось:

CODE

Файлов     Размер     Сохранено
14000       1гб          39мб
2220      212мб         403кб
13152       2гб         8.6мб
7119        2гб          20мб

Обработка каталога с 14тыс файлов заняла всего несколько минут. Часто размер мусора в одном файле доходил до 40кб.

Глюки:
1. В каталоге, где 7тыс. зависла на 4 файлах, вот они:
180.jpg
182.jpg
220.jpg
292.jpg

2. Файлы с русскими буквами в консоли показываются крякозябрами. Не знаю чей это глюк, у меня ХР английская, возможно из-за этого. Far Manager нормально показывает русский язык.



Сообщение было отредактировано jTommy: Dec 1 2007, 14:31

[-=CHE@TER=-]

jTommy!
Большое спасибо за тестирование и замечания/отчёт!

Вот что получилось:

CODE

Файлов     Размер     Сохранено
14000       1гб          39мб
2220      212мб         403кб
13152       2гб         8.6мб
7119        2гб          20мб

Не очень, конечно, много съэкономило, но всё же... Какие-то у тебя файлы частично пострипанные. (*улыбается*)

Обработка каталога с 14тыс файлов заняла всего несколько минут. Часто размер мусора в одном файле доходил до 40кб.

40кб - не предел. (*улыбается*)

Глюки:1. В каталоге, где 7тыс. зависла на 4 файлах, вот они:

О! Большое спасибо!
Там, почему-то, между секциями мусор был. Т.е., например, FF xx SZ (DATA) .. .. .. FF xx SZ (DATA) - т.е. после конца одной секции и началом другой шли, почему-то, какие-то левые байты.
Заменил в коде:

CODE

        Move(P[I], W, 2);
        Move(P[I+2], Sz, 2);

На поиск FF:

CODE

        Repeat
          Move(P[I], W, 2);
          Move(P[I+2], Sz, 2);
          If Lo(W)<>$FF Then I:=I+1;
        Until ((Lo(W) = $FF) Or (I>=JPGOldSize));

Всё заработало.

2. Файлы с русскими буквами в консоли показываются крякозябрами. Не знаю чей это глюк, у меня ХР английская, возможно из-за этого. Far Manager нормально показывает русский язык.

А, ну дык: CharToOEM(). Исправил.

Ещё заменил копирайт Grom PE / -=CHE@TER=- на CTPAX-X Team.
Надеюсь, никто не против? (*улыбается*)

Версия 0.22. Смотрим первый пост.

[Grom PE]

Ещё заменил копирайт Grom PE / -=CHE@TER=- на CTPAX-X Team.
Надеюсь, никто не против? (*улыбается*)

Все правильно, я же теперь в команде.

P.S. Кажется, список нужно обновить =)

[jTommy]

Оказывается битых файлов было не 4 а около 15 (я их незаметил, потому что она на них не зависла). Теперь со всеми работает правильно.

Не очень, конечно, много съэкономило, но всё же... Какие-то у тебя файлы частично пострипанные. (*улыбается*)

Я наоборот, ожидал меньшей пользы.

Предлагаю еще одну опцию:
- оставлять Exif информацию (прога удаляет весь мусор, кроме Exif).

[-=CHE@TER=-]

Все правильно, я же теперь в команде.

P.S. Кажется, список нужно обновить =)

О, блин, точно. (*улыбается*) Совсем забыл. Спасибо! Заодно актулизировал информацию в связи с тем, что Extractor.ru ожил.

Оказывается битых файлов было не 4 а около 15 (я их незаметил, потому что она на них не зависла). Теперь со всеми работает правильно.

Кстати, думаю, нужно разрулить ситуацию с .BAK файлами да на сайт выложить - пущай другие тоже оценят. (*улыбается*)

Предлагаю еще одну опцию:
- оставлять Exif информацию (прога удаляет весь мусор, кроме Exif).

Хе-хе. Как раз на exif-то больше всего инфы и стрипается.
Кстати, вопрос тогда: никто не знает exif - это один FF xx блок или несколько? Туда же, вроде, ещё уменьшенные превьюшки входят или это другой блок?
Короче, спасибо за todo - вынес его в первый пост под номером 4. Надо обмозговать.

[jTommy]

1) Косяк с .BAK файлами - если переименовывать, то FindNext возвращяет новый .JPG с таким же именем, уже стрипнутый
2) Улучшить поддержку .BAK - чтобы .BAK файл не создавался, если ничего не стрипалось

Сканируем .jpg, "не мусор" записываем в .tmp файл. Дошли до конца .jpg файла, переименовываем: .jpg -> .bak; .tmp -> .jpg. Если мусора не оказалось - ничего не делаем. Создается только один .tmp файл.
Или в два прохода: сначала сканируем, если мусор есть, тогда возвращаемся в начало .jpg и начинаем записывать в .tmp. Но так как случай, когда мусора нет вообще встречается редко (во всяком случае, в моих файлах) можно не заморачиваться с этим вариантом.

3) Что делать с изображениями с не ICC профайлом (см. ниже)?

Я так понимаю, они настолько редки, что на них можно забить. Это изображение, которое ты выложил, даже Corel Photo-Paint X3 неправильно отображает. Ну или научится их распознавать.

Вообще надо бы GUI интерфейс сделать, но такой, чтобы он был удобным. Например слева дерево папок, справа настройки и ход процесса. На как это сделать на WinAPI?... "TTreeView" сложный контрол. На VCL не хочется - программа для уменьшения файлов, а сама весит 400кб.
Можно проще: кнопочка "добавить каталог" и список каталогов, на случай если пользователь хочет сразу несколько каталогов обработать.

Добавлено:
Вот нашел неофициальный сайт про Exif, но с официальными спецификациями: http://www.exif.org/

Сообщение было отредактировано jTommy: Dec 2 2007, 18:00

[-=CHE@TER=-]

Пофиксил работу с повторной обработкой - сначала делаю список файлов в памяти и его обрабатываю потом.
Косяк с двумя косыми чертами - ExtractFilePath из утилит Grom PE возвращял на конце "\", чего стандартная функция Delphi не делает. Сейчас добавил пару проверок, так что пофигу из-под чего компилируется.
Переместил исходные коды на Team FTP.

Version: 0.22 -> 0.23
-=CHE@TER=- * Create filelist before handling
-=CHE@TER=- * Fixed problem with two '\' characters in path

Кстати, немецкая Википедия считает, что 0xEE - это "Often for copyright records" (гуглом превёл). Т.е. грубо говоря, Adobe отказывается открывать CMYK файл, если его не фотожоп создал или оттуда его копилефт "Adobe" вырезали?.. А вот интересно, как узнать, что файл CMYK, чтобы этот блок оставить? И он ещё отличается от других таких же блоков в не CMYK-файлах. Если понять, какой байт или поле в этом блоке отвечает за его нужность/ненужность, то можно анализировать и оставлять, если надо. Только вот описание этого блока нигде не нашёл... А уж описание того, что туда Adobe суёт, мне кажется, вообще не найти - это ноу-хау.

[Grom PE]

-=CHE@TER=-
Как сохраняет в CMYK JPEG Corel Photo-Paint 9.
После обрезки, файл перестает нормально читаться ACDSee 3.1. Самим Photo-Paint'ом читается нормально.
А больше у меня нет программ, которые могли бы читать CMYK JPEG =)

Внес мелкие изменения в JPGStrip:

Version: 0.23 -> 0.24
Grom PE * New fancy make.bat
Grom PE * Smaller jpgstrip.ico
Grom PE * Removed double import of WriteFile (Write2 function)
Grom PE * Changed year to 2008

[-=CHE@TER=-]

Обновил первый пост - JPGStrip 0.25:

Version: 0.24 -> 0.25 (2008.03.27)
---------------------
-=CHE@TER=- * Filename doesn't output if file is already optimized
-=CHE@TER=- * Don't write to disk anything if nothing is stripped - a bit faster work
-=CHE@TER=- * Better support for .BAK: they won't created if nothing is stripped
-=CHE@TER=- * "File Access/Modification/Create Time" always restore for all files
(only if BTNoDatetime not specified), because file always readed for
JPEG signature which dropped "File Access Time" property

Блин, чертовски удобную штуку мы сделали. JPGStripper от SteelBytes я уже выкинул, а также вытер с винта и реестра всё то, что оно нагадило. (*улыбается*)

Чего ещё изменил:
1. Дату у каждой версии в истории
2. Все изменения пометил как {* 0.25 *}, чтобы можно было в случае чего знать, где искать ошибку, да и просто ориентироваться что и когда меняли
3. Файл читается в память, апосля этого в массив из 100 элементов (взял с большим запасом) заносится смещение и размер секций, которые нельзя стрипать. После этого подсчитывается размер этих секций - если он, в сумме, оказался меньше размера файла - только тогда создаётся .BAK файл, а файл перезаписывается. Всё гениальное - просто. (*улыбается*)

Насчёт To Do:

- show error if no files given

Не совсем понял про что тут речь - объясните, кто добавил, или уберите из to do.

А вот что реально нужно добавить:

- skip duplicate FF blocks (for damaged files)

У меня пару лет назад рухнул винт. Восстанавливал когда с него файлы - восстановил сайт какой-то по Silent Hill 2. У картинок почему-то дублировался JFIF заголовок. Вот примеры:
dupjpghdr.zip (102 533 байта)
Может в массив, который у меня сейчас используется для секций (Sect[]) добавить поле - номер секции с проверкой: дублирующиеся секции не добавлять?