Jump to content

Photo
- - - - -

Nikon D600 gradient problem


  • Please log in to reply
10 replies to this topic

#1 procent

procent

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 18 February 2013 - 01:56 PM

Hi everone!

 

Can some one tell me is this normal?

 

please watch in HD

 

this is straight out of camera, lens nikkor 24-70, no filter

I can see circular gradient :/ dont know where problem is..

 

here you can download original file 46mb where you can see this even more.

 

http://www.mediafire...c5uer12hw63xsuc

 

 


  • adetrybed likes this

#2 QuickHitRecord

QuickHitRecord

    Advanced Member

  • Members
  • PipPipPip
  • 810 posts

Posted 18 February 2013 - 03:02 PM

That is a classic example of color banding. It is a result of an 8-bit codec. There are only 255 shades available from each color channel with 8-bit (over 1000 for each channel in 10-bit). Unfortunately, it's very common, especially in DSLRs. It's easier to see in some cameras than in others.



#3 EOSHD

EOSHD

    Andrew Reid - British Filmmaker - Editor EOSHD

  • Administrators
  • 3,754 posts

Posted 18 February 2013 - 03:07 PM

Scaling and compression don't help either. I think the 8bit is only the main source of a banding problem when you grade heavily. (But don't mention that to Bloom!)

 

JPEGs are 8bit but usually have much smoother gradation.

 

The fix - well more of a bandaid really - is to add dithering or grain to the image.



#4 richg101

richg101

    Advanced Member

  • Moderators
  • 1,000 posts
  • LocationBristol. UK

Posted 18 February 2013 - 03:25 PM

If using premiere avoid using non 32bit effects.  eg. 'curves' being 32bit seem to be better than 'levels' when adjusting contrast.  I am unable to explain why this seems to lower the amount of banding but i am sure people here can explain the reasons it seems to work better.  I used to use rgb curves to grade then levels to adjust the contrast.  Now I use the master curves to adjust the contrast and it seems to be cleaner than 'levels'.

 

also i find setting up a 4k workspace and upscaling your 1080 footage, then working on it, grading etc, applying a slight blur, then re-sharpening.  overlaying a fine 4k grain over the top, then exporting out as a 1080p file.  seems to create a perception of extra data from nowhere once scaled back down during export.  Again, I don't know why it works, but it looks better to my eyes.  anyone care to explain might be happening with this workflow? 



#5 procent

procent

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 18 February 2013 - 03:37 PM

thx guys for fast reply :) so i dont have to worry? and what about that bloom thing in the middle?



#6 hmcindie

hmcindie

    Advanced Member

  • Members
  • PipPipPip
  • 319 posts

Posted 19 February 2013 - 01:36 PM

It's not just 8-bits guys. If you haven't noticed, the D800 and D600 suffer from this a bit more than other 8 bit cams. Why? Because they apparently debayer the image into 8bit and THEN apply a picture profile.

 

You will get more banding with the D800 and D600 than other 8bit cams so blaming this on 8bits is kinda weak.



#7 Axel

Axel

    Advanced Member

  • Members
  • PipPipPip
  • 996 posts
  • LocationGermany

Posted 20 February 2013 - 01:57 PM

If using premiere avoid using non 32bit effects.  eg. 'curves' being 32bit seem to be better than 'levels' when adjusting contrast.  I am unable to explain why this seems to lower the amount of banding but i am sure people here can explain the reasons it seems to work better.

 

It's in the way filtered values are being computed. There are i.e. operations that multiply the original value (by more or less than "1"). So, if you have the value of 10 of 0-255, and you multply it by 1,32, you won't get 13,2 in 8-bit,  you get 13. There are only integer numbers, and every other result is rounded. 

 

This doesn't mean instant banding. But almost. Because every change you make is performed on top of the one before (*the rendering order must not be same in which you applied the filters, another BIG pain in the ass with 8-bit). The next filter takes the not-so-exact 13 and rounds again.

 

With 32-bit floating point, the 13,2 of the first filter is contemporarily stored. The next filter adds 2,87 to every value, the next divides by 2,51, the last multplies by 0.3.

 

At the very end, the result is rounded again to fit into 8-bit. Now look at the outcome: The final value with 8-bit is 2, with 32-bit it's 14!

 

I read (but don't know why), that only one 8-bit filter in the render pipe makes everything 8-bit.


Either you care - or you don't

#8 QuickHitRecord

QuickHitRecord

    Advanced Member

  • Members
  • PipPipPip
  • 810 posts

Posted 20 February 2013 - 02:25 PM

I read (but don't know why), that only one 8-bit filter in the render pipe makes everything 8-bit.

 

I have heard this too. Is there a way to tell which filters are 8-bit?



#9 Axel

Axel

    Advanced Member

  • Members
  • PipPipPip
  • 996 posts
  • LocationGermany

Posted 20 February 2013 - 03:01 PM

The old FCP has very few 32-bit filters, see here (at least the main CC-filters among them). FCP X has only 32-bit-filters. Premiere has very few 8-bit filters left. The 'good' ones are distinguishable by those icons:

32BitIcon.png


Either you care - or you don't

#10 QuickHitRecord

QuickHitRecord

    Advanced Member

  • Members
  • PipPipPip
  • 810 posts

Posted 20 February 2013 - 03:31 PM

The old FCP has very few 32-bit filters, see here (at least the main CC-filters among them). FCP X has only 32-bit-filters. Premiere has very few 8-bit filters left. The 'good' ones are distinguishable by those icons:

32BitIcon.png

 

Fantastic. I will stay away from the 8-bit. Thanks for the info!



#11 see ya

see ya

    Advanced Member

  • Members
  • PipPipPip
  • 216 posts

Posted 20 February 2013 - 04:47 PM

With 8bit we work within 0 - 255, with 16bit we work within 0 - 65536 but in both instances 0 - 255 8bit are remapped into those ranges.

Problem is that our video sources are often full range or at least 16 - 255 but the conversion between YCbCr to RGB is based on 16 - 235 YCC to 0 - 255 RGB so those top 20 levels get clipped to white.

With 32bit 0.0 to 1.0 is 0 - 255 RGB ie: 16 - 235 YCC those twenty levels don't get clipped but instead are mapped above 1.0 and not clipped. Same for shadows below 16 they get mapped below 0.0. Not crushed.

When you read 16bit is enough it maybe enough precision but doesn't solve crush and clip with full range video sources. 32bit is essential.

After Effects CS5.5 onwards works a little differently the 0 - 255 levels is mapped with 0 RGB at 0.5 rather than 0.0 which I think is because blending and color processing is done in the linear domain, so all levels get shifted up to avoid working too much in the lower end of the range.

I believe that any CUDA or OpenCL operations are always 32bit and in the linear domain so even 16bit filters become historic.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users