Russian Qt Forum

Добрый день!

При сохранении QImage в графический файл JPEG значительно искажается цветовая гамма изображения. Цвета приобретают более тёмные оттенки. Изменение compression, quality эффекта не дает. В чем может быть причина?

что и что сравнивается?

у нас в компании есть дизайнер который тоже самое говорит, мол качество гораздо ниже, но мне кажется это дизайнерские заморочки, я разницы не заметил.

Ну гамму и смотрите в первую очередь (gamma(), setGamma()). Теоретически может быть еще палитра но маловероятно (кому она нужна)

Вот это вероятнее всего. Для того чтоб на разных мониторах одна и та-же картинка выглядела одинаково в графические форматы добавили параметр гаммы. Хотели как лучше, а получилось как всегда. Кто как хочет так и делает, одни учитывают, другие не учитывают. В общем вместо унификации получили бардак.

Отображение QImage и просмотр файла стандартным win-приложением.

Гамма для JPEG игнорится.

А Вы посмотрите внимательнее на это "стандартное Win-приложение" и станет ясно, что этот кусок поросячьего помёта гадит таким образом во всех просматриваемых файлах. Для примера откройте рядом один и тот же файл в этом дебильном просмотрщике и в чём-нибудь нормальном типа XnView или IrfanView.

Смотрел в IrfanView - эффект тот же.

Дело в том, что если сохранить в bmp, то все ок. Более того: если взять этот bmp и открыть в GIMP, а затем сохранить в jpg, то все ок. То есть косячит именно Qt. ХЗ, пока что делать. Блин, и это критично...

Дело в том, что при сохранение в jpg идет сжатие с потерей качества (т.е. при считывании изображение отличается). Можно поиграться с качеством при записи. Или писать в какой-нибудь формат без потери качества (в png к примеру)

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

Тогда ХЗ. Скриншот в bmp 24+ bit киньте куда-нибудь. Будем посмотреть.

Параметр quality менял...не помогло.

Тебе же русским языком сказали скинь оба варианта jpeg(нормальный и ненормальный). А также BMP.

Не кипятись...еще не успел.

Кидаю файлы.

Как по мне так это из за слишком большого коэффициента сжатия. А там где ты сравниваешь в просмотрщике вообще масштаб не выдержан.

Тыкалка, я же писал уже, что все доступные коэффициенты (compression, quality, gamma) уже пробовал подгонять...не помогло.

Еще кидаю файлы. bmp2.bmp - соотв-ет действительности, jpg2.jpg - не соотв-ет.

попробуй в png сохранить и сравнить результат, мне кажется что после этого все встанет на свои места

C png как раз все ок. Кидаю еще раз файлы.

собственно о чем я и говорил. jpg не очень предназначен для хранения изображений с областями одного цвета и резкими границами между цветами, для этого предназначен gif и png. jpg же пытается смазать эти границы из-за чего скорее всего и происходит изменение цвета, да и границы цветов размываются, теряется четкость изображения.
jpg это обязательное требование тз? Ведь даже по размеру получившегося файла видно что png подходит гораздо больше.

Так что, выходит что jpg не умеет сохранять lossless (без потери квачества)? Бред собачий, конечно умеет.
К концу дня будет время, посмотрю файло

Сама технология записи в jpg подразумевает потерю качества (сравни побитово изображения). Другое дело, что есть разные алгоритмы, которые пытаются сделать эту потерю не видимой глазу (видать по умолчанию в Qt реализован не самый лучший алгорима). Такое изображение лучше сжимать png, tiff или pcx (форматы, которые умеют сжимать без потери качесва). К примеру, на png у тебя получился самый минимальный результирующий размерю

Умеет, но на мой взгляд для сохранения подобных изображений png больше подходит, потому и спросил про тз. Хотя куда уж нам, раз сам Igors сказал что это бред...
Тут код смотреть надо, т.к. на словах топикстартер уже сказал что качество крутил по всякому.

Ну резковато сказал :) Но ведь елы-палы, не раз видел в гугле что есть. Ладно, разберемся

