Pull to refresh

Comments 35

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

Но, как уже сказано выше, идею следует дорабатывать.
Согласен, дорабатывать надо, подскажите какие бы Вы видели существенные преимущества?

Думаю, тут стоит определиться с областью применения. Это укажет на необходимость нового формата.


Если идти по пути наименьшего сопротивления (и если я всё верно оценил), то пожалуй, формат может стать очень актуальным для спецефических, но востребованых изображений. Например:


  • Фотообои с высоким боке/блуром
  • Однотонные/градиентные фоны
  • Фоторамки (для печати, открыток и т.д) где более 90% экрана — белый фон
  • Фото с минимализмом
  • С многократно однотипно повторяющимися элементами
  • С ограниченной палитрой (сюда автоматом монохром и рисованные с несколькими цветами)

Практически все вышеназванные примеры на мой взгляд логичнее описать математичесски (вектрно) с небольшими "попраками"растра. "Весить" такие изображения должны существенно меньше, а обрабатываться быстрее.
P.s.
С мобильника не очень удобно искать и вставлять ссылки на картинки (и возможно моя карма хабра этого не позволит), но надеюсь донести мысль удалось))

Сдаётся мне, что автор будет долго эвристики писать даже для одного варианта.

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

Надо определиться или без потерь, или с.
А там уже смотреть.
Мне кажется, что скорость, если без потерь.
И сжатие/качество если с потерями.
Подозреваю, что обогнать стандартные алгоритмы не выйдет в подавляющем большинстве случаев.
Теоретически, вы можете сделать чутьт лучше за счёт каких-либо эвристик в определении тех же градиентов и т.п., но нужно ли оно — большой вопрос, как и то, сможете ли вы это реально сделать га кроме достаточном для коммерческого использования.

Без потерь растр — основная миссия, надеюсь с помощью сделать видеокодек

Не покидает мысль о фрактальном сжатии. Которое, например, уже используется в формате djvu

Очень интересно, но ничего полезного для своих изображений найти не удалось.
1. Было бы неплохо посмотреть сравнение с Full HD изображениями, реальными, а не зелёный пиксель.
2. Надо бы ещё сравнить с lossy форматами, которые визуально не отличаются (например, средний разброс на пиксель на канал < 10).
3. В чём заключается цель формата? Сжатие, скорость, гибкость, масштабируемость?

Какие техники сжатия вы используете? Цветовое/палитровое усреднение? Вейвлеты, градиенты?
  1. Для этого надо переложить алгоритм на нормальный язык и оптимизировать его, пока могу проводить анализ лишь на небольших изображениях
  2. Хорошая идея, подскажите как определить 10 или больше
  3. В основном масштабируемость поворот без гал
  4. Аналог дефлейта и кардинально новое кодирование
def comapare(original:ndarray,lossed:ndarray,threshold):
  return (original.astype(float)-lossed.astype(float)).abs()/original.size <= threshold

Как-то так)
Сравнение с lossy форматами, которые визуально не отличаются (например, средний разброс на пиксель на канал < 10) — готово, анализ добавлен в статью, спасибо за идею
Спасибо. Неожиданный результат (впрочем, мой критерий тоже весьма неточен, т. к. человеческий глаз различно чувствует каналы).

Жду с нетерпением возможность «пощупать» ваш формат и сравнить его со своей модификацией jpeg. Он у вас открытый, или требуются какие-то программы? Или вы его ещё не опубликовали?
А Вы какой результат ожидали?

Пока формат закрыт. Буду думать передать его кому-то, найти инвестора и дорабатывать, сделать сайт для пощупать (без исходного кода) или выложить в открытый доступ
Я пытался сжать вот такое изображение.

image

Вот мои результаты с потерями:
Метод >> Размер [Рейтинг]
================
mozjpeg3_scan2q0.jpg >> 7172 [34,6997677147633]
mozjpeg3_scan2q10.jpg >> 43833 [9,30787229938271]
immagick_100kb.jpg >> 90852 [7,37031523276748]
mozjpeg3_scan2q50.jpg >> 176149 [4,72453414351851]
immagick_200kb.jpg >> 198639 [4,83299623842592]
immagick_stripInterlaceplaneQ75Gaussianblur005.jpg >> 275102 [4,76800620498971]
mozjpeg3_scan2msssimq75.jpg >> 278419 [3,72148517875514]
mozjpeg3_scan2q75.jpg >> 316395 [3,5429057355967]
mozjpeg3_defaultsq75.jpg >> 316431 [3,5429057355967]
mozjpeg3_baselineq75.jpg >> 324497 [3,54019257973251]
immagick_stripInterlaceplaneQ75Dctmethodfloat.jpg >> 333342 [3,36465020576131]
immagick_2Q75.jpg >> 334832 [3,37778147505144]
immagick_stripInterlaceplaneQ75.jpg >> 334832 [3,37778147505144]
immagick_stripInterlaceplaneQ75Samplingfactor420.jpg >> 334832 [3,37778147505144]
pingo_sb_sample1_srgb.jpg >> 408000 [1,95785027649176]
pingo_defaults.jpg >> 435437 [1,95785027649176]
mozjpeg3_scan2psnrq75.jpg >> 443252 [1,87784063143004]
mozjpeg3_scan2ssimq75.jpg >> 451224 [1,9114073752572]
mogrify_best.jpg >> 622008 [0,533710615997942]
immagick_stripInterlaceplaneQ100.jpg >> 1113882 [0,548464988425926]
mozjpeg3_scan2q100.jpg >> 1426281 [0,143501961162551]

