paulinventome

That's a good call. I would guess that part of the ACES DNG IDT is desaturating the shadows. Because i know the actual colour values in the source DNG from the data before any debayering are that colour. Of course i will now have to doubly check AGAIN!! cheers Paul

Your 640ISO doesn't flicker. That's correct right? I need to redo mine to double check that 320 was doing it all the time but 400 was the trigger factor on my camera. I think there are ways you can get around purple/green and most of them, like BMD Film, involve crushing the shadows and possibly desaturating them, so they're not so obvious. @Lars Steenhoff suggested incorrect black levels but it's not that. I suspect ACES is crushing a bit and an IR Cut filter may leech some colour out overall, you could desaturate the shadows in Resolve. The blotchiness is a factor of 10 bit shadows, each one of those blotches is a single shadow value. In most codecs and compressed formats you would never see this because noise is breaking it all up! But uncompressed shows you what's really there and of course you can add noise to break up the blotches should you want too. I don't want to keep repeating because i will sound like a broken record but if you take a 12 bit file and a 10 bit file that has the same grey point then what you will see in terms of actual finite values are: Stop 0 : 1 value Sopt 1 : 2 values Stop 2 : 4 values Stop 3 : 8 values Stop 4 : 16 values Okay, if 10 bit and 12 bit have the same 18% exposure brightness level (they do, in the DNG) what the 12 bit is giving you are 2 more stops of shadows. So a value in 10 bit which is at stop 2 is 4 values but that same stop in 12 is 16 values. This is why, when you compare 10 bit to 12 bit (look at my lens images) the shadows in the 12 bit are not blotchy, but a lot more tonality. Now if i pushed 12 bit a further two stops then i would see similar blotchiness but the colours are more accurate (not green/magenta) I hope that makes sense to anyone still wrapping their head around things.... cheers Paul

Yes, ACES works well once set up correctly. I just use IPP2 because i'm mostly Red based and find it nice than ACES. cheers Paul

My point is that the very lowest shadows going green/magenta shouldn't really be happening. If we assume that the sensor is in 12 bit mode and the sensor data that the camera is getting is the same as we see with a 12 bit cDNG then we can assume that these 10bit shadows are a software bug because 12bit cDNG looks perfect. That's really my point. And i think if you have a night scene and you are on the bleeding edge of exposure and can't shoot 24p then you are going to hit this problem just trying to expose normally. Now if sigma are unable to output 12bit at 25p then the solution that works for everyone is to do 10bit but to use a curve to redistribute values so that the last stop of recorded light does not take 2048 integer values to describe it and then use the saved values to ensure the shadows get every last drop of sensor data they can. Then we'd have 12 bit quality in a 10 bit container at all these frame rates and EVERYONE is happy. There is literally no downside to doing this. This is what 8 bit is doing and that can produce great images in a fraction of the space. The code is already in the camera! If you see earlier on in this thread i even show what that curve looks like because each DNG file has a copy of it in 8bit so Resolve can debayer properly. It's standard practice in cDNG. We need a wave of people to say this to sigma because sometimes i think it's only me.... cheers Paul

Yup. Good. Now shoot the same scene in 12 bit and compare. Then be amazed at what the camera *can* do in the shadows... This is why i want sigma to do a curve so they can squeeze 12 into 10 so we can shoot 12bit at 25p... cheers Paul

I run Davinci Colour Managed all set to 709 2.4 gamma In the DNG Settings it's Clip based on CinemaDNG. The Color Space and Gamma are greyed out in Davinci Colour Managed because it will do the 'right' thing. This is the 'native' image or as native as it can be. I see the same in RAW Digger for anaylsis of DNGs so i know it's an honest view. There is a little more shadow latitude this way but not enough to make anything of it. I run Davinci Colour Managed as part of a bigger workflow and pipeline so whatever i do is under that umbrella. And that umbrella also allows me to use IPP2 mapping which i think produces a lovely highlight roll off with DNG footage as well. Screenshots show BMD Film against the above. You can see a bit more detail in the above compared to BMD Film which has a lower exposure. IMHO BMD Film does seem wrong to me. The whole point of Resolve is that you're working in linear light space (photographic) and the purpose of that RAW tab is to move the camera data into linear data. If you choose BMD Film and it changes the curve (or rather it thinks the data coming from the camera has a specific tonality) then the camera isn't really being translated into linear. If you use the camera by itself and you're eyeballing then it doesn't really matter. But if you're using other cameras and need shots to match then it would be very difficult through BMD Film. Shot matching really needs all the cameras to be decoding in a single linear space so that exposure adjustments happen in the same way. And if you are doing any comping or vfx work then you *really* need to know that your data is linear. But i know i'm looking at it from my perspective, so it's really just a IMHO - if you like the look then go for it cheers Paul

