FS7: Compression artifacts: XAVC-I "feature", or my FS7 malfunction?

moldcad

Veteran
Dear Friends,

So - after some 18 months of using my FS7 - unfortunately I must re-investigate the problem I wrote about on this forum at the very beginning of my FS7 ownership. Some of you may remember my complaints about the compression artifacts in large areas of single color, like the blue skies; at that time I was new to many aspects of FS7 technology so I posted my findings under a rather misleading thread title:

http://www.dvxuser.com/V6/showthread.php?346566-nasty-artefact-on-clear-blue-sky-with-FS7-kit-lens

The title suggested that the artifact was related to the kit lens (which it was not); my "diagnosis" then evolved through a number of other suspected factors - and finally, I gave up believing that what proved to be nasty compression macroblocking was only present in my Log footage, and present in UHD@25fps footage more often then 50p...

Well - in the meantime I purchased 2 other cameras (the A7Rii and GH5), as well as the Shogun Inferno recorder; comparing all those different image sensors, codex and encoding formats now make me believe that those really nasty artifacts are present in all sort of FS7 footage I managed to acquire during the period: be it UHD or 4K, only XAVC-I (recorded internally, of course - I never inspected XAVC-L or MPEG though), it may be Log or HG (shot in CineEI or custom mode) and no matter if 25 or 50 fps :(

As my FS7 warranty will expire in several months, I can still simply send the camera off for servicing - but I'd like to avoid it if unnecessary, i.e. if you guys help me establish above any doubt that it's the FS7 codec's "feature" and not any malfunction of the camera. Of course this would only be possible if I uploaded a reasonably short but representative clip for you to judge. So here's a couple of questions:

1. Which software would you recommend to use for trimming my longer clips to get just a 2-4 seconds clip(s) which does not differ from the original at all? I'm afraid that cutting and exporting such a clip in Resolve might introduce some nuances making it difficult to assess - is there a tool capable of cutting XAVC-I UHD mxf files without re-compression?

2. Would any of you guys volunteer to download such a clip and help me answer the above, all-important question whether what I'm seeing (and hating) is actually normal under some circumstances, or it is some sort of malfunction manifesting itself?

I'd really appreciate it very much if someone helped me with the assessment; thank you all in advance

Piotr
 
regarding #1 : catalyst browser should let you trim and export to XAVC again, but no idea if it's slicing properly or re-encoding. Worth a shot. Otherwise I would use Davinci Resolve and export a few frames in the DPX format.
 
Thanks Gentlemen - I will pick the most offending clip and trim it with Browse then. I will upload it to some cloud storage, and provide you with a download link. Hoping you will find some time to download and - with your huge expertise - let me know authoritatively whether you see normal XAVC-I behavior (the same as with your FS7 cameras), or something which is a proof of some malfunction in my FS7 unit. TIA

Piotr
 
OK, so here are 2 short clips:

- https://www.dropbox.com/s/uubmmo4ucs4b2s3/184_0066_1.MXF?dl=0 (S-log3/S-Gamut3.Cine, UHD@50p)
- https://www.dropbox.com/s/h03lwd8px2zvhco/184_0044_1.MXF?dl=0 (HG3, UHD@25p)

Here is the link to tthe DropBox folder containing both clips:

https://www.dropbox.com/sh/kt1ke062mkvih3i/AAAqGUECJhDf0bk-KMo590Bia?dl=0

When I was reviewing my older footage (mainly my oldest test clips, looking for the same scene containing the offending blue sky, crossed by some thin black cables in the foreground), I again noticed that non-log clips do not show the same severity of mackroblocking in the sky as the log footage does. So I'm again tending to not blame the camera, but how the codec (even at 500 Mbps) handles S-Log footage; my theory is that the banding noise inherent to S-log breaks the codec in areas of little detail / single color, where the codec doesn't do its best "expecting" very little work to be done (as opposed to scenes with lots of movement, detail and varying colors - where I never encountered this kind of artifacts; banding is non-existent and noise is at acceptable level).

What do you think? If you find the phenomenon in my S-Log3 clip "normal" and within the spec, it's sad that an $2,000 GH5 -even with the "old" 150 mbps codec - doesn't produce similar artifacting even with V-Log ! Please, share your thoughts;

Piotr

PS. Usually we expect noise in the shadows of S-log footage, and - provided it's exposed properly at some 1-2 stops "over the target" - we can virtually eliminate it by lowering exposure back to the target level while grading. With the noise-originated banding and consequent macroblocking as in the first of my clips, moving levels down doesn't help at all - the only remedy with scenes like this is to either add considerable amount of film grain, or use noise reduction (bye, bye details :() - or both... I'd be very disappointed if the general consensus between those of you guys who would be nice enough to sacrifice some time and effort and inspect my clip(s) turns out to be "yes, this is normal for the FS7's S-log footage in XAVC-I codec"...

PPS. When assessing the S-log clip, if you can't notice the artifacts at once just increase the saturation (look at the blue sky, particularly in the area just above the trees in the far background (between the birch and the barn's roof) and a little higher, just below the black cable.
 
Last edited:
I could be off on this, but when I looked at your clip, the only place I notice "noise" or what you call macroblocking is in some parts of the sky. For me, I noticed it mostly in the upper left corner and the blue channel is clipped, which to me means it is working overtime. I did have to boost the saturation to see the noise.

This is pure speculation on my part, but I would say that perhaps it is a stress on the codec in the blue channel specifically. I say this because that's the only place I see it.

There is a fantastic thread here and I think you posted in it, but they have a fairly lively discussion about exposure and a couple of people mention the potential problems with noise in the blue channel.

Mitch Gross said:
Noise is always seen first in the blue channel, basically because blue is usually getting pumped up in the processing. So the worst thing you can do when shooting in daylight is have the camera set to tungsten balance (pumping up the blues) and then throw an 85A filter on there (pushing them back down again).

And Bass Pig said:
Scenes with lots of high frequency detail will break the high compression CODECs. With XAVC, mixing dense foliage with open patches of deep, blue skies will produce some particularly nasty artifacts.

This is the thread I'm referencing.
http://www.dvxuser.com/V6/showthread.php?351045-Overexposing-on-the-FS7-for-cleaner-shadows/page2

I realize CINE EI only gives you 3 choices, but wonder if the white balance setting was set at 3200 and might have aggravated the noise.

I honestly had to hunt for it and the rest of the image looked okay to me. And as I was pushing the saturation, I was wondering if that's not creating more strain on the codec.

Again I am only speculating here but I am guessing blue is especially susceptible to noise and as others have alluded to, is the first place it shows.

If you had WB set to 3200 k, would that have aggravated it?
 
If you had WB set to 3200 k, would that have aggravated it?

Thanks for your time and answers - but no; the WB was definitely at 5,500K in this clip.

Piotr

PS. Unlike Resolve, Sony's own Catalyst suite (including the free Browse) reads FS7 metadata - hence I can state he above with certainty, even though the clip was recorded more than a year ago (see the grab below). And one more thing: when following the universally now accepted "rule" to rate the FS7 lower than 2000 ISO, one must avoid not just generally clipping the highlights, but - with the presence of large blue areas like the sky - limit the overexposure to protect the Blue channel specifically...

PPS. What size of a screen did you inspect my clip on? If it's just a computer monitor, no wonder you can not see it at its full ugliness - believe me that on my 49" HDR10-grading monitor, hanging on the wall over my desktop at some 1m distance form my eyes, it does look ugly :(
 

Attachments

  • browse.JPG
    browse.JPG
    16.6 KB · Views: 0
Last edited:
Piotr,

I downloaded the S-LOG3 clip and I don't see any problems with it. Maybe I'm missing what you are seeing but it looks fine to me. The sky (which is not white) hits 70 IRE so that means it is over-exposed, even by the standards of those of us who purposely over-expose S-LOG, but it's still within reason and recoverable. Everything else in the metadata looks correct.

I think your problem is either in your monitoring or your workflow in post.

Here's a quick grade I did in Resolve. I progressively of added more saturation to the point of going nuclear. I still don't see blocking problems. You can download the original file through Vimeo if you want.

I hope it helps.

Password: FS7
 
Last edited:
Thanks Doug, but unfortunately on my 49" display I can see the very same artifacts in your clip (I downloaded the "original" from your Vimeo page) as in my footage...

Regarding possibility of doing something wrong in post - well, this is not the sort of artifacts that might be created - even by a person who doesn't know what he/she is doing. Below is a screen grab with my Resolve settings (RCM). This is an HDR10 project, but I can see the glitch in SDR as well.

I have put some stills, grabbed from Resolve, into the same folder on Dropbox. Please enlarge it, if you only have access to some smaller screen. Also, I'm watching the footage on a 10-bit HDR monitor!

Piotr
 

Attachments

  • RCM.JPG
    RCM.JPG
    36.2 KB · Views: 0
Hi good morning everyone,

Piotr thanks for sharing the snip of footage. There are many things going on here that I believe can be contributing to what you are seeing.

First this is a very high detailed scene that contains a lot of small detail like the branches, foliage, flower pedals, grass, including a sky that normally should have a nice gradient to it. This is an easy recipe to break the XAVC codec, especially in 4K as the codec works 4 times harder than HD.

On very close inspection I see very small macro blocking artifacts around some parts of the electric/telephone wires across the scene, as well around most branch tips or areas where there is high level of thin branches in the scene. Most codecs are going to have problems with this and when it does other aspects of the scene may also suffer as the real-time XAVC encoding chip has to make some tradeoffs in order to work. So for example the sky may be easy suspect to blocking or banding.

Here is a very drastic grade to help show others what it is you might be seeing in the sky:

Screen Shot 2017-09-30 at 8.22.12 AM.jpg

But this is a very drastic grade and with a normal grade the blocking will not really be visible:

Screen Shot 2017-09-30 at 8.30.47 AM.jpg

For the macro blocking artifacts there is nothing you can really do about this unfortunately, your FS7 is not broken of defective. If you could perform a test using an external recorder that was capable of uncompressed recording I am almost certain you would not see any of these defects as I once did the same type of test and it was amazing how clean the uncompressed images were compared to the camera's internal codec. Perhaps what you can try is recording the same scene internally in 4K XAVC and also 4K externally via HDMI using a very high quality codec (inferno has ProRes HQ) and see if there are noticeable differences. Only issue with that test is I believe the HDMI output is only 8-bit. Still you can try this test if you like.

The last thing that can be going on is the post software itself. Depending how you de-log the footage and what method or plugin you use, I've seen banding in Adobe Premiere on the same clips that look find in Catalyst or DaVinci Resolve. I suspect it's a bit depth limitation of either the plugin or Adobe, but needless to say you can try your own comparison tests and see if any issues arise more in one software over another. That clip you made is perfect for testing it.
 
Sorry I was mistaken. There is no clipping on the blue channel. Was accidentally looking at the clip I rendered to view on a big screen. FWIW, I have noticed artifacting in blue skies on some footage I've shot in the past. Shooting in CINE EI, Slog3.
 
Thanks again to all of you guys who took your time and effort to help me confirm the problem, and make sure it's not my FS7 unit at fault. At least I do not need to go through all the hassle of sending it for inspection and repair to Sony's Prime Support!

Having said that, we have also established above any reasonable doubts that the otherwise great XAVC codec has its limitations, even in its All-I form and relatively high bitrate of 500 Mbps (in case of my 4K@50p format). Some of you indicate that with a scene like the one I uploaded, "Most codecs are going to have problems with this" as Dennis put it. But unlike over a year ago when I only had one 4K camera (my FS7), I now can get a much broader outlook comparing XAVC-I encoding with several other options, namely:

1. Another flavor of the same codec, but of Long GoP type and pathetic data rate of just 100 Mbps (XAVC-S in my A7Rii)
2. DNxHR and Prores codecs with high data rates, roughly twice as high as XAVC-I (on my Shogun Inferno)
3. CDNG from FS7's 12-bit RAW (also offered by the Inferno)
4. Yet another H.264 codec, available now as Long GoP, 150 Mbps or All-I, 400 Mbps (in my Panasonic GH5)

Comparing all those options - after excluding Number 1 (the A7Rii) as not only is its codec the most intensively compressing, but also 8bit 420 only - I must tell you that by far the best results IQ-wise can I get recording on the Inferno (options 2 and 3). I've always been wondering if - should we get XAVC Class 480 option in some future FS7 fw update - the higher datarate alone could leverage the IQ of XAVC-I to the same territory...

But the most unexpected and positively surprising is the IQ I'm getting from my GH5, even with the Long GoP, 150 Mbps codec; believe me or not - but the very same scene we've been discussing here is absolutely free of any sort of artifacting when recorded internally on the GH5! And I'm using it with V-Log L and always in the 10bit, 4:2:2 color, because that's the minimum required for successful HDR10 (PQ) grading... Thumbs up for Panasonic - but really, shouldn't internal recording IQ from the $10,000 FS7 be at least on par with that from the $2,000 mirrorless camera?!!

Well - as I said earlier, with my 2-camera gigs I can always use my Inferno for getting the best IQ from my FS7 (instead of using it with my B-cam, as originally intended). But if Sony are listening - please oh please, give us the XAVC Class 480 in the next FS7 firmware update :)

