Народ — хотелось бы обсудить тему того, как в фотошопе устроен ИХ менеджер памяти. Пока что у меня не получается придумать аналог, который работал бы с такойже скоростью. Есть какие-нибудь соображения?

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

ATP>Народ — хотелось бы обсудить тему того, как в фотошопе устроен ИХ менеджер памяти. Пока что у меня не получается придумать аналог, который работал бы с такойже скоростью. Есть какие-нибудь соображения?

Слова-то какие умные... "Менеджер памяти"...
Работа через ScanLines позволяет добиться отличных результатов, сопоставимыми по скорости работы с фотошоповской

Здравствуйте, Аноним, Вы писали:

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

ATP>>Народ — хотелось бы обсудить тему того, как в фотошопе устроен ИХ менеджер памяти. Пока что у меня не получается придумать аналог, который работал бы с такойже скоростью. Есть какие-нибудь соображения?

А>Слова-то какие умные... "Менеджер памяти"...
А>Работа через ScanLines позволяет добиться отличных результатов, сопоставимыми по скорости работы с фотошоповской

Именно менеджер, т.к есть собственный файл подкачки и память вродибы организована тайлами. Интересно у Photoshopа используется линейная модель при работе с изображением или нет?

Здравствуйте, Аноним, Вы писали:

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

ATP>>Народ — хотелось бы обсудить тему того, как в фотошопе устроен ИХ менеджер памяти. Пока что у меня не получается придумать аналог, который работал бы с такойже скоростью. Есть какие-нибудь соображения?

А>Слова-то какие умные... "Менеджер памяти"...
А>Работа через ScanLines позволяет добиться отличных результатов, сопоставимыми по скорости работы с фотошоповской

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

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

R>Здравствуйте, Аноним, Вы писали:

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

ATP>>>Народ — хотелось бы обсудить тему того, как в фотошопе устроен ИХ менеджер памяти. Пока что у меня не получается придумать аналог, который работал бы с такойже скоростью. Есть какие-нибудь соображения?

А>>Слова-то какие умные... "Менеджер памяти"...
А>>Работа через ScanLines позволяет добиться отличных результатов, сопоставимыми по скорости работы с фотошоповской

R>ScanLine — это хорошо, но он не решает проблемы загрузки/отображения/редактирования файлов в пару гигабайт... Если картинки сравнительно небольшие — то все замечательно.

Ах, вот о чём речь.
Я видел эту тему в книге Дарахвеидзе П.Г. и Маркова Е.П. "Программирование в Delphi 5".
Там есть глава, где описана работа с графическими файлами объёмом до нескольких террабайт(!).

А>Ах, вот о чём речь.
А>Я видел эту тему в книге Дарахвеидзе П.Г. и Маркова Е.П. "Программирование в Delphi 5".
А>Там есть глава, где описана работа с графическими файлами объёмом до нескольких террабайт(!).

Ну а можно в двух словах, что там написано на эту тему?
И еще вопрос: Что понимается под термином ScanLine? Может я знаю, но незнал что это именно так называется...

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


А>>Ах, вот о чём речь.
А>>Я видел эту тему в книге Дарахвелидзе П.Г. и Маркова Е.П. "Программирование в Delphi 5".
А>>Там есть глава, где описана работа с графическими файлами объёмом до нескольких террабайт(!).

ATP>Ну а можно в двух словах, что там написано на эту тему?
ATP>И еще вопрос: Что понимается под термином ScanLine? Может я знаю, но незнал что это именно так называется...

ScanLines — одноимённый массив байт, в кототых хранится картинка. Доступ к пискселям происходит непосредственно, а не через тормозную канву (Canvas)

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


А>>Ах, вот о чём речь.
А>>Я видел эту тему в книге Дарахвелидзе П.Г. и Маркова Е.П. "Программирование в Delphi 5".
А>>Там есть глава, где описана работа с графическими файлами объёмом до нескольких террабайт(!).

ATP>Ну а можно в двух словах, что там написано на эту тему?
ATP>И еще вопрос: Что понимается под термином ScanLine? Может я знаю, но незнал что это именно так называется...

...в двух словах описать не могу, т.к. книга лежит дома, а я сейчас на работе.
Поищи, может в сети есть где-то эта книга или статья из неё

Здравствуйте, Аноним, Вы писали:

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


А>>>Ах, вот о чём речь.
А>>>Я видел эту тему в книге Дарахвелидзе П.Г. и Маркова Е.П. "Программирование в Delphi 5".
А>>>Там есть глава, где описана работа с графическими файлами объёмом до нескольких террабайт(!).

ATP>>Ну а можно в двух словах, что там написано на эту тему?
ATP>>И еще вопрос: Что понимается под термином ScanLine? Может я знаю, но незнал что это именно так называется...

