Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.136.97.64] |
|
Страницы: (3) [1] 2 3 все ( Перейти к последнему сообщению ) |
Сообщ.
#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 "картинка". |