Piotr
 
I could be off on this, but when I looked at your clip, the only place I notice "noise" or what you call macroblocking is in some parts of the sky. For me, I noticed it mostly in the upper left corner and the blue channel is clipped, which to me means it is working overtime. I did have to boost the saturation to see the noise.

+1. That is exactly what I am seeing. This I feel is one of the reasons you sky is pushing towards Cyan rather that towards Blue. I tried grading your LOG clip in both Resolve and Vegas 15 on a 32bit floating point timeline while monitoring via Display Port on a true 10-bit grading monitor with the Nvidia card set to 10-bit depth. I had to push very hard to get any blocking or lines to appear. The worst one I saw was a line running between the third branch of hanging leaves right side of the Beech's trunk running across to the first pine tree tip sticking above the left side of the shed/garage roof. Is that one of the issues you are seeing?

At the levels I had to push to to get these artifacts to appear I was not surprised I was beginning to see issues. The levels at which this was happening were totally off the WFM and Vector scope legal levels while grading at DATA levels. SLog3 defaults to DATA levels topping out at 0-109%. Interestingly I tried just a LOG levels grade with no LUT and a number of grades with different levels and LUTs and in a number of cases certain LUTs brought the blocking issues on at earlier levels. All the same the grades that exhibited the issues though were well outside of any Data or Video levels that I would dare to deliver as a final grade.

