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

[Doob 2 749]

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

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

 

Изменено 3 августа, 2015 пользователем Doob

[Fingercomp 4 409]

Я просто оставлю ссылку. Либа для работы с пыныги. http://oc.cil.li/index.php?/topic/266-libpngimage-a-preliminary-library-for-decoding-encoding-png-images/

[Asummonster 592]

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

 

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}

Изменено 15 июля, 2015 пользователем Asummonster

[NEO 541]

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

 

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}

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

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

[Fingercomp 4 409]

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

 

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 штук приляпал. Внимательно читай: "с-ж-а-т-и-е".

[Zer0Galaxy 2 187]

 

 

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

 

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

[Doob Автор вопроса 2 749]

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

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

 

 

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

 

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

 

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

 

 

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

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

[eu_tomat 2 153]

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

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

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

 

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

 

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

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

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

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

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

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

[Doob Автор вопроса 2 749]

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

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

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

 

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

 

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

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

 

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

 

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

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

Изменено 15 июля, 2015 пользователем Doob

[eu_tomat 2 153]

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

[Asummonster 592]

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

[Doob Автор вопроса 2 749]

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

[eu_tomat 2 153]

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

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

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

 

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

[Doob Автор вопроса 2 749]

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

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

 

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

 

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

 

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

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

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

Изменено 17 июля, 2015 пользователем Doob

[eu_tomat 2 153]

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

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

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

[Doob Автор вопроса 2 749]

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

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

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

 

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

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

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

Изменено 17 июля, 2015 пользователем Doob

[eu_tomat 2 153]

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

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

 

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

[Doob Автор вопроса 2 749]

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

Но откуда взялось 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%

 

 

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

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

[LeshaInc 625]

qwerty

 

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

[eu_tomat 2 153]

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

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

[Doob Автор вопроса 2 749]

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

 

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

 

 

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

 

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

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

 

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