Здравствуйте, LM, Вы писали:

LM>не...
LM>ну тут прям недавно про проецируемые в память файлы говорили... вот их и надо использовать.
LM>и, к тому же, это зачем фильтру надо сразу всю картинку? это должен быть фильтр, для которого изменение пикселя или небольшой группы пикселей основывается на информации обо *всех* остальных пикселях — это что за фильтр такой?
Таких я не встречал, хотя может и есть. А вот когда для обработки одного пикселя требуется довольно большая область вокруг пикселя — такие есть.

Здравствуйте, LM, Вы писали:

LM>не...
LM>ну тут прям недавно про проецируемые в память файлы говорили... вот их и надо использовать.
LM>и, к тому же, это зачем фильтру надо сразу всю картинку? это должен быть фильтр, для которого изменение пикселя или небольшой группы пикселей основывается на информации обо *всех* остальных пикселях — это что за фильтр такой?

Только нужно помнить, что если фильтр реализован в DLL, то сразу накладывается ограничение на использование проецируемых в память файлов, т.е. например замапить хотябы 256Мб уже неполучится!

Удачи всем!

Здравствуйте, LM, Вы писали:

LM>не...
LM>ну тут прям недавно про проецируемые в память файлы говорили... вот их и надо использовать.
LM>и, к тому же, это зачем фильтру надо сразу всю картинку? это должен быть фильтр, для которого изменение пикселя или небольшой группы пикселей основывается на информации обо *всех* остальных пикселях — это что за фильтр такой?

На счет всех пикселей — не встречал, но есть фильтры, которым требуется довольно большая область для обработки одного пикселя (окрестность пикселя)

ничего. я не думаю, что плагины будут использовать граф. данных боьше 256 Мб

Здравствуйте, LM, Вы писали:

LM>не...
LM>ну тут прям недавно про проецируемые в память файлы говорили... вот их и надо использовать.
LM>и, к тому же, это зачем фильтру надо сразу всю картинку? это должен быть фильтр, для которого изменение пикселя или небольшой группы пикселей основывается на информации обо *всех* остальных пикселях — это что за фильтр такой?

Что значит использовать проецируемые файлы (в случае с изображениями)? Ведь с ними всеравно нужно работать окном, напимер по 100МГб. Но тогда файлы несколько не упростят программирование фильтров, т.к. придется самому отслеживать пересечение с границей окна и т.д., а в таком случае, это уже ничем не будет отличатся он любой другой НЕЛИНЕЙНОЙ организации памяти. В общем Photoshop не делает.
Я же хотелбы придумать способ работы с изображением похожий на файл подкачки, что бы Windows сама следила, есть память, нет ее, вышел ли фильтр за границу окна..... Такое можно сделать?

Здравствуйте, Acid the Programmer, Вы писали:

ATP>Я же хотелбы придумать способ работы с изображением похожий на файл подкачки, что бы Windows сама следила, есть память, нет ее, вышел ли фильтр за границу окна..... Такое можно сделать?

Так в чем проблема? Делаешь класс Image, под которым тайловая структура. Фильтры и внешние клиенты работают с классом Image, как с немрерывной матрицей M x N (те они не подозревают о тайловой структуре, и никаких геморроев не испытывают), а Image уже сам поднимает данные для тайла из файла, когда к ним обращаются, и выгружает неиспользуемое. Писал такое, очень давно, для реализации БПФ при размере входа ок 265 МБ, а памяти — 64. Обработка по строкам, ессно, шла медленнее, чем при прямой загрузке файла в память, а по столбцам — на порядки быстрее.

Здравствуйте, Reunion, Вы писали:

R>Погодите, погодите... Как это фильтры в лоб? Чтобы делать в лоб, его надо загрузить в оперативку. А как в 512 мег загрузить 1500 мег? Или есть другов "в лоб"?

Фотошоп и не показывает (на сколько я понимаю) тебе всю картинку в 1500 Mb , это и не зачем.. Он делает с неё превьюшку нужного размера и показывает превьюшку. При увеличении, ты всё равно не работаешь с полной картинкой, а только с её частью, поэтому тайлы в этом очень помогают. Но это всё только догадки пользователя.

Здравствуйте, ivan_k, Вы писали:

_>Здравствуйте, Acid the Programmer, Вы писали:

ATP>>Я же хотелбы придумать способ работы с изображением похожий на файл подкачки, что бы Windows сама следила, есть память, нет ее, вышел ли фильтр за границу окна..... Такое можно сделать?

_>Так в чем проблема? Делаешь класс Image, под которым тайловая структура. Фильтры и внешние клиенты работают с классом Image, как с немрерывной матрицей M x N (те они не подозревают о тайловой структуре, и никаких геморроев не испытывают), а Image уже сам поднимает данные для тайла из файла, когда к ним обращаются, и выгружает неиспользуемое. Писал такое, очень давно, для реализации БПФ при размере входа ок 265 МБ, а памяти — 64. Обработка по строкам, ессно, шла медленнее, чем при прямой загрузке файла в память, а по столбцам — на порядки быстрее.

