>> >Everythings work not too bad except i can notice a luminance difference >> >between frame i had extracted and the rest of the video stream. It is >> >like a white transparent shadow (it s more visible from Quicktime Player >> >though ...) >> ... >> >So i concluded y4mtoppm or ppmtoy4m is the culprit (or both) . I know >> >the subsampling and colorspace operations is lossy so i guess the shadow >> >comes from this loss. ... >> >>Hmm... I have a suggestion for something which could help diagnosing >> the problem. Could you extract one (problematic) frame from your >> original source, and then pass it through "y4mtoppm | ppmtoy4m" to >> get a modified frame, and then mail both the original and modified >> to me (as the plain, raw, short YUV4MPEG2 streams)? ... >> >Thanks for that ! they are included in attachement. (I tried to use >y4mtopnm but it complain about the -f option.) >I made some other tests and it appears that the shadow thing does not >happen (or it might be not visible) when i export from avid to Quicktime >container using DV Codec. The problem seems to occur only when the >Quicktime is with MJPEGA. I would gladly go for DV Codec but the quality >is actually less good than MJPEG ... > >>Even though it is lossy, I wouldn't have expected a noticeable difference >> in one "y4mtoppm | ppmtoy4m" cycle, so it could be a bug. (Or, it could >> be that your original stream/frame has a lot of pixels with Y'<16, which >> are getting clipped -- which would brighten them.)
Hey, Seb, I don't think there is any particular problem with ppmtoy4m/y4mtoppm; testing with colorbars/whatnot shows that the output of a cycle is pretty faithful to an input. One thing though: in the frame you sent me, about 10% of the pixels are clipped in the initial conversion to R'G'B' --- these are Y'CbCr values in the orginal frame which lie outside of the R'G'B' color cube. When they are clipped (projected/forced into the R'G'B' cube), they will generally appear brighter (the Y' of the clipped pixel will be higher than the original Y' value). Perhaps this is what is happening? In other words, this is classic colorspace-conversion lossiness, which is affecting 10% of the pixels in your frame (with an average shift of +10 in G for those pixels...). (I have no good suggestion for fixing this --- maybe passing the entire stream through the Y'CbCr->R'G'B'->Y'CbCr process, so that there will be no visible transition between the frames with 'effects' and those without? Or doing the work in Y'CbCr colorspace [all non-ideal for a few reasons]. Or writing tools which will handle negative R'G'B' values. Or writing a luma-preserving clipping algorithm....) -m ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
