Romario
Окт. 30, 2008 16:50:29
Стоит задача разрубить JPG больших (или очень больших - до 200Мб) размеров на кучу маленьких JPEGчегов (скажем 256х256 пикселей).
Проблема в том, что подобная возможность должна быть на любом устройстве: PC (Windows,Linux) (не проблема), Nokia N8x0 (Linux Maemo) - 40-70Мб ОЗУ, Nokia Series60 - 15-80Мб ОЗУ.
Пока в качестве варианта решения задачи, вижу подробное изучение формата JPG и чтение нужных блоков из большого файла (изображение JPG состоит из кусочков 8х8 пикселей), но это очень времязатратное занятие
Вопрос: может быть есть библиотека, позволяющая узнавать размеры изображения JPG, не загружая файл (уверен, что такое есть) и загружать кусок изображения по его координатам (очень сомневаюсь, но очень хочется).
igor.kaist
Окт. 30, 2008 17:32:23
По поводу первого, это легко сделать при помощи
pyexif.sourceforge.netПо поводу второго, думаю это возможно….
А зачем это, если не секрет? Для одноразового использования, это понятно.
Всвязи с разнообразием платформ, могу предположить что имеем в распоряжении карту? Может имеет смысл присмотреться к другим форматам?
slivlen
Окт. 30, 2008 17:56:11
Romario
Пока в качестве варианта решения задачи, вижу подробное изучение формата JPG и чтение нужных блоков из большого файла (изображение JPG состоит из кусочков 8х8 пикселей), но это очень времязатратное занятие
Может использовать libjpeg?
Romario
Вопрос: может быть есть библиотека, позволяющая узнавать размеры изображения JPG, не загружая файл (уверен, что такое есть)
Размеры можно получить из заголовка jpeg файла. Для этого надо прочитать только его. Н-р с использованием libjpeg получится примерно следующее(правда на C =) ):
#include <stdio.h>
#include <jpeglib.h>
int main()
{
FILE * infile;
struct jpeg_decompress_struct cinfo;
struct jpeg_error_mgr jerr;
cinfo.err = jpeg_std_error(&jerr);
jpeg_create_decompress(&cinfo);
infile = fopen("1.jpg", "rb");
jpeg_stdio_src(&cinfo, infile);
jpeg_read_header(&cinfo, TRUE);
printf("width: %i, height: %i\n", cinfo.image_width, cinfo.image_height);
jpeg_destroy_decompress(&cinfo);
return 0;
}
igor.kaist
Окт. 30, 2008 18:00:44
slivlen
Может использовать libjpeg?
Так платформы то разные… PyEXIF pure-python и после небольшой дороботки напильником работает даже на series60.
и что за глюк в твоем посте, это писал не я :)
slivlen
Окт. 30, 2008 18:09:07
igor.kaist
Так платформы то разные… PyEXIF pure-python и после небольшой дороботки напильником работает даже на series60.
libjpeg вроде и под симбиан уже портировали. pure-python решение - это хорошо, но вот со скоростью могут быть проблемы на мобильных девайсах. Хотя лично я ее не замерял =)
igor.kaist
и что за глюк в твоем посте, это писал не я smile
Не знаю, кнопку цитирования юзал =) Цитату поправил.
igor.kaist
Окт. 30, 2008 18:23:49
slivlen
pure-python решение - это хорошо, но вот со скоростью могут быть проблемы на мобильных девайсах. Хотя лично я ее не замерял =)
Я
проверял, нормально :) всего то нужно,прочитать exif заголовки. Нет особенной разницы какого размера файл.
Вот по поводу чтения по частям, стоит всетаки выбрать другой формат. Romario, всетаки карты?
Romario
Окт. 30, 2008 18:52:05
Игорь, правильно угадал - карты. Собственно преобразование большого JPG в кучу маленьких - это необходимость думаю понятная. Будут ли эти маленькие JPGами или каким то другим форматом - еще не решал - посмотрю по ресурсоемкости и производительности. Возможно буду использовать GIF, так как 256 цветов будет более чем достаточно.
Всю эту гадость я затеял для того, чтобы создать кроссплатформенный и бесплатный аналог OziExplorer (кто не в курсе - это программа под Windows и Windows Mobile для работы с растровыми картами). Под Series60,80,UIQ такой аналог есть - это SmartComGPS, а вот под устройства на GNU/Linux - к сожалению не ничего даже близко стоящего. А мне оно очень нужно (да и людям думаю пригодиться).
К слову о вероятных форматах карт. В обоих озвученных мною программах изображение разбито на сегменты, которые подгружаются по мере необходимости отобразить их на экране. К тому же там содержатся уменьшенные копии изображений для оперативного маштабирования (иначе при попытки просмотреть всю карту на экране чего-либо, пришлось бы по сути, открывать целиком все квадраты).
Всем спасибо за помощь.
bw
Окт. 30, 2008 20:56:06
JPEG, после дискретно косинусного преобразрования, подвергается компрессии алгоритмами RLE (LZW?) и Huffman. Но я точно не знаю сжимаются фрагменты 8x8 или уже всё в кучу. Для тебя было бы лучше, если сжимались фрагменты. К тому прогрессивные JPEG (аналог черезстрочности для GIF) так же могут усложнить тебе жизнь, ибо данные одного участа изображения будут размазаны по всему файлу, тонкостей этого алгоритма не знаю.
Можно пойти другим путем. Некоторые библиотеки (PIL) по загрузке JPEG вполне сностно могут работать с битыми изображениями. Попробуй образать файл (не грузить весь), это позволит сэкономить память на размер оставшейся части файла, так как память под bitmap все же будет выделена в полном объеме. Хотя этот вопрос нужно изучать, разные библиотеки будут по разному себя вести.
..bw
igor.kaist
Окт. 30, 2008 22:03:29
Модуль graphics на симбиан не поддерживает gif. Только png и jpg. Может стоит использовать векторный формат. Не думал над этим? Скорость динамической отрисовки примитивов думаю должна быть выше, чем чтение сжатых графических файлов. Карты в каком формате? Может нет смысла переводить в другой формат, а использовать уже готовые карты. Кстати насчет симбиана могу помочь, есть опыт неплохой работы с ним.
shiza
Окт. 30, 2008 23:48:41
PNG рулит =)