Есть серый растр, 16 бит. Можно ли его отобразить средствами GDI как есть? 

в смысле, вывести битмап, каждый пиксел которого хранит только одну компоненту?

Earnest, нельзя, если в текущем режиме глубина 1 канала 8разрядов, то 16никак не нарисовать
и я вообще не уверен что существуют режимы экрана с 16-разрядными каналами, и что существуют мониторы которые смогут отобразить 48-разрядный цвет

однако, можно увеличить разрешение изображения, и использовать дизеринг
(http://en.wikipedia.org/wiki/Dither#Digital_photography_and_image_processing)

а число битов-то я и не заметил )

можно в принципе помучить GradientFill, но все равно придется готовить растр,
проще масштабировать обратно в 8 бит

По описанию диб-секций и прочей лабуды в MSDN получается, что 16-битный растр можно выводить только цветным (по 5 бит или масками задавать), а серый никак. Потому и спрашиваю, что ничего не нашла. 
Ну ладно, в принципе сколько уровней серости отобразить, не сильно важно, все равно никто не различит 64000 оттенков, и 256-то дай бог.
Но тогда проблема в другом: как быстро отображать. Понятно, что можно преобразовать в 8-битный. Но не хочется (нельзя) терять информацию. Т.е. обрабатывать нужно все-таки 16 бит, а для вывода нужно 8. 
Очевидный выход - завести еще один растр, для просмотра. Но жаба душит. Растры немаленькие (космо-снимки). А на лету (при отображении) делать то же самое - боюсь, притормаживать вывод будет. Тем более, что нужно не просто отшибать младший байт, но и, возможно, делать какую-то обработку, чтобы полностью использовать диапазон 8 бит, типа гамма-коррекции или растягивания гистограммы.
Собственно, это стандартный прием систем, которые снимки показывают\обрабатывают. 
Но как это делается, что-то не могу найти \ понять.
Например, ArcView это умеет. И делает быстро (реагирует на переключение режима просмотра). Что при ее общей неповоротливости работы с растрами настораживает. А ведь надо пройтись по каждому пикселу немаленького растра.
Может, кто-то знает? Или есть какие-то идеи?
Фотошоп, например, как 16-битную серость рисует? Ну он-то точно памяти отжирает раза в 3 больше для каждого растра, но нем не менее...

  OpenGL умеет работать с такими растрами, но в любом случае он преобразует все в свой внутренний формат. Кое что по преобразованиям есть тут http://www.progz.ru/forum/index.php?showto...&pid=187140 . Сам вопрос я не изучал, но в аргументах функций встречается формат GL_RGB16, GL_LUMINANCE16 и т.д.

Добавлено через 7 минут и 16 секунд
C GDI можно максимум сделать так, оформить маски для RGB как 0xFFFF, 0x0000, 0x0000 и нарисовать все красным цветом вместо серого.

при преобразовании 16 бит в 8 информация потеряется по определению.
если хочется сохранить малые уровни сигнала - то можно использовать логарифмическое сжатие.
логарифм быстрее всего считать таблицей.
времени это займет наверное всего лишь раза в полтора-два больше чем простое копирование

Для быстрого преобразования 16->8 скорее всего применяется SSE. Там вроде есть такие команды группового преобразования (на 64х битах будет по 4 пиксела зараз)

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

Это очевидно, но потери допустимы только при отображении, а внутри, стало быть, придется хранить 2 растра... задавив жабу.

xvr, а при этом можно всякие хитрые преобразования делать (в смысле можешь ссылку дать на описание)? 
Скорее уж проще один раз таблицу нарисовать, 64К это ерунда по сравнению с остальным.

А самый простой вариант: отобразить значения в интервал 0..1 потом умножить на 255 не пойдёт? 

И картинка из 16ти битной превратиться в 32х битную  .

Добавлено через 16 секунд
Экономия на лицо

W4FhLF, это называется отбросить младшие 8 бит

переводим в 0..1
x1 = (x / 2^16) 
домножаем на 256
x2 = x1 * 256 = x / 2^8
округляем
x3 = round(x / 2^8) = x shr 8

Это сообщение отредактировал(а) GoldFinch - 7.4.2010, 12:15

не, простое масштабирование - это без операций с плавающей точкой, т.е. ( gray_x16 * 0xff) / 0xffff или просто:

но я склоняюсь к мнению xvr, т.е. логичнее использовать доступные расширения

сразу видно математиков ;)

Добавлено через 1 минуту и 12 секунд
GremlinProg, в чем сакральный смысл умножать на 2^8-1 и делить на 2^16-1  ?

Добавлено через 6 минут и 5 секунд
Earnest, в конечном счете, задача сводится к преобразованию некоторой функцией, которую можно задать в табличном виде
если цель - визуализация, подберите такую функцию, для которой на ваш взгляд (или взгляд пользователя) картинка будет нарисована лучше всего.
гамма -значит гамма, логарифм - значит логарифм

или, еще раз повторюсь, если увеличить размер пиксела (и изображения) в 2^n раз, можно отобразить на экране на все 16бит

Alexeis, так это промежуточная операция.