eric75 a écrit:Tout les lecteurs ont un probleme d'ICP, c'est du à la limitation de la compression mpeg2.
Le chroma bug est un cas particulier d'ICP qui n'est pas systematique.
c'est pourquoi il est specifié ICP 4:2:0= Chroma upsampling Error
L'erreur provient du passage de 4:2:0 sur le dvd à 4:2:2 par surechantillonage.
Source: Dale Adams sur AVS.
Une fois encore, AVS est une bonne source, mais peu fiable sans décodeur (avec ou sans CU error le décodeur ??!)
Une difference mise en évidence dans le lien donné par Bastien entre ICP et CUE est que l'ICP concerne les video (source entrelacée, donc pas les films) et le CUE concerne aussi les films !
et c'est bien toute la difference entre dire que le 868 a le CUE bug (ce qui est faux) au lieu de dire qu'il a le ICP bug (ce qui est vrai): dans un cas (CUE) les FILMS seront mal retranscrits avec des erreur de chroma, dans l'autre cas (ICP) les films seront parfaitement retranscrits, les video non (comme le denon 2900,entre autre, ... )
A suivre ...
PS: a suivre, car je n'ai pas relu le chapitre sur le CUE et l'ICP de HTsecrets depuis longtemps
http://www.hometheaterhifi.com/volume_8 ... -2001.html
où Dale Adams y est cité
edit:
voici la difference entre ICp et CUE, selon HTsecrets:
"
Here's the problem: In 4:2:0 interlaced MPEG frames, the chroma channel is really two separate chroma channels interleaved. One channel is for field one, and the other is for field two. These two chroma fields are extremely low resolution. The chroma channel for a 480 line frame of 4:2:0 has already been cut down to 240 lines of vertical resolution, so a single field only has 120 lines of resolution. In order to convert to 4:2:2 interlaced video, those 120 lines must be upsampled to form two 240-line chroma fields. The upsampling process essentially fills in the missing scan lines of the image, without regard for the samples from the other field. So in the process, detail is left out of each field, and the upsampling process fills it in with what you could call a "best guess." That guess is different for each field, because the two fields have a completely different set of data to work from. Most importantly, the positions of edge contours, especially diagonals, will always be calculated in slightly different locations in each field because the samples are in different locations in each field.
It's this mismatch of edge contours that causes the problem. When the two fields are put back together later by a deinterlacer (or by your eye and brain, if you watch it on an interlaced TV), the relatively smooth gradations and contours of each field are broken up by a slightly different set of gradations and contours from the other field. If the image is moving, this isn't a problem, because you'd never notice that the two fields' chroma channels don't match up. But on static content, something that looks very much like the chroma bug appears on the diagonal edges of bright-colored objects.
It's important to note that this is not the chroma bug. First off, it's not a bug. The decoder is doing exactly what it's supposed to do, unlike the classic chroma bug case where it ignores the progressive_frame flag and upsamples with an incorrect algorithm. Secondly, the results are subtly different from the results of the chroma bug. From the viewer's perspective, though, they look pretty much the same. Let's call this second issue the 4:2:0 interlaced chroma problem (ICP).
All DVD players suffer from this second problem, and all MPEG decoders. On static interlaced scenes, the chroma channel is all messed up. And there's nothing that can be done in the MPEG decoder to solve the problem, because it can't know which parts of the scene are moving and which parts are static.
"
puis des pistes pour tenter d'atténuer les effets de ce pb.
Le point est que ICP n'est pas CUE.
Que le ICP est propre au source entrelacée codée en entrelacée en 4:2:0 ce qui fait descendre la résolution de chroma de 480 lignes à 120 lignes, au lieu de 240 lignes sur les sources film ou vidéo (donc entrelacée) codées en progressif.
et que vouloir désentrelacer 2 1/2 images qui ne font pas partie de la meme image initiale, quand on les a codé en 4:2:0 entrelacée, donne obligatoirement des problemes: l'ICP.
Alors que le CUE peut se rattraper, car l'algorithme de désentralecement n'a pas bien affecter le chroma aux bonnes lignes en ne prennant pas correctement en compte le flag "progressif":
Si le signal initiale est entrelacé et codé en progressif: il faut d'abord désentrelacer l'image puis upsampler de 4:2:0 à 4:2:2 indépendament les deux 1/2 images. Ensuite seulement recombiner les images (si besoin ... )
Si le signal initiale est progressif, codé en progressif: il faut interpoler de 4:2:0 en 4:2:2 sur l'image complete (et ne pas découper l'image). Ensuite seulement désentrelacer l'image en 2 (si besoin ... mais il y a toujours besoin ...)
2 pb bien differents.
De ce que j'ai compris ...
Tcha