We don't know if this sensor is dual gain but it could be. I'd assumed that in the UI you see exposure changing (there's a setting for it to in terms of how fast) and i think there is a persistent bug somewhere in that firmware. In one of my 320 tests i saw not a flicker but a pulse of exposure change. So i think it's something linked to electronic exposure in the firmware. The screen flicker happened with the original firmware but i still saw it in low light. I don't record MOV so can't confirm that. With MOV you're loosing so much of what this camera can do that IMHO i think it's crazy to do that. And SSD is cheap, and you can use SlimRAW to compress the DNGs as you copy them off the SSD. But you're most likely right about base iso and compensation, just haven't quite figured out why. +1 for ISO Wheel in cine mode! cheers Paul

Got them, thanks Can confirm all of that but you do have green shadows at the very bottom. The scene still has quite a bit of light even at 125 ISO but i can see from the enclosed screenshot where you have a green/magenta at very lower shadow step. You can see it on the left edge in the shadow under the object and also on the darker reflective horn thingy. In 10 bit if you shoot with something that is genuinely black in the scene and then shoot the same scene in 12 bit you can sometimes see by eye but if you raise the whole thing you can see very clearly (like my lenses one which was very very little light and high contrast). This shows the major difference between 12bit and the other modes - the shadow detail. Now you've been using BlackMagic Film and actually that is reducing it a little which is perhaps why you're not seeing it. I'm not using BMDFilm but using the matrixes in the DNG via the normal DNG setting. I don't believe you get the best out of the camera with that setting but i suppose i need to look it that in greater detail. Maybe it does make sense. BMD Film seems to drop the exposure and take some of that tint off but BMD Film is expecting the colorimetry from a BMD camera, not a Sony sensor. cheers Paul I wouldn't touch MOV with a bargepole. There are many better cameras which shoot MOV out there - this beauty is all about the RAW and no compression. cheers Paul

Great, although it is 400 that flickers for me!! Look forward to taking a look at those shadows. cheers Paul

There's clip and there's specular clip. The camera really has around 11.5 stops so you need to be mindful of that. The highlight recovery depends on what you're shooting. Skies recover well, people not so much. Recovery is based on one channel *not* clipping where the others have. If you grade under a decent roll-off curve like IPP2 or an ACES ODT then what happens is you get much nicer colour handling as you head up to clip whereas the default process (in Resolve anyway) starts going a bit wonky with odd cyan clipping and salmon highlights. The shadows are good if you are doing 12 bit. Not so much in 10 or 8. And as described above the very nature of linear means that the bottom 3 stops are always represented with just 7 values. cheers Paul

Just a default +3 on DNG exposure so that i can see the shadows. I really don't think you need anything like that with RAW files. If you are recording 8 bit DNG then expose naturally, both the shadows and highlights have less data to give to the mids. If you are exposing 10 or 12 (especially 10) then expose as far right whilst not clipping what you need. The shadows have a lot less detail in them so it's better to shoot over and then take it down in post. You get an extra stop or two if you do highlight reconstruction, which is plenty for spec hits (try to avoid clipping faces though) If you are using with Red footage (username...) Set Resolve up to use IPP2 and a red workflow. Then when you add a DNG, do some exposure/ G/M adjustment and highlight options and you'll find that the linear data matches red fairly well and you get the nice roll off in IPP2 which is much better than normal DNG handling. If you are trying to match EpicW and the camera then the ISO is 4 times higher on the sigma. The fp is at least 2 stops less than the red. You can get lovely images from the sigma. cheers Paul

I'm hoping for consistency! Exposure issue on first frames seems the same as me. So can anyone else confirm that it is just this range? But the flicker is different and that's infuriating! What else might affect the flicker that we're not taking into account. @Chris Whitten so you not seeing any flicker is important too - unless we find a reason why. On the green issue would it be possible to upload a single DNG from something done at low ISO, like 100, in 10 bit so i can compare? @Lars Steenhoff It's not black level, i can adjust that but that affects higher tones as well and also 12 bit is fine. cheers Paul

I've cycled through all my settings, on 8, 10 and 12 bit. 180 degree shutter. My findings are consistent across bit depths, so that's something solid. I flicked at 400ISO and i think 320 but it might just be an odd flicker at the start. The flash frames seem to be an ISO setting incorrect. Flash frames happen for me 125, 160, 200 and 250 but seems solid after that. What i was talking about was whether everyone sees a skew towards green in 8 and 10 bit modes at the bottom end? I have reported this and mentioned on this thread. This is a side effect of reduced shadow bit depth you can see clearly below. But i still think it's a bug because there's no need for it to be green. Shoot at a low ISO and push the exposure up 3 in Resolve, it's very clear then (as below), these are ISO 160 So firstly if we're going to report this 1) Are we all happy that the depth setting doesn't change things? 2) Can we confirm what our own flicker ISOs are (and include shutter speed and frame rate)

I'm happy to do this as i've been emailing for quite a while now but also once we have them collated then we should reach out on twitter as well? I will probably get a chance tomorrow to do all the tests. Too busy fixing up bikes for a quick escape to the countryside for some fresh air! Out of curiosity for those doing very low light 10 bit tests are you very bottom shadow stops quite green? I want to know if this is universal or whether it's just me. It's only 10 bit this happens to. cheers Paul

