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

"мазохизм" со склейками нужен для того, чтобы получить мегапикселей в разы (или больше), чем их есть на сенсоре; а ваша "панорама" в сколько раз больше дает? полтора? можно просто ширик взять с бОльшим углом обзора и камеру с пиксельным сдвигом матрицы (пентакс к-1)

От 3200 и выше уже всё линейно растёт, как мне кажется.

Ну и плюс то что Алексей писал о панорамах - весь мазохизм со склейкой и последующей коррекцией просто испаряется если снимать панорамы со сдвигом.

Кому должна?

Я не совсем апонимаю о чем вы.
Есть объективы (типа кэнон 90 TS), где ось тилта не проходит через центр кадра и т.о. после тилта из нейтрального положения центр матрицы больше не смотрит на оптическую ось, и приходится делать коменсирующий шифт. Вы об этом?

2) получается среднеформатка со сканирующим сенсором и ручным приводом :)))
А панорама должна быть цилиндрической.

Вот прямо из тех исходников что есть - не соберется, к гадалке не ходи.

Какое-то ограниченное представление о подвижках. Сдвиг он не только для коррекции вертикалей - например looming делать на широких углах (то что достигается на view камерах наклоном заднего стандарта, а без этого делается одновременным сдвигом и наклоном объектива).

FRV особо не задумывается "зачем он блокирует", std::filestream блокирует при RO-открытии - и прекрасно.

Происходит это, по всей видимости, оттого, что в Win32/CreateFile в sharemode передается 0, отчего там эксклюзивный лок (что-то у меня оно не трейсится туда, но и никаких способов передать SHARE_READ я чего-то не вижу).

Но, как в том преферансном анекдоте, "и так неплохо получается", потому что не дадут, к примеру, файл увести в процессе чтения (а в OS X не дадут другим механизмом - там если файл к примеру стерло, он на самом деле сотрется только после его закрытия всеми процессами)

Но, действительно, конфликт.

Т.е. при установке last opened file - нужно галку в Grid снимать (и запрещать). Но снимать ее на невидимой закладке - неправильно, юзер не увидит.

Вменяемого решения я не вижу пока, поэтому пока забьем.

ну ладно - это более менее терпимая проблема... просто вот первый запуск C1 из свежеотрытого FRV имел разительный временной контраст по сравнению с тем же из xnview или запуском PS/ACR из FRV... т.е. если никаких лишних блокировок frv не делает то и аллах с ним... хотя зачем frv вообще что-то блокирует если он raw ничего не пишет ? во избежание что этот файл находится в процессе записи чем-то (например копируется, итд) ?

Ну у меня вот какая гипотеза таки
- C1 таки вычитывает каталог целиком и щупает там файлы.
- а FRV, прочитав текущий файл, делает префетчи в разные стороны (в зависимости от фазы луны) - и блокирует (RO) не текущий файл, а следующие.

При показе первого файла в FRV - эта последующая вычитка будет большой (по числу ядер CPU при стандартных настройках). При показе последующих (листаем пробелом) - один файл.

Собственно вот.

Проверка
а) или выключить префетч (Number of .. RAW decode threads в Performance), ну полностью не выключится, ну хоть до 1 сократить
б) или поразвлекаться в фолдере со строго одним файлом, там префетча нет т.к. нечего.

> Не зачитывает ли C1 долго каталог, например?

уже зачитала давно - из XnView все тоже самое, на тех же файлах быстро - это скорее всего FRV зачитывая что-то блокирует

Вообще, собственно на момент отрисовки (в режиме single view) - файл разблокирован. Ну там "плюс-минус", потому что как там сообщения между тредами ходят - некоторый (негарантированный) вопрос.