А>...в двух словах описать не могу, т.к. книга лежит дома, а я сейчас на работе.
А>Поищи, может в сети есть где-то эта книга или статья из неё

Ну понятно все про ScanLine..... Photoshop конечно работает не так. Пойзучав немного, я пришел к выводу, что его менеджер памяти реализован по Тайлам (квадратам NxM) и память под них он выделяет по мере необходимости. Но вот вопрос: можно ли Тайловую организацию памяти обьединить с линейной (например с помощью структурных исключений)?

Здравствуйте, Аноним, Вы писали:

А>Ах, вот о чём речь.
А>Я видел эту тему в книге Дарахвеидзе П.Г. и Маркова Е.П. "Программирование в Delphi 5".
А>Там есть глава, где описана работа с графическими файлами объёмом до нескольких террабайт(!).

Если бы ещё эти советы были практически применимы..

Речь там шла всего-лишь о проецировании файла с картинкой в память..
Но такой способ с фотошоповским менеджером и рядом не лежал..

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

D>Здравствуйте, Аноним, Вы писали:

А>>Ах, вот о чём речь.
А>>Я видел эту тему в книге Дарахвеидзе П.Г. и Маркова Е.П. "Программирование в Delphi 5".
А>>Там есть глава, где описана работа с графическими файлами объёмом до нескольких террабайт(!).

D>Если бы ещё эти советы были практически применимы..

D>Речь там шла всего-лишь о проецировании файла с картинкой в память..
D>Но такой способ с фотошоповским менеджером и рядом не лежал..

Не... ну это совсем не интересно. Для таких методов не нужно книжки читать.
Ну неужели никому не приходилось работать с картинками размером 15000х10000 например ?

ну ты правильно говоришь про тайлы
а что тебе мешает их реализовать?
бери за основу виды организации страничной памяти ОС (т.н. стратегии управления страницами) и вперёд

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

LM>ну ты правильно говоришь про тайлы
LM>а что тебе мешает их реализовать?
LM>бери за основу виды организации страничной памяти ОС (т.н. стратегии управления страницами) и вперёд

Мешает пока то, что у меня в мозгу никак не смешивается линейная структура памяти с тайловой. Ведь я так понимаю, что я не могу веделить меньше 4КБ, т.к. работа ведется по страницам. Получается что я не могу выделить отдельную строку тайла, а могу только сразу несколько строк, да и в соседних тайлах память под строки тоже автоматически выделится. Как быть в таком случае?

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

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

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

Неуверен, что у Photoshopa именно так все и устроено Дело в том, что основную головную боль вносят не функции рисования примитивов, т.к точка, линие и т.д, а фильтры изображений. При такой организации очень неудобно писать филтры и обработки т.к:
1. Мы не имеем линейной организации памяти, а как известно максимальная скорось достигается имеено в этом случае.
2. Мы ловим все глюки связанные с граничными эффектами (т.е. многие фильтры Фотошопа не могут быть написаны для каждого тайла в отдельности)

для фильтров не надо ничего мудрить: основные тормоза при работе с большими изображениями — отрисовка
для фильтров делаешь "в лоб"

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

ATP>Народ — хотелось бы обсудить тему того, как в фотошопе устроен ИХ менеджер памяти. Пока что у меня не получается придумать аналог, который работал бы с такойже скоростью. Есть какие-нибудь соображения?

Помимо тайлов Photoshop строит ещё пирамиды различных уровней детализации для быстрого отображения с раззличным масштабом. Для не очень больших картинок (10000х10000) можео попробовать использовать file mapping.

Рекомендую также посмотреть исходнки GIMP -там вроде также всё сделано через тайлы.

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

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

ATP>>Народ — хотелось бы обсудить тему того, как в фотошопе устроен ИХ менеджер памяти. Пока что у меня не получается придумать аналог, который работал бы с такойже скоростью. Есть какие-нибудь соображения?

Fed>Помимо тайлов Photoshop строит ещё пирамиды различных уровней детализации для быстрого отображения с раззличным масштабом. Для не очень больших картинок (10000х10000) можео попробовать использовать file mapping.

Fed>Рекомендую также посмотреть исходнки GIMP -там вроде также всё сделано через тайлы.

GIMP — смотрел. По скорости и оптимизации GIMP не в какое сравнение не идет с Фотошопом и работает в несколько раз тормознее. Одним словом Open Source — сами для себя делали. И так сойдет...

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

LM>для фильтров не надо ничего мудрить: основные тормоза при работе с большими изображениями — отрисовка
LM>для фильтров делаешь "в лоб"

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

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

Здравствуйте, 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 — посмотри просто описание основной ф-ии маппинга файла.