Current Server Time: 01:08 (Central Europe)

#apertus IRC Channel Logs

2016/02/05

Timezone: UTC


23:12
comradekingu
joined the channel
23:13
comradekingu
How many people paid their 1k⬠vouchers
23:18
comradekingu
I am wondering if i can pay all of it at once
00:49
darthrak_
joined the channel
00:53
darthrak_
left the channel
01:47
aombk
joined the channel
02:50
darthrak_
joined the channel
02:54
darthrak_
left the channel
03:29
comradekingu
I have a company, and Norway is outside EU, just tell me where to send monies. IBAN is fine
03:51
darthrak_
joined the channel
03:55
darthrak_
left the channel
04:01
gnufan
joined the channel
05:19
jucar
joined the channel
05:28
jucar
left the channel
05:28
jucar
joined the channel
05:49
jucar
left the channel
05:51
darthrak_
joined the channel
05:56
darthrak_
left the channel
06:05
tezburma
joined the channel
06:17
gnufan
left the channel
06:41
se6astian|away
changed nick to: se6astian
06:59
se6astian
good morning
07:13
John_K`
good morning
07:15
se6astian
hi John_K`
07:16
John_K`
I think I figured out our PIC issue
07:16
John_K`
intermittent connection between the pin headers on the main board and the receptacle on the power board
07:16
John_K`
the pin headers weren't long enough
07:24
getzi
joined the channel
07:29
pusle
Recorders suck? How about making a rail/cartridge holder for standard 2.5" SSD and just plug them into the camera
07:30
John_K`
pusle: that would require SATA controller IP in the FPGA
07:30
John_K`
the Zynq doesn't natively have a SATA controller, so someone would need to write VHDL for the controller
07:40
pusle
"An Open-Source SATA Core for Virtex-4 FPGAs" http://www.ecs.umass.edu/ece/tessier/gorman-fpt13.pdf
07:43
pusle
or an FPGA SOC like Xilinx Zynq. Some of the upcoming ultrascale+ versions even has hard ip h264/h265 module up to 4k@60fps
07:45
pusle
ok only the new Zynq UltraScale+ MPSoC has Sata (3.1)
07:52
darthrak_
joined the channel
07:55
John_K`
it's also not shipping yet
07:55
John_K`
and will be a nice premium over the current Zynq-7000 series
07:57
darthrak_
left the channel
08:09
jucar
joined the channel
08:55
jucar
left the channel
09:53
darthrak_
joined the channel
09:56
Bertl_zZ
changed nick to: Bertl
09:56
Bertl
morning folks!
09:57
darthrak_
left the channel
10:06
Bertl
John_K`: great to hear! (@connectors)
10:12
Bertl
pusle: that's the reason why we started a FOSS/OH project in the first place ... somebody interested (like you maybe) can and will extend the AXIOM cameras with new interfaces
10:13
Bertl
1.5GBit might even work directly and for 3Gbit only a simple gearbox is required
10:52
John_K`
Bertl: how do I program the CPLD with the PICs?
10:53
Bertl
alexML, intracube: after I downloaded the entire RecTest image collection, the ab1.tif seems to be a good candidate for analysis
10:53
Bertl
John_K`: PIC is working as expected and has been programmed?
10:53
John_K`
yes
10:53
John_K`
the right IDs came up and then I programmed both
10:54
Bertl
excellent, give me 10minutes to finish my breakfast then I'll explain/upload latest versions
10:54
John_K`
sounds great, thanks
10:54
Bertl
ah, do you have an assembled PMOD debug module at hand? would help with testing
10:55
alexML
Bertl: which is the input file for ab1? (I only downloaded the ones for o, p and d)
10:56
Bertl
ab1 is an artificial bar test
10:56
alexML
also, Max promised me the prores data, just not today
10:56
alexML
yes, artificial bar, but you have some info on how it was generated (or the memory dump), right?
10:57
Bertl
it is implemented in the mimg test image suite
10:57
Bertl
i.e. either use the source or take a quick look and you'll probably see how it was generated
10:58
Bertl
you can also generate it and dump the memory of course
10:58
alexML
have a link?
10:58
Bertl
ah, yes, the Beta is not available
10:59
Bertl
will upload shortly (after breakfast)
11:14
alexML
do you remember if you used any gamma correction during the test? (it looks like around 0.8 to me)
11:15
alexML
wanted to know if it is from your side, or from the recorder
11:18
alexML
with this value, input values (after gamma) under 16 and over 235 were indeed clipped, and then the range was stretched back to 0-255 when decoding
11:19
alexML
so, after correcting the input signal with x^0.8, the transfer curve in RGB is a straight line from (16,0) to (235,255)
11:26
John_K`
Bertl: no PMOD module
11:33
Bertl
okay, that makes it a little tricky to verify everything is working correctly
11:33
Bertl
alexML: might have been with a gamma set, don't know
11:34
Bertl
alexML: the point is, we have full RGB range, otherwise we would see missing values in the channels
11:35
alexML
and you do see missing values
11:35
alexML
input: http://files.apertus.org/AXIOM-Beta/snapshots/reversing-digital-filters/hdmitest/red-input-raw-encoded.jpg
11:36
alexML
recorded: http://files.apertus.org/AXIOM-Beta/snapshots/reversing-digital-filters/hdmitest/red-hdmi-from-tif.jpg
11:36
John_K`
Bertl: understood
11:36
Bertl
anyway, let me upload the python scripts
11:36
John_K`
thanks :)
11:37
Bertl
you managed to build the lattice code yourself?
11:37
John_K`
I have not
11:37
John_K`
haven't installed their tools yet
11:37
John_K`
looked at the vhdl though
11:37
Bertl
okay, you can use a prebuilt one, but it is probably better to get that part working as well
11:37
John_K`
are you planning on communicating to uZed via the two diff pairs?
11:37
John_K`
of course
11:38
John_K`
it's just straight wired to SPI right now
11:38
John_K`
and we'd like to make use of global shutter
11:38
Bertl
yep, the two LVDS pairs are for bidirectional data transfer
11:39
John_K`
I see one pair has termination, is the other pair terminated on the uZed?
11:39
Bertl
on the main board?
11:39
Bertl
there is termination for both
11:40
John_K`
ah so there is
11:40
Bertl
it's just not populated in our Early Betas at the moment
11:47
John_K`
right, wouldn't make sense given the current config
11:48
John_K`
scripts uploaded?
11:54
darthrak_
joined the channel
11:57
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/pic_jtag_id.py
11:57
Bertl
start with this one
11:58
darthrak_
left the channel
12:00
getzi
left the channel
12:01
John_K`
which bitstream should be loaded on FPGA for that?
12:02
Bertl
the icsp.bit
12:06
John_K`
00000001001010111001000001000011
12:07
Bertl
is that an old version of the script or just partial output?
12:07
John_K`
ah it might be the old one
12:13
John_K`
found MXO2-640HC [00000001001010111001000001000011]
12:13
John_K`
usercode 00000000 [00000000000000000000000000000000]
12:13
John_K`
traceid 00:443307090CCC17 [00000000:01000100001100110000011100001001000011001100110000010111]
12:13
Bertl
that looks way better
12:13
Bertl
okay, you decided to go for the 640HC
12:14
Bertl
in this case you need to rebuild the bitstream for the lattice anyway
12:14
alexML
updated HDMI experiment images with correct gamma and scaling, at http://wiki.apertus.org/index.php/Reversing_digital_filters
12:14
John_K`
ah ok
12:14
Bertl
(we have been using the 1200 and 2000 for now)
12:14
John_K`
I'll grab their tools now
12:14
alexML
cc troy_s and intracube
12:14
John_K`
there were quite a few departures from your BOM in the one linked from the wiki apparently
12:15
Bertl
yeah, apologies for that, the google spreadsheet was created before we had a bom and never updated :/
12:23
John_K`
downloading lattice tools now
12:50
intracube
alexML: nice work :)
13:05
jucar
joined the channel
13:42
troy_s
alexML: You need to sample the raw YCbCr
13:43
troy_s
alexML: That is the only way to properly analyse.
13:44
troy_s
alexML: There was proper scaling applied on the RGB to YCbCr right? 16-235/240 correct?
13:45
troy_s
It isn't a clip either, it is a uniform scale.
13:45
troy_s
So there is a subtle quantization.
13:46
troy_s
There is a very simple matrix plus offset via OCIO to do the conversion at 32 bits per channel float.
13:48
jucar
left the channel
13:54
darthrak_
joined the channel
13:59
darthrak_
left the channel
14:08
troy_s
alexML: Ping me and I can help you with the FFMPEG command to dump the raw YCbCr planes.
14:13
cbohnens|away
changed nick to: cbohnens
14:13
cbohnens
changed nick to: cbohnens|away
14:13
Bertl
that was a short visit :)
14:21
troy_s
People got stuff to do!!!
14:21
troy_s
Lulz.
14:23
intracube
"<Bertl> alexML, intracube: after I downloaded the entire RecTest image collection, the ab1.tif seems to be a good candidate for analysis"
14:23
intracube
Bertl: ^ there's some strange banding going on with that one
14:25
Bertl
yep, might be related to the encoding though
14:26
Bertl
i.e. it might be better to redo those tests with known settings
14:26
Bertl
(we found at least two bugs in the experimental raw encodings)
14:27
troy_s
intracube: Again, base all judgements off of the YCbCr. ;)
14:27
troy_s
Use a LERP to sample the channel dimensions, and simply look at what was in the bitstream. It is hokey voodoo if you don't.
14:27
intracube
Bertl: yep
14:28
troy_s
The RGB <-> YCbCr _twice_ is madness.
14:28
intracube
Bertl: if the issue is with the Shogun, why not feed it from a known source instead of the Beta?
14:28
troy_s
Bertl: You are going from RGB to YCbCr then? Or letting the Atmos handle that?
14:28
intracube
troy_s: yep
14:29
troy_s
intracube: Likely _not_ the Shogun. Decent estimate it isn't.
14:29
troy_s
(There are quite a few capable imagers with that device that have peeled apart the encodings and, quantization aside, I haven't seen too many reports of mangling.)
14:29
Bertl
intracube: what would be a "known source"?
14:30
intracube
Bertl: dedicated bluray player with testcharts on a disk
14:30
troy_s
Easiest test would be to do the following:
14:30
intracube
apparently players often have an option to send RGB or YCbCr over HDMI which could eliminate the shogun doing any rescaling?
14:30
intracube
troy_s: if you're feeding the Shogun an RGB signal, by definition it has to convert to YCbCr and scale down the chroma channels, right?
14:30
Bertl
intracube: don't have either, but maybe somebody else does
14:30
troy_s
A) Send the RGB to the unit and pull the YCbCr raw planes from the resultant file.
14:31
intracube
and the downscaling could introduce some edge-ringing/sharpening?
14:31
troy_s
B) Manually perform an RGB to YCbCr transform via OCIO and feed that to FFMPEG using the same encoding level. Compare.
14:31
troy_s
intracube: Where would there be down sampling?
14:31
intracube
CbCr are not at full res
14:32
intracube
(4:2:2)
14:32
troy_s
Wait, are you telling me?
14:32
troy_s
LOL
14:32
intracube
isn't sure why you asked
14:32
troy_s
My point would be that this is all voodoo guesswork until we stop the madness.
14:32
intracube
:P
14:32
troy_s
It really isn't that tricky.
14:33
intracube
just hit the ball back regardless
14:33
troy_s
We should be evaluating anything the recorders do based _strictly_ on the YCbCr streams which will be bitwise exact to what they encoded to.
14:34
troy_s
The ProRes encodes aren't nearly as all-over-the-map either, so once the ProRes level is deduced (hq?)
14:34
troy_s
A comparison could be done at the YCbCr level on each plane against a similar encode via FFMPEG.
14:35
troy_s
As a final notch of testing, a decode can be done using straight LERP on the Cb/Cr and an OCIO transform at 32 bit float per channel. (It is literally a single spimtx transform)
14:36
Bertl
I refuse to further discuss the "bitwise exact" topic :)
14:36
troy_s
Bertl: Bitwise exact being the bitstream.
14:36
Bertl
there is no bitstream. period.
14:37
troy_s
As in _all_ decoders will be looking at that precise exact series of bits.
14:37
troy_s
Period.
14:37
troy_s
Whereas likewise, there is a zero chance that _any_ decoder will deliver RGB values at that same level.
14:37
troy_s
Sense?
14:38
troy_s
All that really matters is that the YCbCr matches or isn't doing anything too funk.
14:38
troy_s
The rest is what it is (compression)
14:39
Bertl
RGB-444-full -> [backbox aka. shogun] -> RGB-444-full
14:39
tezburma
left the channel
14:39
Bertl
the blackbox further can be broken down into:
14:40
troy_s
No.
14:40
Bertl
[ProRes Encoder (shogun)] -> [ProRes Decoder (ffmpeg, adobe)]
14:40
troy_s
RGB full to YCbCr 444 full.
14:40
troy_s
That is my point!
14:40
troy_s
_That_ is what needs to be analyzed.
14:40
troy_s
No speculation.
14:41
troy_s
The _only_ black box there is the encode to YCbCr, which because of ProRes, isn't nearly as randomly guessy.
14:41
troy_s
The "decode" isn't nearly as complex as it seems.
14:42
troy_s
And, again, given the nature of the codec, we can be rather certain that the YCbCr streams handed to whatever output context is quite precise.
14:42
Bertl
the ProRes Encoding part (shogun) consists of a) Color Space Conversion, b) Color Space Decimation, c) Lossy Compression and d) Actual Encoding
14:42
troy_s
Whereas if you try to do this based on yet another YCbCr to RGB conversion, you are pursuing a fool's errand.
14:43
troy_s
The decimation is quantization only.
14:43
troy_s
But again, my point is
14:43
Bertl
nope
14:43
troy_s
It will be virtually the same across most encoders
14:43
Bertl
IIRC, the shogun record YCbCr 422
14:43
troy_s
Super.
14:43
Bertl
*records
14:44
troy_s
Why is that relevant? Isn't the goal to spot funk? (Also, there is a Shogun that can do 444 no?)
14:44
Bertl
that's what I'm trying to say, there is nothing "bitwise identical" anywhere
14:44
troy_s
(Pehraps they only planned it)
14:45
troy_s
You are misreading what I was saying
14:45
troy_s
Bitwise exact means the streams are exact as fed to decoders
14:45
troy_s
(Been over this with MN a few times, and I am reasonably faithful in his judgement)
14:45
Bertl
I still have no clue what you are trying to say with that
14:45
troy_s
God.
14:45
troy_s
Look...
14:45
Bertl
looks
14:45
troy_s
If you and I evaluate RGB footage
14:46
troy_s
Based on an RGB to YCbCr to RGB transform series
14:46
troy_s
There is exactly _zero_ chance that either of us is doing anything meaningful.
14:46
alexML
troy_s: I found the ffmpeg commands, now waiting for the movie; until then, I just analyzed what I had
14:46
troy_s
Whereas if we cut off that last unnecessary RGB transform
14:46
troy_s
We can be absolutely _certain_ that if you and I are using that same exact source, we are looking at precisely the same values.
14:47
troy_s
Hence bitwise exact.
14:47
Bertl
okay, let's go that route for entertainment
14:47
troy_s
To reiterate:
14:47
Bertl
we produce an RGB 444 full test image
14:47
troy_s
If we add on that final RGB transform, there is zero chance.
14:47
Bertl
we record it to ProRes
14:47
Bertl
we then decode it to YCbCr-444
14:47
Bertl
now what?
14:47
troy_s
Wait
14:48
troy_s
How?
14:48
Bertl
what how?
14:48
troy_s
alexML: Great. It is relatively easy.
14:48
troy_s
Bertl: I am saying that if you and I are handed a file.
14:48
Bertl
a ProRes recording
14:49
troy_s
We can _both_ be very sure that the bitstream is giving us exactly the same bits in the YCbCr stream
14:49
troy_s
If we instead do something foolish and decode that back to RGB
14:49
se6astian
gotta go
14:49
troy_s
There is exactly zero chance we will be looking at the same values.
14:49
se6astian
changed nick to: se6astian|away
14:49
alexML
troy_s is right; instead of one black box (the ProRes), we had 3
14:49
troy_s
_that_ is what I have been trying to make clear from the start; do the evaluations on the YCbCr bitstreams, and nothing else.
14:50
troy_s
alexML: Exsctly!
14:50
Bertl
well, I'm pretty sure there are different decoders out there as well, although I agree that the output (probably regardless of the actual format) should be identical
14:50
troy_s
alexML: Worse, that last one is a massive black box of complexity that I can't begin to even say.
14:50
alexML
or actually 4
14:50
troy_s
Bertl: It will be.
14:50
troy_s
Put it this way
14:50
troy_s
I can say beyond certaibty
14:50
troy_s
For example
14:50
Bertl
but how does that help us?
14:51
troy_s
If you and I are basing our judgements on say, a browser decode (I know we wouldn't)
14:51
pusle
left the channel
14:51
troy_s
Did you know that a browser decode might be different based on whether or not it is full screen?
14:51
troy_s
Yeah that is how flakey the decoding landscape is.
14:51
Bertl
I would presume so
14:52
troy_s
(GPU frequently gets handed the YCbCr streams and they will take alternate code paths (frequently wrong) compared to the software implementation (frequently wrong)
14:52
troy_s
So my sole point us that decoding is a freaking mess. Total, unadulterated, mess.
14:52
tezburma
joined the channel
14:52
troy_s
So be eliminating that entirely, we are dealing with constants and that helps us tremendously.
14:52
Bertl
so is encoding :)
14:52
troy_s
But encoding isn't quite that random in truth.
14:53
troy_s
There are certainly variations etc, but the flags in the file etc. or the raw bitstream can't lie; it is what it is.
14:53
Bertl
have you looked at jpeg?
14:53
troy_s
Yes. I understand your concern. Totally.
14:53
alexML
why it helps: these extra 3 black boxes (gamma on our side, RGB->YCbCr on the recorder, and YCbCr->RGB on the decoding software) are not lossless transformations
14:53
troy_s
But where we _were_ was looking at RGB, which is plain and simple a fool's errand.
14:54
Bertl
you can create a million (actually way more) different jpeg files from one source
14:54
troy_s
I know.
14:54
troy_s
I get that.
14:54
Bertl
and that is not even by changing the quality
14:54
troy_s
We have limitations. We all agree.
14:54
alexML
and there's scaling from 16-235 to 0-255 as well (most likely on the last black box)
14:54
troy_s
alexML: That is the scaling I said yesterday
14:55
troy_s
That is _mandatory_ to call yourself "709" or "240m" etc.
14:55
pusle
joined the channel
14:55
troy_s
It should be 16-235 for Y', and 16-240 Cb' Cr'.
14:55
troy_s
But that is all very simply done via a single matrix transform in OCIO because they have offsets.
14:55
alexML
so probably the clipping is applied after RGB->YCbCr
14:55
troy_s
I have a file transform if you would like to test in a float environment.
14:56
alexML
(in my simulation, I applied it on RGB)
14:56
troy_s
No clipping. Quantization only.
14:56
alexML
troy_s: RGB values below 16 and above 235 got clipped
14:56
troy_s
There should be no clipping, hence I suggest doing so at float quantization.
14:56
troy_s
Nope.
14:56
alexML
(look at the images)
14:56
troy_s
Bad encode.
14:56
troy_s
Wrong flags.
14:56
troy_s
;)
14:57
troy_s
You have to pass a flag when encoding, and this is also up for grabs now thanks to Canon.
14:57
alexML
how do you pass flags on the Shogun?
14:57
alexML
sebastian told me he only had options to select the codec
14:57
troy_s
Don't know.
14:58
troy_s
If you are passing it along YCbCr the stream must always be broadcast scaled.
14:58
alexML
yes, and if it's not, what happens?
14:58
alexML
will the encoder explode?
14:58
troy_s
If RGB, it _should not_ be mapping 240ish to 240ish. That is wrong.
14:58
alexML
or, more likely, it will just clip the values that are out of range?
14:58
troy_s
Nope.
14:58
troy_s
It will just chop, which is a mangled encode.
14:58
alexML
right
14:58
alexML
that's what it did here
14:59
troy_s
Proper encode maps 0-255 to the YCbCr broadcast scaled values
14:59
troy_s
Decode maps back.
14:59
troy_s
That issue is _extremely_ common.
14:59
troy_s
Ask intracube - he spots mangled encodes at YouTube like an eagle.
14:59
troy_s
Remember too that the same mangling can happen on decode.
15:00
alexML
makes sense; in octave, rgb2ycbcr maps 0-255 to 16-235/16-240 and back to 0-255
15:00
troy_s
A proper and correct round trip should deliver 1:1 on the 0 and 255 values
15:00
troy_s
With some quantization at the extrema.
15:00
troy_s
alexML: So factor in this:
15:01
troy_s
A) Proper specification based scaled values.
15:01
troy_s
B) Proper specification based "full range" (1-254 IIRC)
15:01
troy_s
C) DSLR mangled "full range" (0-255)
15:01
troy_s
E) Coefficient mangling (601 vs 709)
15:02
troy_s
(Or others!)
15:02
troy_s
Now do that mangling once on encode
15:02
troy_s
And then do it again on decode
15:02
troy_s
Oh
15:02
troy_s
And, to make it worse
15:02
troy_s
Factor in exactly TWO code paths
15:02
troy_s
One for CPU and the application's mangling
15:03
troy_s
And one for GPU and the application's mangling smashed into the video card acceleration
15:03
troy_s
Smashed into any number of video cards.
15:03
troy_s
Now tell me how many variations we have.
15:03
troy_s
LMAO
15:03
troy_s
It is a total mess.
15:04
troy_s
In most higher end imaging systems that deal with codecs, there is _very_ granular control and overrides on this such that you can be certain that your bitstream is being decoded precisely as you choose.
15:05
troy_s
Finally, note that the quantization reference space matters; many decoders are doing it at that buffer depth, which adds to poor decodes.
15:13
tezburma
left the channel
15:43
intracube
changed nick to: intracube_
15:55
darthrak_
joined the channel
16:00
darthrak_
left the channel
16:05
davidak
joined the channel
16:33
Bertl
off for now ... bbl
16:33
Bertl
changed nick to: Bertl_oO
16:48
LordVan
joined the channel
16:50
troy_s
alexML: Any progress?
16:54
alexML
no, waiting for the original movie file (and even then, I can get rid of only one black box - the one at the end of the chain)
16:55
alexML
there was also a gamma correction (I identified the value, but not the exact implementation, how the rounding was done, etc) - so let's call that a gray box
16:56
alexML
and the RGB -> YCbCr that happen on the recorder, for which I think I've identified the clipping behavior (which you say it shouldn't be done)
16:57
alexML
I can't get rid of those myself without camera and source code
16:57
alexML
so, until then, I'm just looking at all those black boxes together
16:59
alexML
and that was the point of my experiment on the wiki - an algorithm (well, a plain old FIR filter) that attempts to undo some of the effects of some black box (and I tested that algorithm on different known boxes)
17:15
troy_s
alexML: great idea
17:15
troy_s
alexML: What do you mean 'original movie file'? The input fed or ?
17:17
alexML
the movie file from the recorder
17:17
alexML
I only have 8-bit TIFs right now
17:17
troy_s
alexML: If the original Shogun was fed a codec of sorts, then that's another issue entirely. That is where you'd see the botched scaling mangling appearing. If it was fed literal RGB values, then there would be a setting somewhere on the encoder to honor the fully range RGB (which it should by default, as there is technically no real way to scale RGB ready
17:17
troy_s
for YCbCr as the scale is distributed across the three planes differently (Y to the Cb/Cr) which means there is no uniform scale for the RGB.
17:17
troy_s
Ah.
17:17
troy_s
Ok.
17:17
alexML
converted with some Adobe software, I think
17:17
troy_s
alexML: That is interesting.
17:18
troy_s
alexML: So here's a hypothesis then...
17:18
alexML
I have the memory dumps used to feed the shogun
17:18
alexML
BUT...
17:18
troy_s
alexML: How do they look?
17:18
alexML
I've identified a gamma correction applied to those dumps before feeding
17:18
troy_s
alexML: What do you mean by "gamma correction" exactly?
17:18
alexML
most likely Bertl forgot to tell me about it
17:18
alexML
scroll up
17:18
troy_s
(hate the term gamma. awful)
17:19
alexML
to get a linear transfer curve, I had to do ((x/255)^0.8)*255 on the memory dumps
17:19
troy_s
Can't see any discussions of gamma.
17:19
troy_s
Why 0.8????
17:19
troy_s
Technically, I'd not do any conversions on anything as RGB in is RGB out (minus the massive discussion we had)
17:20
alexML
that's what appeared to fit the data
17:20
troy_s
That is, no matter what the coefficients etc., as long as the encode is done "correctly" and the decode is done "correctly" (again all caveats about quantization, compression, etc. aside) the RGB values are 1:1 (again, please please please do not mistake that for meaning 'lossless' etc.)
17:21
alexML
I wouldn't do it either, but looks like the guys who did the experiment forgot it enabled or something
17:21
troy_s
Od.
17:21
troy_s
Anyways, you shouldn't need to correct it either.
17:21
alexML
(I'm just interpreting the files I've already got)
17:22
troy_s
I hear you.
17:22
troy_s
What are you considering it "should be"?
17:22
troy_s
(as in why is there an adjustment being made on the transfer in the first place?)
17:23
alexML
maybe it was unintentional, idk
17:24
alexML
but after applying this correction, I've got a nice transfer curve that clips at 16 and 235
17:24
alexML
a bit too much for a coincidence :P
17:26
alexML
and the overall brightness in all 3 channels match the output from the tif's pretty well after I apply this scaling and gamma to the input data
17:27
troy_s
I am not certain, but I don't believe the broadcast scale would end up uniform across the 235 range, but I'd need to check the math.
17:28
troy_s
I'd expect it to be nonuniformly distributed.
17:29
troy_s
(Perhaps not because it _is_ the luminance weights after all, and the 235 broadcast scale is on the Y)
17:29
troy_s
alexML: So I guess you are looking at the RGB output and trying to figure out what is what?
17:30
troy_s
alexML: If that is the case, I'd not read too much into it because that could easily be a botched decode.
17:30
troy_s
(doubly more likely if you are seeing chopped RGB values, which tells us that the decoder didn't check a flag or it was overridden.)
17:33
alexML
for decoding, we compared both Adobe and ffmpeg on a different test file (a resolution chart) and found only minor differences (not obvious when watching the images)
17:33
alexML
so I doubt the artifacts I'm looking at are from the decoder
17:34
alexML
and I've also fed the (gamma-corrected and 16-235-corrected) input data to ffmpeg prores, and the artifacts are much less obvious
17:35
troy_s
alexML: Could very well be the decoder if a flag isn't set.
17:35
alexML
even with prores proxy (strongest compression), the artifacts aren't that bad as on the hdmi recorder
17:35
troy_s
alexML: WRT this, the fullrange flag.
17:35
troy_s
You shouldn't feed anything "corrected" to FFMPEG or an encoder.
17:35
troy_s
That's wrong.
17:36
alexML
well, I believe that was the closest approximation of the data sent to the HDMI recorder
17:36
alexML
so I fed that to ffmpeg
17:36
troy_s
That's part of the problem then.
17:36
troy_s
You never futz anything when sending it to an encoder.
17:36
troy_s
The encoder should understand that what you are feeding it is RGB, and in particular, sRGB.
17:36
alexML
I know, we should ask the guys to repeat the experiment
17:37
troy_s
If the encoder is only grabbing a limited "scaled" range, then something is _totally_ whack.
17:37
troy_s
(Granted I am unsure how that data is even fed to the Shogun at this point,.)
17:38
troy_s
If it is fed along an HDMI port, FSM knows it is going to be Mr. Toad's Wild Ride.
17:42
troy_s
OMFG http://www.bhphotovideo.com/c/search?Ntt=sony+a6300&N=0&InitialSearch=yes&sts=ma&Top+Nav-Search=
17:43
gnufan
joined the channel
17:52
GrahamM
joined the channel
17:56
darthrak_
joined the channel
18:00
darthrak_
left the channel
18:11
se6astian|away
changed nick to: se6astian
18:43
se6astian
changed nick to: se6astian|away
18:54
se6astian|away
changed nick to: se6astian
18:59
jucar
joined the channel
19:13
comradekingu
comradek
19:13
comradekingu
did anyone know how to pay the full amount all at once?
19:17
GrahamM
Email sebastian.
19:20
se6astian
hi comradekingu
19:20
se6astian
yes email me :)
19:20
se6astian
its possible and I will instruct you how to do it
19:21
comradekingu
thanks, writing another one now :)
19:24
comradekingu
done and dids
19:43
se6astian
perfect
19:43
se6astian
will reply shortly
19:50
LordVan
prefers libav to ffmpeg ^ ^
20:09
troy_s
LordVan: You are drunk.
20:09
LordVan
nah
20:09
LordVan
;)
20:09
troy_s
Yah
20:09
troy_s
As someone that has looked at the code, you aren't even in the same timezone
20:09
troy_s
LibAv is a joke.
20:10
LordVan
and ffmpeg carries around lots of old crap ^ ^
20:11
troy_s
Wait. So mangled colour decoding (aka the pixels you are looking at) take a lower precedence than "cleaning up old crap"
20:11
troy_s
I get it.
20:11
troy_s
You are one of those astronaut types.
20:11
troy_s
Copy.
20:11
LordVan
lol
20:12
LordVan
i don't have any problems with libav for what I use it for ^ ^
20:12
troy_s
Great.
20:12
troy_s
You clearly don't use it for imaging.
20:12
troy_s
I get that.
20:12
LordVan
which is mostly processing stuff from DVB-s
20:12
LordVan
and my camcorder
20:12
LordVan
i mostly just re-encode ;)
20:12
troy_s
You'll have to have faith when I say it is doing it wrong.
20:12
troy_s
Or not.
20:13
troy_s
It uses _really_ old FFMPEG code that MN cleaned up a couple of years ago.
20:13
troy_s
(That was in FFMBC for a long while, albeit via a different path)
20:13
troy_s
If you are at all keen on imaging, LibAv is as far away from useful as you can get regarding proper decoding.
20:14
LordVan
i did swap quite a while back from ffmpeg to libav because i had problems with ffmpeg . as long as libav works for me i don'T see much reason to swap back ;)
20:14
troy_s
Great. But that would also imply that your "preference" is a broken decode, which I can't advise anyone to do.
20:14
LordVan
(which is not to say you are wrong or aynthing ;)
20:15
LordVan
just the usual works4me
20:15
troy_s
Hence my even caring about a preference. Folks in this channel may be misled.
20:15
LordVan
^^
20:15
troy_s
We are currently going through _exactly_ some of the problems with encoding / decoding here (scroll up) and little goofy libraries that do crap wrong are part of the problem.
20:16
LordVan
yeah seen that
20:16
LordVan
- don't worry i'm not going to try to convert anyone ;)
20:17
LordVan
nor do i intend to advertise
20:49
jucar
left the channel
21:12
LordVan
left the channel
21:14
darthrak_
joined the channel
21:14
darthrak_
left the channel
21:27
se6astian
off to bed
21:27
se6astian
changed nick to: se6astian|away
21:59
comradekingu
The voucher number i got from se6astian had expired, can someone pm me an updated one?
22:00
comradekingu
Were voucher-numbers ever sent out as individual emails?
22:38
gnufan
left the channel