Файловый API-интерфейс для растровых изображений [закрыт]

Question

Файловый API-интерфейс для растровых изображений [закрыт]

0

Я хочу писать измененные сектора по объему в растровом изображении. Я не думаю, что это полезно использовать в битовой карте памяти, потому что громкость может быть чрезвычайно большой, и большой объем оперативной памяти будет постоянно занят. Я думаю, что файловое растровое изображение (битмап в файле на диске) будет оптимальным. Снижение производительности будет значительно смягчено менеджером кэшей Windows. В Windows есть много классов для работы с битовыми картами памяти (бит-массив), но я не могу найти готовые к использованию реализации файловых растровых изображений. Например, мне нужен void, который может установить некоторые бит (от n до k) в этом файле. Может писать, но я предпочитаю использовать готовый lib. Вы знаете некоторые подпрограммы, apis или libs для этого? Я принимаю c или c++, режим пользователя или ядро.

Brans Ds 04 июнь 2014, в 13:56

Источник

0

Насколько большой вы ожидаете, что ваш растровое изображение будет?
Yexo 04 июнь 2014, в 11:45
0

@Yexo. Насколько большой может быть пользовательский объем? Максимальный размер тома для кластеров ntfs 2 ^ 32. Так может иметь до 2 ^ 32 бит в битовой карте
Brans Ds 04 июнь 2014, в 11:50
1

Предполагая размер сектора 4 КБ и объем 1 ТБ, «просто» 256 миллионов секторов. Если вы используете 1 сектор = 1 px, с 256-битным цветом растровое изображение будет иметь размер 256 МБ, а с 32-битным цветом - 1 ГБ. Все еще управляемый в памяти. Я сомневаюсь, что есть какая-то основа для эффективной обработки таких больших растровых изображений, но написание BITMAPINFOHEADER и последующий вывод буфера представляется наиболее эффективным решением.
Agent_L 04 июнь 2014, в 11:51
1

@Agent_L Я действительно не думаю, что «растровое изображение» здесь относится к изображению.
unwind 04 июнь 2014, в 12:35
0

@unwind ровно. не изображение. массив битов.
Brans Ds 04 июнь 2014, в 12:43

Показать ещё 3 комментария

Теги:

c++

c

1 ответ

Ещё вопросы

Насколько большой вы ожидаете, что ваш растровое изображение будет?
@Yexo. Насколько большой может быть пользовательский объем? Максимальный размер тома для кластеров ntfs 2 ^ 32. Так может иметь до 2 ^ 32 бит в битовой карте
Предполагая размер сектора 4 КБ и объем 1 ТБ, «просто» 256 миллионов секторов. Если вы используете 1 сектор = 1 px, с 256-битным цветом растровое изображение будет иметь размер 256 МБ, а с 32-битным цветом - 1 ГБ. Все еще управляемый в памяти. Я сомневаюсь, что есть какая-то основа для эффективной обработки таких больших растровых изображений, но написание BITMAPINFOHEADER и последующий вывод буфера представляется наиболее эффективным решением.
@Agent_L Я действительно не думаю, что «растровое изображение» здесь относится к изображению.
@unwind ровно. не изображение. массив битов.

user1937198 · Accepted Answer · 2014-06-04T09-11-00.000Z

EDIT: Теперь, когда вы сказали, что размер вашего растрового изображения составляет 2 ^ 32 бит, просто используйте нормальное распределение. С 64-битными процессами выделение GB не является проблемой.

Во-первых, я предполагаю, что вы используете 64 бит. Если нет, переключитесь, так как это упрощает работу при работе с большими файлами.

Если растровое изображение больше, чем разумно хранить в файле страницы (> 20-50 ГБ), используйте файл с сохраненной памятью, иначе просто используйте нормальное распределение. Файл с отображением памяти обеспечивает преимущества хранения данных в памяти, но без недостатка требующих больших объемов пространства подкачки, поскольку файл используется как отдельный файл страницы.

Если файл достаточно мал для размещения в вашем адресном пространстве (128 ТБ на 64 бит), тогда вы можете просто отобразить весь файл, в то время как если он больше, вам просто нужно отобразить в той части, в которой вы работаете.

О том, как сопоставить файл в памяти, см. По адресу: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537(v=vs.85).aspx.

мне нужно сохранить этот растровое изображение перед перезагрузкой, не лучше ли файлы с отображением в памяти для этого, чем обычное распределение + сериализация / десиарилизация? хотите, чтобы потребление памяти было хуже с растровым изображением в памяти, если я буду часто писать / читать случайным образом из растрового изображения?