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

Title Comment
Быстродействие

Легкое тестирование на быстродействие.(продолжение)
6 threads.
Plextor PX-G256M6e M.2 PCI-Express.
Освободил колесо крысы и крутанул что дурное - Красота.(ни тебе спотыкача, ни тебе медленной работы....)

Вот меня лично эти базы

Вот меня лично эти базы достают. Что ACDSee, что FastStone.
Буду делать это место только если будет необходимо. Пока я необходимости не вижу, примитивный photonic с одного HDD с каталога с 3000+ файлами (jpeg) - показывает все приемлемо по скорости.

Путей как его ускорить видно сходу много (даунсамплить при декодировании, декодировать в много потоков видимую часть, затем пустить в фоне одну нитку декодировать дальше).
Если этого не хватит - будет база, конечно. Sqlite прикрутить - дело ну на день.

FastStone показывает 'grid'

Там если Выставить 200х200 то не так и много.(а хотелось бы и поболее 300х300)

Про дырки не понял.

Неправильно выразился, это излишек в базе, или "дырка" от raw.
Был raw, построилась превьюшка, Удалили raw, другим способом, в базе превьюшка есть. файла нет.
Или переструктурировали каталог. Даже если удалять из FastStone, база превьюшек не трогается.
На этапе просмотра превьюшки только добавляются.
А вот "чистка мусора" отдельная операция.

Но приделать базу, потом, если скорость не будет устраивать - ну реально же несложно.

Наше дело раскачать, чтоб мысли в разные стороны смотрели ;)

FastStone показывает 'grid',

FastStone показывает 'grid', то есть одновременно нужно показать много (десятки)
А для показа strip - нужно показать одновременно - десяток (один). Это совсем другая история, этот десяток можно достаточно быстро прочитать (и декодировать).

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

Но приделать базу, потом, если скорость не будет устраивать - ну реально же несложно. Чуть сложнее будет, если сжимать в нее на лету, но и тут никакого рокет-сайенса нету.

С базой же возникает понятная засада:

Это понятно. Мне нравится(почти) как это реализовано в FastStone Image Viewer.
Логично имя файла с каталогом.
На этапе работы наплевать на дубли и дырки, размеры там мизерные. Хотя врядли дубли, скорее дырки...
Просто потом есть функция Оптимизировать базу которая и подчищает весь мусор. Которую сам пользователь запустит когда хочет.

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

Я вот и говорю "посмотрим".

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

С базой же возникает понятная засада: если ключ в базе - это имя файла (пусть даже с каталогом), то возможны дубли ключей (если камера начала нумерацию файлов с нуля, а путь - сдублировался на карточке памяти). Если ключ - контрольная сумма от файла, то для показа превьюшки нужно считать весь RAW, а не только превьюшку из него.

будет показываться встроенный JPEG

Я не имел ввиду рендерить реальные RAW.
Всё равно будет тратится время на ресайз даже из встроенного JPEG. Будет превьюшка - допустим 300*300 (те. 300 по длинной в каждой ориентации)и каждый раз ресайз. А если проресайзить и загнать в базу, потом уже показывать только имеющиеся превью.

В качестве превьюшек будет

В качестве превьюшек будет показываться встроенный JPEG (за исключением кодаков, где превьюшка - тоже RAW, но мелкого размера). Рендерить десятки(тысяч) raw на лету (с полной распаковкой, основные тормоза в ней) - нет возможности.

Пока необходимости в базе не видно, дальше посмотрим.

Механизм чего?

>>> filmstrip
>>> Будут вам превьюшки (filmstrip) в следующем major update.

Как эти превьюшки будут формироваться, на лету, или формируем в базу, потом из неё показываем...

Механизм чего?

Механизм чего?

>>> filmstrip

А какой механизм планируется? Построение в реальном времени,
или сохранение в промежуточную базу и уже от туда показывать?

Разрешение "в мегапикселях" в

Разрешение "в мегапикселях" в данном примере - растет более чем вдвое (было 16, стало "больше 36").

Что там ограничивает, вообще физические (математические) ограничения, либо же тот способ, которым в камере делается интерполяция - я не могу тебе сказать, аппаратом Super Resolution не владею в степени "свободного оперирования".

Я не говорю, что роста нет :)

Я не говорю, что роста нет :). Просто при сдвиге сенсора мы делаем выборки "большими" пикселями (понятно, что есть микролинзы, обвязка и прочие нюансы). Если взять одну "строку", то получается что мы имеем наложение (перекрытие) пикселей, которое ограничивает рост линейного разрешения. Собственно, оно и растет не в 2 раза, как хотелось бы, а заметно меньше. Т.е. 64Мп мы никак не получаем в реальности.

Уменьшение муара - это уже

Уменьшение муара - это уже рост разрешения, даже при прочих равных.

Если посмотреть на скриншот с компарометра, видно вот что разрешение "не хуже" чем у D810

А с чего должно радикально

А с чего должно радикально расти разрешение при сдвиге сенсора? То, что растет цветное разрешение и уменьшается муар понятно. А для увеличения "линейного" разрешения надо весьма сложной математикой заниматься, да и ограничения там вполне понятные имеются.