I think maybe I would be getting the camera checked out by Sony very carefully in any case to make sure the LOG levels being recorded are correct especially with regards to the blue channel as it seems to be biased towards the Cyan vector, easily seen on the V scope when you boost the chroma levels. Overall though I could get a perfectly good grade out of the LOG clip. A grade without artifacts that I would feel quite happy to deliver.

Chris Young
CYV Productions
Sydney
 
Last edited:
Thanks again to all of you guys who took your time and effort to help me confirm the problem, and make sure it's not my FS7 unit at fault. At least I do not need to go through all the hassle of sending it for inspection and repair to Sony's Prime Support!

Having said that, we have also established above any reasonable doubts that the otherwise great XAVC codec has its limitations, even in its All-I form and relatively high bitrate of 500 Mbps (in case of my 4K@50p format). Some of you indicate that with a scene like the one I uploaded, "Most codecs are going to have problems with this" as Dennis put it. But unlike over a year ago when I only had one 4K camera (my FS7), I now can get a much broader outlook comparing XAVC-I encoding with several other options, namely:

1. Another flavor of the same codec, but of Long GoP type and pathetic data rate of just 100 Mbps (XAVC-S in my A7Rii)
2. DNxHR and Prores codecs with high data rates, roughly twice as high as XAVC-I (on my Shogun Inferno)
3. CDNG from FS7's 12-bit RAW (also offered by the Inferno)
4. Yet another H.264 codec, available now as Long GoP, 150 Mbps or All-I, 400 Mbps (in my Panasonic GH5)