Да есть, есть - никто не спорит. В Википедии про это написано, просто там кроме всего прочего вот такой текст есть:
пруфлинк (http://ru.wikipedia.org/wiki/JPEG)

Ну так если "есть" - то чего же не сохраняет? Ладно, не буду попусту препираться, по теме:

- Qt использует libJpeg (самую популярную реализацию) которая НЕ обеспечивает lossless (даже с задаваемым качеством 100%) http://stackoverflow.com/questions/7982409/is-jpeg-lossless-when-quality-is-set-to-100 (http://stackoverflow.com/questions/7982409/is-jpeg-lossless-when-quality-is-set-to-100)

Дополнительно: набросал утилитку для сравнения картинок "байт в байт" (интересно - выложу) и проверил 2 приложения которые обещают сохранение без потерь

- GraphicsConverter (Mac)
- RealWorld Photos (Вындоуз)

Сохраненные картинки отличаются (никакого lossless не наблюдаю)

Что-то я не понял - а какой собственно смысл пытаться сжать такие картинки JPEG? Он же совершенно для этого не предназначен и при любых раскладах для такой картинки будет сжимать хуже, чем png, gif и даже pcx c RLE? Для сравнения исходный файл (BMP 3 104 694 Байта) в:
PCX - 128868 Байт,
GIF - 7 684 Байта,
PNG - 7 375 Байт.
JPEG c 75% качеством - 85 659 Байт.
Ну и PNG при этом будет без искажений, JPEG - с искажениями, в том числе колористическими.
Для справки:
ZIP - 7 690 Байт,
7Z Ultra - 2 374 Байт (!!!!).
Настоятельно рекомендую избавиться от JPEG для таких картинок.

Ну "рекомендовать" легко, а вот просить заказчика изменить ТЗ - куда менее приятно. И это надо мотивировать и знать точно чтобы утверждать "JPG этого не позволяет". Так что смысл в обсуждении есть/был

Ты точно устанавливаешь 100% качество? Ибо у меня при 100% качестве получается 248кб, а при дефолтном 116кб как у тебя. А вот XnView при максимальных настройках(DCT Method: Float и SubSampling factor: 1x1,1x1,1x1) 262кб и на глаз неотличимо от оригинала. Так что либо лезть в недры кьюта и добавлять возможность менять DCT Method и SubSampling factor, либо взять стороннюю библиотеку которая поддерживает такую тонкую настройку.

C++ (Qt)
    QImage image;
    QString in = QFileDialog::getOpenFileName( this, "Open image", qApp->applicationDirPath(), "Image Files (*.png *.jpg *.bmp)" );
    if( in.isEmpty() ) return;
    if( !image.load( in ) ) return;
    QString out = QFileDialog::getSaveFileName( this, "Save image", qApp->applicationDirPath(), "JPEG (*.jpeg)" );
    if( out.isEmpty() ) return;
    image.save( out, "JPEG", 100 );

От автора автора темы тут про требования ТЗ  ни слова не было. Про "JPG этого не позволяет" от меня - тоже. Так что то с этими упрёками - не по адресу.

А я никого и не упрекал :) По существу вопрос стоит так: "можна" сохранить в jpg 1:1 или "не можна"? То есть да или нет (bool). И вот ответа я что-то не увидел, вместо этого - повторение хорошо известного, мол, jpg хорош для фоток а не... С этим никто не спорит, но ответа-то нет.

Ну так "не на глаз" все же отличимо - значит непринципиально. Предлагаю подытожить так

- средствами Qt сохранение в jpg 1:1 недостижимо. Другими - также проблематично.

100%

Что ты так пессимистично говоришь. Если предполагается использование jpeg, то явно разработчик знает про потерю качества. Но можно добиться максимального качества, когда на глаз неотличимо. И про то что другими средствами проблематично тоже глупость. В аттаче оригинал и jpeg созданный XnView. На глаз ты вообще не увидишь изменений, ибо там погрешность в 1 уровень на канал для 90%, для остальных 10% не больше 5 уровней на один канал. Для сравнения у jpeg сжатый кьютами погрешность до 85 уровней на канал, разница таки большая. И jpeg созданный XnView еще и не так много занимает места, кстати там еще вроде можно попробовать увеличить качество путем отключения всяких оптимизаций под максимальное сжатие.

GIMP практически 1:1 сохраняет.

Специально процитировал полностью. Витя, какие же глупости я сказал? :) Вам удалось сохранить в jpg 1:1 т.е. "байт в байт"? Сами пишете что нет, хотя Вы могли использовать любой софт. Ладно, Вы хотя бы показали как в Qt добиться "приемлемого" результата, не говоря о "точном"? Тоже нет, и Вы тоже сами об этом пишете. Программист Вы конечно творческий/инициативный, но уж очень любите лезть нахрапом :)