I haven't had a chance to do more tests but ISO200 saw the first frame brighter. And it was 320 ISO at 10 bit for me, none of the others. But consistency is a question - is it *always* the same ISOs? So i think if we can all test then we need to post our results here and list ISO/BitDepth/ShutterSpeed and whether the first frame was overexposed or whether it flickered. I should get a chance tomorrow i hope cheers Paul

I had mentioned this before to them but i didn't have any data at that point. I will do some tests this weekend. I think collectively we may be able to hammer it down a bit better. I don't like it when things *randomly* differe, it usually means we just don't know the pattern yet. One thing is to see whether the flickering at different ISOs is uniform across 8,10 and 12 - because i would guess that if there is a bug then it is in that process - from the sensor to DNG. Also important to see if this is affecting all of us... cheers Paul

So i've managed to find a similar thing on mine at 320 ISO in 10 bit. It's a bit different it's like the bottom few values appear then disappear. It's pretty imperceptible. So if others fancy playing this game - Shoot a dark area - I'm doing 10bit 25p, now 10 bit has bad shadows but good highlights - Cycle through the ISO - Put them in Resolve and use the exposure on the RAW to bump up 2 or 3 stops - Watch the histogram scope. Do you see a random on/off flicker of data in the shadow end? So more work needed, but i suspect all the cameras are doing it to a lesser or greater degree... cheers Paul

That could be compression though... What shutter speeds are you using and how do you specify them, in degrees? cheers Paul

I suspect that a purchase now probably doesn't include such niceties.. Good call though, the site looks great. I will try to knock something up and give it a go. Another angle is finding an optical element (or two) that makes for a much more compact VF. cheers Paul

Oh that's awesome. I didn't know that. The small rig cage has a hotshot on it so i was thinking of something that could slide in and fix in there. Needs thinking about. I would need to use a service for 3D Printing here in the UK, there's no point in buying a printer really. I use Houdini and Modo for 3D, what are the normal formats these places accept - can you or anyone recommend any? Cheers Paul

I was interested whether the exposure changes across the whole image. When it's in Resolve and debayered then there is a gamma curve so it makes it more difficult to see if at source it is an overall data shift. If there were some chips that could be averaged in a frame and then compared to an average in the next frame it might be possible to tell if the values are shifting uniformly. You see, in the shadow a shift of 6 units in the red (which is what was happening) would be impossible to tell in the upper regions because a sensor is linear. So it's a doubling of value for every stop. But 6 units in the very bottom equates to around 3 stop difference. Stop 0to1 - has 1 value Stop 1to2 - has 2 values Stop 2to3 - has 3 values so in the first 6 integer values there are 3 stops of light recorded. At the last stop there are 2048 values allocated. So a difference of 6 units isn't going to show. Make sense? I may try to record some as well. cheers Paul ALSO: Another thought, is it shutter speed that is wavering? That is electronic - is there a pattern there, in other words it's not the ISO but the shutter speed at fault? That might explain why different people see it at different ISO values?

Whoa, brain is confused! But yeah, i see. I think maybe i'll do some more tests. On another note one of those GGS VF arrived. It's a nice compact well made however it's not actually big enough to cover the fp screen, you would cut the sides off. So i have no idea what all those that are using it are doing - they would have to stick the magnetic adhesion so it cuts into the screen. Also there is obviously no optical adjustment and actually for my eye i find it clearer about half a CM away from the screen and actually then it does show the whole screen. So i am wondering if i can make something that means i can have it the right distance from the screen and slots into the small rig cage i have on the camera. Does this mean i can get a 3D printer?! I think the optical quality of sigma is better - this one distorts the sides of the image but it's plenty usable if i can find a way to mount it. cheers Paul

On a static scene it's clear. if you download Scotts DNGs it is very obvious, if you go into DNG and bump up the exposure it is even more so. You can see on the scopes that there are two modes that the images are flicking between - one with truncated blacks and one with more shadow detail. In the DNG there is a concept of a black level. This is subtracted from the data and i thought perhaps that was being incorrectly calculated. Because it's jumping between two seemingly fixed states - it does seem like a software thing but then we'd all be seeing it. If it's hardware then is it environment? Temp? I need to try a few things, because it looks like it's shadows only but then this is linear data so changes in shadows are going to be much more obvious than lights. Scott - do you have a macbeth chart? It would be interesting to have a scene with dark, mid and highlight greys and just shoot that with the lowest iso that flickers, Then we can look at the averaged data (to get around noise) and see if the values are linearly incorrect in the data. Also i don't see a reply from redepicguy....? Was it removed? cheers Paul

Fixed in current firmware. It is very good with M lenses so far. No OLPF but don't know about the thickness of the filter stack. I need to get hold of a 28 cron to test with but others seem fine cheers Paul

Ah, well yes, do that. Because i find it difficult to believe that the physical sensor or hardware is changing depending on ISO like that and the way the data is looking it seems like a bug perhaps between sensor and writing out the RAW data. 8bit and 10bit would be slightly different. I've mostly *not* used 12 bit because i am in 25p land. I have used it when shooting without sound sync but certainly beyond tests and messing around i've not 100% focused on it... cheers Paul