Comparing all those options - after excluding Number 1 (the A7Rii) as not only is its codec the most intensively compressing, but also 8bit 420 only - I must tell you that by far the best results IQ-wise can I get recording on the Inferno (options 2 and 3). I've always been wondering if - should we get XAVC Class 480 option in some future FS7 fw update - the higher datarate alone could leverage the IQ of XAVC-I to the same territory...

But the most unexpected and positively surprising is the IQ I'm getting from my GH5, even with the Long GoP, 150 Mbps codec; believe me or not - but the very same scene we've been discussing here is absolutely free of any sort of artifacting when recorded internally on the GH5! And I'm using it with V-Log L and always in the 10bit, 4:2:2 color, because that's the minimum required for successful HDR10 (PQ) grading... Thumbs up for Panasonic - but really, shouldn't internal recording IQ from the $10,000 FS7 be at least on par with that from the $2,000 mirrorless camera?!!

Well - as I said earlier, with my 2-camera gigs I can always use my Inferno for getting the best IQ from my FS7 (instead of using it with my B-cam, as originally intended). But if Sony are listening - please oh please, give us the XAVC Class 480 in the next FS7 firmware update :)

Piotr

Many of us over estimate the quality of XAVC-I but keep in mind because it's intraframe it must create a lot of data for each and every frame. type L or S might seem inferior, but the encoder chips to far less work when the scene is static and not much movement going on, so in fact, it is possible for type L or S to outperform type I.

