#apertus IRC Channel Logs

morning folks!

mithro: how? switching I/O voltage on the fly on an FPGA seems to require reconfiguration

morning Bertl!

requires to upload an eeprom configuration (already done) and special commands (I'm working on that :)

but it looks good so far

off for now ... bbl

Bertl_oO: I wonder if it would work with partial reconfiguration

yeah, while I'm sure a recondiguration would work, the sequence to switch VCCIO together with that reconfiguration is probably very problematic

been hunting a bug in the filters stuff in the last few hours

it appears to be a bug in ffmpeg

I assumed that ffmpeg -vcodec copy does just that - copies exactly

http://files.apertus.org/AXIOM-Beta/snapshots/tmp/direct.jpg

nice

i.e. transformation or misinterpretation of color ranges, etc

so maybe limited vs full range?

Stream #0:1(eng): Video: prores (apch / 0x68637061), yuv422p10le(bt709), 1920x1080, 470399 kb/s, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 6k tbn, 6k tbc (default)

first is shogun, second is copied

does it count as a bug in ffmpeg? (as in, should we report it?)

the main question is, can you easily change it?

i.e. with an option specifying the "proper" color space?

yeah, that should work

well, my expectation was to get identical output in both cases

idk, on Canon MOV I get identical output

it looks like a bug

which has no relation to the interpretation though

the very same bitstream, considered as "limited range RGB" for example instead of "full range RGB" will result in quite a different image

Bertl_oO: oh, yep. of course

this one appears to get somewhat closer visually: -vf "colormatrix=bt709:bt601" -pix_fmt rgb48 (also tried bt601:709), but standard deviation of the difference image gets much worse in both cases

if you force a colour space for the decode, you shouldn't see any differences between the encoded streams

can you suggest a command line that I could try?

I found other people having similar issues

*since I last tried it

https://media.giphy.com/media/xT9DPl04nNfIDClaLu/giphy.gif

alexML_: I tried the colormatrix setting again and it doesn't work when outputting a png image sequence

eg:

and

codec is libx264

ffmpeg -i default.mp4 -vf colormatrix=bt709:bt601 %04d.png

I've identified some change as well, but not in the right direction

I'm working on a single frame for now, so I output just one ppm

alexML_: ^

specifically: "ffmpeg always assumes the BT.601 colorspace when converting from RGB->YUV and from YUV->RGB. A patch to fix this is welcome, but no one has ever cared enough to provide it."

eh, probably not

well, for what I'm doing, I don't really care in what exact color space it is, because I'm going to profile it anyway (I just need it to be consistent for all files)

good night

nn

so the profile will be based on an image with lost data?

because value range in those files is about 10000 - 50000, so it's quite hard to get it to overflow from this bug

off to bed now ... have a good one everyone!

TimVideos got into Google summer of code!