Графический формат , Какой меньше?

Есть ли формат который бы весил меньше jpg и по качеству ему не уступал?

Лучше jpeg сжимают wavlet алгоритмы сжатия, и фрактальное сжатие.
Фрактальное сжатие - формат fif.
С помощью него сжал картинку на порядок меньшего размера, чем jpeg. (Правда сжимал где - то минут 40).

в некоторых случаях gif совсем не уступает jpg и весит при этом меньше. Но вообще-то все сильно зависит от размеров и качества картики (для широкораспространенных форматов)

Правда гиф 256 цветов

Цитата

Andrey_Kun, 27.07.04, 10:06
Правда гиф 256 цветов

само собой
png в этом отношении лучше
Да и есть ли смысл гнаться за маленькими размерами картинок? Разве что изображение очень большое и надо передавать его в инет...

Если по сравнению с обычным jpegом, то jpeg2000 или LizardTech DjVu.

В некоторых случаях PNG обходит и JPEG и GIF по сжатию и качеству.
Поддерживает до 48 бит на пиксел.

http://www.niac.ru/graphinfo.nsf/36536803d...7e?OpenDocument

архив, 96 кб
Прикреплённый файлtest.zip (95.98 Кбайт, скачиваний: 162)

а что за Jpeg2000

Jpeg2000 Это новый стандарт в котором устаревшее дискретное косинусное преобразование заменено на вейвлет преобразование Добеши.
Подробнее можно узнать здесь

Цитата

Romtek, 28.07.04, 03:31
В некоторых случаях PNG обходит и JPEG и GIF по сжатию и качеству.

Когда я делал свой аватар, столкнулся именно с таким случаем
png - 2.69 K
jpg - 7.38 K
gif - 5.07 K

так этот Jpeg2000 уже есть под Делфи?

Посмотрите вот на эту тему!

Но к делфи не имеет никакого отношения...

Посмотрите вот на мой компессор:

тот ваш PNG файл размером в 18кб, мой компрессор сжал до 9кб !!!
Прикреплённый файлssp.zip (32.34 Кбайт, скачиваний: 160)

SCINER
Не работает твой компрессор. Файл BMP 45МБ не смог открыть. Другии файлы сжал, но по размеру больше чем jpg и не всегда открывает свой же формат. Замечено переполнение стека. При сжатии в фото.

Форматами надо уметь ПРАВИЛЬНО пользоваться-
например если в картинке много схожих цветов,
то больше подойдет GIF- он сохраняет по такому
принципу: если он видет пять стоящих подрят
пикселей одного цвета, то в отличае от др.
(не знаю про PNG) форматов он не пишет
черн. пикс., черн. пикс, ..., и т.д. Он
пишет 5 ЧЕРН. ПИКС.! JPEG тоже хорош,
но этот формат плох тем, что он фигова
сохраняет надписи - вокруг него появляются
точки разных оттенков цвета того текста!
Поэтому в разных случаях приходится
использовать разные форматы!
Поэтому выбор за вами!

png свои данные сжимает zlib'ом (обычным архиватором), поэтому потери качества нет

PNG превосходит по сжатию GIF на всех изображениях, включая малоцветные.

Цитата Romtek @ 27.07.04, 21:31

В некоторых случаях PNG обходит и JPEG и GIF по сжатию и качеству.

Это все ерунда, поскольку JPEG - это сжатие с потерями, а это значит что часть информации удаляется из файла, но алгоритм сжатия JPEG далеко не самый слабый даже по сравнению с PNG. Как при таких условиях сжатие с потерями может уступать беспотерьному. Просто формат jpeg является многофункциональным и помимо информации о изображении может содержать еще кучу другой, да и заголовок у него не самый короткий. Я могу в jpeg размером 15 кб, добвать 100мб баласта и при этом он будет соответствовать стандарту. Нужно сравнивать "очищеный" jpeg а не любой вообще.
Интересен тот факт что различные программы сжимают картинки в jpeg c разной степенью потери качества, при всех равных параметрах сжатия. И это не смотря на то, что формат стандартизирован и не допускает вольностей. В этом смысле лидеры Photoshop и ACDSee - их jpeg ближе всего к оригиналу. Хуже всего себя показал делфийский модуль Jpeg. Это было сказано к тому, что методика сравнения далеко не однозначна.

