Версия для печати темы

Нажмите сюда для просмотра этой темы в оригинальном формате

CTPAX-X _ Программы _ JPGStrip

Автор: -=CHE@TER=- Oct 13 2007, 09:50

QUOTE
Скачать программу: >>>http://www.ctpax-x.org/index.php?goto=cxsoft&show=35<<<

Кто уже читал мой обзор http://www.forum.ctpax-x.org/index.php?showtopic=96&view=findpost&p=1379, наверняка заметил, что я не очень доволен ситуацией сложившейся с JPG стрипперами. Так что я написал свой, что называется, from scratch (с нуля).
Вот оно:
QUOTE
АХТУНГ! Программа на стадии тестирования - так что, на всякий пожарный, делайте резервные копии ваших .JPG файлов! Вас предупредили.


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

История изменений
QUOTE
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 Oct 14 2007, 00:04

Сравнение 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

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

QUOTE(Grom PE @ Oct 14 2007, 12:04 AM) *
(3) обе программы оптимизировали картинку, но ujpg сделал файл меньше (в конце каринки был мусор).
Это вот как раз проблема FFD9. В Интернете (http://www.squarebox.co.uk/users/rolf/download/jpegsize.c, http://www.xpounded.netfirms.com/xJPEGMarkers.html и ещё пара ссылок по теме: http://www.opennet.ru/docs/formats/jpeg.txt, http://www.impulseadventure.com/photo/jpeg-decoder.html) написано, что FFD9 ищется так: FFDA блок - пропускаются те 12 байт, которые к нему относятся, затем ТУПО ищется FF, причём пропускаются комбинации FF00 и FFFF. И вот, если найдено что-то, типа FFxx, где 0<xx<FF, то это считается началом нового маркера...
Тупость какая-то. Это что же получается - что при упаковке JPEG последовательность байт FFxx, удовлетворяющая приведённому выше условию не может встретиться? Неужели нет точного способа вычислить размер FFDA (SOS-блок (Start of Scan))?..

Автор: Grom PE Oct 16 2007, 08:02

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

Автор: -=CHE@TER=- Oct 17 2007, 05:09

QUOTE(Grom PE @ Oct 16 2007, 08:02 AM) *
Хотя, может, это и правильно — пытаться достать "хоть что-то целое" у недокачанной картинки?
Ага, спасибо.
Думаю, что нет. ИМХО, тогда нужно резать всё, что идёт после FFD9 и, если этот блок не найден, то файл считать недокачанным и переписывать всё что идёт после FFDA от начала и до конца.

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

Особенности:
1) Картинка в CMYK
2) Из моих программ (XnView / ACDSee 5.0) картинку правильно показывает только фотошоп - во всех остальных ярко ядовитый зелёный цвет.
3) Стрипать можно всё, кроме блока FFEE (сейчас он тоже стрипается), иначе картинку даже фотошоп неправильно отображает.
4) Судя по http://www.impulseadventure.com/photo/jpeg-decoder.html 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

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

Автор: -=CHE@TER=- Oct 23 2007, 09:08

QUOTE(Alex @ Oct 20 2007, 12:55 PM) *
-=CHE@TER=- а графический вариант уже есть? smile.gif
В смысле - графический?

Автор: Alex Oct 23 2007, 14:03

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

Автор: -=CHE@TER=- Oct 23 2007, 17:28

QUOTE(Alex @ Oct 23 2007, 02:03 PM) *
Ну всмысле что бы не надо было прописывать всякую... Вообщем что бы всё просто было, раз кнопочку нажал, два кнопочку нажал. ))
Вообщем готовый вариан дай пожалуйста, а то мне по крайней мере не понятно что там наверху. wink.gif
А, точно, ты же скомпилировать не можешь.
Ну, вообще-то:
а) программа на стадии разработки
б) она консольная (т.е. там нет кнопок)
В принципе, бета-версию можно выложить.
Ты умеешь с консольными утилитами работать?

Автор: Alex Oct 23 2007, 20:38

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

Автор: -=CHE@TER=- Oct 24 2007, 11:17

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

Автор: jTommy Dec 1 2007, 14:21

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

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

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

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

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

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


Автор: -=CHE@TER=- Dec 1 2007, 16:00

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

QUOTE(jTommy @ Dec 1 2007, 02:21 PM) *
Вот что получилось:
CODE
Файлов     Размер     Сохранено
14000       1гб          39мб
2220      212мб         403кб
13152       2гб         8.6мб
7119        2гб          20мб
Не очень, конечно, много съэкономило, но всё же... Какие-то у тебя файлы частично пострипанные. (*улыбается*)