Эти результаты тоже весьма интересные, т.к. качество 10% даёт рейтинг 9, но качество 10% — это, очевидно, сильно бросается в глаза. Возможно, я ошибся в функции рейтинга (код не сохранился).

p.s.
Проверял и другие форматы (всевозможные архиваторы, bpg, flif, jp2, png, webp, xz, zst), но они проиграли эту гонку.
Рейтинг здесь — это погрешность на пиксель на канал?
Да. Как видите, у качества 0% (размытая картинка) точность изображения +-35 по модулю 256 на пиксель на канал. Если оценивать «на глаз», то рейтинг должен быть примерно меньше 4.
А у вас рейтинг < 10 только без потери качества? Что-то здесь не так… Возможно, вам стоит попробовать сжать моё изображение?
Дело в том, что я подбирал шаблоны для того, чтобы ни одно изображение, сжатое им не выходило > +-10 + у Вас размер изображения большой (ваше изображение без инвестора не смогу сжать — пока только маленькие), а у меня маленькие. Чем больше изображение, тем строже должен быть критерий. И нет не только без потери, но и JPG 80% 4:2:2

Попробуйте взять группу изображений и чтобы ни одно из них не выходило за рамки +-4 (так как изображения большие) в одном шаблоне сжатия. Интересно будет посмотреть, что у Вас выйдет.
Вот что у меня получилось на 100 файлах с помощью pingo, которое даёт рейтинг ~2.
46 271 812 байт -> 33 247 962 байт
первая цифра — это оригинал в JPG? второе тоже в JPG? или как?
Да, это суммарный вес 100 файлов jpg до и после обработки. Получается, было 0,544 бит/пиксель/канал, а стало 0,424 бит/пиксель/канал.
А если взять ваше яйцо с 961 точек, получается 0,014 VPR и 0,034 JPG. Разница на порядок.

Дело в размере, чем больше и сложнее картинка тем больше нужно бит на пиксель

Небольшое описание формата выложил здесь: https://boosty.to/macreative/posts/6187937f-e4b1-48f8-ad4c-a9aa2938b7d1?share=success_publish_link

Небольшое описание формата выложил здесь: https://boosty.to/macreative/posts/6187937f-e4b1-48f8-ad4c-a9aa2938b7d1?share=success_publish_link

Монетизировать формат практически нереально. Никто не согласится покупать фотоаппарат, если фотографии можно будет просматривать только на нем, либо доплачивать за отдельную программу.
Это имеет право на жизнь, только если формат будет на порядок лучше существующих.

Да, на порядок лучше сразу вряд ли, что посоветуете? Забыть? Выложить в открытый доступ и надеяться, что кто-то будет им заниматься?

А если просто например в фотоаппарате будет такая опция сохранять фото в VRP, просматривать в бесплатной программе(программах) с преимуществами формата, конвертировать в ней без потерь в любой другой формат, а также с потерями, оставляя исходник на всякий случай, который не занимает много места?
У Вас реализован алгоритм сжатия бинарных изображений без потерь?
Любых растровых (пока до 8 бит на канал) без потерь реализован (на 5-ом слайде 4,5 строчки)
Я имел в виду битовое изображение — бинарное изображение, для представления и хранения которого в цифровом виде используется битовая карта, где на каждый элемент изображения (пиксель) отводится 1 бит информации.
Существует алгоритм сжатия без потерь (см. Six-page legal document: www.cartesianinc.com/Tech/samples.html), который сжимает изображение более чем в 600 раз. Какой эффект для данного случая от Вашего алгоритма?
Я понимаю, в скором времени представлю анализ, спасибо за образцы изображений (жаль что их придётся уменьшить в габаритах, думаю пока 150х150 только потяну), 600 раз в редких случаях там, в среднем 100 раз
скоро сравнение с форматами, поддерживающими сжатие с потерями
Сравнение с webp и другими готово, анализ добавлен в статью
Sign up to leave a comment.

Articles

Change theme settings