Здравствуйте.

В моей научной работе настало время перейти от теории к практике и трудности не заставили себя ждать.

Задача такова:

есть 100 тысяч изображений (jpeg) размером от 200Кб до 1Мб — все это "выхлоп" некоего устройства (назовем его скоростной фотоаппарат).
есть алгоритм который умеет распознавать все что надо на одном изображении с минимумом затрачиваемых ресурсов.

ВНИМАНИЕ ВОПРОС! Как оптимальнее всего "скормить" алгоритму эти 100000 файлов?
Интересует для OS Windows, но если у *nix есть объективная возможность сделать это оптимальнее, также готов выслушать идеи.

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

Под оптимальностью понимается наименьшее время (загрузки, записи) без учета алгоритма обработки, то есть считаем что алгоритм выполняется за 0 миллисекунд.

Заранее благодарен.

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

F>ВНИМАНИЕ ВОПРОС! Как оптимальнее всего "скормить" алгоритму эти 100000 файлов?
Первая мысль: не перегружать файловую систему. Нарезать, скажем, на 200 каталогов по 500 файлов, работать по каталогам.
Вторая мысль: если есть возможность, писать результаты на другой физический диск.
Третья мысль: работать в 2 (чтение и запись) или 3 (+обработка) потока. Если обработка действительно моментальная, то можно обрабатывать в потоке чтения или записи.

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

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

Здравствуйте, Sni4ok, Вы писали:
S>... за полночи точно выполнится.
а до минут за 10-30 можно эти "полночи" сократить?

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

F>Здравствуйте, Sni4ok, Вы писали:
S>>... за полночи точно выполнится.
F>а до минут за 10-30 можно эти "полночи" сократить?

Считай сама , скорось чтения 30 мб/сек. Итого 100 Гб прочитать = 100 000 /30 = 10 000/3 = 3300 сек ~ 1 часа
Записать — как правило дольше. Итого 2-3 часа минимум как ни крути, решается только аппаратно.

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

F>а до минут за 10-30 можно эти "полночи" сократить?

какой смысл, если это одноразовое действие.

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

S>какой смысл, если это одноразовое действие.
Подозреваю, что сильно неодноразовое. Видимо, речь идет про подстройку параметров алгоритма

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

S>>какой смысл, если это одноразовое действие.
C>Подозреваю, что сильно неодноразовое. Видимо, речь идет про подстройку параметров алгоритма

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

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

S>когда действие неодноразовое- исходные данные не портят,в случае же если данные образуются постоянно, то нет смысла их писать на диск, чтобы потом прочитать и подпортить- лучше сразу подпортить и писать.
Ну, пусть автор темы даст пояснение.
Я понял задачу так. Есть данные (например экспериментальная выборка, то есть мощного потока данных пока не ожидаем). Надо данные прочитать, сделать действие, записать обратно ("обратно" = "на диск" != "в те же файлы").
Потом смотрят на результат и делают какие-то выводы.

А если одноразовая конверсия, то конечно — пусть хоть сутки или несколько работает. "Машина должна работать, а человек — думать".

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

F>Здравствуйте, Sni4ok, Вы писали:
S>>... за полночи точно выполнится.
F>а до минут за 10-30 можно эти "полночи" сократить?
он сделает это быстрее!

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

F>>а до минут за 10-30 можно эти "полночи" сократить?

A>Считай сама , скорось чтения 30 мб/сек. Итого 100 Гб прочитать = 100 000 /30 = 10 000/3 = 3300 сек ~ 1 часа
A>Записать — как правило дольше. Итого 2-3 часа минимум как ни крути, решается только аппаратно.

30 мб/сек — это на чем?
На приличной дисковой системе скорость ~ 100MB/s.
Т.е. прочитать можно минут за 20. Обработка, как было сказано, "0 миллисекунд" (интересно, а в микросекундах это сколько? ); писать можно, как было предложено выше, на другой диск, одновременно. Итого ~ 20 минут на все.

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

