На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела "Программирование графики"
1) Данный раздел предназначен для обсуждения проблем, возникающих при программировании задач, связанных с чтением, сохранением, обработкой, созданием, отрисовкой графической информации (в том числе - 3D [OpenGL, Direct3D] и анимации [в т.ч. VFW, DirectShow, OpenDML]).
Флэш обсуждают здесь!.

2) Если вы хотите получить совет для конкретной платформы/языка программирования, обязательно укажите их в вопросе.

3) Уважаемые новички! Мы приветствуем Ваше желание научить всех посетителей раздела правильному программированию. Но огромная просьба, перед тем, как писать поучения в старых (последний ответ - "старее" месяца, а особенно, если вопрошавший не появляется на форуме уже не первый месяц, в чем можно убедиться в его профиле) темах, хорошо подумать, будет ли кому-нибудь, кроме Вас cамих, это интересно.



Ваше мнение о модераторах: user posted imageBarazuk, user posted imageOpenGL, user posted imageMikle
Модераторы: OpenGL, Mikle
  
> Повёрнутое хранение , и сжатие по возможности...
    Пусть у меня есть "изображение", кое откуда-то получается и выдаётся в виде этакой "повёрнутой на 45°" картинки:
    Прикреплённая картинка
    Прикреплённая картинка

    Подскажите, как было бы целесообразно хранить такие данные (с потерей/без потерь), если известно, что они несут информацию о некоем изображении? Ну т.е. формат/контейнер интересует (ну и прочие мысли. :thanks:

    П.С. я могу, конечно, разбить её на 2 куска (чётные места и нечётные) и хранить как пару обычных картинок, но получится некое расслоение=потеря связей между пикселами одного куска от другого, что выглядит неприятным. :oops:
      Не очень понятно что нужно.

      Иметь оригинальное изображение, но хранить повернутое так, чтобы можно было восстановить оригинал без потерь?
        Дифракционная картина с кристалла?

        Имеет смысл хранить исходное изображение, несжатое или сжатое без потерь. Не обязательно это будет формат картинки, удобнее может быть какой-нибудь формат, приспособленный для обработки, такие данные обычно лучше не сжимать.
        При необходимости можно добавить варианты с промежуточной обработкой.

        Любое преобразование, как правило, теряет часть данных. Из-за чего иногда алгоритмы начинают давать совершенно неожиданные ошибки и погрешности.
          Цитата simsergey @
          Не очень понятно что нужно.
          Иметь оригинальное изображение, но хранить повернутое так, чтобы можно было восстановить оригинал без потерь?
          На картинке ромбики нарисованы условно. Т.е. приходят=имеются просто точки, причём первый слой - обычный, а второй - сдвинут на полпиксела вправо. Третий - снова обычный, и т.д. Вот эту имеющуюся и надо как-то хранить. Ничего повёрнутого, по сути, нет, а есть только изменение в нечётных слоях - со смещением.

          Цитата amk @
          Имеет смысл хранить исходное изображение, несжатое или сжатое без потерь.
          Ну так и приходит такое, кое я описал - прямоугольное, но уже со смещением нечётных слоёв.

          Цитата amk @
          Не обязательно это будет формат картинки, удобнее может быть какой-нибудь формат, приспособленный для обработки, такие данные обычно лучше не сжимать.
          Просто на картинках много что построено, вот и интересен именно этот путь, как хорошо изученный.

          Цитата amk @
          Любое преобразование, как правило, теряет часть данных.
          Непонятно, к чему это? У меня нет преобразования, хочу хранить и без потерь тоже! :-?
            Я что-то в принципе не понимаю вопроса. По нему создаётся впечатление, что по какой-то непонятной причине, причём явно не технической, а то ли политической, то ли религиозной, приходящие данные нельзя хранить именно в том виде, в каком они приходят. Ну бред же, право слово...
              Цитата Akina @
              Я что-то в принципе не понимаю вопроса.
              Ну вот так ещё постараюсь: данные есть в виде такой матрицы:
              Прикреплённая картинка
              Прикреплённая картинка

              Цитата Akina @
              приходящие данные нельзя хранить именно в том виде, в каком они приходят.
              Да можно, конечно: скажем, в виде последовательности и всё. Но таковое хранение не будет нести информацию о картинке, о том, что пиксел n+1'ый связан с четырьмя ближайшими соседями. Нет возможности использовать JPEG-сжатие, если допускается такое воздействие. Алгоритмы PNG-упаковки не реализовать, если цветов/оттенков мало и т.д. :yes-sad:
                Я так понимаю, нужно хранить первый кадр и дальше разницу изменений картинки.
                Чем-то напоминает IPTV, заметно на экране такое изменение картинки, если что-то теряется по сети.
                Можно посмотреть исходники VLC, к примеру (вот не помню как кодек называется, как бы не mpeg2).

                Если реализовать сам алгоритм вручную, с нуля, то тут работы не мало.
                  Цитата Славян @
                  таковое хранение не будет нести информацию о картинке, о том, что пиксел n+1'ый связан с четырьмя ближайшими соседями.

                  Как на ХРАНЕНИЕ может влиять наличие связи с соседями? Не на обработку, не на интерпретацию - именно на хранение? С какого надо хранить в потоке данных сведения о том, что это будет картинка? Не надо смешивать все задачи в одну кучу, фигня получится. Уже собственно получается.
                    Расскажи о реальной задаче.
                      Цитата Akina @
                      Как на ХРАНЕНИЕ может влиять наличие связи с соседями?

                      JPEG кодирует квадратные сегменты, 1D массив в JPEG корректно не закодируется.
                      Но реальную задачу я тоже не понял.
                        Цитата Akina @
                        Как на ХРАНЕНИЕ может влиять наличие связи с соседями? Не на обработку, не на интерпретацию - именно на хранение?
                        Очень просто: GIF/PNG/... при хранении стараются пожать без потерь, чего и я хочу, потому хочу выбрать такой способ хранения, кой будет близким к реализации широкоизвестных алгоритмов работы с изображениями.
                        Цитата Akina @
                        С какого надо хранить в потоке данных сведения о том, что это будет картинка?
                        Мне дополнительно известно, что это - a'la "картинка". :yes:
                        Цитата Akina @
                        Не надо смешивать все задачи в одну кучу
                        Ну пока одна токмо задача - "как выгоднее хранить?". ;)

                        Добавлено
                        Цитата simsergey @
                        Я так понимаю, нужно хранить первый кадр и дальше разницу изменений картинки.
                        Если я правильно понял, то нет. "Картинка" всего одна, никаких изменений в оной не предвидится. Просто она имеется со "скошенными"=сдвинутыми слоями (через 1). :blush:
                          Цитата Славян @
                          "как выгоднее хранить?"

                          https://www.google.ru/?gws_rd=ssl#newwindow...age+compression
                            Цитата Славян @
                            Ну пока одна токмо задача - "как выгоднее хранить?".

                            Отвечаю - выгоднее хранить,положив [censored] на то, что это - a'la "картинка".
                              Набросились на Славяна, аки пирании :lol:

                              Славян, не сдавайся - держи удар. Вопрос нормальный, только сумбурно сформулирован.
                              Я бы его перефразировал так "Как выгоднее хранить данные (пусть картинки), до преобразований или после?"

                              Отвечаю :) Однозначного ответа на все случаи жизни нет и не может быть. Зависит от конкретных исходных данных.

                              Пример 1. Когда выгоднее хранить "оригинал"

                              Пусть формирование картинки происходит следующим образом:

                              • Создается пустая картинка 20000x20000 RGB24
                              • Выводится ряд вертикальных линий
                              • Применяется размытие по Гауссу
                              • Результирующее изображение преобразовывается с порядком кодирования YUY2

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

                              Пример 2. Когда не выгодно хранить "оригинал"

                              Пусть формирование картинки происходит следующим образом:

                              • Создается пустая картинка 20000x20000 RGB24
                              • Все пространство заполняется точками с рандомным цветом и расположением
                              • Применяется размытие по Гауссу
                              • Результирующее изображение преобразовывается с порядком кодирования YUY2

                              В данном случае "оригинал" по размеру будет сопоставим с "результатом". Поэтому лучше обработать заранее и сохранить обработанное.

                              Резюме

                              Смотрите с чем работаете, вычисляйте профит, пробуйте определить возможность обратных преобразований (так, чтобы они "упрощали" данные), без потерь, естественно.
                                Цитата Akina @
                                Отвечаю - выгоднее хранить,положив ... на то, что это - a'la "картинка".
                                Ну так это тривиальный вариант, рассмотренный в самом первом случае. Увы, но размеры заставляют задуматься и о других путях... :yes-sad:
                                  Цитата Славян @
                                  GIF/PNG/... при хранении стараются пожать без потерь
                                  Собственно им деваться некуда. С потерями сжимать они не умеют.
                                    Цитата Славян @
                                    размеры заставляют задуматься и о других путях...

                                    Во-о-от... наконец пошла хоть какая-то конкретика.

                                    Размер - единственная проблема? если да - то есть смысл подумать о вульгарном архивировании. Можно поподбирать метод - начиная от слабеньких, зато блочно-потоковых, и кончая узкоспециализированными, но в своей области супер-эффективными. Последние, кстати, хоть и направлены на эффективное сжатие информации определённого смыслового наполнения, но на самом деле эффективны для некоего типа потока вне зависимости от этого наполнения. Так что будь твоя инфа десять раз а-ля картинка, а самым эффективным может оказаться, например, метод компрессии, рассчитанный на аудиопоток. Или ещё на что... не зацикливайся на изображении.
                                    Цитата Славян @
                                    имеются просто точки, причём первый слой - обычный, а второй - сдвинут на полпиксела вправо. Третий - снова обычный, и т.д. Вот эту имеющуюся и надо как-то хранить. Ничего повёрнутого, по сути, нет, а есть только изменение в нечётных слоях - со смещением.

                                    Попробуй для начала плюнуть на это смещение. Выровняй по левой границе, а в чётных "строках", которые на 1 пиксел короче, для выравнивания просто удвой последний пиксел. А потом получившуюся картинку жми. Для начала выбери способы сжатия без потерь, потом, если степень сжатия не устроит, попробуй сжатие с потерями, но с настройками для незначительной потери данных (высокое качество), и постепенно снижай степень "сохранности" оригинала, ищи порог, когда потери ещё допустимы, а степень сжатия максимальна.
                                      Кажется, я допёр!
                                      Славян, у тебя на картинке в п.1 видно повёрнутые на 45 гр. крупные "пиксели", я верно понял, что это и есть исходные данные? То есть, если забыть про поворот, картинка получается в виде ромба, причём она симметрична относительно вертикальной оси. Достаточно хранить одну половинку ромба, пусть левую, но все популярные форматы хранят прямоугольные изображения.
                                      Берём левую половинку, режем её пополам вдоль горизонтальной оси, нижнюю половинку поворачиваем на 90 гр. и приставляем к верхней так, что выходит квадрат, квадрат сохраняем в любом удобном формате, раскодировка в обратном порядке.
                                        Цитата Akina @
                                        Выровняй по левой границе, а в чётных "строках", которые на 1 пиксел короче, для выравнивания просто удвой последний пиксел. А потом получившуюся картинку жми.
                                        Я тоже могу сказать: "во-о-от... наконец пошла хоть какая-то конкретика". Имеем: 1 бит на смещение влево/вправо + 1 бит на смещение вверх/вниз слоя с "чётными клетками", а потом ужо BMP/GIF/JPEG/... Это один вариант, так называемого "почти полного сведения" к известным форматам!
                                        Ну ещё сколько-то бит на выбор формата... Хм-м-м... небось, оптимальнее и не придумать?.. :scratch: :scratch: :scratch:

                                        Добавлено
                                        Цитата Mikle @
                                        она симметрична относительно вертикальной оси.
                                        Это просто у меня столь неудачный пример. :blush: В общем случае - всё разное, нет симметрии никакой. Об остальном - думаю. Обождите минутку. :blush:

                                        Добавлено
                                        Цитата Akina @
                                        Выровняй по левой границе
                                        Несколько беспокоит, что высота получится вдвое больше ширины, а это чуток смущает. Чуется потеря в алгоритмах/способах сжатия. Экспериментировать только?.. :o

                                        Добавлено
                                        Цитата Mikle @
                                        Берём левую половинку, режем её пополам вдоль горизонтальной оси, нижнюю половинку поворачиваем на 90 гр. и приставляем к верхней так, что выходит квадрат, квадрат сохраняем в любом удобном формате, раскодировка в обратном порядке.
                                        Так, раскурил и сие! Да, это тоже вариант! Второй. Увы, но и в нём получим из квадрата прямоугольник 2:1. Хм... Ещё один бит на выбор и такого варианта. Впрочем, всего один бит, а уже вон какое разнообразие!!! :jokingly:
                                          Цитата Славян @
                                          Несколько беспокоит, что высота получится вдвое больше ширины

                                          Это сфига бы? я вообще-то описывал трансформацию не для исходного массива данных, а для повёрнутого на 45 градусов - в точности такого, как показано в исходном посте, почти квадратного.


                                          Цитата Славян @
                                          Это просто у меня столь неудачный пример. В общем случае - всё разное, нет симметрии никакой.

                                          А нельзя ли пяток этих всякоразных несимметричных? без красоты, просто чтобы ощутить и осознать?
                                            Цитата Славян @
                                            в нём получим из квадрата прямоугольник 2:1.
                                            А именно, где-то так:
                                            Оригинал:
                                            Прикреплённая картинка
                                            Прикреплённая картинка

                                            Преобразуем в:
                                            Прикреплённая картинка
                                            Прикреплённая картинка

                                            И вот этот широкий и пожать/сохранить. Хм... :unsure: :-?

                                            Добавлено
                                            Цитата Akina @
                                            Это сфига бы?
                                            Ну потому что "нечётные" клетки станут в один ряд с полноценным, причём встанут в вертикальные слои. Ну или мы по-разному поняли друг друга.
                                              Цитата Славян @
                                              Ну потому что "нечётные" клетки станут в один ряд с полноценными
                                              Т.е. я понял так:
                                              Было:
                                              Прикреплённая картинка
                                              Прикреплённая картинка

                                              Предложили вы в такое:
                                              Прикреплённая картинка
                                              Прикреплённая картинка
                                                Практически так, только на самой первой картинке во втором ряду на 1 пиксел меньше, а в этой модельке почему-то столько же. Т.е. D2n не завершает второй ряд, а начинает третий.
                                                Сообщение отредактировано: Akina -
                                                  Да это мелочи, точно не суть.
                                                    Цитата Славян
                                                    "изображение", кое откуда-то получается и выдаётся в виде этакой "повёрнутой на 45°"


                                                    Цитата Славян
                                                    имеются просто точки, причём первый слой - обычный, а второй - сдвинут на полпиксела вправо


                                                    Цитата Славян
                                                    Ну вот так ещё постараюсь: данные есть в виде такой матрицы:
                                                    Прикреплённая картинка
                                                    Прикреплённая картинка


                                                    Что-то я так и не улавливаю сути... Что такое слои? Речь о фактической сущности, т.к. битовый слой, цветовой слой или это абстракция за которую цепляется глаз? Приложенная иллюстрация не сильно помогла... С поворотом на 45° тоже не совсем ясно, это вывод сделанный "на глаз"?
                                                    Проиллюстрирую примером:
                                                    Прикреплённая картинка
                                                    Прикреплённая картинка
                                                    Прикреплённая картинка
                                                    Прикреплённая картинка
                                                    , теперь вопрос, какое изображение повернуто? Пример синтетический, но я хотел продемонстрировать два момента, первый - "на глаз" не всегда можно сделать правильную оценку, второй - поворот может ухудшить ситуацию с точки зрения сжатия данных.
                                                    Вот еще один пример:
                                                    Прикреплённая картинка
                                                    Прикреплённая картинка
                                                    Прикреплённая картинка
                                                    Прикреплённая картинка
                                                    , размер файлов примерно одинаковый, этот пример демонстрирует работу фильтров в PNG, предсказание работает в том числе и по диагонали.

                                                    Я не уверен, что правильно уловил суть задачи, не видя реальных данных тяжело что-то конкретное рекомендовать, но, возможно, стоит присмотреться к идее фильтров как в PNG и соорудить что-то похожее, что будет учитывать особенности данных.


                                                    Цитата amk
                                                    Цитата Славян @
                                                    GIF/PNG/... при хранении стараются пожать без потерь
                                                    Собственно им деваться некуда. С потерями сжимать они не умеют.


                                                    Это не совсем так. У GIF-а есть ограничение на количество цветов и сохранить полноцветное изображение в GIF без потерь невозможно, разве что с "хаком" использующим анимацию. С PNG интересней, хоть он и задуман беспотерьным, есть реализации, которые умеют квантовать дельту после фильтров и получать дополнительное сжатие с контролируемыми потерями.
                                                      Цитата x128 @
                                                      У GIF-а есть ограничение на количество цветов и сохранить полноцветное изображение в GIF без потерь невозможно, разве что с "хаком" использующим анимацию
                                                      Это называется ограничение на формат изображения, а не потери. При изменении формата, естественно, часть информации может теряться. При этом многократная перепаковка изображения, в отличие от JPEG, дополнительных искажений не создаёт.
                                                      В версии 87-го года не было анимации, а "хак с анимацией", был документированным средством получить изображение, имеющее более 256 цветов.
                                                      Цитата x128 @
                                                      С PNG интересней, хоть он и задуман беспотерьным, есть реализации, которые умеют квантовать дельту после фильтров и получать дополнительное сжатие с контролируемыми потерями.
                                                      Это вряд ли можно назвать поддержкой такого сжатия со стороны формата файла. Так сжатые таким способом изображения перестают читаться стандартными библиотеками работы с PNG.

                                                      JPEG тоже поддерживает безпотерьное сжатие, причём в рамках стандартной библиотеки. Хотя многие библиотеки реализуют только чтение таких файлов.
                                                        Цитата x128 @
                                                        Что-то я так и не улавливаю сути... Что такое слои?
                                                        Это горизонтальные ряды точек.

                                                        Цитата x128 @
                                                        Речь о фактической сущности, т.к. битовый слой, цветовой слой или это абстракция за которую цепляется глаз?
                                                        Это геометрический набор точек, в каждой из которых заданы данные, вообще говоря разные: шкала серого, или какие-то индексы, или три вещественных числа, переводимые в цвет.

                                                        Цитата x128 @
                                                        Приложенная иллюстрация не сильно помогла...
                                                        Печально, но как ещё понятнее - не представляю. :blush:

                                                        Цитата x128 @
                                                        С поворотом на 45° тоже не совсем ясно, это вывод сделанный "на глаз"?
                                                        Не, это точное значение. Как бы "в точно такой точке" данные "вычисляются".

                                                        Цитата x128 @
                                                        возможно, стоит присмотреться к идее фильтров как в PNG и соорудить что-то похожее, что будет учитывать особенности данных.
                                                        Ну в фильтрах не секу ничего, но мысль запомню, поколдую вокруг. :thanks:
                                                          Цитата Славян
                                                          Печально, но как ещё понятнее - не представляю.

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

                                                          Цитата amk
                                                          Так сжатые таким способом изображения перестают читаться стандартными библиотеками работы с PNG.

                                                          Этот способ не нарушает совместимости и такой PNG, с точки зрения декодера, ничем не отличается от обычного.
                                                            Цитата x128 @
                                                            Я пытаюсь представить визуализацию этих данных по описанию и представляю десятки разных вариантов от разреженного облака точек, до вариантов напоминающих чересстрочную развертку или байеровскую матрицу.
                                                            Ну вот сверхформализованое определение:
                                                            В узлах (точках) с целочисленными координатами {(i,j) | i=0..N & j=0..M & i+j чётно} заданы целые значения 0..255 (или тройка целых 0..255). Требуется на основе этих целых значений и пары (N;M) как-то их хранить, желательно со сжатием [без потерь], учитывая, что они несут информацию как с изображения.
                                                              Цитата Славян
                                                              Ну вот сверхформализованое определение:

                                                              То есть визуализация будет такой
                                                              Прикреплённая картинка
                                                              Прикреплённая картинка
                                                              , где синий это отсутствие данных?
                                                                Да.

                                                                Добавлено
                                                                Точнее, это у вас один из вариантов визуализации, где вы узел решили изобразить квадратиком. А могли и ромбиком, кружочком, другой фигурой. Т.е. в точке (центр квадратика) у меня задан какой-то цвет.

                                                                Добавлено
                                                                П.С. под ромбиком я тут понимал "квадратик, но повёрнутый на 45 градусов".
                                                                  Теперь всё еще загадочней ;)

                                                                  Вариантов можно придумать много. Например можно формировать изображение без пропусков, т.е. для каждой строки при условии (x+y) and 1 = 0, писать пиксел по координатам (x/2,y). Или заполнить пропуски средними значениями по соседям из ближайшего окружения и результат сжать обычным JPEG (если допустимы потери). Это первое, что приходит в голову. Не имея полной информации о природе данных и чем обусловлен такой порядок тяжело предложить что-то толковое.

                                                                  Цитата Славян
                                                                  где вы узел решили изобразить квадратиком

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

                                                                  Ромбики с кружочками меня окончательно запутали... :(
                                                                  Сообщение отредактировано: x128 -
                                                                    Мне кажется, что в №19 я уже дал оптимальный вариант, только, раз симметрии нет, хранишь не квадрат, а прямоугольник 1:2.
                                                                      Цитата x128 @
                                                                      Этот способ не нарушает совместимости и такой PNG, с точки зрения декодера, ничем не отличается от обычного.
                                                                      В таком случае это просто предобработка изображения, не имеющая отношения к собственно фрмату PNG. Просто после неё полученное изображение лучше сжимается, чем исходное.
                                                                        Цитата amk @
                                                                        В таком случае это просто предобработка изображения, не имеющая отношения к собственно фрмату PNG.

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


                                                                        Рейтинг@Mail.ru
                                                                        [ Script execution time: 0,1926 ]   [ 31 queries used ]   [ Generated: 28.03.24, 08:36 GMT ]