Я понимаю о чем вы говорите, но я имел ввиду не работать с входным видео-потоком от камеры (который конечно же будет с высоким fps), а просто вместо сохранения N кадров в N *.jpeg файлов сохранять их как единый пакет h264 вместе с метаданными (таймстепами например). Вообще я согласен, если у вас 4 кадра в секунду, сжимать их при помощи h264 действительно не имеет особого смысла, но кмк начиная с fps 10 и выше использование аппаратного видео-энкодера может иметь преимущество.
Лет 10 назад разработал небольшое приложение под Android, которое решает очень похожую задачу: забирает картинки с камеры и записывает их в JPEG-файлы (плюс их таймстемпы). Работало примерно так: один поток, принимая callback от камеры, копировал raw RGB-картинку (или YUV, не помню точно) в промежуточный буфер; другой поток параллельно забирал эти фреймы из буфера, кодировал их в JPEG и сохранял в файлы. Такое приложение на не самых мощных смартфонах тех времен (например на https://ru.wikipedia.org/wiki/HTC_One_Mini), работая с разрешением фреймов 640x480, выдавало от 20 до 30 кадров в секунду. Интересно, что FPS падал из-за низкого уровня освещения: в этом случае камера автоматически выставляла нужную экспозицию, увеличивая выдержку. Но и экспозицию в Android SDK можно зафиксировать, получая в итоге стабильные FPS. Да, и сохранение в JPEG было сделано просто из-за лени, по идее нужно сжимать кадры в видео при помощи H264 (или H265, AV1), благо аппаратная поддержка кодирования видео встроена сейчас в каждый утюг: так вы получите гораздо более хорошее качество при гораздо меньшем объеме занимаемого места.
В MacOS в Preview есть функция распознавания рукописного текста, вот что получилось для этой картинки: Лена Мишина Леня Минине Лена Мишина Лена Мишица Леня Мишина
Проблема изменение климата не только в одном лишь графике температуры. Посмотрите на график изменения содержания углекислого газа в атмосфере, который мы умеем измерять прямым способом очень точно на очень долгий период в прошлое за счет антарктических ледовых кернов.
В случае использования только значений RGB результат будет совсем не таким. Как минимум, наравне с синей и красной машинами в отдельный кластер будут отнесены зеленая трава и серый асфальт. Приведу пример применения алгоритма K-средних для изображения, взятого из книги Bishop, «Pattern recognition and machine learning»:
Если же использовать вместе со значениями RGB еще и координаты самой точки (как предлагает автор), то возникает вопрос соотношения и нормировки этих величин: может сложиться ситуация, когда разница в расположении точек вносит намного бОльший вес в «расстояние» (которое считается как корень из суммы квадратов разницы соответствующих значений), нежели разница в цвете, либо наоборот. К примеру, для изображения 1000х1000 px максимальная разница координат точек (x и y) составляет 1000, тогда как разница в значении красного, зеленого и синего цветов не больше 255.
Я понимаю о чем вы говорите, но я имел ввиду не работать с входным видео-потоком от камеры (который конечно же будет с высоким fps), а просто вместо сохранения N кадров в N *.jpeg файлов сохранять их как единый пакет h264 вместе с метаданными (таймстепами например).
Вообще я согласен, если у вас 4 кадра в секунду, сжимать их при помощи h264 действительно не имеет особого смысла, но кмк начиная с fps 10 и выше использование аппаратного видео-энкодера может иметь преимущество.
О каком разрешении идет речь?
Лет 10 назад разработал небольшое приложение под Android, которое решает очень похожую задачу: забирает картинки с камеры и записывает их в JPEG-файлы (плюс их таймстемпы). Работало примерно так: один поток, принимая callback от камеры, копировал raw RGB-картинку (или YUV, не помню точно) в промежуточный буфер; другой поток параллельно забирал эти фреймы из буфера, кодировал их в JPEG и сохранял в файлы. Такое приложение на не самых мощных смартфонах тех времен (например на https://ru.wikipedia.org/wiki/HTC_One_Mini), работая с разрешением фреймов 640x480, выдавало от 20 до 30 кадров в секунду. Интересно, что FPS падал из-за низкого уровня освещения: в этом случае камера автоматически выставляла нужную экспозицию, увеличивая выдержку. Но и экспозицию в Android SDK можно зафиксировать, получая в итоге стабильные FPS.
Да, и сохранение в JPEG было сделано просто из-за лени, по идее нужно сжимать кадры в видео при помощи H264 (или H265, AV1), благо аппаратная поддержка кодирования видео встроена сейчас в каждый утюг: так вы получите гораздо более хорошее качество при гораздо меньшем объеме занимаемого места.
В MacOS в Preview есть функция распознавания рукописного текста, вот что получилось для этой картинки:
Лена Мишина
Леня Минине
Лена Мишина
Лена Мишица
Леня Мишина
Проблема изменение климата не только в одном лишь графике температуры. Посмотрите на график изменения содержания углекислого газа в атмосфере, который мы умеем измерять прямым способом очень точно на очень долгий период в прошлое за счет антарктических ледовых кернов.
Если же использовать вместе со значениями RGB еще и координаты самой точки (как предлагает автор), то возникает вопрос соотношения и нормировки этих величин: может сложиться ситуация, когда разница в расположении точек вносит намного бОльший вес в «расстояние» (которое считается как корень из суммы квадратов разницы соответствующих значений), нежели разница в цвете, либо наоборот. К примеру, для изображения 1000х1000 px максимальная разница координат точек (x и y) составляет 1000, тогда как разница в значении красного, зеленого и синего цветов не больше 255.