Ну так, в случае фильтра я работаю с отдельными пикселами, и следовательно что бы не подозревать об "извращенном" хранении картинки, я должен звать функцию GetPixel, что будет очень медленно. В противном случае, при таком подходе я должен работать с окном, а как толькл появилось окно, появляется и весь гемор, с отлеживание его координат, переключением, и т.д. Я же спрашивал об автоматических методах такого контроля.

Идея: например выделяю VirtualAlloc непрерывный кусок в памяти, обрабатываю структурны исключения при необходимости и подключаю новые страницы физической памяти если нужно (АВТОМАТИЧЕСКИ). Если страницы уже не нужны, то сам сбрасываю из на диск или в мапированный файл или еще кудато. Таким образом, я работаю как бы со всей картинкой, но процесс переключения происходит полностью АВТОМАТИЧЕСКИ. Впрос: Можно ли такое осуществить, или есть какие-то неизвестные мне нюанся и подводные камни?

зачем следить за окнами при проецировании?
просто работаешь как с линейной памятью — главное, чтобы больше 256Мб не пытался вынуть за раз

Здравствуйте, LM, Вы писали:

LM>зачем следить за окнами при проецировании?

Секундочку, а как еще.... или я не понял вашу идею.... можно поподробней или иначе объяснить?

LM>просто работаешь как с линейной памятью — главное, чтобы больше 256Мб не пытался вынуть за раз

Через класс как с линейной.. ? что-то не понял ..... если имеентся ввиду переопределить operator[] то каждый раз будет вызываться функция — будут медленно. Или както еще. Можно привести пример, как это должно примерно выглядеть?

а ты с проецируемыми в память файлами работал?
они тем и хороши, что представляют всё как работу с линейной памятью, а всё "пагинацию" берут на себя

Здравствуйте, LM, Вы писали:

LM>а ты с проецируемыми в память файлами работал?
LM>они тем и хороши, что представляют всё как работу с линейной памятью, а всё "пагинацию" берут на себя

Ну елки палки..... ну хоть кто-нибудь читает предыдущие сообщения..... Ну не дают проецируемые в память файлы линейного доступа к памяти без ОКНА. Файл ты проецируешь ЧАСТЯМИ к адресному окну ручками. А следовательно опять окно, опять следить за ним, опять руками переключать и все это будет в коде обработки изображения в том или ином виде. А мне хотелосьбы все это делать полностью автоматически. Как примерно я написал выше — через VirtualAlloc. И еще задал вопрос: можно ли так сделать теоритически?

Да где ты там руками то работаешь???
Ты тогда код приведи чтоль! Я уже засношался объяснять!
Возьми и открой боооольшой файл на проекцию в память и фигач скока влезет — где ты там окно передвигаешь?

Здравствуйте, LM, Вы писали:

LM>Да где ты там руками то работаешь???
LM>Ты тогда код приведи чтоль! Я уже засношался объяснять!
LM>Возьми и открой боооольшой файл на проекцию в память и фигач скока влезет — где ты там окно передвигаешь?

Ну понял, понял что ты имел ввиду Тогда еще есть вопрос:
допустим у меня ОЗУ 100МГб а я проецирую на виртуальное адресное пространство 800МГб и напимер хочу сделать memset всем 800-ам.... как будет вести себя менеджер памяти в таком случае?
1. Он будет свопить в системный файл подкачки, а потом когда Unmap седалаю, скинет все на диск.
2. Страницы которые не влизают в оперативку будет по мере надобности в тот самый отмапленный файл писать.

Почему вопрос возник: попробовал дома, у меня 256 оперативки, так смапировал 400Мб и прошелся memset. И в результате очень уж мне показалось медленно операция прошла и диск мигал вааще капец просто... Можно ли как-ньть ускорить?

Ты не забывай, что 256 оперативки это далеко не 256 физической свободной памяти... Было у тебя свободно физической мегов 50 — вот и получилось медленно
Быстрее вряд ли сделаешь — мапинг на уровне менеджера памяти системы поддерживается.

Здравствуйте, LM, Вы писали:

LM>Ты не забывай, что 256 оперативки это далеко не 256 физической свободной памяти... Было у тебя свободно физической мегов 50 — вот и получилось медленно
LM>Быстрее вряд ли сделаешь — мапинг на уровне менеджера памяти системы поддерживается.

Ладно, хрен с ними с тормозами... Так всетаки в предыдущем вопросе прозвучало:
1. Он будет свопить в системный файл подкачки, а потом когда Unmap седалаю, скинет все на диск?
2. Страницы которые не влизают в оперативку будет по мере надобности в тот самый отмапленный файл писать?

Мне очень важно получить ответ для понимания происходящего.

1. Да, всё, что не умещается в физ. памяти располагается в виртуальной => своп-ся на диск. Но скидывает он на диск, вроде, не обязательно по unmap-у — когда сочтёт нужным (есессно, если файл был открыт на запись, а то екзепшн швырнёт). Кстати, при открытии только на чтение — вот здесь может быть увеличение скорости.
2. Тоже на усмотрение memory manager-а.

Вообще, я этим довольно давно занимался и тебе лучше обратиться в MSDN — посмотри просто описание основной ф-ии маппинга файла.