Sometimes coordinater are larger than the screen size

[erazortt]

Stats at frame 801:
MaxCLL: 963.61, raw value: 49007 0.747799 at X 4324 Y 932 at frame 788
MinCLL: 0, raw value: 0 0 at X 0 Y 0 at frame 6733
MaxFALL: 97.8258 at frame 388
FALL Average: 19.7778 across 801 frames.

Where is X=4324 supposed to be? The max width is of UHD 3840.
And it appears that the coordinates are counting from bottom to top and from right to left. In video editing top left is usually 0,0.

[TomArrow]

Sorry for the confusion. That data was meant more for debugging really, otherwise I would have fixed it up a bit. If I recall correctly, the number is the pixel position but without accounting for color channels. Basically, the way the video is stored in memory is as a sequence of R,G,B (and sometimes A for alpha) pixels. So let's say you have an RGB video, the row offset of the first channel (let's say blue, it depends on the particular application), is going to be the pixel position in terms of screen coordinates multiplied with 3. For RGBA, it would be multiplied with 4. Which I think is what this plugin uses. So the actual position would be 4324/4 = 1081.

You're right about top left usually being 0,0. As said, this output was more of an afterthought really. Is it important to you?

[erazortt]

Kind of, so that I can find the spot. Since sometimes its just single pixels which have very weird luminosities and in thsi case I could find it. Without the coordinates its impossible to guess where on the frame the single pixel might be.

[TomArrow]

I see, that's fair I guess. I'll just leave this open until I have the time to fix that. Might not be for a while though. Thanks for the feedback.

[erazortt]

Sorry didn't have time to wait. You can use my pull request if you like.

PS: I also cleaned up your code and made another pull request for that as well.

[TomArrow]

I see you already did it yourself and then some. Thanks for the cleanup and bugfix.

[erazortt]

Oh I guess the readme still needs to reflect the change from RGB64 to RGB48.

[TomArrow]

To be honest I would like it the most if it supported both RGB64 and RGB48, because most of my code deals in RGB64 and it would be more consistent for my workflow being able to use that. It's fine however, not a big deal, and I can see your logic for changing it. Feel free to change the readme.

[erazortt]

Ok I can make a change so that both are supported.

[erazortt]

Is the MinCLL value actually of any use?

[TomArrow]

I don't think so. Just thought it'd be interesting and perhaps for debugging, see if any strange stuff happens.

[TomArrow]

Although, when encoding HDR, you can set a minimum brightness level of the mastering display. Might be of interest for that I suppose.

[erazortt]

But that will always be 0, at the very least due to the black bars.

[TomArrow]

Well that's not the plugin's fault though. The user is free to crop black bars out or pre-process the video. It's simply an option that is offered.

[erazortt]

Ok then. So are you thinking of compiling and releasing the newest version?