Перейти к содержимому
  • 0
Doob

Сжатие цветных изображений

Вопрос

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

Если дельных предложений не поступит - прикручу deflate на 18 килобайт.

LwTNjTM.png

 

Изменено пользователем Doob

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Рекомендуемые сообщения

Строка. Вот тебе кодик, очень простой:

 

function subTheText(text) 
	texttoreturn={}
	noExit=true
	while noExit do
		startTEXT, stopTEXT=string.find(text, "CSTART") 
		startC, stopC=string.find(text, "CSTOP") 
		if startTEXT~=nil and stopTEXT~=nil and startC~=nil and stopC~=nil then
			if string.sub(text, stopTEXT, stopC)~="" then
				table.insert(texttoreturn, string.sub(text, stopTEXT+1, stopC-#"CSTOP"))
			end
			text=string.sub(text, stopC, #text)
		else
			noExit=false
		end
	end
	return texttoreturn
end

 

 

То есть ты в компе-камере между цветами вставляешь CSTART и CSTOP. То есть "CSTART0x000000CSTOPCSTART0xff0000CSTOPCSTART0x00ff00CSTOPCSTART0x0000ffCSTOP" вернёт {0x000000, 0xff0000, 0x00ff00, 0x0000ff}

Изменено пользователем Asummonster

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Строка. Вот тебе кодик, очень простой:

 

function subTheText(text) 
	texttoreturn={}
	noExit=true
	while noExit do
		startTEXT, stopTEXT=string.find(text, "CSTART") 
		startC, stopC=string.find(text, "CSTOP") 
		if startTEXT~=nil and stopTEXT~=nil and startC~=nil and stopC~=nil then
			if string.sub(text, stopTEXT, stopC)~="" then
				table.insert(texttoreturn, string.sub(text, stopTEXT+1, stopC-#"CSTOP"))
			end
			text=string.sub(text, stopC, #text)
		else
			noExit=false
		end
	end
	return texttoreturn
end

 

 

То есть ты в компе-камере между цветами вставляешь CSTART и CSTOP. То есть "CSTART0x000000CSTOPCSTART0xff0000CSTOPCSTART0x00ff00CSTOPCSTART0x0000ffCSTOP" вернёт {0x000000, 0xff0000, 0x00ff00, 0x0000ff}

Что - это за хрень??  :nono:

Зачем так говно кодить???

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Строка. Вот тебе кодик, очень простой:

 

function subTheText(text) 
	texttoreturn={}
	noExit=true
	while noExit do
		startTEXT, stopTEXT=string.find(text, "CSTART") 
		startC, stopC=string.find(text, "CSTOP") 
		if startTEXT~=nil and stopTEXT~=nil and startC~=nil and stopC~=nil then
			if string.sub(text, stopTEXT, stopC)~="" then
				table.insert(texttoreturn, string.sub(text, stopTEXT+1, stopC-#"CSTOP"))
			end
			text=string.sub(text, stopC, #text)
		else
			noExit=false
		end
	end
	return texttoreturn
end

 

 

То есть ты в компе-камере между цветами вставляешь CSTART и CSTOP. То есть "CSTART0x000000CSTOPCSTART0xff0000CSTOPCSTART0x00ff00CSTOPCSTART0x0000ffCSTOP" вернёт {0x000000, 0xff0000, 0x00ff00, 0x0000ff}

Мало того, что цвета огромное кол-во байт занимают, а ты ещё 11 штук приляпал. Внимательно читай: "с-ж-а-т-и-е".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

Если дельных предложений не поступит - прикручу deflate на 18 килобайт.
 

Когда то предлагал Тоторо алгоритм сжатия голограмм.  Может и тебе подойдет нечто подобное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что - это за хрень??  :nono:

Зачем так говно кодить???

 

 

Мало того, что цвета огромное кол-во байт занимают, а ты ещё 11 штук приляпал. Внимательно читай: "с-ж-а-т-и-е".

 

Вы ничего не понимаете, это чтобы не взломали)) http://computercraft.ru/topic/831-zaschischyonnye-soobscheniia-v-opencomputers/

 

Когда то предлагал Тоторо алгоритм сжатия голограмм.  Может и тебе подойдет нечто подобное.

 

 

Интересно.. мне Fingercomp предложил сделать проще:

У меня есть набор из n цветов в разных таблицах, я для каждого цвета создаю индекс в виде одного символа, т.е. чтобы мне передать изображение алмазного монитора 160*50 - оно принимает вид 8 килобайт, но я использую квадратное окно, следовательно у меня абсолютный максимум для алмазного монитора = 4950 байт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Два замечания по теме:

1) Название темы не соответствует вопросу. Не играет роли канал передачи данных. Вопрос в том, как сжать данные.

2) Зачем сначала преобразовывать карту высот в цветное изображение, а потом его сжимать, если можно сжать первичные данные, и уже в конце декодировать в цветную картинку? Конечно, если цветопередача приемника ограничена, имеет смысл еще до передачи произвести огрубление данных, но желание передавать именно картинку, создает лишние проблемы.

 

И один вопрос: В каком формате приходят данные с камеры? Полагаю, что это построчная развертка удаленности в каждой точке. В каком формате эти числа? Меня интересует диапазон и точность. Сколько уровней должно получиться на выходе (на тепловой карте)? Исходя из этого можно будет придумать или подобрать алгоритм сжатия без потерь.

 

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

Интересно.. мне Fingercomp предложил сделать проще: У меня есть набор из n цветов в разных таблицах, я для каждого цвета создаю индекс в виде одного символа, т.е. чтобы мне передать изображение алмазного монитора 160*50 - оно принимает вид 8 килобайт, но я использую квадратное окно, следовательно у меня абсолютный максимум для алмазного монитора = 4950 байт.

Собственно, я предлагаю то же самое.

Преобразуем карту высот в n уровней и передаем именно ее.

Если сжатие недостаточно, можно использовать дельта-кодирование.

Всё очень просто.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Два замечания по теме:

1) Название темы не соответствует вопросу. Не играет роли канал передачи данных. Вопрос в том, как сжать данные.

2) Зачем сначала преобразовывать карту высот в цветное изображение, а потом его сжимать, если можно сжать первичные данные, и уже в конце декодировать в цветную картинку? Конечно, если цветопередача приемника ограничена, имеет смысл еще до передачи произвести огрубление данных, но желание передавать именно картинку, создает лишние проблемы.

 

И один вопрос: В каком формате приходят данные с камеры? Полагаю, что это построчная развертка удаленности в каждой точке. В каком формате эти числа? Меня интересует диапазон и точность. Сколько уровней должно получиться на выходе (на тепловой карте)? Исходя из этого можно будет придумать или подобрать алгоритм сжатия без потерь.

 

Первичные данные это числа с плавающей запятой, они округляются сразу, неважно, в цвета или индексы.

Я сделал так, чтобы программа могла работать в качестве передатчика и приемника изображений с автоматической адаптацией под используемый монитор/видеокарту.

 

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

 

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

Собственно, саму строку можно пожать используя data card, либо библиотеку deflate.

Изменено пользователем Doob

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я думал проблема в передаче самого цвета и его отделении. К примеру, при передаче картинки с экрана монитора удобнее всего было отправлять строку, так как таблица с цветом и символом весила слишком много(больше 8кб и модем просто не хотел отправлять). А НЕО опять агрессивный...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь другая проблема, стоит вообще сжимать? Можно же обойтись кодированием, т. к. сообщения передаются моментально. Сжатие и разжатие отнимают время.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь другая проблема, стоит вообще сжимать? Можно же обойтись кодированием, т. к. сообщения передаются моментально. Сжатие и разжатие отнимают время.

Отличный вопрос.

Сжатие при передаче данных это почти всегда поиск оптимума. И тут только практика покажет, стоит ли сжимать и до какой степени. Оптимум зависит от используемого метода сжатия, скорости компрессии-декомпрессии и скорости передачи данных. В твоем случае могу предложить только экспериментальную проверку.

 

Главное, не передавай избыточную инфу. Ты же сейчас передаешь цветовые индексы, а не сами цвета?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отличный вопрос.

Сжатие при передаче данных это почти всегда поиск оптимума. И тут только практика покажет, стоит ли сжимать и до какой степени. Оптимум зависит от используемого метода сжатия, скорости компрессии-декомпрессии и скорости передачи данных. В твоем случае могу предложить только экспериментальную проверку.

 

Главное, не передавай избыточную инфу. Ты же сейчас передаешь цветовые индексы, а не сами цвета?

 

Конечно индексы, цвета не в лезут в сообщение... Хотя можно разбить на пакеты...

 

У меня 46 цветов, т. е. 46 индексов для одного символа, для сжатия берем 46 для двух идущих подряд, 46 для 4х, 46 для 8, 46 для 16... Следовательно, в общем имеем 46*5 = 230 индексов с индексами сжатия, в идеальных условиях (в пределах видимости 33 блока нету никаких блоков) процент сжатия равен

( ( ширина передаваемого изображения / 16 ) * длинна передаваемого изображения) / (ширина*длинна)

Но, если камера в пещере, где блоки находятся на рандомном расстоянии, то сжатие = 0%, тогда какая разница сжимать или не сжимать?

Изменено пользователем Doob

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не понимаю, о чем идет речь:

  • 46 индексов для одного символа Имеется в виду – возможных индексов?
  • для сжатия берем 46 для двух идущих подряд, 46 для 4х, 46 для 8, 46 для 16... Как берем, что делаем?
  • Следовательно, в общем имеем 46*5 = 230 индексов Откуда появилось пять?
  • процент сжатия равен... откуда взялась такая формула?

Поэтому я не понимаю, почему сжатие для камеры в пещере будет нулевым.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не понимаю, о чем идет речь:

  • 46 индексов для одного символа Имеется в виду – возможных индексов?
  • для сжатия берем 46 для двух идущих подряд, 46 для 4х, 46 для 8, 46 для 16... Как берем, что делаем?
  • Следовательно, в общем имеем 46*5 = 230 индексов Откуда появилось пять?
  • процент сжатия равен... откуда взялась такая формула?

Поэтому я не понимаю, почему сжатие для камеры в пещере будет нулевым.

 

Попробую по-порядку.

  • Имеется ввиду используемых в программе цветов.
  • Повторное кодирование повторяющихся символов, т. е. уже сжатие.
  • Из предыдущего вывода - 1 символ, 2 символа, 4 символа, 8, 16.
  • Из здравого смысла - максимально возможное сжатие - в 16 раз (т. е. 16 символов идущих подряд кодируются одним)

Сжатие в этой теоретической пещере равно 0%, потому что шум сжать невозможно.

Изменено пользователем Doob

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь понял, как ты сжимаешь: вместе с индексом цвета пересылаешь количество символов.

Но откуда взялось 5, ты так и не пояснил.

 

Картинка в пещере не шумовая. В ней должно быть эффективным дельта-кодирование.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь понял, как ты сжимаешь: вместе с индексом цвета пересылаешь количество символов.

Но откуда взялось 5, ты так и не пояснил.

 

Картинка в пещере не шумовая. В ней должно быть эффективным дельта-кодирование.

 

Кхм... Что есть сжатие?

Берем данные, которые надо сжать:

AAABBBCDDDDEE

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

0 = A
1 = B
2 = C
3 = D
4 = E
5 = AA
6 = BB
7 = CC
8 = DD
9 = EE
Щ = AAA
К = BBB
Ж = CCC
Ю = DDD
Х = EEE
Ъ = AAAA
Л = BBBB
Н = CCCC
И = DDDD
У = EEEE

Проходим по сжимаемому сообщению, подбирая подходящий индекс от самого эффективного к менее эффективному.

 

В итоге получаем это:

AAABBBCDDDDEE = ЩК2И9

Считаем количество символов в исходном тексте и в сжатом.

 

Вход = 13

Выход = 5

(5/13)*100 = 38.46%

Исходный текст был сжат на 38.46%

 

 

Картинка может оказаться шумовой, в этом случае алгоритм сжатия только отнимет время.

Дельта-кодирование это всего-лишь кодирование, у меня используется ничем не хуже, к тому же адаптированно к простому алгоритму сжатия.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

qwerty

 

Только если сжимаешь — не юзай кириллицу в результате, они по два байта жрут, а латиница юзает 1 байт. Изменено пользователем LeshaInc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Картинка может оказаться шумовой, в этом случае алгоритм сжатия только отнимет время. Дельта-кодирование это всего-лишь кодирование, у меня используется ничем не хуже, к тому же адаптированно к простому алгоритму сжатия.

Полностью шумовые картинки почти не встречаются в Майнкрафте. И дельта-кодирование здесь выглядит наиболее уместным. Даже если ты фотографируешь бедрок, там, кончено, виден шум, но и он имеет весьма ограниченный диапазон. Так что, дельта-кодирование должно быть лучше уже использованного тобой как раз для случаев пещер и вообще любых "природных" изображений. Твой алгоритм хорош только для искусственных сооружений, которые чаще всего имеют прямоугольную геометрию. Сжатие всегда отнимает время, и целесообразность его применения можно оценить, только собрав статистику. Но она будет разной для каждого алгоритма и исходных данных.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только если сжимаешь — не юзай кириллицу в результате, они по два байта жрут, а латиница юзает 1 байт.

 

Дурака за меня не держи, я знаю, что такое ASCII

 

 

Полностью шумовые картинки почти не встречаются в Майнкрафте. И дельта-кодирование здесь выглядит наиболее уместным. Даже если ты фотографируешь бедрок, там, кончено, виден шум, но и он имеет весьма ограниченный диапазон. Так что, дельта-кодирование должно быть лучше уже использованного тобой как раз для случаев пещер и вообще любых "природных" изображений. Твой алгоритм хорош только для искусственных сооружений, которые чаще всего имеют прямоугольную геометрию. Сжатие всегда отнимает время, и целесообразность его применения можно оценить, только собрав статистику. Но она будет разной для каждого алгоритма и исходных данных.

 

Я же показывал картинки? Камера сканирует расстояние, а не прямоугольники. Т. е. ровная стена будет выглядеть цветными кругами, а чистый бедрок, с расстояния 5-10 блоков больше чем на половину выглядит шумом.

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

 

Мой вывод - сжатие не необходимость, а понты, вроде шифрования, когда есть modem.send

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить на вопрос...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...