Cartoon Mode

[gizmotech]

Good Day guys,

I realize this topic has been discussed before, however I was hoping to get a current explination of how cartoon mode is working.

Given my lack of familiarity with how the "cartoon mode" works atm, I encoded the same huffy with the same settings to 2 files, one w/ cartoon mode and one w/o.

Now the interesting thing as far as I was concerned was that the first pass in cartoon mode was approx 10MB smaller (233,078KB vs 223,120KB). Now assuming that it was smaller I investigated further to find that the source almost looks like it has had a light smoother applied to it. Resulting in less "random" compression noise in the cartoon mode as compared to the regular 2 pass.

I was wondering if someone explain exactly what cartoon mode is doing, and if this almost "smoothed" effect is going to lead to a siginifigant loss of detail (I'm working with a relatively oversmoothed source atm so detail is semi hard to come by).

Gizmo

[haibane]

When i try to use the cartoon mode, it produced too much temporal artifacts on B-frames compare to the normal encode. May be it has worse motion search or it drop out more information on B-frames.........

[gldblade]

The popup description says that its using special motion estimation, so I don't think it's applying a noise/smoothing filter over the source.

[sysKin]

Cartoon mode is a set for two differnt things, both designed to help with cartoons:

- detect_static_motion is a motion estimation flag. The threshold below which a macroblock is concidered static is tripled, or something like that. It really helps saving many bits with would otherwise be used to code noise on a static picture.
The backgrouds should be at least as solid as with divx3.11 ;) but I personally fear trails left by moving objects on smooth backgrounds (again, like old divx).

- vop_cartoon .. do you remember 'infamous' TOOSMALL_LIMIT? It's about quantization - when a block is motion-compensated well enough (with total error below the limit) it's just not coded at all. XviD doesn't drop any data in normal mode (limit = 1), but drops quite a lot in cartoon mode.
Again, this usually means that noise is ignored. It might also remove some small details, but small details shouldn't really happen in "proper" cartoons. ;)

I would like to hear all your impressions about cartoon mode. You can even try it on normal movies and see what happenes. I expect a "nandub feel" :)

Radek

[gizmotech]

Hmm..

I will have to do some more testing. You're right that in a "cartoon" ala north american style, there shouldn't be fine details in a background, however on animes where there was a high production value there can often be VERY detailed backgrounds, or granular backgrounds which won't have the correct textures anymore.

How small would this block be, that isn't recorded, in pixels usually? 2x2,1x1?

At any rate, as I said I'll have to do some more testing. It certainly has some very interesting effects on one of my more recent encodes.

Gizmo.

[iwod]

so this is infact a real cartoon mode...... And not for anime.....

However it is still interesting to see how cartoon mode works with anime.

[Leak]

Originally posted by iwod
so this is infact a real cartoon mode...... And not for anime.....

However it is still interesting to see how cartoon mode works with anime.

Well, I encoded the 3rd episode of the R1 Witch Hunter Robin DVD using quantizer 2 (2 pass first pass, but all episodes but one from the first DVD come out undersized at 640x480 with minimal filtering), once using cartoon mode and once without it and other than the file being smaller (by 1.5MB for ~25 minutes) with cartoon mode I haven't noticed any missing details, at least when I compared the first 4 or 5 minutes.

There's this scene at the beginning with lots and lots of computergenerated small and swarming insects - which probably amount for a lot of (high-contrast) detail - where I couldn't make out much of a difference looking at the side by side.

Also, since I'm not exactly glued to the screen while watching my encodes I don't really mind if a bit of very fine detail gets lost as long as the overall picture stays crisp and visually pleasing, but maybe that's just me... :)

np: Autechre - Bronchusevenmx24 (Garbage EP)

[WyldeF1r3]

excellent work with the new xvid I'm going to enjoy it and exploring what it's capable of. I'll give more useful feedback after I've had a chance to use it a bit more, still running some tests now, but I'd like to express my thanks to everyone for their time and hardwork on this ongoing project.

[haibane]

Here is some screen shots of the artifacts I'm talking about.......
the good ones are w/o cartoon mode........

http://www-personal.umich.edu/~liusu/bug/good.jpg
http://www-personal.umich.edu/~liusu/bug/cartoon.jpg
on the cartoon.jpg you can clearly see a black dot on top of the line in the middle, which is not suppose to be there. It might be a block carried up from the line below.



http://www-personal.umich.edu/~liusu/bug/good.png
http://www-personal.umich.edu/~liusu/bug/cartoon.png
here is more pictures, on the cartoon.png, there are some black dots above the black lines, which is no present in the encode w/o cartoon mode checked.

I've notice this for a few months, I don't know is this a bug or it is a trade off for samller filesize.

[Bulletproof]

Actually I think that is a "normal" thing. I used to get the same exact problem with DivX 3.11. Sometimes in DivX 3.11 I would also get "inverted blocks". Though it is still a bug. I think syskin said that it would probably exhibit problems that DivX 3.11 did if you use that mode.

[sysKin]

Originally posted by Bulletproof
Actually I think that is a "normal" thing. I used to get the same exact problem with DivX 3.11. Sometimes in DivX 3.11 I would also get "inverted blocks". Though it is still a bug. I think syskin said that it would probably exhibit problems that DivX 3.11 did if you use that mode. Yes, this is what I was talking about. Imagine you have a moving object. At one frame, the object leaves one macroblock with only little bit of it still in this macroblock. On next frame, it still moves - but this particular macroblock is *almost* good, looks as if it can be skipped... and it gets skipped unfortunately.
The fix would be to not only check for total error, but also for maximum error of each pixel... but it's not there. I'm thinking of similar stuff for after-1.0 development.

Radek

[gizmotech]

I dunno about you but I'll take a small random block like that w/ the impressive overall noise reduction, over the alternative for the moment.

I would hope there could be some developments to analyze the situation more thorouhgly when using cartoon mode, but for the moment I find the current solution acceptable.

Gizmo.

[K-Dash]

I must say that I'm quite impressed for what the xvid team has done so far since dev3, thanks.