QUOTE(jTommy @ Dec 1 2007, 02:21 PM) *
Обработка каталога с 14тыс файлов заняла всего несколько минут. Часто размер мусора в одном файле доходил до 40кб.
40кб - не предел. (*улыбается*)

QUOTE(jTommy @ Dec 1 2007, 02:21 PM) *
Глюки: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));

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


QUOTE(jTommy @ Dec 1 2007, 02:21 PM) *
2. Файлы с русскими буквами в консоли показываются крякозябрами. Не знаю чей это глюк, у меня ХР английская, возможно из-за этого. Far Manager нормально показывает русский язык.
А, ну дык: CharToOEM(). Исправил.

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

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

Автор: Grom PE Dec 1 2007, 16:36

QUOTE(-=CHE@TER=- @ Dec 1 2007, 11:00 PM) *

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

P.S. Кажется, http://www.ctpax-x.org/index.php?goto=about нужно обновить =)

Автор: jTommy Dec 1 2007, 16:44

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

QUOTE(-=CHE@TER=- @ Dec 1 2007, 07:00 PM) *
Не очень, конечно, много съэкономило, но всё же... Какие-то у тебя файлы частично пострипанные. (*улыбается*)
Я наоборот, ожидал меньшей пользы. smile.gif

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

Автор: -=CHE@TER=- Dec 2 2007, 05:42

QUOTE(Grom PE @ Dec 1 2007, 04:36 PM) *
Все правильно, я же теперь в команде.

P.S. Кажется, http://www.ctpax-x.org/index.php?goto=about нужно обновить =)
О, блин, точно. (*улыбается*) Совсем забыл. Спасибо! Заодно актулизировал информацию в связи с тем, что Extractor.ru ожил.

QUOTE(jTommy @ Dec 1 2007, 04:44 PM) *
Оказывается битых файлов было не 4 а около 15 (я их незаметил, потому что она на них не зависла). Теперь со всеми работает правильно.
Кстати, думаю, нужно разрулить ситуацию с .BAK файлами да на сайт выложить - пущай другие тоже оценят. (*улыбается*)

QUOTE(jTommy @ Dec 1 2007, 04:44 PM) *
Предлагаю еще одну опцию:
- оставлять Exif информацию (прога удаляет весь мусор, кроме Exif).
Хе-хе. Как раз на exif-то больше всего инфы и стрипается.
Кстати, вопрос тогда: никто не знает exif - это один FF xx блок или несколько? Туда же, вроде, ещё уменьшенные превьюшки входят или это другой блок?
Короче, спасибо за todo - вынес его в первый пост под номером 4. Надо обмозговать.

Автор: jTommy Dec 2 2007, 08:07

QUOTE(-=CHE@TER=- @ Dec 2 2007, 08:42 AM) *
1) Косяк с .BAK файлами - если переименовывать, то FindNext возвращяет новый .JPG с таким же именем, уже стрипнутый
2) Улучшить поддержку .BAK - чтобы .BAK файл не создавался, если ничего не стрипалось
Сканируем .jpg, "не мусор" записываем в .tmp файл. Дошли до конца .jpg файла, переименовываем: .jpg -> .bak; .tmp -> .jpg. Если мусора не оказалось - ничего не делаем. Создается только один .tmp файл.
Или в два прохода: сначала сканируем, если мусор есть, тогда возвращаемся в начало .jpg и начинаем записывать в .tmp. Но так как случай, когда мусора нет вообще встречается редко (во всяком случае, в моих файлах) можно не заморачиваться с этим вариантом.

QUOTE(-=CHE@TER=- @ Dec 2 2007, 08:42 AM) *
3) Что делать с изображениями с не ICC профайлом (см. ниже)?
Я так понимаю, они настолько редки, что на них можно забить. smile.gif Это изображение, которое ты выложил, даже Corel Photo-Paint X3 неправильно отображает. Ну или научится их распознавать.

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

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

Автор: -=CHE@TER=- Jan 21 2008, 07:57

Пофиксил работу с повторной обработкой - сначала делаю список файлов в памяти и его обрабатываю потом.
Косяк с двумя косыми чертами - 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

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

Автор: Grom PE Jan 21 2008, 09:55

-=CHE@TER=-
http://grompe.org.ru/pic/cpt9.jpg
После обрезки, файл перестает нормально читаться 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