Формат png делался как бесплатная замена GIF (правда с недавнего момента он тоже бесплатный). Png представляет собой архив одной из разновидностей PKZIP, специально оптимизированой для сжатия цвета, что позволило досичь степени сжания недоступной даже WinRAR и 7z. Что касается количества цветов то это 24-bit/48-bit для true-color
и 32-bit/64-bit при использовании альфа-канала.

про фрактальное сжатие

Цитата

Фрактальное сжатие

Эта группа алгоритмов, по-видимому, является самой перспективной и развивается сейчас наиболее бурно. Первые практические результаты были получены совсем недавно - в 1992 году - и произвели ошеломляющее впечатление. Коэффициент сжатия у фрактальных алгоритмов варьируется в пределах 2-2000. Причем большие коэффициенты достигаются на реальных изображениях, что, вообще говоря, нетипично для предшествующих алгоритмов. Кроме того, при разархивации изображение можно масштабировать. Уникальная особенность этого алгоритма заключается в том, что увеличенное изображение не дробится на квадраты. Во фрактальном сжатии используется принципиально новая идея - не близость цветов в локальной области, а подобие разных по размеру областей изображения. Это, безусловно, наиболее прогрессивный подход на сегодняшний день. Алгоритм ориентирован на полноцветные изображения и изображения в градациях серого цвета.

Его особенностью является потребность в колоссальных вычислительных мощностях при архивации. При этом распаковка требует меньше вычислений, чем у JPEG. Фактически, это первый существенно несимметричный алгоритм, упоминаемый в этой статье. Причем, если у предыдущих алгоритмов коэффициент симметричности (отношение времени архивации ко времени разархивации) не превышал 3, то у фрактального алгоритма он колеблется в пределах 1000-10000. Как следствие - основные работы сейчас ведутся по распараллеливанию и ускорению его работы. Фрактальное сжатие реализовано в формате FIF.

JPEG2000 - многие хвалят за еще более высокую степень сжатия. Может на определенных типах изображения это так и есть, но как показала проверка JPEG2000 по размеру в 2 раза меньший обычного jpeg зачастую и гораздо хуже его .
Так что если говорить в целом, то степень сжатия возрасла не более чем в 1,5 раза, хотя в большинстве анонсов утверждают что в 2-3 раза. JPEG2000 имеет один временный недостаток - пока не распространен и мало поддерживается.

Всякие там PCX и еще куча других форматов использующих слабые алгоритмы сжатия типа RLE, вообще рассматривать не стоит, а вот как ни странно BMP, в этом случае не самый плохой, так как начиная начиная с Windows 2000, этот формат позволяет хранить в себе данные jpeg сжатия, что позволяет достичь высокую степень сжатия.

Из всего перечисленого можно сделать следующие выводы из быстрых алгоритмов сжатия с потерями с лучшее качество дают Wavelet алгоритмы (jpeg2000, Djvu, и др.) вполтную к ним приближается jpeg, bmp(jpeg).
Для сжатия без потерь лучше всего подходит PNG, bmp(png) как самый прогресивный формат поддерживаемый современными браузерами. Формат GIF из-за своих серьезных ограничений практически уйдет из применения.

Фрактальный алгоритм это формат будующего, по одной простой причине, что при его реализации используются алгоритмы с экпоненциальной зависимостью времени кодирования от размеров изображения, это не просто проблема слабости процесоров, а проблема вообще всех класических процесоров. Для пущей наглядности приведу пример.(все цифры не имеют отношения к реальным алгоритмам и носят показательный характер) Пусть картинку 500 на 500 пикселей сможет сжать средний компьютер за 20 минут, тогда картинку 1000 на 1000 не смогут закодировать все компьютеры земли за все время их жизни, а для картинки 2000 на 2000 не хватит атомов во всей вселенной чтоб сделать столько класических процессоров которые могли бы провести расчет даже за астрономическое время. Вот такой вот рост. Но в будущем, как некоторые уже знают, возможно появятся квантовые компьютеры, которые призваны решать именно задачи с экспоненциальным временем обсчета(для них оно линейное). Т.о. данный алгоритм в данный момент имеет существеные ограничения и практически не может быть использован.

