Hi, (This is also a combination reply)
First, thank you for the elaborate reply. I really appreciate this. Second, I don't have the original flower (it's not my picture), so I took another image of which I do have the original to work with. This picture can be found at the following links: Original: http://www.nuonsoft.com/temp/07_orig.jpg Scaled: http://www.nuonsoft.com/temp/07_scaled.jpg Mpeg2enc result: http://www.nuonsoft.com/temp/07_mpeg2enc.png Commercial result: http://www.nuonsoft.com/temp/07_commercial.png The original picture above was taken with a Sony digital video camera. This camera has an option to make photographs at resolution 1360x1020. The camera automatically saves them to a lowly (to avoid graphical artifacts) compressed JPG. Then I scaled that image with Corel Photopaint image rescaler to 720x576 with the anti-aliasing option enabled. Then I used the latest mpeg2enc (1.6.2) and got the result above. The same scaled image was used by the commercial encoder so that non of the encoders had to do any scaling. I also have a Minolta slide scanner and I'm currently in the process of archiving around 7000 slides to DVD. These slides are scanned at a resolution of 4000 dpi using 8 bit per channel resulting in an uncompressed TIFF file of around 55 MB. I've also tried to use such a slide as encoder test and get the same quality issues. Remarks about the above shots: You cleary see that the 07_mpeg2enc.png shot is more blocky than the 07_commercial.png. This is especially noticeable in the lower left corner of the image. You can see block in the marble. You also see blocks in the orange wall in the back. These blocks are not visible in the commercial encoded result. The blocks on there own aren't that much of a problem (I know that mpeg encoding works by dividing the image into blocks), but the blocks show a clear discontinuity between them. > One other thought just hit me - if you can get the > image into PPM > format (which should be a lossless operation) then > y4mscaler (and > other mjpegtools programs) can be used. That would > avoid going thru > JPG which may introduce ringing at edges. Part of my source files are coming from a Sony digital video camera that is also capable of taking pictures at 1360x1020 resolution, but the camera automatically saves them to JPG using a low compression rate to avoid artifacts. My slides are originally uncompressed TIFF files and they exhibit the same kind of artifact when encoded with mpeg2enc, so the problem there isn't related to the JPG artifacting. > I was hoping to get the raw unscaled/processed original > so I could > run an experiment or two and see if the distortion is > coming in during > the conversion to .jpg and scaling. From what I've > seen that is the > case - look at the flower_orig.jpg at a 2x or 4x zoom > in the GIMP, there > is the same ringing on the edges of the flowers and so > on as the > mpeg2enc version shows. See above for unscaled images. The ringing might come from the jpg artifacts which are then enlarged by mpeg2enc. But, see my new tests above, you clearly see that there are blocks in the mpeg2enc result and these blocks are showing some discontinuity between them. I also get this with my uncompressed slides as source material. > Ok. Yeah, using -h wasn't a good idea since that's > conventionally > the way to request help or the usage summary. Are you one of the developers on mjpegtools? If so, perhaps you can add a --version or something to query the version of mpeg2enc. Just a suggestion ;) > >So I downloaded mjpegtools 1.6.2 and compiled it with cygwin > without a problem. > > Super! I was fairly sure that was ok - but after that release > a lot of changes were made. Some of those changes > stood a good chance > of breaking the win32 build. If you can try building > the CVS version > it'd be of interest (apparently none of the developers has much > interest in windows - I know I don't ;)). I will try to compile the latest CVS version when I find some more time and will post my results to this mailinglist. > > Using that mpeg2enc version, changing -h to -H I get almost > the same > > results. Even with a -q 1, the filesize just barely increases. > > The largest file I got was about 61000 bytes or so. Which is > correct - even with a small number (1) of frames the > rate control > of mpeg2enc is better than the other encoder and is > attempting to > keep the bitrate out of the stratosphere. Ok, the rate control might be better but I still get those discontinuities between blocks. Isn't there anything about mpeg2 stills in the mpeg or DVD standards? Perhaps the standards allow for much higher bitrates for stills? > Yes, I took a look at the image and experimented for a > little while. > > One part of the experiment does require, I believe, the > CVS version > of mpeg2enc because a bug was recently fixed. Until a few days > ago the "--no-constraints" option was broken - the > effect of that > breakage was that mpeg2enc would enforce the maximum bitrate for > [EMAIL PROTECTED] (Main Profile @ Main Level), there was no way to give huge > values for -b. > I'll have to checkout that CVS version then ;) > Averages require more than 1 sample to be significant > :) 1 frame isn't enough to compute an average. > > In fact for 1 frame you don't even need mplex. Just > take the size > of the frame, multiply by 25 (frames/sec) and then by 8 > (bits/byte). > > That's all mplex is really doing in this case. Of course ... you are right ;) > Thus it appears that the rate control for the other encoder is > rather wacked ;) What do you mean 'wacked'? Do note that the stills created with the commercial encoder work perfectly on all DVD players I tested them with (including hardware players). Perhaps this is perfectly allowed for mpeg2 DVD stills. I don't know were I could check this if this is mentioned in some standard. > But I wouldn't be surprised > if there were a player somewhere that was allergic to > 170KB frames. So far, I didn't encounter a hardware DVD player not capable of playing my discs with those stills ;) > > When multiplexing (with a silent audio-frame) the > commercial generated .M2V file with mplex I do get the > following warnings: > > ++ WARN: [???] Stream e0: data will arrive too late sent(SCR)=13019 > > ++ required(DTS)=0 > > That's because the VBV (Video Buffer Verifier) size is > too small - > that's the "-b" option to mplex. The VBV size is > correct for up to > ~10Mb/s but if you get a huge spike (as in ~35Mb/s) > then the default > 220KB buffer isn't the right size any more. > > HDTV (which in the US uses a 19.8Mb/s stream) has a VBV > of 488KB for > example. Ah, that makes sence. Didn't know that. > Ok, now on to the results of my testing this afternoon/evening. > > Created the Y4M file with: > > jpeg2yuv -n 1 -f 25 -I p -j flower_orig.jpg > flower_orig.y4m > > Then encoded that with: > ... > > The differences between encoders is, as you'd expect, > much less when > comparable (but wildly high) bitrates are used. Not > identical but > close enough. Did you see any discontinuities between blocks in the mpeg2enc results? > > Apparently my version does not recognize the -R option. > > Where can I download the latest version (preferably for Windows). > Hmmm, if you built 1.6.2 and it does not recognize -R then that > option must have been added after the last release. You'll need to > check out the CVS version in that case. > > -R is needed to make sure the chroma is in bounds but that won't fix > the quality issue that you're seeing. Sorry, my mistake. I was still using an older version of jpeg2yuv :(. I now took the jpeg2yuv of the mjpegtools 1.6.2 and that version does indeed have the -R option, but like you said, this didn't fix the quality issue. PS: Do note that the discontinuities in the blocks are visible when playing the DVD's on the PC and are much less visible when playing the DVD's on a TV set, but I just thought I'd mention this quality issue. Cheers, Marc Gregoire ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