Около года назад я цеплял lbJpeg - ну конечно "не хуже др либов", но забот на 2 платформах хватило с избытком. Вам lbJpeg не подойдет, так что забот будет больше. Чего Вы уперлись в этот jpg? Ну очевидно что здесь он совсем нехорош, почему не использовать прекрасный png?

Сохраняю по ТЗ в различные форматы. Увы, но jpg убрать нельзя. Надо хотя бы добиться, чтобы видимо практически не отличалось.

В общем буду пробовать использовать другую либу для этих целей. Подскажите, пожалуйста, кросс-платформенную либу!?

А может просто договориться с заказчиком - ну так, мол, и так - такой формат, для этих целей не предназначен, как сохраняет - так и сохраняет.  Или совсем уж заказчик-зверь попался?  :)

Возникла экспериментальная (возможно глупая) мысль. А если так: сохранить, прочитать, сравнить. Докрутить цвета "в доугую сторону" - опять сохранить. Возможно повторить. Ну понятно если цвет 255 - то крутить уже некуда. Это несложно сделать и может будет дешевле чем мудохаться с либой (эдак с месяц)

Ну а если "принципиально" - гуглите "lossless jpeg"

Никогда jpeg не был lossless кодеком. "Качество 100%" - это значит минимально возможные потери / максимальный размер данных, а не lossless.

А автору и не требуется 1:1 сохранить, ему надо чтобы не было сильных визуальных искажений. У меня нет желания и времени искать jpeg либу и разбираться с ней, тем более что оно мне не нужно. Я указал в какую сторону надо копать: DCT Method: Float и SubSampling factor: 1x1,1x1,1x1.

Это подтверждается тем что я проверил (отвечая в этой теме). Но как быть с многочисленными упоминаниями о lossless в гугле, более того, опциями в очень приличных приложениях? (attach)

Jpeg работает с цветовым пространством YUV.

В нем же идет транляция цифрового телесигнала и вообще всё видео в YUV.
Там вместо 3-х привычных нам компонент (R, G, B) есть 2 компоненты: Y - luma (яркость), UV - хрома - цветорастностная компонента.

Конвертация RGB<->YUV не проходит без потерь, т.к. размеры этих пространств разные.

P.S. Сабсэмплинг 4:4:4 - это хорошо, в подавляющем большинстве случаев используется другой, при нем потери еще больше (т.е. яркость задается для каждого пикселя, в цвет - одно значение на 2 или 4 пикселя), но для человеческого это как правило незаметно.

Читал это где-то в середине 90-х :) Конечно все Вы правильно написали, но вот ответа на мой вопрос почему-то не даете  :)

Возможно тем, что jpeg (Joint Photographic Experts Group) разработал далеко не один кодек и беспотерьные среди них были. Вот только распространения они не получили.
Ну и вариант, что гугл нашёл результаты "jpeg is not lossless" тоже исключать нельзя. ;D

И каков результат? Действительно беспотерьный? А другими программами такой файл открывается?

vipet, насколько я знаю, пространство может быть разное, просто YUV - вариант по умолчанию.

Открывается Ok, но результат НЕ 1:1, т.е. "потерьный" (писал в посте #26)

Ну в теории DCT можно применить к любым данным.. На практике же в jpeg'e кроме YUV ничего не встречал

Встречайте (во вложении).
YCbCr - это как раз то, что обычно называют YUV.
Впрочем на практике встречал только YCbCr и Greyscale (второй встречал у чёрно-белых сканов).

Глянул быстренько исходники libjpeg, кот. идет вместе с Qt, там есть Grayscale, RGB, YCbCr, CMYK и YCCK.

Также глянул IPP (либа от Intel), там есть поддержка lossless jpeg (только для jpeg2000 вроде)

Кстати, для видео используется "сжатый" диапазон для YUV: 16 <= Y <= 235; 16 <= U, V <= 240. Для JPEG используется полный диапазон 0..255 (для 8-битного цвета). Для видео в зависимости от SD / HD (standard / high definition) используются разные формулы для конвертации RGB <-> YUV. Для джпега про такое не слыхал