Сообщение отредактировано: alexeis1 - 20.08.06, 15:42

Помойму ты заблуждаешься насчет фрактального сжатия, причем глубако.

Помойму будущенее не заметодами сжатия, а за методами расжатия.

Цитата alexeis1 @ 19.08.06, 23:34

Это все ерунда

Если цитируешь, то цитируй всё, а не выборочно!

Цитата Romtek @ 27.07.04, 21:31

В некоторых случаях PNG обходит и JPEG и GIF по сжатию и качеству.

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

а мне в "чертежах, схемах и любых других немногоцветных изображениях" GIF рулит. да и сам распаковщик этого формата весит (в коде) очень мало.

Цитата Pavia @ 20.08.06, 01:10

Помойму ты заблуждаешься насчет фрактального сжатия, причем глубако.

Ну хорошо, для маленьких картинок типа аваторов можно применять и сейчас.

Добавлено 20.08.06, 15:43

Цитата Romtek @ 20.08.06, 08:48

Если цитируешь, то цитируй всё, а не выборочно!

Sorry, поправил

Добавлено 20.08.06, 15:57

Цитата Pavia @ 20.08.06, 01:10

Помойму будущенее не заметодами сжатия

Ну это вопрос спорный, на врядли веб програмист захочет потратить 20 минут, чтоб сэкономить 15кб

Добавлено 20.08.06, 16:03

Цитата Romtek @ 20.08.06, 08:48

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

О чем вы говорите, я вот только что сделал красный квадрат 500 на 500 и сжал его png и jpeg
результат
для jpeg(85%)= 2 520 байт
для png = 4 179 байт

Добавлено 20.08.06, 16:14
Дальше проверяю градиентную заливка по типу "шарик"
jpeg(80%) = 25 339 байт
png = 62 838 байт

разница еще более существеная.

Ну проверку на пестрых картинках я думаю проводить нет смысла.

Сообщение отредактировано: alexeis1 - 20.08.06, 16:14

Прикреплённый файлImage.zip (3.39 Кбайт, скачиваний: 123)

RedChrom, выбор формата зависит от типа картинки в файле... Скажем, если тебе надо фотографию записать - я JPEG бы посоветывал (ну, или его потомки).... А если у тебя, скажем текст на картинке, или чертёж, то явно gif круче, так как JPEG будет немного "размывать" изображение...

Посмотри картинки в аттаче... Там JPEG с 0 качеством и GIF с 4я цветами Gif и весит в 3 раза меньше там и качество круче намного...
Прикреплённый файлgraph.zip (6.68 Кбайт, скачиваний: 115)

Цитата alexeis1 @ 20.08.06, 15:41

я вот только что сделал красный квадрат 500 на 500 и сжал его png и jpeg

Во-первых, чем сжал? Мой ACDSee сжимает "красный квадрат" 500*500 в 1,855 байт для PNG, так что...

Цитата alexeis1 @ 20.08.06, 15:41

Ну проверку на пестрых картинках я думаю проводить нет смысла.

А я все-же рискну: кусок скриншота (619*584) (в аттаче)
PNG: 56,081 байт
JPG (85%): 104,956 байт
Кстати, GIF дал размер 79,692 байт

(и заодно сравни качество, особенно это заметно на строке BreakPoint-а с белым текстом)
Прикреплённый файлImage.zip (140.64 Кбайт, скачиваний: 118)

Цитата alexeis1 @ 20.08.06, 15:41

