Marek <p...@s...com> writes:

> Jak to wygląda z fizycznym przesyłaniem 8+ bitowego obrazu z
> aplikacji. Mam np. zdjęcie zapisane na 16 bitach. Otwieram je w
> aplikacji X. Mam kartę 10cio bitową, mam monitor 10cio bitowy.

Nigdy czegoś takiego nie robiłem. To kwestia sprzętu i przestrzeni
kolorów w komputerze. Normalnie to służy chyba tylko jako LUT +
ustawienie jasności itd. Może też być używane w GLu i podczas
wyświetlania video (przeliczenia z YUV), ale żeby tak po prostu mieć
frame buffer lepszy niż 8-bitowy RGB(A), to nie wiem.

> Jaką
> mam gwarancję, że obraz nie zostanie zredukowany gdzieś po drodze do 8
> bitów?

To byłoby oszustwo, nie? Łatwo sprawdzić, tu bym się nie spodziewał
zasadzki. Gorzej może być z liniowością i wysyceniem na końcach.

>> Zarówno karta jak i wyświetlacz muszą to obsługiwać i musi to być
>> włączone. Można sprawdzić w EDIDzie.
>
> Tzn jak? Bo chyba nie poprzez przechwycenie jakimś analizatorem
> cyfrowym sygnału w kablu HDMI? :-)

Tak też można, to jest sygnał do 100 kHz, dwie linie (SDA i SCL), tam
nie ma GHz, ale mam nadzieję, że są łatwiejsze sposoby.

> Windows / karta graficzna to
> odczytuje i udostępnia?

Odczytuje, na pewno, bo na tej podstawie ustawia tryby graficzne.
Czy udostępnia, to nie wiem.

Np. w jednym z monitorów, których używam, wygląda to tak (w postaci
tekstowej, bo normalnie to jest binarny fragment zapisany w EEPROMie
monitora):

Manufacturer: PHL Model: 81b
Year: 2005 Week: 3
EDID Version: 1.3
Digital Display Input
Max Image Size [cm]: horiz.: 38 vert.: 30
Gamma: 2.20
DPMS capabilities: StandBy Suspend Off
Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
Default color space is primary color space
First detailed timing is preferred mode
redX: 0.640 redY: 0.349 greenX: 0.283 greenY: 0.598
blueX: 0.142 blueY: 0.071 whiteX: 0.313 whiteY: 0.329
Supported established timings:
720x400@70Hz
640x480@60Hz
640x480@67Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
832x624@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
1152x864@75Hz
Manufacturer's mask: 0
Supported standard timings:
#0: hsize: 640 vsize 480 refresh: 75 vid: 20273
#1: hsize: 800 vsize 600 refresh: 75 vid: 20293
#2: hsize: 1024 vsize 768 refresh: 75 vid: 20321
#3: hsize: 1152 vsize 864 refresh: 75 vid: 20337
#4: hsize: 1280 vsize 1024 refresh: 60 vid: 32897
Supported detailed timing:
clock: 108.0 MHz Image Size: 376 x 301 mm
h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0
v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0
Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 82 kHz, PixClock max 145 MHz

To jest oczywiście stary monitor, żadnych 10-bitowych itp. kolorów nie
rozumie. Niektóre monitory mają specjalny util, który pozwala na
modyfikację tych danych (oczywiście w sensownych granicach), tak żeby
podłączone urządzenie było maksymalnie szczęśliwe.

W innym monitorze (laptopowy TN) mam m.in.:
6 bits per channel
Supported color encodings: RGB 4:4:4 YCrCb 4:4:4

Ten, nieco nowszy, ma dodatkowo np.:
CEA extension block
Extension version: 3
51 bytes of CEA data
Video data block
VIC 16
VIC 31
VIC 04 (native)
VIC 19
VIC 05
VIC 20
VIC 03
VIC 02
VIC 18
VIC 32
VIC 33
VIC 34
VIC 21
Audio data block
Vendor-specific data block, OUI 000c03 (HDMI)
Source physical address 2.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 225MHz
Extended tag: Colorimetry data block
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes

Może tam być więcej informacji.
http://en.wikipedia.org/wiki/Extended_display_identi
fication_data
--
Krzysztof Hałasa