#apertus IRC Channel Logs

good morning

21:05 < troy_s> The solution is very much possible, but the larger issue is that a non-linear editor shouldn't be doing that sort of thing.

21:05 < troy_s> The solution is very much possible, but the larger issue is that a non-linear editor shouldn't be doing that sort of thing.

21:05 < troy_s> The solution is very much possible, but the larger issue is that a non-linear editor shouldn't be doing that sort of thing.

21:05 < troy_s> The solution is very much possible, but the larger issue is that a non-linear editor shouldn't be doing that sort of thing.

SORRY for that spam.

I need to learn more about the things you are talking about... of course I am limited extremely how much I can grade because I still shoot in crappy Canon H.264 8-bit 420

Maybe I would understand the problems more if I tried the non-libre apps?

antiatom: FCP, Mediacomposer, and Lightworks, etc. all are capable as offline NLEs.

(Pre FCPX, included specifications for splines, effects blocking, etc. Useful marking / blueprinting for visual effects, post, etc.)

antiatom: Even your 420 footage can be decoded to a more decent entry point. Use a 32 bit float buffer and scale the Cb / Cr manually in that buffer.

Hey Bertl_oO

you're the color research guy, yes?

I assume you got my mail too as I sent it to the team mail?

our local color expert is troy_s, you might be interested to chat with him about color spaces and how bad libre software is :)

Ok, cool to know. Hey troy_s.

Color science is not only a problem in the libre software world …

I already had a short look into the looks but not too deep.

sure, go ahead

When do you expect to have prototypes of the first stage that are hardware ready?

we are currently finalizing the hardware for the Early Betas

yup, the Sensor Frontend is not expected to change after the Early Beta

hi irieger

Please excuse my bad response time. I just came home about a hour ago and I’m currently “compiling” a dinner and with oily fingers going to the laptop is a bad Idea …

*I just finished that oily phase

bon appetit

irieger: learned much with the first prototype and how horrific the actual sensors are. Bertl_oO was very helpful on that front.

A very by-the-book set of colour transforms.

we have been making a lot of progress hardware wise in the last year

if you go the ACES route the colors are really nice

http://www.oscars.org/science-technology/sci-tech-projects/aces

And the most important thing: A public standard to ease work between postproduction studios which often had (or still have) their own color science which doesn’t help when colaborating.

Besides being a color space it’s also a toolset to convert to and from this colorspace. There are transforms for all major cameras to get their files into ACES and have a set of output transforms for various display spaces.

is this an open standard? can you point me to the documentation?

aces-dev is the official color transformation archive. CTL is the reference implementation for the color transformation language used for the transforms

ACES is a cool toolset but sadly to few software supports it really good

troy_s: what are your thoughts on the pipeline front?

irieger: ACES isn't ideal for CG. The more limited gamut ACEScg is better.

sent it to you as a message on the lab.

(Little known factoid is that tristimulus colour models all behave differently when performing physical based manipulations.)

I don't check there too often, and email notifications apparently don't work.

Pipe

troy_s: seem to work fine here (email notifications)

You still need the native camera space for things like keying to avoid crosstalk etc.

I also had no problem with notification yet. The only thing aces does is offering a standard way to work :D And a nice color rendering with the film like reference rendering

My bigger worry is trying to get a very good set of LUTs for the entire dynamic range.

It is great that someone has dealt with it.

I even thought that it might be nice to have different spaces for recording. A nice log format and maybe something else. There are some new ideas how to best store camera data trying other concepts. I’m trying to find more to read about it in the coming weeks. Idea is: If you are ok with storing data in a way not really usable for direct grading you can do some nice stuff I heard. Have to use aces or a lut to get to a grading space maybe

And getting some nice luts is manageable if you have a good starting point

irieger: The camera data storage is somewhat irrelevant as it always wants to store the entire dataset as it is best rendered on the camera.

irieger: Having a handle on a typical post production pipe also helps on the colour front

It highlights the difference between display referred and scene referred models, as well as touches on the why a little.

irieger: Worth a read.

Easier for me to reply and such

what’s your email address?

gotta go

good night

tx