[Grant Lovering]

Thanks for your input Ramona.

[Grant Lovering]

Definitely something that will take a video source (ideally HD-SDI) so you are viewing a broadcast reference. Id recommend looking at the JVC DTV series. We recently road tested a whole heap and found this to be the best. One I would have liked to have tested that we couldn’t get down in Australia was the eCinema, it gets good wraps. Found the TV logic had pretty bad off-axis viewing angle with massive shifts and looked pretty average too. The Sony range is pretty overpriced and underachieves quality wise.

https://pro.jvc.com/prof/attributes/category.jsp?productId=PRO2.1

Hope this helps.

[Grant Lovering]

I think Bob is onto it with the card locations. We had the same problem with a blazing system and RAID, SD was capturing but HD was dropping. Turned out the system arrived with the fibre channel card where the AJA card should have been. Swapped them around as per the AJA tech notes and problems solved.

This should show you what you need.
https://www.aja.com/html/support_kona_rec_sys.htm

[Grant Lovering]

Thanks Gary, I’ve got a good understanding of LOG and Lin and the different scales.

What has me interested is material that has been shot digitally in a custom LOG space (such as Sony’s S-LOG) the pictures would still need to go through almost an S-LOG (or proprietary LOG, Sony, Panavision etc) to LOG conversion prior to doing a LOG grade to get them ready for a film out as they each use there own curve to define what their LOG is which is not the Cineon convention everyone typically works with.

I came across this which shows recommended conversion of LOG to LIN (I realise LIN is not what we are looking for here, but stick with me while I use it to explain) for a Panalog source. You can see the values are quite different to a typical LOG to Lin which suggest we have logarithmic data which is off a very different base to the Cineon base typically used when doing a data scan or providing source for a film out (because Panalog has used it’s own curve (or maths) to distribute the LOG data and has it’s own LUT for previewing it in LIN).

https://prolost.blogspot.com/2008/01/panalog.html

Conversion of Panalog to LIN
10 Bit Black Point: 0
Internal Black Point: 0.0
10 Bit White Point: 681
Internal White Point: 1.0
Gamma 1.480
Highlight Rolloff: 0

Typical LOG to LIN (Cineon Spec)
10 Bit Black Point: 95
Internal Black Point: 0.0
10 Bit White Point: 685
Internal White Point: 1.0
Gamma 1.7
Highlight Rolloff: 0

I realise this example is showing a conversion to Linear which may be confusing the issue, but was just using this data that I could find to show that these proprietary LOG formats that use Custom LUTs to look okay are encoding to a unique LOG space.

In my opinion this has proven that you need to determine the gamma and black and white point variance of these custom LOG formats to the typical Cineon base so you can do a LOG to LOG conversion for grading and then supply of Cineon DPX files for film out.

So…….we have some data for Panalog from Stu Maschwitz’s blog. Anyone got data for Sony’s S-LOG? Apparently Sony are releasing a LUT for S-LOG soon which will probably contain the maths for those inclined to work out the translation from S-LOG to Cineon LOG or S-LOG to Lin.

Unless someone has data, I’m guessing the best thing is to do your own tests with a LOG to LOG translation of the S-LOG with the film LUT that previews your target and play with the gamma, black and white point until you get something balanced that you can then grade. Any better ideas or has someone already done the maths for S-LOG?

Alternatively I’ve tried making this way harder than it needs to be and just load in your Panalog or S-LOG material and start grading with your LUT that is previewing your target film out and it will be all good.

🙂

[Grant Lovering]

Ahhh….I enjoy a lively thread.

Hey, the thing I was keen to know though is when these custom LOG formats (which are designed to protect highlights and lift darks to avoid noise when shooting in the digital world) are coming off tape and into Kona is the codec (10-Bit RGB or 10-bit RGB LOG) doing anything differently for how it is interpreted or is the mapping just layed down 1:1 in each codec so theoretically you can transcode between or does the codec map the data differently effectively doing some conversion on the way in?

G.

[Grant Lovering]

Hey Gary,

I’ve just posted a new thing to solve re: 10bitRGB and 10bitRGB LOG, wondering if you know on this one?

https://forums.creativecow.net/readpost/98/870596

Cheers,
G.

[Grant Lovering]

All fixed….thanks for your help Gary.

[Grant Lovering]

Thanks Gary for your help on this one. That is my understanding too. We have used cineSpace to generate a Kona compliant 1D LUT and have confirmed that it loads fine in Kona 2, but Kona 3 will not load it, reports a file not found error.

I had a cineSpace tech check the LUT file too and confirmed it looked technically correct.

[Grant Lovering]

Driver uninstall reinstall didn’t work.

[Grant Lovering]

This shift on playback happens when FCP and your IO card are doing RGB to YUV conversions on the fly to your broadcast monitor. If you set your timeline to the RGB codec used and set the sequence settings to RGB and set your video output setting to an RGB setting (not a 10 or 8 bit) the shift will go.

Just listing those off the top of my head without the system in front of me. Had to solve the same issue a few months back.