Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.17.128.129] |
|
Сообщ.
#1
,
|
|
|
Пусть у меня есть "изображение", кое откуда-то получается и выдаётся в виде этакой "повёрнутой на 45°" картинки:
Прикреплённая картинка
Подскажите, как было бы целесообразно хранить такие данные (с потерей/без потерь), если известно, что они несут информацию о некоем изображении? Ну т.е. формат/контейнер интересует (ну и прочие мысли. П.С. я могу, конечно, разбить её на 2 куска (чётные места и нечётные) и хранить как пару обычных картинок, но получится некое расслоение=потеря связей между пикселами одного куска от другого, что выглядит неприятным. |
Сообщ.
#2
,
|
|
|
Не очень понятно что нужно.
Иметь оригинальное изображение, но хранить повернутое так, чтобы можно было восстановить оригинал без потерь? |
Сообщ.
#3
,
|
|
|
Дифракционная картина с кристалла?
Имеет смысл хранить исходное изображение, несжатое или сжатое без потерь. Не обязательно это будет формат картинки, удобнее может быть какой-нибудь формат, приспособленный для обработки, такие данные обычно лучше не сжимать. При необходимости можно добавить варианты с промежуточной обработкой. Любое преобразование, как правило, теряет часть данных. Из-за чего иногда алгоритмы начинают давать совершенно неожиданные ошибки и погрешности. |
Сообщ.
#4
,
|
|
|
Цитата simsergey @ На картинке ромбики нарисованы условно. Т.е. приходят=имеются просто точки, причём первый слой - обычный, а второй - сдвинут на полпиксела вправо. Третий - снова обычный, и т.д. Вот эту имеющуюся и надо как-то хранить. Ничего повёрнутого, по сути, нет, а есть только изменение в нечётных слоях - со смещением.Не очень понятно что нужно. Иметь оригинальное изображение, но хранить повернутое так, чтобы можно было восстановить оригинал без потерь? Цитата amk @ Ну так и приходит такое, кое я описал - прямоугольное, но уже со смещением нечётных слоёв.Имеет смысл хранить исходное изображение, несжатое или сжатое без потерь. Цитата amk @ Просто на картинках много что построено, вот и интересен именно этот путь, как хорошо изученный.Не обязательно это будет формат картинки, удобнее может быть какой-нибудь формат, приспособленный для обработки, такие данные обычно лучше не сжимать. Цитата amk @ Непонятно, к чему это? У меня нет преобразования, хочу хранить и без потерь тоже! Любое преобразование, как правило, теряет часть данных. |
Сообщ.
#5
,
|
|
|
Я что-то в принципе не понимаю вопроса. По нему создаётся впечатление, что по какой-то непонятной причине, причём явно не технической, а то ли политической, то ли религиозной, приходящие данные нельзя хранить именно в том виде, в каком они приходят. Ну бред же, право слово...
|
Сообщ.
#6
,
|
|
|
Цитата Akina @ Ну вот так ещё постараюсь: данные есть в виде такой матрицы:Я что-то в принципе не понимаю вопроса. Прикреплённая картинка
Цитата Akina @ Да можно, конечно: скажем, в виде последовательности и всё. Но таковое хранение не будет нести информацию о картинке, о том, что пиксел n+1'ый связан с четырьмя ближайшими соседями. Нет возможности использовать JPEG-сжатие, если допускается такое воздействие. Алгоритмы PNG-упаковки не реализовать, если цветов/оттенков мало и т.д. приходящие данные нельзя хранить именно в том виде, в каком они приходят. |
Сообщ.
#7
,
|
|
|
Я так понимаю, нужно хранить первый кадр и дальше разницу изменений картинки.
Чем-то напоминает IPTV, заметно на экране такое изменение картинки, если что-то теряется по сети. Можно посмотреть исходники VLC, к примеру (вот не помню как кодек называется, как бы не mpeg2). Если реализовать сам алгоритм вручную, с нуля, то тут работы не мало. |
Сообщ.
#8
,
|
|
|
Цитата Славян @ таковое хранение не будет нести информацию о картинке, о том, что пиксел n+1'ый связан с четырьмя ближайшими соседями. Как на ХРАНЕНИЕ может влиять наличие связи с соседями? Не на обработку, не на интерпретацию - именно на хранение? С какого надо хранить в потоке данных сведения о том, что это будет картинка? Не надо смешивать все задачи в одну кучу, фигня получится. Уже собственно получается. |
Сообщ.
#9
,
|
|
|
Расскажи о реальной задаче.
|
Сообщ.
#10
,
|
|
|
Цитата Akina @ Как на ХРАНЕНИЕ может влиять наличие связи с соседями? JPEG кодирует квадратные сегменты, 1D массив в JPEG корректно не закодируется. Но реальную задачу я тоже не понял. |
Сообщ.
#11
,
|
|
|
Цитата Akina @ Очень просто: GIF/PNG/... при хранении стараются пожать без потерь, чего и я хочу, потому хочу выбрать такой способ хранения, кой будет близким к реализации широкоизвестных алгоритмов работы с изображениями.Как на ХРАНЕНИЕ может влиять наличие связи с соседями? Не на обработку, не на интерпретацию - именно на хранение? Цитата Akina @ Мне дополнительно известно, что это - a'la "картинка". С какого надо хранить в потоке данных сведения о том, что это будет картинка? Цитата Akina @ Ну пока одна токмо задача - "как выгоднее хранить?". Не надо смешивать все задачи в одну кучу Добавлено Цитата simsergey @ Если я правильно понял, то нет. "Картинка" всего одна, никаких изменений в оной не предвидится. Просто она имеется со "скошенными"=сдвинутыми слоями (через 1). Я так понимаю, нужно хранить первый кадр и дальше разницу изменений картинки. |
Сообщ.
#12
,
|
|
|
Цитата Славян @ "как выгоднее хранить?" https://www.google.ru/?gws_rd=ssl#newwindow...age+compression |
Сообщ.
#13
,
|
|
|
Цитата Славян @ Ну пока одна токмо задача - "как выгоднее хранить?". Отвечаю - выгоднее хранить,положив [censored] на то, что это - a'la "картинка". |
Сообщ.
#14
,
|
|
|
Набросились на Славяна, аки пирании
Славян, не сдавайся - держи удар. Вопрос нормальный, только сумбурно сформулирован. Я бы его перефразировал так "Как выгоднее хранить данные (пусть картинки), до преобразований или после?" Отвечаю Однозначного ответа на все случаи жизни нет и не может быть. Зависит от конкретных исходных данных. Пример 1. Когда выгоднее хранить "оригинал" Пусть формирование картинки происходит следующим образом: Понятное дело, если пройдем все шаги, будет "монстр". Выгоднее хранить "вектор отрезков", размер хранения будет на порядки меньше. Плата - скорость извлечения. Все операции нужно будет делать "потом", а не "заранее". Пример 2. Когда не выгодно хранить "оригинал" Пусть формирование картинки происходит следующим образом: В данном случае "оригинал" по размеру будет сопоставим с "результатом". Поэтому лучше обработать заранее и сохранить обработанное. Резюме Смотрите с чем работаете, вычисляйте профит, пробуйте определить возможность обратных преобразований (так, чтобы они "упрощали" данные), без потерь, естественно. |
Сообщ.
#15
,
|
|
|
Цитата Akina @ Ну так это тривиальный вариант, рассмотренный в самом первом случае. Увы, но размеры заставляют задуматься и о других путях... Отвечаю - выгоднее хранить,положив ... на то, что это - a'la "картинка". |
Сообщ.
#16
,
|
|
|
Цитата Славян @ Собственно им деваться некуда. С потерями сжимать они не умеют. GIF/PNG/... при хранении стараются пожать без потерь |
Сообщ.
#17
,
|
|
|
Цитата Славян @ размеры заставляют задуматься и о других путях... Во-о-от... наконец пошла хоть какая-то конкретика. Размер - единственная проблема? если да - то есть смысл подумать о вульгарном архивировании. Можно поподбирать метод - начиная от слабеньких, зато блочно-потоковых, и кончая узкоспециализированными, но в своей области супер-эффективными. Последние, кстати, хоть и направлены на эффективное сжатие информации определённого смыслового наполнения, но на самом деле эффективны для некоего типа потока вне зависимости от этого наполнения. Так что будь твоя инфа десять раз а-ля картинка, а самым эффективным может оказаться, например, метод компрессии, рассчитанный на аудиопоток. Или ещё на что... не зацикливайся на изображении. Цитата Славян @ имеются просто точки, причём первый слой - обычный, а второй - сдвинут на полпиксела вправо. Третий - снова обычный, и т.д. Вот эту имеющуюся и надо как-то хранить. Ничего повёрнутого, по сути, нет, а есть только изменение в нечётных слоях - со смещением. Попробуй для начала плюнуть на это смещение. Выровняй по левой границе, а в чётных "строках", которые на 1 пиксел короче, для выравнивания просто удвой последний пиксел. А потом получившуюся картинку жми. Для начала выбери способы сжатия без потерь, потом, если степень сжатия не устроит, попробуй сжатие с потерями, но с настройками для незначительной потери данных (высокое качество), и постепенно снижай степень "сохранности" оригинала, ищи порог, когда потери ещё допустимы, а степень сжатия максимальна. |
Сообщ.
#18
,
|
|
|
Кажется, я допёр!
Славян, у тебя на картинке в п.1 видно повёрнутые на 45 гр. крупные "пиксели", я верно понял, что это и есть исходные данные? То есть, если забыть про поворот, картинка получается в виде ромба, причём она симметрична относительно вертикальной оси. Достаточно хранить одну половинку ромба, пусть левую, но все популярные форматы хранят прямоугольные изображения. Берём левую половинку, режем её пополам вдоль горизонтальной оси, нижнюю половинку поворачиваем на 90 гр. и приставляем к верхней так, что выходит квадрат, квадрат сохраняем в любом удобном формате, раскодировка в обратном порядке. |
Сообщ.
#19
,
|
|
|
Цитата Akina @ Я тоже могу сказать: "во-о-от... наконец пошла хоть какая-то конкретика". Имеем: 1 бит на смещение влево/вправо + 1 бит на смещение вверх/вниз слоя с "чётными клетками", а потом ужо BMP/GIF/JPEG/... Это один вариант, так называемого "почти полного сведения" к известным форматам!Выровняй по левой границе, а в чётных "строках", которые на 1 пиксел короче, для выравнивания просто удвой последний пиксел. А потом получившуюся картинку жми. Ну ещё сколько-то бит на выбор формата... Хм-м-м... небось, оптимальнее и не придумать?.. Добавлено Цитата Mikle @ Это просто у меня столь неудачный пример. В общем случае - всё разное, нет симметрии никакой. Об остальном - думаю. Обождите минутку. она симметрична относительно вертикальной оси. Добавлено Цитата Akina @ Несколько беспокоит, что высота получится вдвое больше ширины, а это чуток смущает. Чуется потеря в алгоритмах/способах сжатия. Экспериментировать только?.. Выровняй по левой границе Добавлено Цитата Mikle @ Так, раскурил и сие! Да, это тоже вариант! Второй. Увы, но и в нём получим из квадрата прямоугольник 2:1. Хм... Ещё один бит на выбор и такого варианта. Впрочем, всего один бит, а уже вон какое разнообразие!!! Берём левую половинку, режем её пополам вдоль горизонтальной оси, нижнюю половинку поворачиваем на 90 гр. и приставляем к верхней так, что выходит квадрат, квадрат сохраняем в любом удобном формате, раскодировка в обратном порядке. |
Сообщ.
#20
,
|
|
|
Цитата Славян @ Несколько беспокоит, что высота получится вдвое больше ширины Это сфига бы? я вообще-то описывал трансформацию не для исходного массива данных, а для повёрнутого на 45 градусов - в точности такого, как показано в исходном посте, почти квадратного. Цитата Славян @ Это просто у меня столь неудачный пример. В общем случае - всё разное, нет симметрии никакой. А нельзя ли пяток этих всякоразных несимметричных? без красоты, просто чтобы ощутить и осознать? |
Сообщ.
#21
,
|
|
|
Цитата Славян @ А именно, где-то так:в нём получим из квадрата прямоугольник 2:1. Оригинал: Прикреплённая картинка
Преобразуем в: Прикреплённая картинка
И вот этот широкий и пожать/сохранить. Хм... Добавлено Цитата Akina @ Ну потому что "нечётные" клетки станут в один ряд с полноценным, причём встанут в вертикальные слои. Ну или мы по-разному поняли друг друга. Это сфига бы? |
Сообщ.
#22
,
|
|
|
Цитата Славян @ Т.е. я понял так:Ну потому что "нечётные" клетки станут в один ряд с полноценными Было: Прикреплённая картинка
Предложили вы в такое: Прикреплённая картинка
|
Сообщ.
#23
,
|
|
|
Практически так, только на самой первой картинке во втором ряду на 1 пиксел меньше, а в этой модельке почему-то столько же. Т.е. D2n не завершает второй ряд, а начинает третий.
|
Сообщ.
#24
,
|
|
|
Да это мелочи, точно не суть.
|
Сообщ.
#25
,
|
|
|
Цитата Славян "изображение", кое откуда-то получается и выдаётся в виде этакой "повёрнутой на 45°" Цитата Славян имеются просто точки, причём первый слой - обычный, а второй - сдвинут на полпиксела вправо Цитата Славян Ну вот так ещё постараюсь: данные есть в виде такой матрицы: Прикреплённая картинка
Что-то я так и не улавливаю сути... Что такое слои? Речь о фактической сущности, т.к. битовый слой, цветовой слой или это абстракция за которую цепляется глаз? Приложенная иллюстрация не сильно помогла... С поворотом на 45° тоже не совсем ясно, это вывод сделанный "на глаз"? Проиллюстрирую примером: Прикреплённая картинка
Прикреплённая картинка
, теперь вопрос, какое изображение повернуто? Пример синтетический, но я хотел продемонстрировать два момента, первый - "на глаз" не всегда можно сделать правильную оценку, второй - поворот может ухудшить ситуацию с точки зрения сжатия данных. Вот еще один пример: Прикреплённая картинка
Прикреплённая картинка
, размер файлов примерно одинаковый, этот пример демонстрирует работу фильтров в PNG, предсказание работает в том числе и по диагонали.Я не уверен, что правильно уловил суть задачи, не видя реальных данных тяжело что-то конкретное рекомендовать, но, возможно, стоит присмотреться к идее фильтров как в PNG и соорудить что-то похожее, что будет учитывать особенности данных. Цитата amk Цитата Славян @ Собственно им деваться некуда. С потерями сжимать они не умеют.GIF/PNG/... при хранении стараются пожать без потерь Это не совсем так. У GIF-а есть ограничение на количество цветов и сохранить полноцветное изображение в GIF без потерь невозможно, разве что с "хаком" использующим анимацию. С PNG интересней, хоть он и задуман беспотерьным, есть реализации, которые умеют квантовать дельту после фильтров и получать дополнительное сжатие с контролируемыми потерями. |
Сообщ.
#26
,
|
|
|
Цитата x128 @ Это называется ограничение на формат изображения, а не потери. При изменении формата, естественно, часть информации может теряться. При этом многократная перепаковка изображения, в отличие от JPEG, дополнительных искажений не создаёт.У GIF-а есть ограничение на количество цветов и сохранить полноцветное изображение в GIF без потерь невозможно, разве что с "хаком" использующим анимацию В версии 87-го года не было анимации, а "хак с анимацией", был документированным средством получить изображение, имеющее более 256 цветов. Цитата x128 @ Это вряд ли можно назвать поддержкой такого сжатия со стороны формата файла. Так сжатые таким способом изображения перестают читаться стандартными библиотеками работы с PNG.С PNG интересней, хоть он и задуман беспотерьным, есть реализации, которые умеют квантовать дельту после фильтров и получать дополнительное сжатие с контролируемыми потерями. JPEG тоже поддерживает безпотерьное сжатие, причём в рамках стандартной библиотеки. Хотя многие библиотеки реализуют только чтение таких файлов. |
Сообщ.
#27
,
|
|
|
Цитата x128 @ Это горизонтальные ряды точек.Что-то я так и не улавливаю сути... Что такое слои? Цитата x128 @ Это геометрический набор точек, в каждой из которых заданы данные, вообще говоря разные: шкала серого, или какие-то индексы, или три вещественных числа, переводимые в цвет.Речь о фактической сущности, т.к. битовый слой, цветовой слой или это абстракция за которую цепляется глаз? Цитата x128 @ Печально, но как ещё понятнее - не представляю. Приложенная иллюстрация не сильно помогла... Цитата x128 @ Не, это точное значение. Как бы "в точно такой точке" данные "вычисляются".С поворотом на 45° тоже не совсем ясно, это вывод сделанный "на глаз"? Цитата x128 @ Ну в фильтрах не секу ничего, но мысль запомню, поколдую вокруг. возможно, стоит присмотреться к идее фильтров как в PNG и соорудить что-то похожее, что будет учитывать особенности данных. |
Сообщ.
#28
,
|
|
|
Цитата Славян Печально, но как ещё понятнее - не представляю. Самым понятным будет показать реальные данные или хотя бы фрагмент. Я пытаюсь представить визуализацию этих данных по описанию и представляю десятки разных вариантов от разреженного облака точек, до вариантов напоминающих чересстрочную развертку или байеровскую матрицу. Цитата amk Так сжатые таким способом изображения перестают читаться стандартными библиотеками работы с PNG. Этот способ не нарушает совместимости и такой PNG, с точки зрения декодера, ничем не отличается от обычного. |
Сообщ.
#29
,
|
|
|
Цитата x128 @ Ну вот сверхформализованое определение:Я пытаюсь представить визуализацию этих данных по описанию и представляю десятки разных вариантов от разреженного облака точек, до вариантов напоминающих чересстрочную развертку или байеровскую матрицу. В узлах (точках) с целочисленными координатами {(i,j) | i=0..N & j=0..M & i+j чётно} заданы целые значения 0..255 (или тройка целых 0..255). Требуется на основе этих целых значений и пары (N;M) как-то их хранить, желательно со сжатием [без потерь], учитывая, что они несут информацию как с изображения. |
Сообщ.
#30
,
|
|
|
Цитата Славян Ну вот сверхформализованое определение: То есть визуализация будет такой Прикреплённая картинка
, где синий это отсутствие данных? |
Сообщ.
#31
,
|
|
|
Да.
Добавлено Точнее, это у вас один из вариантов визуализации, где вы узел решили изобразить квадратиком. А могли и ромбиком, кружочком, другой фигурой. Т.е. в точке (центр квадратика) у меня задан какой-то цвет. Добавлено П.С. под ромбиком я тут понимал "квадратик, но повёрнутый на 45 градусов". |
Сообщ.
#32
,
|
|
|
Теперь всё еще загадочней
Вариантов можно придумать много. Например можно формировать изображение без пропусков, т.е. для каждой строки при условии (x+y) and 1 = 0, писать пиксел по координатам (x/2,y). Или заполнить пропуски средними значениями по соседям из ближайшего окружения и результат сжать обычным JPEG (если допустимы потери). Это первое, что приходит в голову. Не имея полной информации о природе данных и чем обусловлен такой порядок тяжело предложить что-то толковое. Цитата Славян где вы узел решили изобразить квадратиком Визуализация была пиксельной и я привел увеличенный фрагмент, иначе все сливалось. Ромбики с кружочками меня окончательно запутали... |
Сообщ.
#33
,
|
|
|
Мне кажется, что в №19 я уже дал оптимальный вариант, только, раз симметрии нет, хранишь не квадрат, а прямоугольник 1:2.
|
Сообщ.
#34
,
|
|
|
Цитата x128 @ В таком случае это просто предобработка изображения, не имеющая отношения к собственно фрмату PNG. Просто после неё полученное изображение лучше сжимается, чем исходное. Этот способ не нарушает совместимости и такой PNG, с точки зрения декодера, ничем не отличается от обычного. |
Сообщ.
#35
,
|
|
|
Цитата amk @ В таком случае это просто предобработка изображения, не имеющая отношения к собственно фрмату PNG. Это не совсем так, используется особенность формата PNG. На этапе кодирования выполняется квантование ошибки предсказания, что позволяет получить дополнительное сжатие при контролируемых потерях. Эффективность такого подхода конечно же ниже, чем у специализированных форматов с потерями, но в некоторых случаях это может быть единственным решением получить дополнительное сжатие в пределах формата. |