Я уже спрашивал, но Вы так и не ответили: почему не устраивает сжатие с потерями?
Вопрос далеко не праздный, так как гарантированно сжимать может только алгоритм с потерями. Алгоритм без потерь не может гарантировать, что в результате сжатия удастся сэкономить хотя бы один байт.
Я задачу уже описывал в начале
Матричный датчик ИК MLX90640 дает матрицу температур 32*24 по 4 байта на каждую ячейку
Я огрубляю значение температуры и записываю каждое значение в 1 байт (вот уже и lossy)
Далее эта матрица отправляется на сервер и скармливается нейросетке с обучающими коэффициентами по состоянию оборудованию.
После завершения периода обучения нейросетка по матрице должна выдавать состояние оборудования.
Не хотелось бы нейросетке подсовывать данные хуже того, что я уже сформировал.
Я это читал.
Но ответа на свой вопрос так и не увидел (и до сих пор не вижу).
Кстати, еще в сообщении №7 Вам предложили наиболее разумный вариант дальнейшей работы. Вы провели эти эксперименты? Можете выложить результаты?
товарищ, ты меня извини, но лично я ничего более безумного за прошедшую неделю не видел. Вам с бабосом надо организоваться, отвечаю, синергия попрет.
gzip - 67%
bzip2 - 72%
xz - 71%
Вас этот коэффициент устраивает?
И, кстати, сколько времени занимает сжатие?
gzip жмет 4мс. Но там ведь еще загрузка программы и работа с файлами
Сжатие не ахти какое, но если удастся его реализовать - лучше чем нечего
на какой платформе?
да что вы такое предлагаете ?!
тут проблема решается просто, берется и передается 2-3 байта температуры, а на другом конце превращается в матрицу… вот и все… но вроде ему это не надо предлагать… а у меня реальная проблема, и аналога решения кроме как сжать нету… а если матрица из данных температур разных, (может я не так понял что у него там) то проблема не решается)))
а я уже спросил, что там за данные. может там полезной информации раза в 4 меньше, чем передается.
ну зависит же от природы значений.
если ты температуру передаешь, то передавай раз в день абсолютные значения, а все остальное время - дельты. Дельты там все будут микроскопические, вот и сожмешь.
я не работал с этим датчиком… и времени нету))) если тепловизор, и если для нейросети то там 2 цвета же достаточно будет ?)))
если размер изображения 32 на 24 то передаем данные так 17.1.1.1.23.1.1.1.25.1.1.1.1.1.23.1.1.1.1. и т.д.
где при приеме первые 17 пикселей будут белыми, далее 1 это пиксель где тепло показывает, затем еще 23 белых пикселя, потом 3 пикселя с температурой, 25 пикселей белых опять температура и т.д.
тоесть отправляем текстом, а потом текст превращаем в картинку…
нет времени вникнуть в вопрос, извините)))
Видишь ли, 99.99% всех самоделок и коммерческих проектов на МК, их функциональные возможности по сути изучны вдоль и поперёк. Всякие протоколы связи, алгоритмы как кирпичики складывай и любуйся(конечно не так просто, утрирую). Так вот, любой будущий проект заранее видно на предмет реализуемости.
Вот я хочу автомобиль изготовить. Легковой. Расход >9л/100км, 100лс, массой 1000кг. Возможно? Вполне, аналогичные конструкции видят все.
А теперь хочу автомобиль с реактивной тягой, вертикальным взлётом, максималкой в 5600км/ч.и расходом 1л/ч. (И Блэк джеком)
Вам надо вникать в чертежи и расчёты чтобы понять нереализуемость?
Спрашивается в 100500 китайский раз: а оно вообще работать как будет? Вы где-нибудь видели передачу графики по УАРТ? А с каких пор снятие температуры объекта требует уже целой матрицы??? вместо одного датчика. Аналоги подобного есть? Нет. Может пора перестать фантазировать и переделать проект в границах реально возможного?
Так у ТС не посто датчик температуры, а сенсор тепловизора. Это можно сказать кадр видеокамеры, где измерение температуры идёт сразу множества точек. Вот и идёт речь о матрице точек, а не об одной точке.
Так и надо соответствующий канал передачи, а не имеющийся канал “натягивать”.
Мы бы сейчас не общались, если бы однажды в лохматые годы люди придумывали как через УАРТ соединить компьютеры.
1 лайк
вайфай, да через сотовую в конце-концов, регистрировать по времени а потом пачкой кидать, например. Это ясно и реально. Начал-сделал-получил результат. Эта возня со сжатием 750 байт очевидная глупость.
и при этих современных скоростях вообще не нужно ничего обрабатывать и жать -кидаешь тупо все данные с этой жалкой матрицы 32х32 или сколько там, по егоных 4 байта на точку.
1 лайк
держи, бабосик, не благодари)
вот и я спрашиваю как теоретически оно может быть могло бы работать))))
спс)))
цифр нет, символов нет, вот только они нужны не токо людям но и машинам! что бы передать инфу)))) я предпочитаю работать с цифрами, берем 4 символа и переводим их в цифры, пусть это будет 99999999 (если быть точнее максимальное число 96969696 так как я работаю с кодировкой utf8 и другие меня пока что не интересуют, и еще там можно 1 выкинуть, все остальные символы часто используются и все нужны, итого их 95 но давайте считать что 100) и вот тут надо какой то алгоритм придумать что бы его уменьшить, и передать уменьшенный результат, а на другом устройстве восстановить… может и иначе как то сделать… вот берем например
unsigned long lowerBound = 0; // Нижняя граница
unsigned long upperBound = 99999999; // Верхняя граница для пятизначного числа
unsigned long guess; // Предполагаемое число
int attempts = 0; // Количество попыток
bool firstGuess = true; // Флаг для первого предположения
int firstResponse = -1; // Переменная для хранения первого ответа (-1 - не задан)
void setup() {
Serial.begin(115200);
Serial.println("Введите число от 0 до 99999999:");
}
void loop() {
if (Serial.available() > 0) {
if (firstGuess) {
unsigned long target = Serial.parseInt(); // Читаем введенное число
Serial.print("Ищем число: "); Serial.println(target);
lowerBound = 0; // Сброс границ и попыток перед началом поиска
upperBound = 99999999; // Сброс границ и попыток перед началом поиска
attempts = 0; // Сброс границ и попыток перед началом поиска
firstGuess = false; // Устанавливаем флаг, что первое предположение сделано
} else { while (lowerBound <= upperBound) {
guess = (lowerBound + upperBound) / 2;
Serial.print("Попытка: "); Serial.println(guess);
attempts++;
Serial.println("Введите '.' для 'больше', ',' для 'меньше' или '/' если число найдено:");
while (true) { if (Serial.available() > 0) {
char input = Serial.read(); if (input == '.') {
Serial.println("Больше");
if (firstResponse == -1) {firstResponse = 1; } // Если это первый ответ
lowerBound = guess + 1; break;
} else if (input == ',') {
Serial.println("Меньше");
if (firstResponse == -1) { firstResponse = 0; }// Если это первый ответ
upperBound = guess - 1; break;
} else if (input == '/') {
Serial.print("Число найдено! "); Serial.print("Результат первого ответа: ");
Serial.println(firstResponse); Serial.print("Количество попыток: ");
Serial.println(attempts);
// Сбрасываем состояние для следующего числа
firstGuess = true; // Сбрасываем флаг для следующего числа
firstResponse = -1; // Сбрасываем результат первого ответа
attempts = 0; // Сбрасываем количество попыток
return;} else {
Serial.println("Неверный ввод. Используйте '.' для 'больше', ',' для 'меньше' или '/' если число найдено.");
}
}
}
}
// Если число не найдено
if (lowerBound > upperBound) {Serial.println("Число не найдено в заданном диапазоне.");}
Serial.println("Введите новое число от 0 до 99999999:");
firstGuess = true; // Сбрасываем флаг для следующего числа
firstResponse = -1; // Сбрасываем результат первого ответа
attempts = 0; // Сбрасываем количество попыток
}
}
}//конец лупа
при загрузке надо наверное нажать сохранить,(что бы в мониторе порта не было крякозябр) затем ввести число, и нажать символ 1(нет времени вникнуть и поправить))) код вырезал из другой части кода))) ) а дальше следовать инструкциям))) можно записать строку из ±(это результаты больше или меньше) затем прогнать через алгоритм Хаффмана, и получить что то типа 110011100011111001001110100111100 что не даст экономии если перевести в байты… но это что бы показать одну из теоретических идей)))) вообще я сейчас думаю можно ли составить виртуальную таблицу, с координатами xyz что бы по ним искать более близкое число к 99999999 что бы из него вычесть эту сумму, передать остаток+ цифры координат xyz для того что на другой машине по координатам построить сумму из которой вычесть остаток, и получить первое число))) суммы будут больше чем 8 знаков, и может быть можно(скорее всего нет) получить экономию))) и куча других таких не работающих теоретических идей, в общем я ищу алгоритм поиска неизвестного числа… что бы сжимать данные))) деление на 2 и запись результата больше или меньше не дает экономию… а 99999999 это диапазон от 01010101 до 99999999 который заменяет 4 символа, мне просто так удобнее, я сначала в цифры перевожу символы, и работаю с цифрами, а потом обратно в символы, не знаю удалось ли обьяснить…
Как ты такой код читаешь?
1 лайк
я его не читаю, читать его не надо, надо грузить и работать с программой через монитор порта)))