LINUX.ORG.RU

Чем/как няшно порезать большую картинку на маленькие?


0

0

Ищу какую-то библиотеку, дабы можно было скормить ей многомегабайтную картинку, она _без_полной_распаковки_ бы порезала ее на небольшие тайлы (скажем, 256х256 пикселей), при этом не пыталась выделить память под все сразу. Особенно приятно было бы, если бы оно сразу генерировало и уменьшенные копии тайлов, как это делает GoogleMaps, т.е. уменьшает до тех пор, пока вся картинка 65000х65000 пикселей не влезет в рамку 256х256 пикселей (правда это можно уже и потом нагенерить, из уже сохраненных тайлов, частями)

JPEG можно нарезать без потерь, библиотеки видел, но все платные. Желательно такую же штуку для PNG. Есть что-то такое, или самому быдлокодить?

На всякий случай: да, я могу взять готовый ImageMagick и сделать все с ним, но если будет картинка 65000х65000 (могу дать такую), оно попытается сожрать 16 гигов оперативы, которых на сервере обычно нет, залезет в своп и тогда хана всему, особенно если не настроены лимиты

simple_best_world_web_master
() автор топика
Ответ на: комментарий от simple_best_world_web_master

Так ведь jpeg'и все равно кодируются по строчке «за присест». Так что, как ни крути, все равно придется, по крайней мере, хотя бы под 256 целых строк считывать, а с ними уже работать. Один мой знакомый занимался в свое время разработкой (правда, под мастдай, но собирался переделать и под линукс) программы, позволяющей работать с большими изображениями. Она считывала картинку кусками. Хотя, может быть и для ваших нужд уже что-нибудь написано.

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от simple_best_world_web_master

и в libjpeg и в libpng есть примеры построчного чтения и записи. Читаешь по X строк в массив байт, потом бегаешь по этому массиву, читаешь данные, пишешь из них столько-то файлов. Читаешь следущие X строк... Таким образом, под буфер понадобится 65000*256*32 байт

alex_custov ★★★★★
()
Ответ на: комментарий от alex_custov

> 65000*256*32 байт

почему 32? Это в битах наверное?

Ну в lossless более менее понятно, благо перепаковки все равно не избежать, да и проблем особенных она не создаст, а вот в случае с lossy, да особенно с jpeg... Он упакован квадратиками по 8х8 пикселей, в теории его можно нарезать БЕЗ пересжатия, если сами квадратики не трогать и резать вдоль них. libjpeg вроде умеет, буду ковырять

simple_best_world_web_master
() автор топика
Ответ на: комментарий от simple_best_world_web_master

упакован квадратиками по 8х8 пикселей

А разве libjpeg позволяет делать такое? Вроде бы, за один раз упаковывается только n-е количество строк (jpeg_write_scanlines)...

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от alex_custov

Увы, видимо с libjpeg ничего не выйдет, ибо на jpegtrans (простая утилька-демка) при обработке картинки 10000х10000 уходит:

==30951== malloc/free: 13 allocs, 13 frees, 225166924 bytes allocated.

а апи самой libjpeg не позволяет читать DCT кусками, jpeg_read_coefficients вызывается 1 раз для всей картинки

simple_best_world_web_master
() автор топика
Ответ на: комментарий от simple_best_world_web_master

может у imagemagic есть настройки по использованию памяти ?
для netpbm сказано, что алгоритмы будут пытаться как можно меньше памяти пользовать (зависит от задачи)
но может руками и быстрее получится

x905 ★★★★★
()

По моему для этого нужен не jpeg а tiff. Tiff специально разрабатывался для работы с очень большими сканированными оригиналами на очень древних машинах и как следствие он оптимизирован под то чтобы подгружать картинку кусками.

Absurd ★★★
()
Ответ на: комментарий от Obey-Kun

> Может, стоит решать задачу иначе? Например, хранить в уже нарезанном виде.

Дабы хранить картинку в нарезанном виде, ее сначала надо нарезать....

simple_best_world_web_master
() автор топика
Ответ на: комментарий от x905

> может у imagemagic есть настройки по использованию памяти ?

не нашел, а вот у jpegtran есть, однако ситуацию это не меняет. Вот сейчас курю исходники и пытаюсь работать с DCT напрямую, наверное будет лучше

simple_best_world_web_master
() автор топика

Попробуйте vips. С помощью nip2 (который по сути gui к vips) я читал огроменные панорамы в jpeg и tiff - они спокойно загружались по кускам и влезали в память. А vips и библиотека, и набор CLI тулзов на манер ImageMagick - можно использовать как хочешь.

slovazap ★★★★★
()
Ответ на: комментарий от alex_custov

> Таким образом, под буфер понадобится 65000*256*32 байт

Будет достаточно 65000*4 (для одной строки исходного изображения) + 256*256*4 (или 3, если не нужна альфа) для выходного куска. Правда придется в этом случае читать каждую строку по 65000/256 раз.

andreyu ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.