Нужен ли нам такой формат?.. и немного статистики

    Несколько месяцев в свободное время занимался разработкой нового формата изображений.

    Акценты сделаны на:
    1. Сжатие без потерь
    2. Хорошая векторизация одноцветных объектов
    3. Более быстрое ДЕкодирование, чем у других форматов
    4. Несколько шаблонов кодирования при едином шаблоне декодирования в зависимости от того, что нужно 1, 2, 3 или что-то среднее
    5. Сжатие любых векторных изображений (с потерями, но можно указать до какого масштаба необходима абсолютная точность)
    6. Стилизация (главным образом для придания уникальности изображению + видеоэффекты и т.д.)
    7. Также возможна прогрессивность (отображение по ходу загрузки) при установке неполного сжатия или в 27% случаев
    8. Имитация рисования изображения
    9. Добавление возможностей с обратной совместимостью


    А вот подробная презентация формата:











    На таких масштабах габаритов в среднем на занятое место PNG можно записать те же изображения в качестве 43% JPG, а на VRP – в качестве 44% JPG.

    Теперь на графике (линии тренда полиноминальны, 2-й степени, штриховые линии — экстраполяция моего скудного мозга):



    VRP меньше BMP(почти несжатое) от 1Б до 350 Б и от ~7КБ, то есть сжатие работает.

    VRP при размере несжатого изображения:

    от 1 Б до 250 Б: оптимален
    от 250 Б до 1 КБ: приемлем
    от 1 КБ до 7 КБ: не оптимален
    от 7 КБ до 400 КБ: возможно приемлем
    от 400 КБ: возможно оптимален

    Теперь сравним VRP(без потерь) и растровые форматы, поддерживающие сжатие с потерями (но погрешность не более ±10/256 в среднем на пиксель на канал — спасибо за идею Griboks) — для каждого формата были испытаны различные шаблоны (чтобы все изображения в этом формате удовлетворяли условию — сжатие с потерями прошло успешно лишь у JPG, остальные форматы удовлетворяют условию лишь без потерь)





    Линии тренда логарифмичны, форматы по возрастанию размера:
    JPEG 80% качества субдискретизация 4:2:2
    VectoRabbitPicture без потерь
    JPEG 2000 без потерь
    JPEG XR без потерь
    WebP без потерь

    Также были проанализированы:
    HEIF: не поддерживаются изображения до 64х64 и цвета искажаются в любом случае
    DjVu: в любом случае выходят большие потери
    *область применимости данного анализа – слабо видимые потери качества и небольшие изображения













    При автоматической трассировке из растра результат получается с потерями. В VRP хотя бы нет потерь вплоть до масштаба в 100%.

    И как видно на графике, при этом, иконки, пиктограммы и несложные логотипы в SVG (и почти в любых других векторных форматах) ещё и заведомо в несколько раз будут больше VRP.

    Также, так как VRP – формат без потерь при масштабах до 100%, из того же файла есть возможность получать абсолютно такие же результаты как у PNGА при наличии дополнительного времени даже смешивать разные результаты! Также, при выборе результатов от VRP на это уйдёт меньше времени, чем у растровых форматов

    Более быстрое декодирование


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

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

    Сжатие любых векторных изображений с потерями, но можно указать любой процент потерь









    Линия VRP указывает где находятся другие векторные форматы (по размеру и сколько нужно потерять, чтобы быть в плюсе относительно формата):



    Не ждите, изображение справа не прогрузится лучше)

    Стилизация изображенийдля придания уникальности изображению и создания видеоэффектов. Для стилизации есть несколько революционных возможностей:

    a) Выбор как сильно стилизовать (от 1 до 100)
    b) Сколько цветов использовать (все, 2млн, …, 512, 64, 8) — от этого сильно разнится результат и не только цветами
    c) Выбор формы элемента (круг, треугольник, квадрат, сердечко, кошка…)
    d) Размер полигонов (от 0.5 до 1)
    e) Размер дополнений к полигонам и нужны ли они (от 0 до 1)
    *Для стилизации изображение должно быть в формате VRP



    Вот несколько результатов с разными настройками:

    Над изображением настройки (a,b,c,d,e). Везде без интерполяции



    Автоматический алгоритм не сможет идентифицировать картинку и будет считать её оригинальной, даже если не сильно стилизовать:
    5 параметров (a,b,c,d,e) с совершенно разными значениями плюс несколько вариантов интерполяции (как на входе, так и на выходе) дают бесконечное количество вариантов и даже разные стилизации будут считаться оригинальной картинкой без претензий в нарушении авторских прав.

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

    Прогрессивность


    Обычно на сайтах картинка грузится сверху вниз или иногда качество вырастает по мере загрузки
    В формате VRP так невозможно, но в 27% случаях либо в 100% случаях при выборе шаблона «Быстрейшая прорисовка» во время сохранения, при прогрузке будет улучшаться не качество, а цветность, т.е. картинку сразу видно и можно понять что на ней, плюсом последние стадии прогрузки глазу будут практически незаметны.

    Иллюстрации в оригинальной презентации. (скачивайте и смотрите через F5 в PowerPoint)

    Имитация рисования изображения

    Иллюстрация в оригинальной презентации. (скачивайте и смотрите через F5 в PowerPoint)

    Формат можно будет легко дополнить.

    Развитие формата и добавление новых возможностей с полной обратной совместимостью


    Программы, не поддерживающие новую версию формата всё равно смогут открывать файлы, за исключением новых возможностей. Программы, поддерживающие новую версию формата будут открывать и все старые версии формата, а также если в конкретном случае не будут использованы новые функции — файл сразу станет старейшей версии и будет меньше весить.

    Имеющиеся недостатки


    В основном все недостатки можно устранить, но на это нужно время и средства.

    Пока что медленное конвертирование и сжатие, из-за неоптимизированности алгоритма, использования устаревшего языка программирования и неадаптированности под x64, из-за чего обработка картинок из более 1000 пикселей пока занимает неприемлемое время. Это точно можно устранить, но на это нужно много человеко-часов.

    Сжатие вектора, прогрессивность, имитация рисования точно можно сделать, но пока не полностью реализовано

    Более быстрое декодирование пока не доказано

    Планы развития


    • Устранить недостатки
    • Реализовать всё до конца
    • Улучшить отображение и сжатие насколько это возможно
    • Добавить поддержку прозрачности
    • Разработать на основе этого формата, формат и алгоритмы для анимации и видео со всеми теми же возможностями

    Монетизация


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

    • Приём спонсирования на создание и поддержание открытого формата и бесплатным предоставлением для программ на его основе
    • Продажа лицензий на использование формата в видео/фотоаппаратах/принтерах
    • Продажа программ, реализующих интерфейс для работы с форматом и всеми возможностями алгоритма
    • Создание платной библиотеки для использования формата и сервисов на его основе
    • Продать готовый рабочий продукт крупной компании

    Вот собственно почти и всё. Скоро добавлю ещё несколько таблиц.
    Жду ваших комментариев — нужен ли такой формат? Почему да? Почему нет? Где я может ошибся? Кто готов инвестировать? Кто готов купить работающий прототип?
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 33

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

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

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


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


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

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

            0

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

              0

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

              0

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

                0

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

                  –1

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

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

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

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

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

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

                      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
                        Рейтинг здесь — это погрешность на пиксель на канал?
                          0
                          Да. Как видите, у качества 0% (размытая картинка) точность изображения +-35 по модулю 256 на пиксель на канал. Если оценивать «на глаз», то рейтинг должен быть примерно меньше 4.
                          А у вас рейтинг < 10 только без потери качества? Что-то здесь не так… Возможно, вам стоит попробовать сжать моё изображение?
                            0
                            Дело в том, что я подбирал шаблоны для того, чтобы ни одно изображение, сжатое им не выходило > +-10 + у Вас размер изображения большой (ваше изображение без инвестора не смогу сжать — пока только маленькие), а у меня маленькие. Чем больше изображение, тем строже должен быть критерий. И нет не только без потери, но и JPG 80% 4:2:2

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

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

                0

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

                  0

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

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

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

                        Самое читаемое