На главную Наши проекты:
Журнал   ·   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
Страницы: (3) [1] 2 3  все  ( Перейти к последнему сообщению )  
> Повёрнутое хранение , и сжатие по возможности...
    Пусть у меня есть "изображение", кое откуда-то получается и выдаётся в виде этакой "повёрнутой на 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:
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (3) [1] 2 3  все


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