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]

Мои эксперименты показали, что замена двух байтов на 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-секций в файле (не стрипать файл, а просто вывести, что там есть)
- сделать опцию ручного ввода секций, которые нужно "оставить в покое" (типа, стрипаешь всё, а потом, если рисунок получился битый, по одной секции включаешь назад и так, пока не находишь ту, которая нужна) --- по хорошему этот пункт было бы не плохо заменить автоопределением чего можно стрипать, а чего нельзя, но на данный момент непонятно как это реализовать... короче, этот пункт вообще, сейчас, под вопросом

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