О чем вы говорите, я вот только что сделал красный квадрат 500 на 500 и сжал его png и jpeg
результат
для jpeg(85%)= 2 520 байт
для png = 4 179 байт

Добавлено Сегодня, 18:14
Дальше проверяю градиентную заливка по типу "шарик"
jpeg(80%) = 25 339 байт
png = 62 838 байт

разница еще более существеная.

Ну проверку на пестрых картинках я думаю проводить нет смысла.

Теперь мои исследования на эту тему...

Размеры объектов: 500х500 (примерно).

rect1 - квадрат с радиальным градиентом.
rect2 - квадрат с вертикальным градиентом.
cir - окружность с вертикальным градиентом.
cir2 - окружность с градиентом под углом около 45 градусов.

Параметры сжатия:
в JPEG - качество 85%.
в PNG
level-6 - default compression level
level-9 - max compression level
PNGOUT - с помощью стороннего плагина (Irfan View).

Размер сжатых изображений (в байтах):

49,913 rect1-level-6.png
40,135 rect1-level-9.png
33,272 rect1-pngout.png
13,963 rect1.jpg

12,390 rect2.jpg
 2,268 rect2-level-6.png
 1,817 rect2-level-9.png
 1,807 rect2-pngout.png

18,725 cir.jpg
14,436 cir-level-6.png
13,509 cir-level-9.png
12,852 cir-pngout.png

48,569 cir2-level-6.png
28,763 cir2-level-9.png
24,336 cir2-pngout.png
18,071 cir2.jpg

Проверил также сжатие Image1.png (однородная заливка цветом) и получил такие результаты:

 1,857 Image1-level-6.png
 1,460 Image1-level-9.png
   125 Image1-pngout.png

125 байт для изображения - слабо в JPEG? И не знаю в какой программе и с какими параметрами сжатия ты пробовал, но у меня результаты получились другие. Не в Паинт, случаем?

Вывод:
PNG следует пользоваться при вертикальных и горизонтальных градиентах (ну и одноцветных, разумеется). Формат показал себя намного выгоднее в этих типах изображения при качестве изображения-оригинала.
В остальных случаях - JPEG.

Borland Delphi 7 для векторной графики лучше всего подходят векторные форматы использовать растровые не рационально, кстати в png эта картинка в 1,5 раза меньше чем GIF.

Цитата volvo877 @ 20.08.06, 21:33

Во-первых, чем сжал? Мой ACDSee сжимает "красный квадрат" 500*500 в 1,855 байт для PNG, так что...

volvo877
Странно, только что сжал PhotoShopом, опять больше 4кб.
А насчет скриншотов это оч. любопытно и неожидано! Да алгоритм сжатия в png очевидно гораздо мощнее. Устарел jpeg, пожалуй слишком, а реальной замены нет. JPEG2000, позволяет получить и меньше чем png, но при ужасном качестве. Тем не менее градиетны png сжимать не умеет, скорее всего многоцветные изображения.

Добавлено 20.08.06, 22:27
Romtek Все я понял откуда размер более 4кб, PhotoShop туда цветовой провиль пихает, т.е. как обычно баласт.

GIF уступает PNG по всем параметрам, кроме возможности анимации. Но для анимации имеется его аналог, MNG (жаль, что непопулярен).

Добавлено 20.08.06, 22:31
И для схем, и для многих других вещей PNG компактнее GIF получается.

А для простых изображений JPEG'у жирный минус, что не может сохранять изображения в меньше чем 24 бита.

Добавлено 20.08.06, 22:33

Цитата alexeis1 @ 20.08.06, 22:20

Тем не менее градиетны png сжимать не умеет

умеет хорошо, но только вертикальные и горизонтальные.

Romtek пришлите свои примеры, у меня ни как не выходит получить градиент png меньший чем Jpeg, ни горизизонтальный, ни вертикальный ни ромбовидный, ни шарообразный.

Да, к стате, существенным плюсом png является поддержка прозрачночти... ну вы знаете....

Удалил ранее, пришлось заново делать:
Прикреплённый файлrect1306.rar (5.52 Кбайт, скачиваний: 130)