Обновил первый пост - 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 заголовок. Вот примеры:
http://www.ctpax-x.org/uploads/dupjpghdr.zip (102 533 байта)
Может в массив, который у меня сейчас используется для секций (Sect[]) добавить поле - номер секции с проверкой: дублирующиеся секции не добавлять?

Автор: Grom PE Mar 27 2008, 14:27

QUOTE(-=CHE@TER=- @ Mar 27 2008, 08:36 PM) *
- show error if no files given
Не совсем понял про что тут речь - объясните, кто добавил, или уберите из to do.

Добавил я. Имел ввиду, что нужно выдавать ошибку, если ни один файл не был найден по маске.

Автор: -=CHE@TER=- Nov 15 2008, 09:47

Нашёл, наверное хрестоматийный, пример безнадёжно изгаженной картинки:

CODE
http://www.bruteprop.com/v3/gallery/images/wesk811.jpg

Занимает 819,693 байта из которых остаётся только 228,764, а остальные 590,929 байт - не поверите - мусор!!!
Причём редкостный мусор, который точно никому не нужен - если интересно скачайте картинку и посмотрите на её содержимое где-нибудь в FAR'е по F3 - и этот хлам качается без спроса и согласия.
Но такие картинки скорее исключение из правил, нежели правило, однако наглядно показывают как нужно правильно тратить чужой трафик, делать невыносимо тяжеловесные сайты и пользоваться настолько же убогим софтом создающим такие файлы.
Это не учитывая то, что для такого скудного количества цветов самым подходящим форматом по критериям размер/качество был бы .PNG!
Справедливости ради нужно отметить, что после снятия всякого в файле вылетают цвета - ICC-Profile?..
Надо, всё-таки, прикрутить его поддержку в JPGStrip. Постараюсь глянуть что в этой картинке не так.

Автор: Grom PE Nov 18 2008, 16:35

QUOTE(-=CHE@TER=- @ Nov 15 2008, 17:47) *
ICC-Profile?..
Надо, всё-таки, прикрутить его поддержку в JPGStrip. Постараюсь глянуть что в этой картинке не так.
А что там прикручивать? Раскомментировать $EE в JPEGAllowBlocks и всё.
Кстати, это не ICC-профиль, а указание на то, что картинка в CMYK. И занимает всего 16 байт.

Автор: -=CHE@TER=- Nov 18 2008, 16:44

QUOTE(Grom PE @ Nov 18 2008, 16:35) *
А что там прикручивать? Раскомментировать $EE в JPEGAllowBlocks и всё.
Кстати, это не ICC-профиль, а указание на то, что картинка в CMYK. И занимает всего 16 байт.
Проблема в том, что у некоторых не CMYK картинок этот блок тоже торчит, хотя если его убрать ничего не изменится. Надо как-то детектить, когда его можно резать, а когда нет.

Автор: Grom PE Nov 18 2008, 17:53

QUOTE(-=CHE@TER=- @ Nov 19 2008, 00:44) *
Проблема в том, что у некоторых не CMYK картинок этот блок тоже торчит
Хотелось бы пример такой картинки.

Автор: -=CHE@TER=- Nov 19 2008, 12:33

QUOTE(Grom PE @ Nov 18 2008, 17:53) *
Хотелось бы пример такой картинки.
Да запросто - бери любую картинку, открывай в Photoshop и сохрани её там в .JPG - независимо CMYK она или нет 0xEE там будет с надписью "Adobe"#0. Я уже http://www.forum.ctpax-x.org/index.php?showtopic=133#entry1398 об этом (см. 3, 4).


Добавлено:
QUOTE(Grom PE @ Nov 18 2008, 16:35) *
Кстати, это не ICC-профиль, а указание на то, что картинка в CMYK.
Некогда было разбираться просто - поэтому предположил, что ICC.

Автор: -=CHE@TER=- Dec 4 2008, 19:42

JPGStrip 0.26
Прикручена поддержка CMYK и арифметического кодирования.
Исходные коды на Team FTP.

Автор: -=CHE@TER=- Feb 27 2011, 10:40

На сайте в новостях есть, но тут более подробно напишу (в принципе, в .DPR файле вначале это всё описано):

JPGStrip 0.27
- исправлена ошибка, когда не сохранялась дата у файлов с атрибутом "только для чтения"
- перетащил несколько процедур и функций в .DPR файл, чтобы можно было компилировать с любой версией "helpers.inc"
- используется DCC32HACK компилятор - на 512 байт меньше размер
- версия больше не BETA (что уж там - 2 с лишним года прошло)

Исходные коды на Team FTP.