JPGStrip, снять всё с .JPG файлов |
Добро пожаловать, гость ( Вход | Регистрация )
JPGStrip, снять всё с .JPG файлов |
-=CHE@TER=- |
Oct 13 2007, 09:50
Сообщение
#1
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
QUOTE Скачать программу: >>>JPGStrip<<< Кто уже читал мой обзор вот тут, наверняка заметил, что я не очень доволен ситуацией сложившейся с JPG стрипперами. Так что я написал свой, что называется, from scratch (с нуля). Вот оно: QUOTE АХТУНГ! Программа на стадии тестирования - так что, на всякий пожарный, делайте резервные копии ваших .JPG файлов! Вас предупредили. Последняя версия лежит на сайте в CTPAX-X Soft. История изменений Предложения по программе (этакий 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 |
Oct 14 2007, 00:04
Сообщение
#2
|
Advanced Member Группа: CTPAX-X Сообщений: 84 Регистрация: 7-February 08 Из: i@grompe.org.ru Пользователь №: 3,120 Спасибо сказали: 95 раз(а) |
Сравнение ujpg и JPGStrip:
Я взял 3563 картинки JPG и прошелся по ним ujpg и JPGStrip'ом. Обе программы справились за несколько секунд*, ujpg был немного быстрее. 3560 файлов оказались идентичными, а 3 файла были обработаны по-разному: (1) ujpg достал из картинки thumbnail, JPGStrip оптимизировал правильно. (2) ujpg достал из картинки thumbnail, JPGStrip оставил обрезок, как и в оригинале (картинка была недокачана). (3) обе программы оптимизировали картинку, но ujpg сделал файл меньше (в конце каринки был мусор). * - Честно говоря, меня удивила такая скорость обработки. |
-=CHE@TER=- |
Oct 14 2007, 09:35
Сообщение
#3
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
О! Спасибо за тест!
(3) обе программы оптимизировали картинку, но ujpg сделал файл меньше (в конце каринки был мусор). Это вот как раз проблема FFD9. В Интернете (раз (на Си), два (на VBS) и ещё пара ссылок по теме: одна, вторая) написано, что FFD9 ищется так: FFDA блок - пропускаются те 12 байт, которые к нему относятся, затем ТУПО ищется FF, причём пропускаются комбинации FF00 и FFFF. И вот, если найдено что-то, типа FFxx, где 0<xx<FF, то это считается началом нового маркера...Тупость какая-то. Это что же получается - что при упаковке JPEG последовательность байт FFxx, удовлетворяющая приведённому выше условию не может встретиться? Неужели нет точного способа вычислить размер FFDA (SOS-блок (Start of Scan))?.. |
Grom PE |
Oct 16 2007, 08:02
Сообщение
#4
|
Advanced Member Группа: CTPAX-X Сообщений: 84 Регистрация: 7-February 08 Из: i@grompe.org.ru Пользователь №: 3,120 Спасибо сказали: 95 раз(а) |
Мои эксперименты показали, что замена двух байтов на FF D9 в середине картинки обрезает ее (даже с использованием неофициального декодера), так что можно спокойно искать эти байты после FF DA.
Также, я проверил 250 мб больших фоток, ни в одном файле не встречается FF D9 именно в данных картинки. ujpg ищет FF D9 с конца файла, поэтому иногда достает thumbnail'ы у недокачанных картинок (хотя бы на байт). Поэтому он не справится с файлом, у которого в конце будет мусор с FF D9. Хотя, может, это и правильно — пытаться достать "хоть что-то целое" у недокачанной картинки? |
-=CHE@TER=- |
Oct 17 2007, 05:09
Сообщение
#5
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
Хотя, может, это и правильно — пытаться достать "хоть что-то целое" у недокачанной картинки? Ага, спасибо.Думаю, что нет. ИМХО, тогда нужно резать всё, что идёт после FFD9 и, если этот блок не найден, то файл считать недокачанным и переписывать всё что идёт после FFDA от начала и до конца. Теперь насчёт профайлов. Мне, наконец-то, дали эту гадскую картинку. Особенности: 1) Картинка в CMYK 2) Из моих программ (XnView / ACDSee 5.0) картинку правильно показывает только фотошоп - во всех остальных ярко ядовитый зелёный цвет. 3) Стрипать можно всё, кроме блока FFEE (сейчас он тоже стрипается), иначе картинку даже фотошоп неправильно отображает. 4) Судя по уже приведённой ссылочке EE - это "APP14 - Application Segment 14 - (Not common)". Т.е. не часто встречающийся. И вообще, начинается он со слов 'Adobe'+#0, что более чем прозрачно намекает на фотошоп. Как отличить нужный блок от мусора - пока что не знаю. Нужно подумать, потому что в других рисунках этот блок, почти со 100%-ой вероятность будет мусором. Таким образом ToDo обновляется: QUOTE - сделать поддержку стрипанья с ReadOnly файлов и возможность их не трогать (/R - don't strip read-only files) - сделать опцию вывода всех FF-секций в файле (не стрипать файл, а просто вывести, что там есть) - сделать опцию ручного ввода секций, которые нужно "оставить в покое" (типа, стрипаешь всё, а потом, если рисунок получился битый, по одной секции включаешь назад и так, пока не находишь ту, которая нужна) --- по хорошему этот пункт было бы не плохо заменить автоопределением чего можно стрипать, а чего нельзя, но на данный момент непонятно как это реализовать... короче, этот пункт вообще, сейчас, под вопросом Надо будет в ближайшее время заняться... |
Alex |
Oct 20 2007, 12:55
Сообщение
#6
|
Незарегистрирован |
-=CHE@TER=- а графический вариант уже есть?
Просто нужно некоторые рисуночки подзажать, а прописывать всё вручную не особо хочеться. |
-=CHE@TER=- |
Oct 23 2007, 09:08
Сообщение
#7
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
|
Alex |
Oct 23 2007, 14:03
Сообщение
#8
|
Незарегистрирован |
Ну всмысле что бы не надо было прописывать всякую... Вообщем что бы всё просто было, раз кнопочку нажал, два кнопочку нажал. ))
Вообщем готовый вариан дай пожалуйста, а то мне по крайней мере не понятно что там наверху. |
-=CHE@TER=- |
Oct 23 2007, 17:28
Сообщение
#9
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
Ну всмысле что бы не надо было прописывать всякую... Вообщем что бы всё просто было, раз кнопочку нажал, два кнопочку нажал. )) А, точно, ты же скомпилировать не можешь.Вообщем готовый вариан дай пожалуйста, а то мне по крайней мере не понятно что там наверху. Ну, вообще-то: а) программа на стадии разработки б) она консольная (т.е. там нет кнопок) В принципе, бета-версию можно выложить. Ты умеешь с консольными утилитами работать? |
Alex |
Oct 23 2007, 20:38
Сообщение
#10
|
Незарегистрирован |
А что там уметь?!))) Просто не очень люблю консольные программы, более склонен к графическим.
|
-=CHE@TER=- |
Oct 24 2007, 11:17
Сообщение
#11
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
Так, программу выложил (см. первый пост) и изменил ToDo (см. там же).
История изменений - в .DPR файле и первом посте этой темы. Помимо всего прочего немного поменял make.bat, чтобы DVCLAL и PAKAGEINFO стрипались. Просьба потестить, кто может. |
jTommy |
Dec 1 2007, 14:21
Сообщение
#12
|
Наблюдающий Группа: CTPAX-X Сообщений: 197 Регистрация: 4-February 08 Из: деревня Москва Пользователь №: 6 Спасибо сказали: 19 раз(а) |
Потестировал немного. Все что нашел у себя на харде скинул в несколько каталогов. Там были фотки с цифровиков, высококачественные обои, также высококачественные и не очень снимки природы, животных и т.д. + всякие мелкие аватарки и смайлики.
Вот что получилось: 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=- |
Dec 1 2007, 16:00
Сообщение
#13
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
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 |
Dec 1 2007, 16:36
Сообщение
#14
|
Advanced Member Группа: CTPAX-X Сообщений: 84 Регистрация: 7-February 08 Из: i@grompe.org.ru Пользователь №: 3,120 Спасибо сказали: 95 раз(а) |
Ещё заменил копирайт Grom PE / -=CHE@TER=- на CTPAX-X Team. Надеюсь, никто не против? (*улыбается*) P.S. Кажется, список нужно обновить =) |
jTommy |
Dec 1 2007, 16:44
Сообщение
#15
|
Наблюдающий Группа: CTPAX-X Сообщений: 197 Регистрация: 4-February 08 Из: деревня Москва Пользователь №: 6 Спасибо сказали: 19 раз(а) |
Оказывается битых файлов было не 4 а около 15 (я их незаметил, потому что она на них не зависла). Теперь со всеми работает правильно.
Не очень, конечно, много съэкономило, но всё же... Какие-то у тебя файлы частично пострипанные. (*улыбается*) Я наоборот, ожидал меньшей пользы. Предлагаю еще одну опцию: - оставлять Exif информацию (прога удаляет весь мусор, кроме Exif). |
-=CHE@TER=- |
Dec 2 2007, 05:42
Сообщение
#16
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
О, блин, точно. (*улыбается*) Совсем забыл. Спасибо! Заодно актулизировал информацию в связи с тем, что Extractor.ru ожил.
Оказывается битых файлов было не 4 а около 15 (я их незаметил, потому что она на них не зависла). Теперь со всеми работает правильно. Кстати, думаю, нужно разрулить ситуацию с .BAK файлами да на сайт выложить - пущай другие тоже оценят. (*улыбается*)Предлагаю еще одну опцию: Хе-хе. Как раз на exif-то больше всего инфы и стрипается.- оставлять Exif информацию (прога удаляет весь мусор, кроме Exif). Кстати, вопрос тогда: никто не знает exif - это один FF xx блок или несколько? Туда же, вроде, ещё уменьшенные превьюшки входят или это другой блок? Короче, спасибо за todo - вынес его в первый пост под номером 4. Надо обмозговать. |
jTommy |
Dec 2 2007, 08:07
Сообщение
#17
|
Наблюдающий Группа: CTPAX-X Сообщений: 197 Регистрация: 4-February 08 Из: деревня Москва Пользователь №: 6 Спасибо сказали: 19 раз(а) |
1) Косяк с .BAK файлами - если переименовывать, то FindNext возвращяет новый .JPG с таким же именем, уже стрипнутый Сканируем .jpg, "не мусор" записываем в .tmp файл. Дошли до конца .jpg файла, переименовываем: .jpg -> .bak; .tmp -> .jpg. Если мусора не оказалось - ничего не делаем. Создается только один .tmp файл.2) Улучшить поддержку .BAK - чтобы .BAK файл не создавался, если ничего не стрипалось Или в два прохода: сначала сканируем, если мусор есть, тогда возвращаемся в начало .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=- |
Jan 21 2008, 07:57
Сообщение
#18
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
Пофиксил работу с повторной обработкой - сначала делаю список файлов в памяти и его обрабатываю потом.
Косяк с двумя косыми чертами - ExtractFilePath из утилит Grom PE возвращял на конце "\", чего стандартная функция Delphi не делает. Сейчас добавил пару проверок, так что пофигу из-под чего компилируется. Переместил исходные коды на Team FTP. QUOTE 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 |
Jan 21 2008, 09:55
Сообщение
#19
|
Advanced Member Группа: CTPAX-X Сообщений: 84 Регистрация: 7-February 08 Из: i@grompe.org.ru Пользователь №: 3,120 Спасибо сказали: 95 раз(а) |
-=CHE@TER=-
Как сохраняет в CMYK JPEG Corel Photo-Paint 9. После обрезки, файл перестает нормально читаться ACDSee 3.1. Самим Photo-Paint'ом читается нормально. А больше у меня нет программ, которые могли бы читать CMYK JPEG =) Внес мелкие изменения в JPGStrip: QUOTE 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=- |
Mar 27 2008, 13:36
Сообщение
#20
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
Обновил первый пост - JPGStrip 0.25:
QUOTE 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: QUOTE - show error if no files given Не совсем понял про что тут речь - объясните, кто добавил, или уберите из to do. А вот что реально нужно добавить: QUOTE - skip duplicate FF blocks (for damaged files) У меня пару лет назад рухнул винт. Восстанавливал когда с него файлы - восстановил сайт какой-то по Silent Hill 2. У картинок почему-то дублировался JFIF заголовок. Вот примеры:dupjpghdr.zip (102 533 байта) Может в массив, который у меня сейчас используется для секций (Sect[]) добавить поле - номер секции с проверкой: дублирующиеся секции не добавлять? Спасибо сказали:
|
Упрощённая версия | Сейчас: 24th December 2024 - 03:35 |