Hard to believe, but it's therefore not so simple to compare datarates between the various types. This was discussed at some length a few years ago on the Sony community forums between Alister and Doug who were looking at a reported problem similar to yours.. ie. micro artifacts, etc...

In some cases, the type L footage produced sharper and clearer images than type I shooting the same scene.

It is likely why Sony has come out with XAVC480 and also why ProRes files are so much larger than XAVC-I. (In some cases ProRes data rates even exceed Sony RAW... )

[EDIT] For what it's worth read the thread below in entirety - someone there had also posted XAVC and ProRes examples of the same scene, you can easily see "mosquito" noise in the XAVC footage but not the ProRes.

https://community.sony.com/t5/FS7/XAVC-I-Quality/td-p/496131/page/1
 
Chris'es answer has made me worry again, especially that - in HDR, and on a big screen - I'm simply unable to grade a scene like the one in question to look decent in the sky area. Not without adding some grain and/or NR to mask what's going on there :(

My A7Rii is unable to render blue sky properly either, but that's understandable as it's only 8bit so banding with S-Log is a normal thing. I don't use it for video much, but if I do - masking the banding with grain and/or NR is absolutely required. But with FS7 being 10bit, it shouldn't be - not even with Log shooting! Whereas with my copy, in order to get this deep blue sky with a nice gradation to it is only possible in Custom mode and HG curve(s).

So, my Friends - unless one of you shows me a similar sample from his/her FS7 in S-Log3 - I'm going to reluctantly send my unit off for inspection by Sony, just before the warranty is over. Would be extremely glad if I could avoid it, so please try to upload a similar scene with the same phenomenon clearly visible; TIA

