Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!usenet.pasdenom.info!from-devjntp
Message-ID: <bPyB10e92kCNX0hRmaa2SCqHG7E@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: Photographie 3D
References: <qiuJTGo_6Z5swKu4EOqij5RuVUs@jntp> <610aaa01$0$12687$426a74cc@news.free.fr> <bnrUvWl4CxwD0bGtx7Olpia4FQo@jntp>
 <610b73a1$0$23939$426a74cc@news.free.fr> <hPmZ2rQSgqW05YiKCSLjVCAniiQ@jntp> <61176e5f$0$21600$426a74cc@news.free.fr>
 <MeBs-ldkkDsxnGmqwEcq--70B1U@jntp> <6117971c$0$6473$426a74cc@news.free.fr> <1D0BgLgL9QM1lSF1VFS2eUotHAQ@jntp>
Newsgroups: fr.sci.divers
JNTP-HashClient: chGJHkk-tgGn8DNrZ8leNZH055Y
JNTP-ThreadID: 6vc_3AhC6FOnUcxggQZx4ajzo1w
JNTP-ReferenceUserID: 1@news2.nemoweb.net
JNTP-Uri: http://news2.nemoweb.net/?DataID=bPyB10e92kCNX0hRmaa2SCqHG7E@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Tue, 17 Aug 21 12:47:32 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Injection-Info: news2.nemoweb.net; posting-host="e246572f689810fcc28c9472f2c6ec1b62db7f04"; logging-data="2021-08-17T12:47:32Z/5953046"; posting-account="44@news2.nemoweb.net"; mail-complaints-to="newsmaster@news2.nemoweb.net"
JNTP-ProtocolVersion: 0.21.1
JNTP-Server: PhpNemoServer/0.94.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-JNTP-JsonNewsGateway: 0.96
From: pehache <pehache.7@gmail.com>
Bytes: 4272
Lines: 41

Le 17/08/2021 à 11:49, Julien Arlandis a écrit :
> Le 14/08/2021 à 12:12, robby a écrit :
> 
>>> Mais ça c'est un problème du capteur lors de la prise de vue, ce n'est 
>>> pas le nombre de bits par couche qui va régler ce problème, c'est 
>>> surtout l'étendue de la plage dynamique des capteurs qu'il faudrait 
>>> améliorer.
>> c'est la meme chose !
>> certes l'appareil peut essayer de mieux regler l'exposition au min/max 
>> de la photo, reste que souvent dans la meme photo tu peux avoir du 
>> normal + tres sombre, ou normal + tres lumineux, ou les deux. Si tu 
>> reparti tes 8 bits par channel sur 4 magnitudes de luminance en pratique 
>> les quantum seront enormes. Il te faut + de bits !  la solution HDR du 
>> pauvre actuelle etant de faire un bracketing rapide à 3 expositions ( 
>> façon de donner plus de bits, au risque du bouger ).
>> A defaut de capteurs 24 bits par channel, un truc malin serait peut etre 
>> d'avoir 2 optiques a exposition differente, l'une basse resolution 
>> servant  à moduler l'exposition des pixels de l'autre.
> 
> Je vois mieux le problème, si on reste sur des capteurs 8 bits par couche, on 
> ne peut plus réhausser numériquement la luminosité dans les zones sombres sans 
> obtenir un gradient en marches d'escalier. Le problème pourrait être contourné 
> comme tu le dis avec des capteurs 24 bits par couche qui permettraient de rescaler 
> numériquement la luminosité avec des marches 2^16 fois moins grandes qu'en 8 
> bits, et on pourrait même reconvertir l'image en 8 bits par couche pour rester 
> compatible avec les écrans actuels. Autre solution avec des capteurs 8 bits, on 
> pourrait enregistrer pour chaque capteur leur réponse U(t) pendant la durée 
> d'exposition, on pourrait ainsi sélectionner localement la bonne luminosité.


Même les capteurs les plus basiques quantifient en 10 bits par couches, 
la plupart le font en 12 bits, et les meilleurs en 14 bits (ouvrir un 
fichier RAW et vérifier ses caractéristiques; en fait quantifier en 
plein de bits par couche est facile, mais ça ne sert à pas grand-chose 
si le rapport S/N est pourri parce que les photosites sont trop petits). 

Ceci dit entre la luminosité enregistrée brute dans un fichier RAW et la 
luminosité codée dans un fichier image courant (JPG, PNG, TIFF,...) il y 
a une loi de gamma appliquée, qui est justifiée par la sensibilité de 
l'oeil : un gris dit "50%" correspond à une luminosité brute de 18% par 
rapport au blanc. Et en fait une résolution 8 bits sur le fichier image 
suffit à exploiter les 12 bits d'un fichier RAW.