Свежие комментарии
| Title | Comment |
|---|---|
| Вот о том и речь: в первом приближении без разницы. |
Вот о том и речь: в первом приближении без разницы. |
| Бывает, ложусь в четыре утра, и встаю в четыре дня :) Собст |
Бывает, ложусь в четыре утра, и встаю в четыре дня :) Собстно мне без разницы, я практически не привязан ко времени По мне вообще было бы лучше, чтобы светлове время было этак с 11 до 20, но на это мало кто согласится :) |
| Кажется, я в ЖЖ про это еще не спрашивал. Ты ложишься в 8, |
Кажется, я в ЖЖ про это еще не спрашивал. Ты ложишься в 8, а встаешь в четыре? Не, ну ладно, в девять и в пять? |
| Не, это ты не понял. Кызыл - это +4 к Москве, если не путаю |
Не, это ты не понял. Кызыл - это +4 к Москве, если не путаю. Т.е. +7 к гринвичу зимой и +8 летом. То бишь, открывалась эта библиотека в два по гринвичу. |
| хе-х, я почему-то уверен, что с отменой перевода часов таких |
хе-х, я почему-то уверен, что с отменой перевода часов таких табличек станет только больше |
| Ты не понял. Отменили зимнее время, а не летнее :) |
Ты не понял. Отменили зимнее время, а не летнее :) |
| Я не дизайнер и не GUI-программист, поэтому возможно сейчас |
Я не дизайнер и не GUI-программист, поэтому возможно сейчас что-то неправильное скажу. Что я вижу: когда я просто леплю программу в духе QRadioButton туда, QMenu сюда, QGroupBox туда т.е. пользуюсь стандартными классами и не использую собственных стилей (ибо не умею) - у меня получается добротная такая программа в стиле 10-летней давности. А современные программы - они по ГУЮ какие-то совсем другие. Я не могу этого внятно описать (кроме того, что сейчас все в тулбарах), но они именно что не такие. И вот это вот место - оно и в KDE плохое и в QT не видно, чтобы развивалось. Ну то есть дырка проковыряна (стили), но и только. Заметим в скобках, что мне очень нравится интерфейс 2007-2010 офиса и хочется сходу получать нечто именно в подобном "стиле". |
| ре-двоиточие |
Тоже юзал 7-й друпал. И тоже не стал использовать как основу из-за нехватки модулей. Подождем-с до лета, думаю там уже можно будет формировать сборку. |
| > Но я не могу понять смысла замены чисто плюсов на смесь пл |
> Но я не могу понять смысла замены чисто плюсов на смесь плюсов с яваскриптом. Ну, такая же, как в и случае жабы. Типа - белые люди пишут компоненты на плюсах, а дизайнеры и т.д. и т.п. быстренько клепают UI из всяго етого ;) |
| > KDE - это Linux, а мне винды с маком сильно первее. > Прич |
> KDE - это Linux, а мне винды с маком сильно первее. Дык разница в платформах там - QPaintEngineEx . Весь L&F что доступен на линухе/КДЕ также переезжает на другие платформы. |
| Ну да, боюсь я именно забивания на десктопы. KDE - это Linux |
Ну да, боюсь я именно забивания на десктопы. KDE - это Linux, а мне винды с маком сильно первее. Причем, не то, чтобы забъют, а просто не будут обновлять look-n-feel под новые веяния. Не, я понимаю, что можно самому, но все-таки..... |
| <i>Но с кастомными реакциями вроде в QML всё хорошо</i> В т |
Но с кастомными реакциями вроде в QML всё хорошо В том что касается отображения - ну да, наверное. Но я не могу понять смысла замены чисто плюсов на смесь плюсов с яваскриптом. А чистый яваскрипт у меня никак не получится. |
| > значит и в основном Qt появится такой режим (в 4.7.2?) ХЗ |
> значит и в основном Qt появится такой режим (в 4.7.2?) ХЗ Но с кастомными реакциями вроде в QML всё хорошо - во всяком случае как на Qt Dev Days в прошлом году пели ;) |
| > Но с этим миго - страшно что на десктопы могут забить. По |
> Но с этим миго - страшно что на десктопы могут забить. Почему? |
| Если интел их к себе заберет - я буду рад, на самом деле. Вс |
Если интел их к себе заберет - я буду рад, на самом деле. Всяко лучше, чем просто так болтаться. Но с этим миго - страшно что на десктопы могут забить. |
| С учетом того, что у меня все реакции на кнопки уж больно си |
С учетом того, что у меня все реакции на кнопки уж больно сильно кастомные получаются (свой код, может быть много кода) - я не понимаю как этот QML к моему больному месту прикладывать. С другой стороны, QML же транслируется куда-то впрямую в QT-шные вызовы, значит и в основном Qt появится такой режим (в 4.7.2?) |
| Миго на Qt. Интел заинтересован, так что никуда оно не денет |
Миго на Qt. Интел заинтересован, так что никуда оно не денется. |
| > Но вот чтобы, например, оставить на месте центр В QML-е |
> Но вот чтобы, например, оставить на месте центр В QML-е обещають. Там якорить за центры будет можно. |
| Но я один раз уже высказался |
И что, теперь молчать!? :) |
| Вряд ли. Вернее, я на своём 5dmk2 такого не замечал. 50/1. |
Вряд ли. Вернее, я на своём 5dmk2 такого не замечал. 50/1.4 достаточно стандартный объектив. Виньетка в raw с него есть. |
| Если мы точно знаем тоновые |
Если мы точно знаем тоновые кривые по каждому из каналов, то сумеем их линеаризовать и все станет хорошо. Касаемо же HL recovery, то в заметной доле случаев там цвета почти нет (облака всякие и т.п.) и восстанавливать можно только яркость. Что тоже правильно делать по линеаризованному каналу. |
| Н-ну из одинакового разное даже JPEG местами делает. Хотя ту |
Н-ну из одинакового разное даже JPEG местами делает. Хотя тут и другой случай... |
| Так чудные открытия в любом |
Так чудные открытия в любом случае будут, ведь цвет который восстанавливает highlights recovery в общем случае "не настоящий", а вот деталюшек "загнутый" канал доставит больше. |
| не-не, это важно. Вот грубо |
не-не, это важно. Вот грубо говоря красный уже "должен вылететь", но камера его загнула и он формально ниже максимума и там еще как-то колеблется. Если в этом месте начать делать highlights recovery, то будут чудные открытия. |
| Можно и меньшего шага |
Можно и меньшего шага измерения добиться, только зачем? Если один канал уже вылетел, то происходящее в других уже не так и важно - все равно цвет не вернуть. |
| Да, я видел. Только вот шаг в |
Да, я видел. Только вот шаг в стоп (и даже в треть стопа) - слишком крупный для всего, кроме фиксации самого факта фигни. |
| Я уже показывал тут свои |
Я уже показывал тут свои изыскания |
| Да-да, дырки в гистограммах - это тоже тема. Причем, есть в |
Да-да, дырки в гистограммах - это тоже тема. Причем, есть вот мнение, что у Canon вообще для известных камере линз может быть аппаратная коррекция виньетирования(!). Ссылки не дам, ибо давно читал, но тема такая есть. |
| >соображение о том, что RAW - это необработанный сигнал с се |
>соображение о том, что RAW - это необработанный сигнал с сенсора я, видя такую вот хрень, отметаю с порога. недавно исследовался nikon d7000 и выяснилось, что зачем-то, по непонятным причинам, перед записью в raw каналы домножаются на константы, типа например на 1.126 от этого в канальных гистограммах (синем и красном) - дырки единичной шириной, и их сравнительно много (10-15%): http://forums.dpreview.com/forums/readflat.asp?forum=1034&thread=3759042... попутно там же выяснилось что максимальное "аппаратное" ISO у D7000 -- 950, а дальше - численное умножение. For D3, the factors are 1.130 for red and 1.166 for blue; the D3s uses 1.125 for red and 1.172 for blue. |
| Это может быть сделано двумя способами 1) Домножением на ко |
Это может быть сделано двумя способами Первый способ однозначно нехорош, то же самое можно сделать на компьютере и за счет больших вычислительных ресурсов - лучше (с лучшей линеаризацией, например). Второй способ нехорош только если ББ поставлен неправильно, а вообще - может быть и хорош. Надо только отдавать себе отчет, что поканальные характеристики шумов становятся сильно разными, отчего в постпроцессинге это надо бы правильно учитывать (что, как я понимаю, или вообще никто не делает или мало кто). |
Pages
