Проблема не только в качестве мониторов, но и в количестве бит на пиксель.
Сейчас практически везде используется 24-битные форматы (8 бит на канал).
Хранить яркость без компрессии не эффективно, т.к. мы воспринимаем яркость (как и громкость) логарифмически.
Чем ярче точки, тем менее заметна между ними разница.
Соответственно, в идеале наши 8 бит (256 градаций) необходимо распределить неравномерно: темным пикселям — больше разрешения, светлым — меньше.
Давным-давно на помощь пришли CRT мониторы, которые по дикой случайности тоже воспроизводят яркость нелинейно.
Если нормализировать напряжение подаваемое на точку в диапазон 0-1 (V), то её яркость получается пропорциональна V^(1/gamma).
У типичного CRT монитора, gamma=2.2 (оппа! вот откуда ростут ноги у sRGB).
Возможно, у CRT мониторов apple нативная гамма была 1.8. А может 1.8 просто потому что think different :-\
Поэтому если вывести на экран #808080 мы получим яркость не 0.5(mid-grey), а примерно 0.217 (0.287 на apple).
Художники работают с изображениями и корректируют их «на глаз». Сами того не зная, они оптимизируют изображение одновременно для представления в памяти и для отображения на _их конкретном мониторе_!
Но сегодня у LCD мониторов соотношение напряжение/яркость — линейно. Поэтому коррекция происходит искусственно при декодировании пикселя монитором. Обычно используется именно гамма 2.2 для совместимости с CRT.
Операционные системы имеют свои функции _дополнительной_ гамма-коррекции. Ну и многие графические утилиты и драйвера предлогают свои меоды коррекции в добавок. Некоторые драйвера предлогают выбрать гамму независимо для всех трех каналов.
Я подозреваю, это всё чтобы окончательно заморочить голову большинству пользователей: вместо одного места для fuck-up-а (настройки монитора), у нас появилось хрен знает сколько.
Возможно, в будущем мы все будем кодировать наши цвета в HDR форматы (как минимум 16 бит на канал). И у всех будут линейные мониторы.
Тогда мы забудем всё это как страшный сон.
А сейчас, на мой взгляд rule of thumb такой:
— выбрать sRGB во всех приложениях (т.е. чтобы приложения ничего сами не конвертировали);
— Не сохранять никаких профилей в изображениях (sRGB по умолчанию);
— Корректировать яркость/гамму настройками монитора (т.е. в ОДНОМ месте);
— Смотреть на разультат на разных компьютерах. Корректировать гамму изображения _в соответствии с результатами_. В самом-самом конце. Один раз.
PS:
И это всё еще даже без упоминания всевозможных графических алгоритмов. Обычно они работают в гамме 1.
Например, что получится если взять изображение 2x1, один пиксель белый, другой черный и resize его в 1x1?
Думаю, современные latency & bandwidth погубят как идею, так и компанию. Этой технологии время через лет 8-10, когда в большинстве европейских стран и в штатах проапгрейдят броадбэнд инфраструктуру.
Ну как причём? Нативная поддержка операций над целыми числами (в т.ч. bitwise операций) пришла в мейнстрим только с выходом DX10, а точнее Shader Model 4.
Аккаунт привязывается к серийному номеру твоей копии. Разрешается только одно подключение с аккаунта.
А все дополнительные методы защиты только портят игру.
Очень правильно с этим поступает Epic Games (unreal tournament series). Сначала игра привязана к диску, но с первым-вторым патчем эта привязка снимается. Делается это с целью остановить первую волну пиратов, которые бы просто установили игру с дисков товарищей для сингла или LAN игры.
Если человек в любом случае не желает покупать игру, никакой DRM не поможет (по крайней мере пока он существует на програмном, а не аппаратном уровне).
Это сложный вопрос. Сейв как таковой там один (одна галактика). В ней можно создать несколько цивилизаций в разных spiral arm-ах и они не будут мешать друг другу (если, конечно, целенаправленно не лететь «в гости»).
Но нельзя разграничить то, что ты создаешь в редакторах. Все видят (и могут редактировать, удалять и т.д.) всё что есть на локальном компьютере. И публиковаться создания будут тоже все от одного имени.
Но это, в принципе, не такая уж и важная проблема на фоне зверского DRM-а и вялого геймплея.
Coding standard-ы на самом деле есть. В любой серьезной софтверной компании как минимум один (могут быть для разных языков, платформ и даже отдельных проектов).
Стандарт описывает индентацию, case-конвенцию, комментарии, namespace-ы, названия классов, допустимые сторонние библиотеки (stl, boost, etc.), глобальные и статические переменные, и многое другое.
Соблюдение этих стандартов улучшает читабильность кода, уменьшает количество ошибок и ускоряет интеграцию новых членов команды.
Это в "старых" картах у нас всё было во float-ах. А в DX10-совместимых картах есть поддержка целых чилел и операций с ними, включая сдвиги и остальные побитовые.
Теперь, чтобы подобрать пароль нам нужно разделить search space (все возможные комбинации байт) на N частей, найти стартовую точку каждой части и последовательно скопировать байты всех стартовых точек в текстуру.
Следующий шаг - шейдер, который сэмплирует нашу текстуру с комбинациями и находит хэш. Если результат совпал, шейдер возвращает 1, а если нет - 0. Это число пишется в текстуру и копируется в сис. память чтобы CPU мог решить когда закончить алгоритм.
Если пароль не найден, текстура с паролями подается второму шейдеру, который знает о номере итерации и добавляет 1 к нужному байту каждого пароля. Результат подается первому шейдеру.
Вот, собственно, и всё.
Каждый диапазон, фактически, обрабатывается в отдельном "потоке". А этих потоков у нас может быть большое количество. При размере текстуры, скажем, 4096х4096 и длинне пароля в 8 байт, за одну итерацию мы сможем проверить 2 миллиона комбинаций.
При росте длинны пароля мы будем упираться в пропускную способность видео памяти и филл-рейт. Поэтому серьезные пароли (скажем, 256-бит и длиннее) всё-равно прийдется распределять между миллионами машин.
новые карты поддерживают целочисленные текстуры и стандартные целочисленные операции прямо в пикселных шейдерах. Благодаря этому при определенной смекалке gpu можно превратить в отличный дата-кранчер. Главная проблема заключается в data dependency - читать и писать в один и тот-же буфер нельзя.
Применить это к брут-форс атаке очень легко. Если у нас есть хэшированый пароль и известен хэш алгоритм, всё что от нас требуется это имплементация алгоритма в шейдере. Остальное тривиально.
Этот-самый алгоритм, скорее всего, и патентуют. На мой взгляд вполне обосновано, т.к. удовлетворить жесткие ограничения в зависимости данных на GPU может быть довольно сложно.
Сейчас практически везде используется 24-битные форматы (8 бит на канал).
Хранить яркость без компрессии не эффективно, т.к. мы воспринимаем яркость (как и громкость) логарифмически.
Чем ярче точки, тем менее заметна между ними разница.
Соответственно, в идеале наши 8 бит (256 градаций) необходимо распределить неравномерно: темным пикселям — больше разрешения, светлым — меньше.
Давным-давно на помощь пришли CRT мониторы, которые по дикой случайности тоже воспроизводят яркость нелинейно.
Если нормализировать напряжение подаваемое на точку в диапазон 0-1 (V), то её яркость получается пропорциональна V^(1/gamma).
У типичного CRT монитора, gamma=2.2 (оппа! вот откуда ростут ноги у sRGB).
Возможно, у CRT мониторов apple нативная гамма была 1.8. А может 1.8 просто потому что think different :-\
Поэтому если вывести на экран #808080 мы получим яркость не 0.5(mid-grey), а примерно 0.217 (0.287 на apple).
Художники работают с изображениями и корректируют их «на глаз». Сами того не зная, они оптимизируют изображение одновременно для представления в памяти и для отображения на _их конкретном мониторе_!
Но сегодня у LCD мониторов соотношение напряжение/яркость — линейно. Поэтому коррекция происходит искусственно при декодировании пикселя монитором. Обычно используется именно гамма 2.2 для совместимости с CRT.
Операционные системы имеют свои функции _дополнительной_ гамма-коррекции. Ну и многие графические утилиты и драйвера предлогают свои меоды коррекции в добавок. Некоторые драйвера предлогают выбрать гамму независимо для всех трех каналов.
Я подозреваю, это всё чтобы окончательно заморочить голову большинству пользователей: вместо одного места для fuck-up-а (настройки монитора), у нас появилось хрен знает сколько.
Возможно, в будущем мы все будем кодировать наши цвета в HDR форматы (как минимум 16 бит на канал). И у всех будут линейные мониторы.
Тогда мы забудем всё это как страшный сон.
А сейчас, на мой взгляд rule of thumb такой:
— выбрать sRGB во всех приложениях (т.е. чтобы приложения ничего сами не конвертировали);
— Не сохранять никаких профилей в изображениях (sRGB по умолчанию);
— Корректировать яркость/гамму настройками монитора (т.е. в ОДНОМ месте);
— Смотреть на разультат на разных компьютерах. Корректировать гамму изображения _в соответствии с результатами_. В самом-самом конце. Один раз.
PS:
И это всё еще даже без упоминания всевозможных графических алгоритмов. Обычно они работают в гамме 1.
Например, что получится если взять изображение 2x1, один пиксель белый, другой черный и resize его в 1x1?
А все дополнительные методы защиты только портят игру.
Очень правильно с этим поступает Epic Games (unreal tournament series). Сначала игра привязана к диску, но с первым-вторым патчем эта привязка снимается. Делается это с целью остановить первую волну пиратов, которые бы просто установили игру с дисков товарищей для сингла или LAN игры.
Если человек в любом случае не желает покупать игру, никакой DRM не поможет (по крайней мере пока он существует на програмном, а не аппаратном уровне).
Но нельзя разграничить то, что ты создаешь в редакторах. Все видят (и могут редактировать, удалять и т.д.) всё что есть на локальном компьютере. И публиковаться создания будут тоже все от одного имени.
Но это, в принципе, не такая уж и важная проблема на фоне зверского DRM-а и вялого геймплея.
Стандарт описывает индентацию, case-конвенцию, комментарии, namespace-ы, названия классов, допустимые сторонние библиотеки (stl, boost, etc.), глобальные и статические переменные, и многое другое.
Соблюдение этих стандартов улучшает читабильность кода, уменьшает количество ошибок и ускоряет интеграцию новых членов команды.
От программиста который «хотя бы работает» или постоянно не высыпается и кодит с температурой гораздо больше вреда чем пользы.
А если программист большую часть дня страдает непонятно чем, то нужен ли такой программист вобще в компании?
Это в "старых" картах у нас всё было во float-ах. А в DX10-совместимых картах есть поддержка целых чилел и операций с ними, включая сдвиги и остальные побитовые.
Теперь, чтобы подобрать пароль нам нужно разделить search space (все возможные комбинации байт) на N частей, найти стартовую точку каждой части и последовательно скопировать байты всех стартовых точек в текстуру.
Следующий шаг - шейдер, который сэмплирует нашу текстуру с комбинациями и находит хэш. Если результат совпал, шейдер возвращает 1, а если нет - 0. Это число пишется в текстуру и копируется в сис. память чтобы CPU мог решить когда закончить алгоритм.
Если пароль не найден, текстура с паролями подается второму шейдеру, который знает о номере итерации и добавляет 1 к нужному байту каждого пароля. Результат подается первому шейдеру.
Вот, собственно, и всё.
Каждый диапазон, фактически, обрабатывается в отдельном "потоке". А этих потоков у нас может быть большое количество. При размере текстуры, скажем, 4096х4096 и длинне пароля в 8 байт, за одну итерацию мы сможем проверить 2 миллиона комбинаций.
При росте длинны пароля мы будем упираться в пропускную способность видео памяти и филл-рейт. Поэтому серьезные пароли (скажем, 256-бит и длиннее) всё-равно прийдется распределять между миллионами машин.
Применить это к брут-форс атаке очень легко. Если у нас есть хэшированый пароль и известен хэш алгоритм, всё что от нас требуется это имплементация алгоритма в шейдере. Остальное тривиально.
Этот-самый алгоритм, скорее всего, и патентуют. На мой взгляд вполне обосновано, т.к. удовлетворить жесткие ограничения в зависимости данных на GPU может быть довольно сложно.