Forum Replies Created

Page 31 of 317
  • Chris Wright

    December 27, 2018 at 1:57 am in reply to: LUTS made in Photoshop look different in Premiere

    when I create luts, I use iwltap, then set it to 64 cube iradas lut with trillions of color from a png HALD image. I don’t use photoshop to make luts directly. It kinda looks like there is a color shift going on there as well. how does it work when you set photoshop to use your monitor’s profile for proofing?

    The problem is, the web is srgb 2.2 and premiere with color management on is BT1886(with it off its rec. 709 but ignores your monitor’s profile). you could use a temporary viewing lut to offset grade in a faux srgb 2.2. firefox would match the best unless you’d want to fiddle with chrome’s color profile tags. i’d use VLC over quicktime. quicktime is kinda all over the place with color depending on old atom tags from 2005 and custom luma levels.

    here’s two luts depending on if your going from premiere or premiere to web/VLC/firefox. one darkens, other lightens. its a viewing lut only, so you’d disable prior to exporting.

    if anyone says it don’t work, i’ll stop posting, but I haven’t heard anything negative yet.
    bt1886 to srgb/rec709 2.2 and srgb to bt1886
    https://drive.google.com/open?id=1HHxxaOWifI3TEhBwEyGSl139x2jRM9dO

  • Chris Wright

    December 24, 2018 at 8:14 pm in reply to: LUTS made in Photoshop look different in Premiere

    i can almost certainly admit that they won’t match at first, because they use color management differently.
    premier with color management on, uses your monitor profile, converts it to rec. 709 2.4 then applies a BT.1886 transform. this is regardless of what your source footage is. you’d need to either setup photoshop for previewing in a BT.1886 format or use a preview lut in premiere, like a BT1886 to sRGB/web color.

  • in the adobe forums, it was a bug. not sure if bug is resolved in latest update.

  • Chris Wright

    December 21, 2018 at 5:21 pm in reply to: Anyway to save this footage?

    this is theoretical but its probably a combination of shutter strobe and color, so you’d need 2 passes.
    digital anarchy deflicker for strobe/luma and a matte for the color. you might be able to use a difference of deflicker and original for color matte. it would be an adventure in color restoration though for sure, maybe even channel mix painting.

  • With the latest version of Premiere, the rabbit hole got a little bit deeper. if you enable its new color management feature, it will interpret through your monitor OS profile. But, it will take that, run it through a rec. 709 transform interpretation and then finally add a BT.1886 transform.(which means, if your monitor is calibrated to BT. 1886, premiere should match any player that can playback BT.1886 like madvr with luts.

    Now, the main problem is, the web isn’t BT.1886(or rec. 709 2.4 with a straight shadow curve) its actually sRGb, so premiere grading won’t translate well to the web. Also FCPX uses rec. 709 2.2(last I checked) so it won’t look right either.

    here’s two luts depending on if your going from FCPX to premiere or premiere to web/VLC/firefox. one darkens, other lightens. They are for monitoring your preview only and should be disabled just prior to playback. They are 64 cube.

    bt1886 to srgb/rec709 2.2 and srgb to bt1886
    https://drive.google.com/open?id=1HHxxaOWifI3TEhBwEyGSl139x2jRM9dO

  • Chris Wright

    December 5, 2018 at 5:54 pm in reply to: CPU: i9 9900K vs i9 7940X

    better check the pugetsystems website, it actually depends on the codec!

  • Chris Wright

    December 4, 2018 at 5:08 pm in reply to: Color saturation issue with theatre lighting

    I saw before and after pictures of this technique and it looks like it worked. ( think he used resolve though)
    It appears he shifted the clipped gamut into a larger gamut and then re-balanced the white balance.

    “I decided to change the input colour space to the timeline (Rec.702/2.2) and just rebuild the gamut/space transformation from slog3 to rec709/2.2 myself. It changed the wb to get things safe so I lost the blue in the haze but I can build that back in. A little bit of tweaking on the log wheels and primary bars and I’ve now got something with safe luma and chroma that I can start to grade!”

  • Chris Wright

    November 19, 2018 at 5:28 pm in reply to: Is 100mbps h264 better or worse than 100mbps Prores?

    your right! it seems only cineform,jpeg2000,redcode are wavelet after all. good catch! prores and dhxhd are DCT. I find that fascinating that cineform hasn’t taken over as it is supposed to be superior to DCT for quality.

  • Chris Wright

    November 18, 2018 at 11:00 pm in reply to: Is 100mbps h264 better or worse than 100mbps Prores?

    according to https://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf

    Prores 422 LT is the closest approx for 102mpbs vs 100mpbs. You would think h.264 would have more visible macroblocking due to codec technology as prores uses wavelet encoding. but this is for HD only. Prores 4:2:2 LT would have to have a bitrate of at least 350mb/sec to compare with 4k h.264 at only a 100mpbs and is the reason why h.264 is used for cheap storage.

    modern cameras can record 4k into h.264 which can actually be higher quality even if they are 4:2:0 due to actual pixels being sampled. this is why a gh4 4:2:0 will chroma key better than a bmpcc HD 4:2:2 because resolution trumps all chroma subsampling encoding and where the 8.33 bits/pixel idea came from, down sampling during resizing gives better quality.

  • Chris Wright

    November 17, 2018 at 5:13 pm in reply to: More realistic fake zooms?

    shoot with an actual zoom lens on some tracking markers. Track them in AE, copy the keyframes over to your scale effect. you’ll have an organic motion. if you shoot in 4k, 5k, 6k, you can zoom without blurring with scale to frame vs set to frame.

Page 31 of 317

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy