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