Устал искать(ключевые слова не могу придумать), решил тему создать.
Расстроила меня FreeImage 3. её предел где-то около 200-250Мег, формат - без разницы.
Удивил встроенный недоделанный TBitmap - 382М bmp прочитал (изображение rgb 24bit), съев в 2 раза больше памяти. Размеры показал правильно, но пощупать его функцией Canvas.CopyRect(R1, Bitmap1.Canvas, R2) не могу, "out of memory" не даёт.
Прога пока 32бит(старая dll держит), но берут меня сомнения и на счет 64 бит....
Проблема наверно не простая, раньше работали с такими растрами только аргис и фотошоп, остальные (ACDSee, FastStone Image Viewer и пр) до 200-400М.
Сейчас FastStone Image Viewer(с версии 5.3) 2Гб открывал, 7Гб нет.
Буду рад ссылкам, советам, предложениям.
На текущий момент у меня мысль такая: написать "велосипед" для чтения bmp (3Гб) с резкой "на лету" на тайлы (куски по 50-10М), про остальные форматы забыть.
PS :Конкретика: нужно открыть(распаковать), точное масштабирование Canvas.CopyRect, и получить доступ к пикселям (например использованием растр.GetDataLineStart(y); аналог Delphi TBitMap.ScanLine, неплохо бы сохранить изменённый.
Специфика (пока не до неё):у "гигантских" растров как правило больше 3-х каналов (+инфракрасные и ультрафиолетовые, 16-битный панхром)
Область использования - ГИС.
Работа с большими(1гигабайт) и гигантскими(10Гб) растрами
Модератор: Модераторы
Работа с большими(1гигабайт) и гигантскими(10Гб) растрами
Последний раз редактировалось Aleh 20.01.2017 01:02:36, всего редактировалось 2 раза.
Ого..
Сам битмап просто массив(векторов) - можно любой функционал написать и при этом не использовать TBitmap.. не проблема..
Сам битмап просто массив(векторов) - можно любой функционал написать и при этом не использовать TBitmap.. не проблема..
Библиотек никаких не посоветую, но вот добрым словом:
* файлы без сжатия - твои друзья! типа bmp, tga - можно прочитать заголовок знать размер и себе составить карту, с каких мест, какие пиксели начинаются. Ну т.е. не читать файл целиком, а только получить информацию.
* В jpeg, поидее, есть "упрощеная версия" изображения. Т.е. сначала читать её?! И... если я не ошибаюсь, там сжатие итак идёт потайлам. Какая из jpeg библиотек поддерживает произвольный доступ я хз.
* в png, сложнее. Сам формат zlib, на самом деле, имеет такую фичу, как сброс словаря. Т.е. поидее можно распаковывая изображения, находить "точки сброса" словаря, и когда нужно прочитать отдельные куски, то можно распаковывать не всё изображение целиком, а только найденными кусками (которые начинаются в точках сброса).
Но, если возможности найти точки произвольного доступа нет, то изображение придётся распаковать, и разрезать на тайлы, а ещё map уровни (для масштабирования), и всё это в отдельных файлах хранить.
(естественно, желательно разрезать в процессе распаковки, не забивая всё изображение в память)
Функции отрисовки, при таком подходе придёться делать свои. (есть мнение, что они не слишком и хитрые будут... не?)
* файлы без сжатия - твои друзья! типа bmp, tga - можно прочитать заголовок знать размер и себе составить карту, с каких мест, какие пиксели начинаются. Ну т.е. не читать файл целиком, а только получить информацию.
* В jpeg, поидее, есть "упрощеная версия" изображения. Т.е. сначала читать её?! И... если я не ошибаюсь, там сжатие итак идёт потайлам. Какая из jpeg библиотек поддерживает произвольный доступ я хз.
* в png, сложнее. Сам формат zlib, на самом деле, имеет такую фичу, как сброс словаря. Т.е. поидее можно распаковывая изображения, находить "точки сброса" словаря, и когда нужно прочитать отдельные куски, то можно распаковывать не всё изображение целиком, а только найденными кусками (которые начинаются в точках сброса).
Но, если возможности найти точки произвольного доступа нет, то изображение придётся распаковать, и разрезать на тайлы, а ещё map уровни (для масштабирования), и всё это в отдельных файлах хранить.
(естественно, желательно разрезать в процессе распаковки, не забивая всё изображение в память)
Функции отрисовки, при таком подходе придёться делать свои. (есть мнение, что они не слишком и хитрые будут... не?)
Конкретика нужна..
если просто резать - то просто move обойтись..
если нужно колдовать с пикселями - вопрос как сложно..
вообще есть библиотека IPP( Intel® Integrated Performance Primitives) которая как раз заточена и оптимизирована для работы с векторами(пикселами).. до больших серверных систем..
лицензия сейчас - фри..
сам её использую.
Добавлено спустя 5 минут 6 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами
https://ru.wikipedia.org/wiki/Integrate ... Primitives
если просто резать - то просто move обойтись..
если нужно колдовать с пикселями - вопрос как сложно..
вообще есть библиотека IPP( Intel® Integrated Performance Primitives) которая как раз заточена и оптимизирована для работы с векторами(пикселами).. до больших серверных систем..
лицензия сейчас - фри..
сам её использую.
Добавлено спустя 5 минут 6 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами
https://ru.wikipedia.org/wiki/Integrate ... Primitives
olegy123 писал(а):Ого..
Сам битмап просто массив(векторов) - можно любой функционал написать и при этом не использовать TBitmap.. не проблема..
... проблема объяснить директору, чем я всё это время занимался, когда есть, например, прямо в компиляторе TLazReaderTiff со всем готовым. Да и самому обидно будет. Кстати мне не удалось прочитать хоть какой нибудь tif используя TLazReaderTiff....
Последний раз редактировалось Aleh 20.01.2017 00:13:48, всего редактировалось 1 раз.
еще это есть:
vampyre
http://imaginglib.sourceforge.net/
Добавлено спустя 1 минуту 14 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами
Native Object Pascal crossplatform library with no dependencies on any dynamically linked libraries or other platform specific binaries. Supported platforms are: Windows, Linux, FreeBSD, Mac OS X, x86/AMD64.
Loading and saving of these image file formats: BMP, JPEG, PNG/APNG, GIF, DDS, TGA, MNG, JNG, JPEG2000, TIFF, PSD, PBM, PGM, PPM, PAM, PFM, PCX, XPM, and more.
Many internal image data formats: 8, 16, 24, 32, 48 and 64 bit RGB and ARGB formats, indexed formats, grayscale formats, floating point formats (IEEE754 and half precision), compressed formats like DXT1/3/5, 3Dc and BTC.
vampyre
http://imaginglib.sourceforge.net/
Добавлено спустя 1 минуту 14 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами
Native Object Pascal crossplatform library with no dependencies on any dynamically linked libraries or other platform specific binaries. Supported platforms are: Windows, Linux, FreeBSD, Mac OS X, x86/AMD64.
Loading and saving of these image file formats: BMP, JPEG, PNG/APNG, GIF, DDS, TGA, MNG, JNG, JPEG2000, TIFF, PSD, PBM, PGM, PPM, PAM, PFM, PCX, XPM, and more.
Many internal image data formats: 8, 16, 24, 32, 48 and 64 bit RGB and ARGB formats, indexed formats, grayscale formats, floating point formats (IEEE754 and half precision), compressed formats like DXT1/3/5, 3Dc and BTC.
Прочитайте про структуру BMP файлов, она, внутри, в самом файле - очень простая и естественно структурированная.
Соответственно сможете считывать пиксели из файла, частями, и на экран выводить уже отскайленную - уменьшенную версию,
При считывании кусочками сразу нужно: скайлить и аппроксимацию - делать до размера экрана (ну или нужного, но умещающегося).
Память, Вы таким образом сохраните и картинку на экран выведите, но если потребуется обработка, то там конечно попотеть придётся.
Времени, считывание кусочками - будет скорее всего занимать меньше, чем при загрузке всего файла в память и попытке там ворочать 10 Гб.
Фотошоп и прочие фИгни, делают тоже самое, только они так умеют работать с любым форматом.
.
Соответственно сможете считывать пиксели из файла, частями, и на экран выводить уже отскайленную - уменьшенную версию,
При считывании кусочками сразу нужно: скайлить и аппроксимацию - делать до размера экрана (ну или нужного, но умещающегося).
Память, Вы таким образом сохраните и картинку на экран выведите, но если потребуется обработка, то там конечно попотеть придётся.
Времени, считывание кусочками - будет скорее всего занимать меньше, чем при загрузке всего файла в память и попытке там ворочать 10 Гб.
Фотошоп и прочие фИгни, делают тоже самое, только они так умеют работать с любым форматом.
.
Пример (ImgBrowser.exe) открывает так-же предел тот-же 200-250мег
Aleh писал(а):открывает так-же предел тот-же 200-250мег
Не пытайтесь искать готовый пакет. Бессмысленно, таких 100% нет. Слишком большой размер файла. Даже текстовые файлы, такого размера считывают частями. Делайте аппроксимацию прямоугольников по 10-100 пикселей, до одного пикселя или считывайте например каждый 10-й или 100-й пиксель. И только при масштабировании до максимального - считывайте и показывайте оригинал. Тоже самое делает и любой DrawScale в пакетах, когда выводит на экран из памяти. А здесь вы будете выводить не из памяти, а прямо с диска. Понимаете?
ИМХО для вашей задачи лучше использовать TIFF для хранения данных
https://ru.wikipedia.org/wiki/LibTIFF
https://ru.wikipedia.org/wiki/GeoTIFF
https://ru.wikipedia.org/wiki/LibTIFF
https://ru.wikipedia.org/wiki/GeoTIFF
olegy123 писал(а):Конкретика нужна..
если просто резать - то просто move обойтись..
если нужно колдовать с пикселями - вопрос как сложно..
вообще есть библиотека IPP( Intel® Integrated Performance Primitives) которая как раз заточена и оптимизирована для работы с векторами(пикселами).. до больших серверных систем..
лицензия сейчас - фри..
сам её использую.
Добавлено спустя 5 минут 6 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами
https://ru.wikipedia.org/wiki/Integrate ... Primitives
У меня к Вам огромная просьба: выложите пожалуйста демо-бинарник с этой библиотекой (раз вы её используете, это не сложно вам будет сделать), я бы протестировал.
vitaly_l писал(а): А здесь вы будете выводить не из памяти, а прямо с диска. Понимаете?
Сейчас в ноутбуках можно 32Gb иметь.
Aleh писал(а):У меня к Вам огромная просьба: выложите пожалуйста демо-бинарник с этой библиотекой (раз вы её используете, это не сложно вам будет сделать), я бы протестировал.
у меня проект под линух, пишу на с++.
Вы бы написали, что вам надо затестить, какую операцию.. я бы сделал exe-шник.
А может и и либлу сделал для lazarus-а.
но это будет на выходных..
имхо лучше свой велосипед, задача несложная особенно если разбить на две части, первое - потоковое чтения нужных форматов с поддержкой тайтлов и масштабированием, для начала достаточно bmp, jpeg, png, исходники есть (вроде), просто скомпоновать, второе менеджмент тайтлов, управление масштабированием.
будет три класса - реадер, тайтл, композитор.
можно сначала без картинок потестить.
для непосредственных манипуляций типа ресайза можно использовать выше предложенную либу IPP, судя по доке она хороша, но! битмапы (буферы) больше 2 гигов не поддерживает в 32бит и даже в 64бит ну или я не нашел обратных утверждений.
будет три класса - реадер, тайтл, композитор.
можно сначала без картинок потестить.
для непосредственных манипуляций типа ресайза можно использовать выше предложенную либу IPP, судя по доке она хороша, но! битмапы (буферы) больше 2 гигов не поддерживает в 32бит и даже в 64бит ну или я не нашел обратных утверждений.
в IPP нет битмапов.. там вектора они же массивы..
есть же GIMP с исходниками. Можно в них покапаться.