Как быстро сохранить изображение большого размера?

[spirit]

А что qCompress будет все-равно медленным, если степень сжатия поставить 1?

а толку от него, если png уже пожат?

[SABROG]

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

[spirit]

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

ааа, ну тогда есть смысл конечно. не понял сначала. 

[SABROG]

А вообще 60 картинок (fps) размером 2500x2000 это даже самый оптимизированный видео-кодек быстро не сожмет. Конечно на скорость будет влиять количество разнообразия пикселей. Если создать белую картинку с одним черным пикселем в центре, то операция будет достаточно быстрой. Но когда 10 человек начнут рисовать что-то свое на таком здоровом поле, то скорость упадет очень быстро.

[¤Se®ega¤]

Формат изображения не обязательно PNG. Размер сегодня уменьшили до  1600*1200.И как вы считаете, если применять методы bits,scanLineбьуьсзн, возможно повысить производительнность?Сейчас важно сгенерированную картинку запихнуть в сокет с частотой 50 fps.'nj сейчас самое слабое место.При сохранении картинки в формате PNG с разрешением 2560*2048 частота была порядка 1 fps, картинку в формате BMP "передавал" в 4-5 раз быстрее.Возможно изменение размера повлияет на частоту, но думаю не в десятки раз.

[SABROG]

Я так и не понял предназначения подобной программы. 50 fps человеческий глаз не воспринимает. Оптимально 25-30. А если надо просто видеть как человек линию ведет, то там все 5 fps подойдут, просто видео будет рывками. А к чему такая точность?

[Sergeich]

Камрад Серега!
Давай определимся, и не будем множить темы на форуме об одном и том же - у тебя уже штук восемь постов по одной конкретной задаче . Давай, если ты не против, сделаем так:
Ты излагаешь здесь свою задачу: а именно - для чего нужна программа, зачем архитектура клиент-сервер, зачем OpenGL, зачем передавать по сети 4-х мегапиксельные картинки с FPS = 50?
Если ты это сделаешь - сразу снимется хренова туча вопросов (libastral, к сожалению, собирается не у всех). И, я уверен, на все твои проблемы найдется хоть один, но дельный совет.
Лично я могу дать совет по использованию OpenGL, передачи данных по сети, и кодированию/декодированию видеопотока, но только в том случае, если задача поставлена нормально.

[SABROG]

Не знаю как вам, а мне подобная задача напоминает попытку сделать полноэкранную 3d игру типа Call of Duty, только вся работа с граффикой идет не на видео-карте клиента, а на сервере. Что-то типа thin client для игр.

[¤Se®ega¤]

Прохожу практику на фирме, занимающейся видеонаблюдением.Руководитель, человек неглупый, дал задание: Создать программу, которая сможет отображать КАРТИНКИ размером (уже 1600*1200) с частотой 50 fps ну и в дальнейшем еще и на несольких мониторах разные картинки.Чтобы видеть, что мы картинки в дейцствивельности получаем надо сделать анимацию, например средствами OPenGL, так как это быстро, чтобы получать картинки и не загружать программу их генерацией,можно организовать  клиента и сервера, сервер генерит, клиент получает и отображает.Картинка уже известным рамером отображаем с известной частотой.Теперь что касается необходимости этого "проекта".Возможно в дальнейшем сервр с генерацией будет заменен на поток данных с камер,которые бдут передавать изображения с подобным разрешнием и подобной частотой.

[spirit]

значит все-таки видео поток.

[SABROG]

Камеры уже в каком-то формате передают видео-поток. По сути ты пытаешься на Qt написать свой алгоритм сжатия этого видео-потока, вместо того, чтобы заняться поиском кроссплатформенного декодера для потока с камеры и проверить насколько хватает пропускной способности сети и мощности компьютера, чтобы передать какой-нибудь сгенеренный фильм в Sony Vegas с подобной частотой и разрешением.

[¤Se®ega¤]

Какого сжатия? вы о чем? мне надо картинку нарисовать, записать во что-то, это что-то передать, и потом отобразить, все.

[SABROG]

Какого сжатия? вы о чем? мне надо картинку нарисовать, записать во что-то, это что-то передать, и потом отобразить, все.

Ага картинку... Если быть точнее, то 50 картинок в секунду с разрешением 1600*1200 по сети и видимо, чтобы не лагало и без задержек. А это уже ну никак не картинка, а видео-поток.

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

Если действительно ограничиваться рамками нарисовать картинку и передать, то какой смысл вообще за это браться, если это изначально неверный подход, который в итоге приведет к тому о чем тебе уже сказали. Лишняя трата времени. Надо подстраиваться под реальную ситуацию, а не под абстрактную. Или создать искусственные условия.
Поставь в сети VLC сервер настрой мультикастинг, сгенери в Sony Vegas или virtualdub видео поток с фрейм-рейтом 50 фпс и разрешением 1600*1200, затем настрой бесконечную прокрутку этого потока в VLC и поставь кодек, аналогичный тому, что стоит в системе видео-наблюдения. Изучи протокол, по которому идет передача видео-потока и начинай дешифровывать его с помощью средств Qt.

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

[¤Se®ega¤]

Куда-то все не туда. касеры, видео, суммы.

[kamre]

сможет отображать КАРТИНКИ размером (уже 1600*1200) с частотой 50 fps ну и в дальнейшем еще и на несольких мониторах разные картинки.

Нормальный такой поток данных: 1600*1200*3*50 / 2^20 ~ 275 MBytes/sec. Внутри компа такой поток можно гонять довольно просто между CPU/GPU/RAM. Но уже не всякий жесткий диск осилит чтение данных с такой скоростью. По сетке такое гонять далеко не по всякой получится.

Так что надо определиться с задачей. Для видеонаблюдения такой поток какой-то не реальный просто. Но, скажем, создавать картинки с указанной скоростью в одном процессе и отображать в другом процессе на одном и том же компе вполне реально - пример X Window system.