Piotr
 
Just send it in. You have nothing to lose really at this point and Sony can perform some diagnostics and/or calibration. At least you will gain some peace of mind.

Let us know how it goes, will be interesting to see if after service it performs the same way.
 
I think maybe I would be getting the camera checked out by Sony very carefully in any case to make sure the LOG levels being recorded are correct especially with regards to the blue channel as it seems to be biased towards the Cyan vector, easily seen on the V scope when you boost the chroma levels.

Hmm... Regarding the sky rendered more Cyan than Blue (which indeed is fully confirmed by the Vectorscope - both in Resolve and Vegas Pro), I suspect this is how it really looked in this scene (specific sunlight). I conclude it from the fact that my GH5 footage shows the exactly same color of the sky in identical lighting conditions, with the same Vectoscope reading. However - in the GH5 footage (also Log, BTW) there is no artifacting at all, even though it is much, much easier to clip highlights with V-Log L (which clips hard w/o recovering possibility) at & above IRE 80.

This is why I'm again suspecting the true nature of the artifact in the XAVC-I codec stems from its tendency for macroblocking in areas where it doesn't see much movement and/or multi-color detail, and economizes on its bandwidth.

Piotr
 
I tried grading your LOG clip in both Resolve and Vegas 15 on a 32bit floating point timeline while monitoring via Display Port on a true 10-bit grading monitor with the Nvidia card set to 10-bit depth.

Unfortunately Chris, you're not getting true 10-bit picture on your monitor in Resolve using nVidia card, even if the card->monitor path is fully 10-bit; you MUST be using some video card like Decklink for that.

I am not sure about Vegas Pro, but the situation was similar up to the release I used before switching to Resolve (13); perhaps it's changed in 14 and/or 15 but I'd use some test image to make sure. The thing is the 10-bit mode of nVidia is only available with DirectX on high-end Geforce cards, and OpenGL on Quadros.

Piotr
 
Piotr,

I went through some footage that was shot in 4K on the FS7 as part of a commercial project I worked on. It is similar to your outdoor scene with lots and lots of detail; house, foliage, sky, plenty of trees, and there is even a car in the shot. With a very extreme grade I can mess up the sky enough to get a few blocks appearing but under normal grading it is not apparent. This is the same I found with your image, under normal grade I don't see any real problem with it.

I found some checker board mosquito noise / macro blocking around some hard contrast edges in the frame and I also found some purple edge fringing on certain hard edges. The fringing is not consistent across the image so I wouldn't attribute it to lens CA but instead the codec breaking down on high contrast edges. This is also another common defect with less robust codecs and where you can sometimes see it break down.

In many ways one could argue that the defects in my image are worse then the ones you had found, but I have to point out that we are conducting some extreme pixel peeping here by examining a frozen frame zoomed in 200% + or more percent. For the final project I had shot, even with the defects I highlighted here, I'd be hard pressed to really notice them and anyone watching the spot isn't going to really notice with a story being told, etc. . I also inter-cut the F55 with FS7 at probably a 50/50 ratio and nothing jumps out on the FS7 shots.

I know that you are not seeing these "defects" with your other camera's so I agree for you it would be VERY bothersome, but for the final use and display of the clips you are shooting with the FS7 do you really think it is going to be noticed? I know this isn't a good solution to your problem, but for some reason if you are really concerned with having defect-free footage then I think you would definitely have to look at recording with a less compressy codec or different camera. MAYBE even consider 12-bit RAW to external recorder for your FS7.. but not sure how much more you want to invest into it.


Original image FS7

Screen_Shot_2017-10-04_at_8.44.53_AM.png



200% zoom crops

Screen_Shot_2017-10-04_at_8.39.00_AM.png


Screen_Shot_2017-10-04_at_8.39.30_AM.png
 
Last edited:
Back
Top