А вот эллипс с горизонтальным градиентом:
JPEG получился на 2 кб больше.

Прикреплённая картинка

Romtek так не честно, мы говорили о сжатии без потерь для png и сжатии с потерями для jpeg, а вы получили правильный градиент затем проредили его по цветам для того чтоб получить палитру 256 индексированых цветов.
Вот как выглядит красный спектр вашего градиента


А вот так выглядит полный непрореженый градиент


Вы попробуйте сжимать png без потерь.
В том что у png алгоритм сжатия немного сильнее, а заголовок у jpeg несколько больше мы уже убедились. Но это все никак не относится к сравненю сжатия с потерями и без потерь! Я же проводил эксперименты с правельным градиентом, и не зря утверждал что сжате с потерями должно давать всегда меньший размер чем сжатие без потерь. png - получает лидерство только в картинках с малым количеством цветов, типа скриншотов, это связано вероятно с тем, что из него выжимали максимум для получения максимального сжатия. jpeg создавался как универсальный внеплатфоменый формат, который может быть легко обработан как писюком, так мобильником. В связи с этим на расположение данных и на структуру заголовка, были наложены более жесткие условия. Да согласен, что из-за того что jpeg использует всегда схему True color, он не способен хорошо сжимать изображения с числом цветов 256 и менее, тут я серьезно ошибался.

Сообщение отредактировано: alexeis1 - 21.08.06, 08:08

Цитата alexeis1 @ 21.08.06, 07:19

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

Не Я его прореживал, а алгоритм сжатия, позволю заметить.

Цитата alexeis1 @ 21.08.06, 07:19

Вы попробуйте сжимать png без потерь.

О каких потерях в качестве PNG ты говоришь?

Добавлено 21.08.06, 07:59

Цитата alexeis1 @ 21.08.06, 07:19

затем проредили его по цветам для того чтоб получить палитру 256 индексированых цветов.

Это при каком сжатии? Или при всех?

Добавлено 21.08.06, 08:02

Цитата alexeis1 @ 21.08.06, 07:19

Я же проводил эксперименты с правельным градиентом

я что-то о таких не слышал.

Цитата Romtek @ 21.08.06, 07:55

О каких потерях в качестве PNG ты говоришь?

Как о каких, а удаление промежуточных цветов из палитры это что не сжатие с потерями? Когда такое делает jpeg обычно это называют потерями, а для png разве придумали другое название?

Цитата Romtek @ 21.08.06, 07:55

Не Я его прореживал, а алгоритм сжатия, позволю заметить

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

Под "правильным градиентом" я понимаю непрерывный спектр.

p.s.

Цитата Romtek @ 21.08.06, 07:55

правельный

когда посты пишешь еще и не такое бывает, главное вовремя поправить

Сообщение отредактировано: alexeis1 - 21.08.06, 08:18

Цитата alexeis1 @ 21.08.06, 08:14

Под "правильным градиентом" я понимаю непрерывный спектр.

А как он у тебя получается непрерывным? У меня при выборе заливки градиентом по умолчанию получается гистограмма, как на снимке экрана.

Цитата alexeis1 @ 21.08.06, 07:19

Вот как выглядит красный спектр вашего градиента

видимо, у меня по умолчанию создаётся линейного типа градиент, а у тебя - какого-то другого. Кстати, одно изображение с "обрезанной" гистограммой получил в Inkscape (векторном редакторе), а в GIMP - сплошную.
Хорошо PNG сжимаются только градиенты с "обрезанной" гистограммой.
Ты так и не ответил откуда ты взял гистограмму от двух образцов ихображений. На каких файлах проверял?

Цитата alexeis1 @ 21.08.06, 08:14

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

Нет, это отдельная операция над изображением и я её не проводил.

вот:

Прикреплённая картинка

Вот градиент, созданный с помощью Inkscape и сжатый с помощью PNGOUT-плагина для Irfan View. Гистограмма обрезанная, но я не знаю как выяснить, индексировал ли он при сжатии изображение или нет.

