Свежие комментарии

Title	Comment
И еще вдогонку.	И еще вдогонку. У меня нет и не могу сделать 3-дисковый массив, есть 8-дисковый (RAID6 на адаптеке) и вот сунул один 10k rpm диск в корзину. Остальной компьютер близкий к вашему: i7-4770k@4.2, 32GB RAM, gtx970. Использую OpenGL-версию FRV, но в данном случае никакой разницы нет. Файлов с A77 у меня столько нету, чтобы тестировать, взял с A7R, из моих предположений об устройстве программы - оно будет линейно медленнее по количеству мегапикселей (формат файла одинаковый и простой, т.е. все тупо упирается в пикселы). Результаты: 8-дисковый массив: при любом количестве decode threads (1-8) оно успевает. 'Highest disk time' пл Perf Monitor - дорастает до 80% но практически никогда не упирается в 100% 1 диск 10k rpm (он будет медленнее массива по линейному чтению, но быстрее по seek) 1 thread - упираемся в ожидание декодирования при листании, диск не насыщается, но оно просто много ждет завершения декодирования т.к. префетч по сути не работает. 2 threads: среднее время капельку лучше, но есть разброс (спотыкач). По process monitor видно, что highest disk time: 100% и уперто именно в диск. ... промежуточные тестировать не стал, на 8threads видна еще более жестокая драка за диск. Рекомендации SSD, конечно. Уж как минимум, для рабочих файлов Если нет, то threads=2.
А, еще.	А, еще. Закрывать не обязательно. Preferences - File Handling - Run single program instance. Тогда окна не размножаются.
Будут вам превьюшки	Будут вам превьюшки (filmstrip) в следующем major update. Сроков не обещаем, но вот в 1.0.5 хвосты текущие подчистили вроде, следущая версия должна быть с Filmstrip.
>> при листании (только)	>> при листании (только) вперед увеличение размера кэша ничего не даст. Вот теперь всё стало на свои места, это фактически кэш назад. >> какая камера, кстати? Sony ILCA-77M2 > Alt-O, стрелку вверх или PgUp 20 файлов было для примера.... Проще тогда закрыть, в FastStone Viewer встать на нужную превьюшку, и опять позвать...
В моем случае гарантия не	В моем случае гарантия не истекла даже "с даты производства", может потому чеков не попросили, не знаю.
Я чек прикладывал, т.к.	Я чек прикладывал, т.к. гарантия на мой диск была ровно 3 года с даты покупки. А на чеке четко была видна дата покупки и серийный номер. Хотя возможно заменили бы и без него.
При листании (только) вперед	При листании (только) вперед увеличение размера кэша ничего не даст. Что за радость с того, что ранее прочитанное остается в кэше. Проблема, повторяю, в HDD: если один линейный поток данных с HDD может читаться ну скажем на 100Mb/sec (c трех, в зависимости от организации - может и 200-300), то несколько потоков декодирования одновременно - дергают головку, мешают друг другу и типичная скорость падает "на порядок" (зависит от диска, от RAID-контроллера если есть, от умности soft-raid/файлового кэша если есть)
В голландию я слал без чеков,	В голландию я слал без чеков, кстати. Просто "ваш диск накрылсо"
Есть размер кэша - сколько	Есть размер кэша - сколько хранить. Есть размер префетча - сколько читать от текущего файла. Если известно направление движения (скажем, листаете вперед), то размер префетча равен количеству decode threads. Если неизвестно (открыли файл и не листаете) - то половинка от decode threads в каждую сторону. Соответственно, спотыкач происходит от того, что у вас запущено много decode threads и они дерутся даже не за процессор, а за диск (потому что HDD очень плохо относится к параллельным запросам на чтение). Соответственно, чем меньше одновременных threads в случае HDD - тем лучше (ну от формата данных зависит, если сильно жатое одна история, если дешевое по декодированию - другая; какая камера, кстати?). Для листания "на 20 вперед" - Alt-O, стрелку вверх или PgUp (размер шага и того и другого зависит от количества файлов в каталоге), Enter.
Паттерн то работы какой?	Вдогонку. Просматриваю файлы из FastStone Viewer. Потом по клавише на нужном файле зову FastRawViewer. Потом знаю, что через файлов 20 есть следующий нужный файл, пытаюсь быстро прокрутить до нужного. вот тут наблюдаетсся "спотыкач". Меня больше всего смущает, что по ощущениям "спотыкач" происходит ну не на 40 файле...
Пролистали (больше чем) на 40 вперед, а потом назад?	Нет, просто листаем вперёд, быстро. Вечером поэксперементирую, с анализом загрузки процессора...
Гарантийная замена SSD OCZ	Тоже поделюсь опытом. В ноябре 2014 приказал долго жить SSD Vertex 2 80 GB. Накрылся контроллер. Проблема массовая, решалась свежей прошивкой. Но этот момент я профукал и в итоге попал на неопределяющийся диск. Нашел здесь информацию. Собирался отправлять в Голландию, но закрутился и забыл. В январе 2015 вспомнил, снова полез сюда обновить в голове процедуру и с радостью прочел что теперь можно отправлять в химки. Гарантия на диск заканчивалась в марте 2015, а продавец успешно разорился еще в конце 2012. В общем создал тикет. Приложил фото чеков о покупке (благо все сохранил). На след день на электронку получил инструкции и RMA. Через пару дней отправил Pony Express в Химки. Получили они его буквально через день, но информация в базе появилась только через 2 недели, т.к. попал на инвентаризацию склада логистов. Изначально писалось что замена будет на аналогичный с припиской RF (Refurbishment - восстановленный), но потом изменилось на Vertex 460. А младший диск в этой линейке на 120 GB. Буквально вчера DHL привезли диск. Vertex 460 120 GB!! Неплохо так то ))))
Паттерн то работы какой?	Паттерн то работы какой? Пролистали (больше чем) на 40 вперед, а потом назад?
уменьшить количество decode threads, скажем до двух.	Уменьшил, стало получше. (кстати не помню по умолчанию сколько стояло, а всё сбрасывать не хочется...) Не такой явный, и сильный, но проскакивает, и как-то не складывается с 40 файлами. Может дать возможность для эксперементов поставить количество файлов побольше в 64 разрядной версии?
Вы занимаете 6 ядр CPU (из 4)	Вы занимаете 6 ядр CPU (из 4) декодированием вперед. Одновременно 8 ядер (из 4), потому что hyperthreading, пытаются заниматься показом. Кроме того, у вас HDD и эти 6 потоков декодирования дерутся еще и за диск. А он не SSD и к конкуренции относится плохо. Имеет смысл попробовать уменьшить количество decode threads, скажем до двух.
потратим на что-то полезное.	Во-во. А то у меня какие-то непонятки с кэшированием. Win 7, SP1, 64 i7-4790k, 16Гб, GTX 970, 3 - HGST HUS724020ALA640 40 RAW, 6 threads Вешаем листание по файлам на колесо мыши. Если крутить колесо на счёт "22" всё идет нормально. Но если увеличить скорость верчения ;) , При первом просмотре, для отбора трэша иногда хочется быстро пробежаться по файлам. Очень быстро наступает "спотыкач", причём довольно серьёзный, и никак 40 файлов в кэше не корелируют с количеством файлов до "спотыкача", там иногда и через 10 наступает....
Количество *показанных на	Количество показанных на экране пикселов - при одном размере окна - одно и то же. Но для их показа нужно прочитать или "примерно все" изображение, или только часть. Кроме того, при зуме меньше 50% будут - при стандартных настройках графики - использоваться mimpaps (версии с уменьшенным разрешением), а генерироваться они могут on demand и, к примеру, на CPU (не знаю как оно сделано у 870m) Кроме того, если мы только смотрим на участок изображения (один раз) - то может быть драйвер ненужное и не пересылает. Короче, там масса мест для оптимизации при показе только куска картинки, но все эти оптимизации - это графический драйвер, а не мы.
то есть все зависит от кол-ва	то есть все зависит от кол-ва показанных пикселей на экране - потому что у меня разница между 15% зумом (картинка занимает маленький кусок в окне) и 100% зумом (картинка занимает соотв все окно) сильно заметна при непрерывном просмотре подряд... gtx870m, i4810mq/32gb
В части процессинга картинки	В части процессинга картинки - никак. Всегда процессится и льется в видеокарту целиком. В той части, которая видеокарта и драйвера - все зависит от. При отрисовки части изображения - отрисовывается только видимая часть, соответственно чем меньше пикселов вы рассматриваете (чем крупнее увеличение), тем быстрее должно быть. С той поправкой, что при разном зуме могут работать разные алгоритмы.
Интереснее, кстати, был бы	Интереснее, кстати, был бы режим с 4 кадрами и честными RGB 16 мегапикселами. Их, правда, учитывая, как сигму пинали за 48 мегапикселов фовеона, так красиво не продашь.
> FRV показывает	> FRV показывает олимпусовский 64-Mpix файл за 0.12-0.15сек а как влияет zoom на экране на скорость ?
Дело же не в формате как	Дело же не в формате как таковом. Ну вот для панасоника формат известен (с поправкой, как видим). Проблема глубже, она в отсутствии внятных стандартов на сколько-нибудь интересные вещи. Ну вот на запись искажений оптики (дисторсия, виньетирование, аберрации). Понятно, у вендоров будут какие-то коэффициенты к какой-то своей формуле. Но никаких попыток стандартизации этого - не делается.
формат этого безобразия	формат этого безобразия
Я вот не понял контекста. Кто	Я вот не понял контекста. Кто опубликует, что опубликует?
А вот честно - не знаю.	А вот честно - не знаю. То есть A2 получается практически "пиксель в пиксель", я бы не трогал, если есть такая возможность. С A3 - можно попробовать, например, дебайеризацию в half с целью подавить часть артефактов.
Пусть хоть такое опубликуют..	Пусть хоть такое опубликуют... Пора бы уже заметить, что за деньги их говнософт никому не нужен.
Вот смотрите, задача FRV -	Вот смотрите, задача FRV - разбор фотографий, а не анализ камеры при покупке. Для разбора фотографий счетчик кадров камеры не нужен. Следовательно, мы на ЭТО тратить время не будем, потратим на что-то полезное.
При таком разрешении, может	При таком разрешении, может ли некий хитрый предварительный "даунсэмплинг" улучшить финальную картинку перед печатью А2-А3?
Для камер Sony есть небольшая	Для камер Sony есть небольшая помощь: \| \| \| \| Sony_Tag9050_0x0032 = 60 \| \| \| \| Sony_Tag9050_0x0033 = 60 \| \| \| \| Sony_Tag9050_0x0034 = 0 (65536 * 0) + (256 * 60) + 60 = 15420 онлайн проверка лежит [utl=http://tools.science.si/index.php]тут[/url] Могу помочь найти для других камер такую информацию...
Вот именно "кто во что горазд	Вот именно "кто во что горазд". А камер мы поддерживаем 780 уже.

Свежие комментарии

Pages