This stream auto-updates   

  1. Yesterday
  2. Fatih OGER
    When using Fusion studio the result is somehow much different.
  3. Ben Price
    Thanks Mazze, appreciate your response, we think that's something to do with it. The colour seems to be exceeding the P3 D65 gamut in the shadows, so desaturating them tends to do most of the leg-work bringing them with the legal limits.
  4. Last week
  5. William Dowling
    This is exactly what I needed to see right now!!! Thank you for the course!!! I'm excited to practice and apply the techniques!!!
  6. Mazze
    Depending on how much "bleeds" outside of the P3 gamut, it could simply be RGB vs. YUV. Inside Resolve (or any DI system for that matter, with very few exceptions) all is RGB-based and so is your measurement. When you then render out to a YUV based codec, the encoder used will convert the RGB data to YUV. That conversion might introduce certain "spikes" that reach outside of the defined gamut. Vice versa, when pulling the rendered result back in, the first thing that happens right after the decode, is a YUV to RGB conversion. Effectively you now have two conversions in between your two measurements. You can check against by exporting the original timeline as RGB DPX and pull those back in and analyse. If they are a 100% match (as you're not going to YUV and back again with those) - the culprit lies with the YUV conversion, and can't be avoided. Cheers, Mazze
  7. Ben Price
    Thanks Luca, appreciate it. We're a little stumped as are BlackMagic, when using the Rec2020 P3D65 limited output transform we're seeing the colour exceed the confines of P3. Interestingly it doesn't occur when working on the project, only when bringing the export back in to look at the scopes.
  8. Luca Leocádio Soares
    After upgrading to Resolve 16, we haven't seen this issue anymore and you can download the LUT on the comment above.
  9. Anfisa Zelentsova
    Good day everyone, We are thrilled to announce our NEW plug-in: Dehancer Film 1.0.0 for Adobe Photoshop / Lightroom Classic For macOS only at the moment. Our team would like to offer a free 2-week trial for anyone who is curious to try. Head over to our website to get yours: https://www.dehancer.com/store/pslr You can learn more about the installation of this plugin in our dedicated article: https://blog.dehancer.com/articles/dehancer-film-plugin-for-adobe-photoshop-and-lightroom-classic-installation/
  10. Ben Price
    We're currently having this same issue, did you ever work out a more permanent solution? Would it be possible to have the LUT too please? Thank you!
  11. Robert Glotzbach
    Thank you for this great course.... its super usefull to me 🙂 One thing i noticed is that the 'Log3g10-RWG-to_LogC-AWG' Ctl is missing in 17.4. Does any one know if this was a intentional choice or just an error? Many thanks, Robert Update: Just found the dctl in the downloaded project folder... Installed and perfect 🙂
  12. mert celal özkan
    ı hope you like
  13. Earlier
  14. Daphne FilmLight
    FilmLight reveals first ever Colour Award winners live from EnergaCAMERIMAGE After a long and careful evaluation process, the honours have been distributed: the winners of the first-ever FilmLight Colour Awards were announced at a special ceremony as part of EnergaCAMERIMAGE on Sunday, 14 November. The ceremony included a panel discussion with several of the winners in attendance and others joining in online, in a hybrid presentation watched live by many across the globe. The award for the grading of a theatrical feature went to Eric Weidt, who worked with DoP Erik Messerschmidt on Mank. Shot on an 8K RED camera, the movie is striking for its 30s Hollywood look combined with the crystal-sharp resolution. The top two entries for the television series/episodic category could not be separated, and so each was awarded a trophy. The Fargo episode ‘East/West’ was an homage to the classic movie The Wizard of Oz. Colourist Tony D’Amore of Picture Shop dug deep into tools available to track mattes to blend monochrome and colour, with beautiful footage shot by DoP Dana Gonzales. Placed alongside Fargo was Damien Vandercruyssen’s work at HARBOR on the series Lisey’s Story, episode ‘Lisey’s Story’, shot by DoP Darius Khondji. The storyline blended reality and dreams, and the grade emphasised the differing environments, including startling marbleised faces. Tim Masick at Company 3 took the award for best grading in a commercial, with a stunning spot for the Dior Spring Summer 2021 Collection, shot by DoP Benoit Delhomme. The striking commercial used chiaroscuro, putting strong skin tones in sharp contrast with the moody settings, very much in the style of Caravaggio. There was also a fourth award, for the most innovative use of Baselight as the grading platform. Gilles Granier, Fabien Napoli and Arnaud Caréo from Le Labo, Paris worked in partnership on Miss to establish the highly individual look of the movie, and together they developed their own gamut manipulation toolbox within Baselight. Both Eric Weidt and the team from Le Labo were in attendance for the presentation at EnergaCAMERIMAGE, while the other winners took part from their home countries. There was also an online appearance from DoP Benoit Delhomme to discuss his amazing photography on the Dior Spring Summer 2021 Collection and his collaboration with colourist Tim Masick, and also DoP Dana Gonzales discussing his work with colourist Tony D’Amore on Fargo. “All of us at FilmLight are really excited by the reception the industry has given the Colour Awards, and by the extraordinary work the finalists and winners presented,” said Jacqueline Loran, Director at FilmLight. “We are very grateful to our partner bodies and of course to the judging panel, but we are even more honoured by the response we saw from colourists across the world. “This was the first FilmLight Colour Awards,” she added. “Already we can see that the mood is there to celebrate the amazing art of the colourist in every respect, and we have plans to make the 2022 edition even more exciting.” The awards were organised in conjunction with EnergaCAMERIMAGE, the American Society of Cinematographers, Imago (the International Federation of Cinematographers) and CSI (Colorist Society International). They were judged by an international panel of well-known directors, DoPs and colourists.
  15. Tristan Summers
    Really good to see this Sir. Keeo filling As a useful hint: I use mine in a Maxpedition Ironcloud, as it is lighter than a peli and becomes a rucksack. I did have the Peli and used to put it inside a larger Maxpedition Iron Storm to carry it. That worked better than the RucPac option to add straps to the peli. Keep making cool stuff and hopefully we can get it in the UK again soon. In the meantime, Tangent also confirmed they are offering their version of the fascia: "We are already offering a service where the fascias of your panels are changed for the new extra durable paint finish in the UK. The cost for the full bundle of 4 panels would be £350 plus £12 return shipping."
  16. Ryan Broomberg
    This was an awesome video. So my question is what do you do with it after you creat it? Is it a lit you export? How do you have it? Where does it go in your project?
  17. Lowepost
    Yes you can.
  18. Luk Monet
    Can I debayer any R3D file using IPP2? Specially older RED DSMC cameras which doesn’t have RWG and not supporting IPP2?
  19. Adrian wolfson
    Are there going to be any discounts on here for registering for the courses for Black Friday?
  20. YUAN CHIN LIM1
    Hello! In lesson 3, Kevin taught compression technique. May i know why we need to compress our curve range? mostly when do we use it? Thanks
  21. lewis jacobs
    I wondered if people could show me examples of fixed node trees that you're using
  22. lewis jacobs
    Did you finish the fixed node tree tutorial?
  23. Mazze
    Hey people, as some of you might know, the original foam inserts to fit Tangent's Element panels into a Peli Case 1510 ceased production around 2017 or so and have been unavailable since. Reason enough for me to look into producing them again, as demand was still there. I have now started a small production batch with an estimated shipping date of december 1st. Pre-order (incl. a small discount) is up now and will last until Nov. 28th 🙂 . https://www.angry-face.com/foam-inserts-for-the-peli-case-1510-are-back/ Cheers, Mazze
  24. Glenn
    David thank you very much for that info. Very interesting, particularly that nots on the PCC software. In the past I have seen definite constant offsets. 3hrs comes to mind. But not with this lates job we had. This one was all kind of random. And so it appears that resolve was not the system used to generate the transcodes that the editor used. Our solution going forward is going to be to not only get the raw cine files but the transcodes used. This way in resolve we can assing the code from those transcodes to the cine so we can use the client xml to conform the spots. Not the greatest solution but it works. Thanks again!
  25. David Coiffier
    I'm also sorry for the confusion... TC is a complex matter with hispeed files. SMPTE TC is derivated from a realtime timestamp, but does not really exists as such inside the metadata. Still, the SMPTE being generated on the fly is supposed to be same no matter what software is used. I had a quick check, here is what I've found so far : • Resolve shows TC related to the inner timestamp (expected behavior) • Silverstack shows also same TC as Resolve. • PCC (Vision Research windows app) DOES NOT show the same TC as Resolve, and this TC is unrelated to actual realtime timestamp. So, as weird as it seems, I'd say correct TC in the Resolve one, while PCC (and so phantom player) won't... That being said, it's of no help for your actual issue... Btw, did you notice a constant offset between those TCs ?
  26. Glenn
    Thank you for the response David. I didnt do such a hot job explaining. Sorry. This is all about timecode and conforming. I'm supplied an XML and ref pic from the editorial company. When I try to conform my spot with that xml and ref pic- no files link on resolve. . It seems to me that the resolve does not "read" (for lack of a better word) the timecode correctly off my cine files. As an example file 4662_P5_8 when that file is dropped in resolve the start timecode on it is 19:45:22:02 Same file on baselight and phantom cine player the timecode on that file is 23:45:22:02 And that 23:45:22:02 is the code that is in the clients XML. So its a bit of a hassle to conform these spots on resolve. So I was just trying to figure out why resolve reads the timecode on that file differently than its read on cine player and baselight. Thanks.
  27. David Coiffier
    Hi Glenn, I'm not a killer colorist but I have a bit of experience with .cine files as I 'm a lucky Phantom owner. What exactly do you mean by reading the code ? Getting correct metadata ? From what I understand, I assume you've tried to change global cine settings in the raw tab settings, but it didn't change a thing, while switching individual clip to custom settings does work. The only case I know these settings will be ignored is when using the DVR color managed mode. Is this your case here ? From what I think I've understood by myself, when Resolve is set to color managed mode, linear raw data is automatically mapped into your actual colourspace, bypassing the classic raw tab with specific phantom options, notably the transfer curve selection (rec709, log1 & log2 curves). While I was trying to set a pipe to color grade .cine files in an HLG colourspace, I've noticed that when color management is ON, the result is quite different to any available curve you can get when in unmanaged mode. And I definitely prefer the rendition I get from the unmanaged mode, with the classic raw tab tools. This color science was probably provided by Vision Research at first, when I suspect the curve being applied by Resolve in managed mode being developed by Blackmagic... In the case you're in unmanaged mode, then this is an issue, as it has always worked well in any actual or previous Resolve versions...
  28. Glenn
    Hi. Relatively new resolve user here. Had a .cine job the other day and it looked to me like resolve was not reading the code off the .cine files correctly. I did a couple searches and I saw some threads from years back about there being some issues with this but nothing really recent. Still an issue? I tried switching the raw file settings for cine in resolve prefs but nothing changed as far as the way the code was being read. Baselight and Phantom Cine Player read the code the same and that matches what was on the client edl. Ended up just changing the code for each shot in the resolve media pool to match the way the code is read by baselight and that worked. running 17.2.1 Any other work arounds? Thanks
  1. Load more activity