Смотри на эпсоновские сканеры со сдвинутыми на 1/2 пикселя линейками - там разрешение росло, но никак не в 2 раза :)

С зарубежными посылками

С зарубежными посылками наложилось, скорее всего, три эффекта
- они (почта) наращивали мощности и, наконец, нарастили. И наводили порядок. И навели (сужу по внутригородским письмам и по тому, как стала районная почта работать)
- при этом количество посылок в последние несколько месяев упало, я думаю, в разы. Потому что фитюлька за 30 баксов - это не 1000 рублей, а 2000 (а в плохую погоду под 3к, с учетом того КАК проводили карточные транзакции все банки в моменты скачков курса)
- а китайцы (aliexpress), судя по новостям, пошли по своей отдельной дорожке, отчего нагрузка еще упала.

Почта конкретно пугает: от

Почта конкретно пугает: от выхода с Внуковской таможни до выхода с Перовской сортировки проходит 5 (пять!) часов всего.

Да, нас периодически про это

Да, нас периодически про это просят. И это есть в планах, хотя вот конкретные формы ЭТОГО непонятны пока.

Написал много всякого и стер. Пусть полежит в планах, пооформляется.

А вот подумалось

несмотря на то, что FRV позиционирует себя как альтернатива необходимости массового рендера превью, у него на самом деле для этих целей все козыри - используя имеющиеся возможности можно легко, быстрее чем остальные и без проблем эти самые превью отрендерить в любом размере и любыми настройками (хоть два рендера сразу +-1ev причем в один файл)

т.е. использовать не для целей отбора в постобработку, а конкретно для задачи "отрендерь мне все и быстро!"

p.s. как дальнейшее развитие, конечно, каталогизация, но это оверхед

Если есть слот M.2 с PCI

Если есть слот M.2 с PCI Express, а не просто с SATA, то да.

Но даже на SATA разница огромная.

SSD очень к месту.

Ну тогда уже на M.2 смотреть ;) .....

Будет filmstrip - будет

Будет filmstrip - будет именно так. Крутите в отдельной дырочке jpeg-и, пожалуйста.

А декодировать RAW частично (ну там с частичным разрешением) - для большинства форматов нельзя.

Дополнение

Остановились, работаем с картинкой, продолжаем работать на кэш, декодим остальные в пару тройку потоков...

Есть маленькое предложение!

А почему нам нужно декодировать в таком количестве потоков?
Стоит прокручивать, хоть по 30 хоть по 50 файлов в секунду но не декодировать их в полное разрешение!
Остановились на каком то кадре, вот тут и стали его декодировать. Крутим дальше, снова не нужно декодировать, остановились, снова декодим картинку.
Просто при старом подходе нам не хватит никогда мощей процессора и дисков. Тут же стоило только остановиться на 1-3 секунды (не эталон по времени, хоть 0.5 секунды) и тут можно...
Что пролистать, пока крутим колёсики, это уже другой вопрос, хоть просто перебор названия файлов, а может внутренний Jpeg превью...

Ну вот могу сказать, что

Ну вот могу сказать, что такому компьютеру (примерно вот как у меня) - SSD очень к месту.
Сначала под систему.
Потом втянетесь.

А в XP этого диалога и нет.

А в XP этого диалога и нет. Это не мой диалог, а системный.
IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI (вот я про это писал: http://blog.lexa.ru/2014/11/16/q_windows_file_associations.html )

И кнопок там тоже нету: я системе предъявляю список расширений, которые умею (на инсталляции, не на рантайме), а диалог оно само.

Поэтому check all, потом uncheck .jpg, OK

SSD

>>> Crucial MX100 256M
Не - мы любители, и весь архив лежит в доступном месте (+бэкап)
Периодически к разным съёмкам возвращаемся, попечатать, походы вспомнить.. ;)
А гонять туда сюда не... - Поэтому SSD пока для меня не актуально.

Хотелки

Сейчас могу посмотреть только Legacy версию на XP.
И ненашёл настройку ассоциации файлов.(дома OpenGL)
Поэтому пишу по памяти(вроде этого нет, хотя могу ошибаться)
В ассоциации файлов хочется кнопку - выбрать Только РАВ файлы.

Если не массив, то мой

Если не массив, то мой однодисковый тест даже в лучших условиях. Т.е. линейное чтение у современных дисков скорее всего быстрее чем у этого WD-раптора, а вот seek - медленнее ну и rotational delay больше.
1-2 threads и куку.

Q&A секцию пора делать и этот вопрос там отразим обязательно.

UPD: Crucial MX100 256M стоит чуть больше 100 баксов. Уж рабочие файлы на нем не страшно держать, если бэкапы есть.

У меня нет и не могу сделать 3-дисковый массив, есть 8-д

У меня не массив.
1. Операционка и темп.
2. каталоги(Ligtroom)
3. исходники

А диски Hitachi Ultrastar 7200rpm 64Mb - довольно быстрые..
Просто теперь поняв принципы кэширования, и подход будет и к тестированию, и к работе чутку другой.
Может в документации, чуть больше уделить этому моменту внимания.

>Закрывать не обязательно. Preferences - File Handling - Run single program instance.
> Тогда окна не размножаются.
А оно открывается мгновенно...

Pages

Subscribe to comments_recent_new