Прикреплённая картинка

Цитата Romtek @ 21.08.06, 09:34

Ты так и не ответил откуда ты взял гистограмму от двух образцов ихображений. На каких файлах проверял?

Да фотошопом и рисовал, указал два цвета и протянул линию от одного края до другого.

Цитата Romtek @ 21.08.06, 09:34

Кстати, одно изображение с "обрезанной" гистограммой получил в Inkscape (векторном редакторе), а в GIMP - сплошную.

Так речь не идет о том обрезана она или нет, это определяется только граничными цветами. Я говорю про забор. Фотошоп тоже делает любоапытный градиент (по краям интенсивнее), но при этом он не прореживает цвета, т.е. сохранет все оттенки указаного диапазона. За счет чего кол-во цветов естествено, переваливает за 256, у нас же размерчик 500 на 500, а не 250 на 250.

Цитата alexeis1 @ 21.08.06, 09:46

Да фотошопом и рисовал, указал два цвета и протянул линию от одного края до другого.

а с "разреженной" гистограммой?

Прикрепляю bmp-шку в сделаную в форошопе, сожмите ее png, и посмотрим что получится.

Сообщение отредактировано: alexeis1 - 21.08.06, 10:11

Прикреплённый файл1.zip (130.65 Кбайт, скачиваний: 130)

Цитата alexeis1 @ 21.08.06, 09:46

Фотошоп тоже делает любоапытный градиент (по краям интенсивнее), но при этом он не прореживает цвета, т.е. сохранет все оттенки указаного диапазона. За счет чего кол-во цветов естествено, переваливает за 256, у нас же размерчик 500 на 500, а не 250 на 250.

В общем, подытожим нашу увлекательную беседу:
Свойства PNG/JPEG:

• PNG отлично сжимает векторные (простые) изображения, с "разреженными" (индексированными?) градиентами.
• PNG не так хорошо сжимает полные (неразреженные) градиенты (в Photoshop/GIMP) и фотографические изображения, как JPEG.
• Снимки экрана программ (опять же, не обоев) сжимает отлично, лучше JPEG.
• Все малоцветные веб-элементы стоит также сжимать PNG.

Romtek, но еще надо иметь ввиду (на будущее), что wavelet, алгоримы постепенно вытеснят, jpeg (их популярноть быстро растет), а вот фракталы, пока слишком экзотичный зверь и его будущее не определно.
Кроме того чертежи и графики лучше хранить в векторных форматах таких кака emf, и т.д. Лидеров в этой области указать не берусь, хотя и это весьма интересная тема.

Сообщение отредактировано: alexeis1 - 21.08.06, 10:23

alexeis1, не могу открыть твой 7z. Зачем 2 раза паковать? Оставь известный всем ZIP.

Цитата Romtek @ 21.08.06, 10:48

Зачем 2 раза паковать? Оставь известный всем ZIP.

К сожалению zip архив превышает 200кб. А паковал два раза, поскольку этот форум не разрешает закреплять файлы типа 7z. Удивительно, что вам не удалось его распаковать. 7z распаковывают не только сам архиватор, но и WinRar 3.5 и старше, totalCommander, powerAchiver. Если ничего из вышеперечисленого у вас нет, то я запакую rar

Ни Винрар, ни Тотальный командер не открыли, ни даже утилита 7z.exe

Ладно тогда выкладываю архив винарар в зипе

Сообщение отредактировано: alexeis1 - 21.08.06, 19:38

Прикреплённый файл1.zip (122.84 Кбайт, скачиваний: 149)

Для данного изображения ответ остаётся таким же, как сказано в сообщении #43.

Romtek, если не трудно какая программа сжимала (название, версия) мне уж очень захотелось ее протестировать.

Цитата alexeis1 @ 22.08.06, 12:18

если не трудно какая программа сжимала (название, версия) мне уж очень захотелось ее протестировать.

Уже не раз писал, Irfan View, 3.97.