На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! ПРАВИЛА РАЗДЕЛА
В этом разделе решаются вопросы, касающиеся векторной/растровой графики, а также 3D-редакторов.
Вопросы по программированию графики (работу с графическими форматами, распознавание изображений и т.д.) - просьба создавать в разделе Программирование графики.

Обучающие материалы: PhotoShop, PhotoPaint, ... растровая графика, Corel DRAW, Illustrator, ... векторная графика, 3D графика, 3D-анимация
Модераторы: Tri Repetae, Serafim
  
> Алгоритм сжатия изображений
    Нашел вот интересный алгоритм сжатия изображений, что думаете?
    Алгоритм сжатия изображений PGA
      На некоторых изображениях может дать прекрасные результаты. На других, результат может оказаться отвратительным.
      Идея сохранять коэффициенты полинома - дурость. Лучше воспользоваться сплайнами Безье. Информации придётся хранить ещё меньше, по крайней мере вдвое.
        Изъян ещё и в том, что блоки независимо анализируются, а тогда на стыках будут разногласия, весьма заметные, думается. Всё же большинство изображений - гладкие в плане конкретного цвета.
          Цитата amk @

          На самом деле, вопрос не только в эффективности сжатия, но и в простоте расшифровки. А кривые Безье как позволяют хранить меньше данных? Парабола это в любом случае парабола, она в любом случае описывается 3 параметрами (либо коэффициенты, либо точки). Но если описывать кривой Безье, то надо использовать три точки, а каждая точка содержит компоненты X и Y. На деле выйдет 6 байт, и только если фиксировать значения X мы вернемся к 3 байтам, как в предложенном случае. В любом случае кривая Безье более затратна по вычислениям. А там же говорится что задача была в быстрой загрузке изображения.
            Цитата Drakon269 @
            А кривые Безье как позволяют хранить меньше данных? Парабола это в любом случае парабола, она в любом случае описывается 3 параметрами (либо коэффициенты, либо точки)
            Ты правильно заметил, что параболу можно описать не только тремя коэффициентами при степенях, но и тремя точками. Например, значениями функции в концах отрезка и в его середине.
            Если соседние параболы соединяются, то на концах отрезков значения совпадают, и одно из них можно не хранить (одно из трёх отбрасывается).
            Если функция меняется не слишком быстро среднюю точку можно хранить как разность со средним арифметическим в концах. Часто на этом можно сэкономить биты.
            Если на границах параболы расходятся, то для хранения разности часто тоже можно отвести меньше бит.
            Ну и значения гарантированно лежат в интервале 0-255, а коэффициенты мало того, что могут выходить за этот интервал, так их ещё и заметно точнее надо хранить.

            В двумерном случае, вместо 9 коэффициентов можно хранить 4 значения, остальные повторяются.

            Цитата Drakon269 @
            если описывать кривой Безье, то надо использовать три точки, а каждая точка содержит компоненты X и Y
            Это для совсем другой задачи, а именно, для описания кривой на плоскости, надо хранить X и Y. Для картинки придётся использовать поверхность Безье, а не кривую. При этом X и Y точек внутри каждого квадрата фиксированы, а хранить надо только Z.
              А как же вычислительная сложность?
              А по поводу коэффициентов там указано что для линейной аппроксимации пишутся коэффициенты, а для квадратичной - сами точки.
              А вообще с поверхность Безье мысль интересная
                Цитата Drakon269 @
                А как же вычислительная сложность?
                А что вычислительная сложность? Там одни сложения, умножения на малые константы и деление на размер сетки (квадрат стороны сетки).
                Так что размер ячейки лучше брать равным степени двойки. Тогда деление можно будет заменить на сдвиг.
                При желании можно вообще обойтись одними сложениями, но тогда придётся придумывать представление для чисел, кратных 1/L2, где L - сторона ячейки.
                  //Дабы не плодить коротенькие темы, здесь задам вопросик. Но, модераторы, можете и в отдельную тему снести, коли сочтёте лучше.

                  Есть (в настройках программы обработки изображений) пункты "преобразование JPEG без потерь". И там есть обрезка, поворот и что-то ещё.
                  Вопрос: а можно ли без потерь склеить 2 JPEG'а с одинаковыми размерами (скажем, 256*256) ?
                  Интуиция говорит, что можно, но всё же интересно было бы увидеть полный список таких вот возможностей.

                  Добавлено
                  П.С. склеить = пристыковать (сбоку или сверху).
                    Все эти "преобразования без потерь" осуществляются путём частичной распаковки, отбрасывания и перестановки коэффициентов и последующей упаковки, само изображение при этом не восстанавливается (пропускаются шаги деквантования, обратного косинус-преобразования, прямого преобразования и квантования). Преобразования возможны, только если размеры изображения кратны ячейке косинус-преобразования (обычно 8х8 для Ч/Б и 16х16 для цветных изображений). Безпотерьная склейка двух изображений даже теоретически возможна только тогда, когда оба изображения имеют совпадающие таблицы квантования. Программ, осуществляющих такую склейку, не знаю.

                    Потери в JPEG появляются на этапе квантования, и немного при косинус преобразовании.
                      В jpeg самый первый этам rgb->YCbCr уже может привести к небольшим искажениям.
                        Да, про преобразование цветов я забыл. Его при "преобразованиях без потерь" тоже пропускают.
                          Цитата Славян @
                          а можно ли без потерь склеить 2 JPEG'а

                          Можно, на этой страничке есть все необходимое.

                          Цитата amk @
                          только тогда, когда оба изображения имеют совпадающие таблицы квантования

                          Вероятно это достигается масштабированием коэффициентов под одну таблицу квантования. Я пробовал склеить два изображения с заведомо разным качеством, итоговый размер файла получился больше, чем сумма отдельных файлов.
                            Мораль-суть то в том, что умный JPEG мог бы анализировать где лицо, номер машины и прочие интересные кусочки и уделять таким местам больше внимания при сжатии. И мы бы получили, что на квадратистые облака ушло мало данных, а на лицо, скажем, снайпера в далёком доме - очень много. И сие как бы правильно! ;)
                              Правильно-то правильно, но формат JPEG под это не заточен. В файле для каждого слоя используется единая таблица квантования (в файле кроме основного изображения может быть ещё несколько уменьшенных).
                              Должны существовать форматы, где для некоторых областей возможно дополнительно повысить детализацию. Вроде в JPEG 2000 такое возможно, но опять же не знаю программ, которые этим пользовались бы.
                              В принципе можно схитрить, наложив на изображение размывающий фильтр, а потом маской врезав туда более чёткие фрагменты. Стандартный J2K кодер должен на размытых участках здорово съэкономить поток.
                                Цитата Славян @
                                умный JPEG мог бы анализировать ... И сие как бы правильно!

                                Технически это реализуемо, но учитывая ограничения, о которых упоминал товарищ amk, это не имеет смысла. В редких случаях это может быть полезно, но в реальных условиях, ограничения формата не дают разгуляться фантазии:
                                user posted image user posted image
                                обе картинки сжаты до одного размера файла, в первом изображении лицо выделено как зона интереса - результат говорит сам за себя. Более навороченный JPEG 2000 поддерживает зоны интереса на уровне стандарта, но, к сожалению, он так и не стал популярным из за патентных ограничений.
                                Сообщение отредактировано: x128 -
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0348 ]   [ 16 queries used ]   [ Generated: 28.03.24, 15:51 GMT ]