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

Title	Comment
Shift + мышка - выделение произвольного размера	Shift + мышка - выделение произвольного размера
Это место просто густо усыпано граблями. В том порядке, что	Это место просто густо усыпано граблями. В том порядке, что вспомнил: 1) Не учтено то, что спектры фильтров и спектры пикселей на мониторе - разные. Причем спектры фильтров на сенсоре расширяют для повышения чувствительности, что ухудшает качество "разделения цветов" (мысленный пример - черно-белая камера, где разделения нет вовсе). В результате однозначного преобразования из цветов камеры в цвета монитора может и не быть. Вот снимаешь радугу, смотришь, а на ней не все цвета (потому что профиль их завернул не туда). 2)Откуда берутся эти самые профили камер, какое у них качество, должны ли мы иметь один профиль для всех съемочных случаев (с учетом пункта 1) - большой для меня вопрос. Ну, вероятно, снимают какую-то мишень или спектралку, строят ICC-профиль, применяют. 3)Что там творится в цветовом движке, с учетом округлений, выхода за диапазон ("охват у камеры" - шире вилимого диапазона) - не меньший вопрос: http://blog.lexa.ru/2010/01/29/tsvetovaya_govorite_nauka.html 4) Вообще, ICC-стандарты для input profiles есть большая попаболь, они как-то работали со сканерами (где одна и та же лампа), а с камерами, как мне кажется, там все не слишком хорошо. В части ICC - Adobe уже от них фактически отказался, их DCP-профили - больше чем ICC. Но народу тоже не нравится, они их обратно раскручивают (untwisted profiles). 5) На закуску. В тенях оно таки нелинейно: http://blog.lexa.ru/2011/03/24/o_lineinosti_v_tenyakh.html (за счет шумов). А где будет синий канал у темно-красной плашки с колорчекера? Это не говоря о всяких засветках-рассеянии от оптики, которые при съемке мишени тоже будут. 6) А потом некто снимает с ETTR, потому что ему на семинаре так велели. Применяя профиль, построенный по мишени, снятой с нормальной экспозицией. Профиль построенный на пункте 5 будет компенсировать нелинейность (коя была в тенях нормально снятой мишени в слабом канале), но мы то подвинулись из области нелинейности - и нам это перекомпенсируют. 7) Ну и пользователи конверторов, они же не хотят правильного цвета. Они хотят красивого цвета. 8) А, да, еще есть интерполяция, где цветовые компоненты восстанавливаются как-то. Вот так: http://www.libraw.su/articles/bayer-moire.html Эти эффекты больше влияют на шум, но в тенях, где шум виден хорошо, там и на цвет тоже. P.S. Давай я из этого сделаю пост и продолжим там? Оффтопика не будет
Алексей, давно хотел где-нибудь спросить, да всё контекст бы	Алексей, давно хотел где-нибудь спросить, да всё контекст был неподходящий:) Тут тоже немного оффтопик, но всё-таки. Вот у нас сенсор (+АЦП). Сигнал от него, как я понимаю, линейный с высокой точностью. Даже если точность не очень высокая, то откалибровать отклик конкретной модели сенсора не должно составлять труда. Перед сенсором светофильтры. Они тоже линейно сворачивают спектр в скаляры. RGB-пространство тоже линейно, ну гамма там по яркости. Получается, что задача преобразования сигнала от сенсора в RGB линейная с точностью до одной единственной заданной гаммы. Значит, чтобы заставить монитор светиться так же как светился объект перед камерой, достаточно линейно преобразовать сигнал от сенсора. С точки зрения цвета это означает ткнуть пипеткой в нейтральный объект и таким образом найти взаимные коэффициенты для трёх каналов. Ну и гамму потом наложить. Всё, этого должно быть достаточно. Что я упускаю? Потому что если я ничего не упускаю, то совершенно непонятно, почему разные конвертеры по-разному разрешают и передают цвета с разных камер а они таки их передают по-разному.
Это видимая коррекция, это не так противно.	Это видимая коррекция, это не так противно.
Алексей, быть может, Вам будет интересно. Новый LR4 BETA, о	Алексей, быть может, Вам будет интересно. Новый LR4 BETA, открывая нетронутый NEF с D3, автоматом вводит экспокоррекцию -1: Для D200 такого нет.
Я в рантайме использовал	Я в рантайме использовал setProperty. Кода в классе для свойства не было. http://doc.qt.nokia.com/4.7-snapshot/qobject.html#setProperty
Да, некрасивенько. Попробуй ещё iSCSI с глубиной очереди 16-	Да, некрасивенько. Попробуй ещё iSCSI с глубиной очереди 16-32, но не факт что будет лучше.
Виндой неудобно, а Far-ом -	Виндой неудобно, а Far-ом - медленно. Заметно медленнее (и всякие Advanced copy на сети не спасают). Поэтому если немножко - то Far, а если вдруг что-то большое, то винда.
Копировать же виндой ужасно	Копировать же виндой ужасно неудобно! :)))) Дело вкуса, конечно...
Ну 111700 - это килобайты,	Ну 111700 - это килобайты, туда-сюда 2.5%.
У меня реальная жизнь вчера -	У меня реальная жизнь вчера - по показаниям винды - 600+ Mb/sec копирования одного большого файла по самбе. А бенчмарка эта намеряла ~700-780 на запись. А пока самбу не потюнил - файл копировался со скоростью ~400 и бенчмарка показывала столько же. А мелкие файлы - едут медленно (винда скорость не показала, но Qt покопировался несколько минут и я это безобразие прервал, а там всего-то гигов 5 т.е. должно было мухой пролететь). И то же самое показывает бенчмарка. Не, она может врать в деталях, но порядок величины там разумный.
MTU1500, так как у Atheros	MTU1500, так как у Atheros максимум 7Kb, и ладно бы 7Kb, но после нескольких часов работы в таком режиме ему отрывает крышу и он начинает дропать половину фреймов. А какие там мегабайты -- десятичные или нет -- не ясно ;-)
А MTU какое? Оверхед	А MTU какое? Оверхед TCP+Ether - байтов ну допустим 60 или 80, я забыл уже сколько. Это, соответственно, меньше 1% для MTU 9000 и ~4% для MTU 1500. 1Gbit/s - это 125 десятичных мегабайт в секунду, после вычитания оверхеда остается 120. а у тебя ~112000 по 1024 т.е. чуть меньше 115 десятичных мб/с
А что у тебя реальная жизнь?	А что у тебя реальная жизнь? У меня типичная задача, в которой видно скорость -- это копировать туда-сюда файлы. И там получается вдвое медленней (30-45Mb/s). Скорость открытия файлов фотошопом прямо с сети оценить сложно, он и на локальном диске иногда тупит.
Да, это я просто описался --	Да, это я просто описался -- конечно, 111MB/s. Но всё равно это как-то больше чем должно быть на гигабите, нет?
В моей реальной жизни - как	В моей реальной жизни - как видишь по картинкам в посте - оно врет ну процентов на 10-20.
А где у тебя Mb/s? Я вижу там	А где у тебя Mb/s? Я вижу там Kb/s, а мегабайт, соответственно, 111.
Т.е. очень хочется кричать	Т.е. очень хочется кричать ``ура'' b что у меня насыщен гигабит -- но, во-первых, его реально из-за кривости контроллеров на обоих концах (Intel LOM на сервере и вообще Atheros на клиенте) не насыщает даже iperf, а, во-вторых, ГДЕ ЭТА СКОРОСТЬ В РЕАЛЬНОЙ ЖИЗНИ?!
Ну то есть надо понимать, что	Ну то есть надо понимать, что это гигабитаня сеть. И 111848MB/s -- это как-то немножко черезчур, как мне кажется.
Вот в том-то и дело, что	Вот в том-то и дело, что что-то и как-то. Например, там есть галка Direct I/O, но в 7-ой винде так перепахали многоуровневое кеширование файлов, что не факт, что программа 2006 года справилась всё отключить.
Второй запуск в тех же	Второй запуск в тех же условиях: В общем, кажется, этот бенчмарк почти ни о чём на высоких скоростях. А Intel NAS Test toolkit не работает на 64-х битных OS, а I/O Mark или как его там не бывает под FreeBSD и вообще он шибко умный какой-то и я в нём не разобрался.
Бенчмарка кривая, но при этом	Бенчмарка кривая, но при этом популярная. Надо понимать что она делает - она создает файл в 256M (или сколько попросишь) и разной длиной блока по нему елозит. И это отражает что-то. И как-то.
Уже не лежат. Результаты,	Уже не лежат. Результаты, прямо скажем, на столько удивительные, что я им не верю:
Canon 40D Есть небольшая виньетка, в данном случае не критич	Canon 40D Есть небольшая виньетка, в данном случае не критично - замер частичный по центру, там же и выделение. +6 ev выдало на гора 12800 по всем каналам по белому листу при дневном освещении. Кликабельно Стандарный замер с 0 ev поправкой. R500 G1177 B982 Выходит R(-4.68 ev) G (-3.44 ev) B (-3.70 ev) Единственное, не разобрался как делать область выделения больше 66*66. На скриншотах с сайта периметр больше, а на растягивание мышкой рамка не реагирует.
Покопался в download history.	Покопался в download history. Я вчера взял отсюда вот: http://sburke.eu/blog/wp-content/uploads/2011/04/bench32.exe По ссылке отсюда: http://sburke.eu/blog/2011/04/quick-disk-benchmark-for-windows/ Но прямо в эту секунду они лежать изволят.
Ну, я пошёл на сайт и скачал	Ну, я пошёл на сайт и скачал -- дали мне 2.47. Видит только NTFS и даже CD-ROM (Никак не уберу его из системника), на смонтированные X, Y, Z не видит... Не выложишь свою?
Ну да. Блюминг же - свойство матрицы, от ISO не зависит. Я	Ну да. Блюминг же - свойство матрицы, от ISO не зависит. Я всерьез обмерял только 5D2, у него между ISO 100,200 и 400(1e/1ADU) разница по качеству картинки микроскопическая (но есть, наилучшая на 200).
Предложение интересное. Насколько я понимаю, подняв чувствит	Предложение интересное. Насколько я понимаю, подняв чувствительность тем самым можно уменьшить количество света, попавшего на сенсор (грубо говоря, меньше света - меньше блюминг), в то же время компенсировав это аналоговым усилением без вопиющего ухудшения соотношения сигнал/шум?
Если это натуральный блюминг, а не глюки конвертора, то можн	Если это натуральный блюминг, а не глюки конвертора, то можно смело поднять ISO. До, к примеру, того самого 1e/1ADU.
К сожалению, есть ещё блюминг - чисто цифровая бага. Со снег	К сожалению, есть ещё блюминг - чисто цифровая бага. Со снегом трюк прокатит, с текстурироваными поверхностями и оптикой, склонной к хроматическими искажениям, на высококонтрастных сценах дотягивание до правильной экспозиции 2 может привести к необратимым явлениям и нарушению микропластики из-за перетекания заряда, которые в конверторе не устраняются откатом экспозиции в минус.

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

Pages