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

                                То есть визуализация будет такой
                                Прикреплённая картинка
                                Прикреплённая картинка
                                , где синий это отсутствие данных?
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (3) 1 [2] 3  все


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