F>есть 100 тысяч изображений (jpeg) размером от 200Кб до 1Мб — все это "выхлоп" некоего устройства (назовем его скоростной фотоаппарат).
Если бы это был не jpeg, а нечто вроде битмапа, то можно было бы использовать отображение файла в память (т.к. тебе нужно записать свои маркеры только в определенные места картинки). Хотя файлы маленькие, так что, наверное, выигрыша особого все равно не будет. С большими файлами имело бы смысл.

You will always get what you always got
  If you always do  what you always did

F>В идеале, на каждую картинку потом желательно нанести графические маркеры (примитивы с небольшим текстом) и картинку записать обратно,
F>вот если еще подскажите как сделать запись на диск оптимальной буду очень признателен.

Писать не "поверх" старых файлов.
Писать на отдельный диск (физический). Диск дефрагментировать перед сеансом.

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

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

A>>Считай сама , скорось чтения 30 мб/сек. Итого 100 Гб прочитать = 100 000 /30 = 10 000/3 = 3300 сек ~ 1 часа
A>>Записать — как правило дольше. Итого 2-3 часа минимум как ни крути, решается только аппаратно.

VF>30 мб/сек — это на чем?
VF>На приличной дисковой системе скорость ~ 100MB/s.
VF>Т.е. прочитать можно минут за 20. Обработка, как было сказано, "0 миллисекунд" (интересно, а в микросекундах это сколько? ); писать можно, как было предложено выше, на другой диск, одновременно. Итого ~ 20 минут на все.

Я боюсь, что и 30 МБ/сек не получится. 100 МБ/сек — это скорость чтения больших файлов большими блоками. Тут же файлы сравнительно маленькие (0.1 -1 МБ), каждый нужно найти, открыть, закрыть. Файловый кэш работать не будет — так как каждый файл будет открывается один раз.
Т.е. я бы не был так оптимистичен... Но стараться надо.

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

F>ВНИМАНИЕ ВОПРОС! Как оптимальнее всего "скормить" алгоритму эти 100000 файлов?

Ну если процессор многоядерный, то можно распараллелить примерно так:

* Чтение jpeg с диска + передача в очередь на "раскодированние Jpg -> пиксели"
* Раскодированние Jpg -> пиксели + передача в очередь на "распознавание"
* Распознавание + передача в очередь на "Вставку графического маркера"
* Вставка графического маркера + передача в очередь на "сохранение"
* Сохранение

В любом случае, основные тормоза будут из-за самого слабого (точнее медленного) звена цепи

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

AD>Ну если процессор многоядерный, то можно распараллелить примерно так:
А зачем это? Ведь сказано же — время обработки 0мс.

если в картинках прописан exif/iptc то можно писать туда — для этого достаточно переписать пару переменных не ичтая файл целиком

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

F>Здравствуйте.

F>В моей научной работе настало время перейти от теории к практике и трудности не заставили себя ждать.

F>Задача такова:

F>есть 100 тысяч изображений (jpeg) размером от 200Кб до 1Мб — все это "выхлоп" некоего устройства (назовем его скоростной фотоаппарат).
F>есть алгоритм который умеет распознавать все что надо на одном изображении с минимумом затрачиваемых ресурсов.

F>ВНИМАНИЕ ВОПРОС! Как оптимальнее всего "скормить" алгоритму эти 100000 файлов?
F>Интересует для OS Windows, но если у *nix есть объективная возможность сделать это оптимальнее, также готов выслушать идеи.

F>В идеале, на каждую картинку потом желательно нанести графические маркеры (примитивы с небольшим текстом) и картинку записать обратно,
F>вот если еще подскажите как сделать запись на диск оптимальной буду очень признателен.

F>Под оптимальностью понимается наименьшее время (загрузки, записи) без учета алгоритма обработки, то есть считаем что алгоритм выполняется за 0 миллисекунд.

F>Заранее благодарен.
Отказаться от использования стандартных ФС и вместо 100 тысяч jpeg-файлов, создать один раздел (или файл), где эти JPEG-файлы будут идти последовательно. За счет строго последовательного чтения данных с диска, скорость возрастет в сотни раз. Если нужно, чтобы на выходе алгоритма были именно jpeg-файлы, то быстрее всего будет почитать про структуры FAT32 и генерить на выходе раздел целиком. Опять же, для строго последовательной записи (к кэшированием FAT-таблиц).