Current Server Time: 19:47 (Central Europe)

#apertus IRC Channel Logs

2013/07/03

Timezone: UTC


23:00
Bertl
vfx = video effects?
23:00
dmj_nova
yes
23:00
dmj_nova
helps with chroma keying
23:00
dmj_nova
though with good lighting you can get good masks out of much less than 4:4:4
23:01
se6astian
4:4:4 is luxury :)
23:01
se6astian
tv broadcast has for decades relied on 4:2:2 footage acquisition
23:03
dmj_nova
I'm using a DSLR. so yeah, I don't have 4:4:4
23:05
dmj_nova
se6astian: what do you think of the idea of performing a detail reducing step before doing lossless encoding in cases where the image exceeds a certain size?
23:06
dmj_nova
rather than doing strictly lossy compression
23:08
dmj_nova
that way you do get strictly lossless compression when below the bitrate
23:08
Bertl
like dropping every second pixel/frame when the bandwidth is exceeded?
23:08
dmj_nova
not dropping resolution
23:08
dmj_nova
more like a smoothing filter
23:09
dmj_nova
something that would filter out graininess/noise primarily with the benefit of reducing encoding size
23:10
Bertl
in some way, that's what jpeg/wavelet encoding does, but this means lossy compression after all
23:10
dmj_nova
right, I do mean that it would be lossy
23:10
dmj_nova
but the alternative is to always use lossy compression
23:11
dmj_nova
or switch between compression schemes mid recording
23:11
dmj_nova
the first requires handling the case where the image is pure noise and cannot compress
23:11
Bertl
there is a lossless jpeg standard, btw :)
23:12
dmj_nova
really?
23:13
Bertl
yes, several actually: http://en.wikipedia.org/wiki/Lossless_JPEG
23:14
Bertl
I think we should consider two kind of data sinks, those used for instant viewing and those used for recording
23:14
dmj_nova
ah, looks like the lossless mode in actual jpeg is a separate mode
23:15
dmj_nova
Bertl: I'm also thinking about this from the perspective of nonlinear video editors and asset management libraries atm
23:15
Bertl
the viewing sinks should be happy with lossy compression all the time, as long as it looks good
23:16
Bertl
the recording/processing/effect/whatever sinks should get raw data
23:17
Bertl
and I don't think we should try to compress any of the raw data beyond the obvious bpp values
23:17
dmj_nova
One reason I'm hoping we can keep the bitrate down (and have a guarantee of this) is that the more data we have, the more data we would have to have hardware to hash for identification/verification
23:17
Bertl
please elaborate
23:18
dmj_nova
Bertl: So I'm part of a project called Novacut
23:18
Bertl
I've heard :)
23:18
dmj_nova
And we have an import system that's been designed to make the on set workflow easier and less error prone
23:19
Bertl
okay, sounds good
23:19
dmj_nova
Dmedia uses the skein hash value of the files to locate them
23:20
dmj_nova
This is good because it means you can always tell when you have perfect copies and where things went wrong and correct as long as you have multiple copies
23:20
Bertl
overkill, but yeah, I like bruce too :)
23:21
dmj_nova
With the openness of Apertus, it should be possible to have files imported already in-camera
23:22
dmj_nova
which removes one more step and eliminates some of the issues of bad flash media or readers
23:23
Bertl
skein (and similar hashes) can be implemented in hardware
23:23
dmj_nova
(Yes, Dmedia has actually identified bad readers and cards for us)
23:23
dmj_nova
Bertl: Yes, it can
23:23
Bertl
i.e. the PL can produce a hash per block or over an entire recording
23:24
dmj_nova
I am a little worried as to whether we will have enough PL units to hash at 1.35 GBPS
23:25
dmj_nova
which is what the calculation seemed to show we would need for recording 4k at max framerate
23:25
dmj_nova
assuming complete noise
23:26
Bertl
and you think that would get better if we add compression to the PL?
23:26
dmj_nova
We could get away with a much smaller hashing unit if the data rate were lower
23:26
Bertl
putting that aside, I think any hash would be a lot better than none at all
23:27
dmj_nova
Well, the reason I'm suggesting actually using the skein hash right away is so you don't have any temporary id nonsense
23:27
Bertl
i.e. in case the skein eats up the fabric, we could replace it by something simpler, no?
23:27
dmj_nova
ie: its name changes later and you have to hash again
23:28
se6astian
I think any compression method will require severe testing and evaluation, lossless and especially lossy, something we don't need to deal with right away
23:28
dmj_nova
certainly it will require testing and tweaking
23:28
se6astian
switching modes with every frame can lead to all kinds of potential new problems
23:29
dmj_nova
se6astian: yes, which is why I suggested a single mode for encoding
23:29
dmj_nova
with an optional filter before that stage
23:31
dmj_nova
se6astian: the sensor reports integer or floating data?
23:31
se6astian
integer
23:31
se6astian
12 bit
23:31
Bertl
www.schneier.com/skein_fpga.pdfâ
23:31
Bertl
this says, we have no chance to make it work in realtime :)
23:33
se6astian
sorry, time for bed for me
23:34
Bertl
we can probably do realtime sha-2
23:35
dmj_nova
Bertl: not at 1.35 GBps
23:36
dmj_nova
Bertl: skein is actually pretty fast (at least in some cases)
23:36
Bertl
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.4568&rep=rep1&type=pdf
23:36
se6astian
can we take any shortcuts, like using the histogram of each image instead of the image itself as basis for hashing?
23:37
Bertl
that's just another hash
23:37
se6astian
but much less data to crunch
23:37
Bertl
so basically it boils down to having a fast hash algo which works sufficiently well for the purpose
23:37
se6astian
anyway, I dont really know what I am talking about... got to go, lets continue this tomorrow :)
23:37
se6astian
good night!
23:37
Bertl
have a good one!
23:37
se6astian
left the channel
23:39
Bertl
dmj_nova: what about using a fast hash per frame and hashing the hashes per recording?
23:40
Bertl
more something like a crc checksum over the frame
23:40
Bertl
which would actually guarantee that there is no dataloss
23:41
Bertl
those checksums could then be hashed e.g. with skein to produce the actual hash
23:42
dmj_nova
the problem becomes the way in which that would make dmedia-based systems prone to error
23:43
dmj_nova
because of the way naming would change over time
23:45
dmj_nova
which means any system dealing with it before the import would have a different name/storage location than anything after import
23:46
Bertl
how so? not sure I understand the problem
23:46
dmj_nova
Which is why I suggested the "lossless under certain data rate" method
23:46
dmj_nova
for dmedia to work with it (and apps built on dmedia) you do have to hash the actual file with skein
23:47
dmj_nova
making an exception for apertus files breaks assumptions dmedia makes regarding data safety
23:48
Bertl
well, I think adding something like a crc/hash combo to dmedia would only be beneficial
23:49
Bertl
I don't think folks like it that the hash algorithm takes several hours :)
23:49
dmj_nova
A quad core i7 could hash at 1.35 GBPS easy
23:49
Bertl
I'm not saying that the proposed crc/hash is the best solution to the problem, but at least it sounds like a good solution
23:50
dmj_nova
on PCs we're actually IO limited
23:50
Bertl
still means that it is barely realtime, no?
23:50
dmj_nova
If I recall correctly, that was also at 120 fps
23:50
Bertl
(for raw data)
23:51
dmj_nova
strangely we actually import faster than file transfers in nautilus
23:51
Bertl
anyway, we won't be able to solve that problem without either adding specialized high speed hashing hardware (somewhere in the queue) or improving the hash concept
23:52
Bertl
let me play the devil's advocate and ask: what is the benefit of skein over the entire file compare to e.g. skein over a crc added for each frame?
23:52
Bertl
(again, not saying that is the solution)
23:53
dmj_nova
my guess is a combination of optimizing the encoding/high-speed-skein will work well
23:53
dmj_nova
it's the way dmedia locates files
23:53
dmj_nova
and why we can do things in a much more distributed way
23:53
Bertl
yeah, well, bad choice :)
23:54
dmj_nova
skein is actually really good in a number of ways, even over keccak
23:54
Bertl
yeah, but it sucks performance wise compared to crc for example
23:55
Bertl
which actually does a really good job in ensuring that the data is intact
23:57
Bertl
don't get me wrong, I'm all for a neat skein PL core which does it in realtime, but you have to code it with probably limited cells (like 4-6k)
23:59
dmj_nova
left the channel
05:56
dmj_nova
joined the channel
06:00
dmj_nova
Bertl: Looking at things, I'm also suspecting we can't sustain data rates of pure raw anyway
07:45
se6astian
joined the channel
08:07
se6astian
good morning
08:46
dmj_nova
morning se6astian
08:48
dmj_nova
se6astian: So I'm kinda starting to wonder whether unconditionally lossless is that viable
08:48
dmj_nova
(barring several SSDs attached at once)
10:05
se6astian
sorry, was afk, back now
10:06
se6astian
why not, uncompressed guarantees highest possible quality and lowest development effort
10:08
se6astian
SSDs are fast, available and becoming more and more affordable
10:19
dmj_nova
http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/Aug2010/documents/papers/WALKER_skein-intel-hwd.pdf
10:19
dmj_nova
se6astian: I'm actually kinda waffling on the idea atm
10:20
dmj_nova
looking at what's done right now
10:20
dmj_nova
looks like the maximum data rate we can achieve is 4.247 GBps
10:21
dmj_nova
(12MP*1.5bytes*3colors/pixel)*75fps
10:23
dmj_nova
which means a 512 GB disk would store 2 minutes of footage
10:38
dmj_nova
se6astian: do you know how the zync compares with virtex5?
10:57
se6astian
if we save uncompressed raw we only have one color not 3
10:57
se6astian
let me look up the fpga specs one sec
10:58
dmj_nova
se6astian: wait, what?
10:59
dmj_nova
is the sensor only 2048 bayer paterns wide?
11:00
se6astian
zynq: http://www.xilinx.com/publications/prod_mktg/zynq7000/Zynq-7000-combined-product-table.pdf
11:00
se6astian
virtex5: http://www.xilinx.com/support/documentation/data_sheets/ds100.pdf
11:00
se6astian
its not a real comparison chart but maybe it helps to start research
11:01
se6astian
what do you mean with "bayer patterns"? the sensor has 4096x3072 photosites
11:01
dmj_nova
ah, and 4 photosites -> 1 pixel
11:03
se6astian
in our prototype RGB image creation method yes
11:03
se6astian
but not in general
11:03
dmj_nova
is there any way that it doesn't?
11:05
se6astian
how do you mean?
11:06
dmj_nova
I'm curious how you would get more than 1 color pixel worth of detail
11:06
dmj_nova
(I may be missing something)
11:09
se6astian
http://en.wikipedia.org/wiki/Demosaicing
11:09
se6astian
our method is actually a workaround not a full demosaicing algorithmn
11:14
dmj_nova
hmm, is it typical for "4k" cameras to actually be 2k bayer patterns wide?
11:15
se6astian
I think there is a misunderstanding :)
11:17
dmj_nova
by bayer pattern I mean "the 2x2 photosite region with 2 green, 1 blue, and 1 red"
11:18
dmj_nova
se6astian: there may be :)
11:19
se6astian
our bayer pattern sensor has 4096x3072 monochrome photosites and a color filter array (CFA) on top of them
11:19
dmj_nova
yes
11:20
se6astian
demosaicing in the process of interpolating color into every pixel -> 4096x3072 RGB pixels
11:20
dmj_nova
I was just wondering if other cameras measured 4k the same way
11:20
se6astian
if they use a bayer pattern yes
11:20
se6astian
foveon sensors stack R, G and B on top of each other
11:21
se6astian
and add up the pixels
11:21
dmj_nova
se6astian: so most "4k" cameras actually produce something between 2k and 4k "real" pixels
11:21
se6astian
so a 1920x1080 foveon sensor advertizes to have 6,220,800 pixels
11:22
se6astian
good demosaicing algorithms can restore 100% of the luma and 80% of the chroma information
11:23
dmj_nova
and yes, I know my nyquist criterion and you can't actually restore all your information
11:23
dmj_nova
though you can produce educated guesses that look better than not
11:23
se6astian
at first sony claimed everyone was counting pixels wrong and their F65 sensor actually has 4096 x RGB pixels
11:24
se6astian
http://library.creativecow.net/galt_john/John_Galt_2K_4K_Truth_About_Pixels/1
11:24
dmj_nova
and then they called it an "8k" camera, right?
11:24
se6astian
yes ;)
11:25
se6astian
so I would say the photosites=pixels method of counting has now been adopted by the industry
11:25
dmj_nova
yeah, I guess it just tripped me up because I do video processing and vfx
11:25
se6astian
so by saving our footage as raw we actually reduce the data to a 1/3rd of what the RGB image would be
11:26
se6astian
basically raw = monochrome
11:29
dmj_nova
of course these cameras still beat digital "IMAX"
11:29
dmj_nova
in terms of resolution
11:31
se6astian
I guess depending on who you ask that we can spend a couple of days here arguing ;)
11:32
dmj_nova
se6astian: I like to poke at digital IMAX resolution because they mandated 2k projectors
11:32
se6astian
Ron Fricke for example shot http://www.imdb.com/title/tt0770802/ entirely on 70mm film because he says its the only medium that can capture this amount of details/color
11:32
dmj_nova
...which at that size means I can discern a screen door effect :{
11:33
se6astian
I saw samsara in a 4K projected theatre and wasn't THAT amazed by the sharpness, but it was still amazing
11:33
dmj_nova
wonder if Samsara will be at ebertfest next year...that would be cool
11:34
dmj_nova
(they do have a 70mm projector that doesn't get much use)
11:34
se6astian
nice ;)
11:34
dmj_nova
Actually I just saw close encounters of the third kind in 35mm on friday
11:37
dmj_nova
that was awe-inspiring
11:40
se6astian
great, bbs - time for lunch
11:56
se6astian
back
11:56
se6astian
but need to bring some packets to the post office
11:56
se6astian
be back soon
11:56
se6astian
changed nick to: sebastian|afk
12:00
dmj_nova
okay, so the theoretical maximum data we could ever have to output is 2.4 GB/s
12:00
dmj_nova
the sensor literally cannot do any more than that
12:00
sebastian|afk
left the channel
12:01
dmj_nova
typical framerates (aka, not 150 fps at 10 bit) will be lower
12:03
dmj_nova
and in 12 bit mode, it's only a maximum of 1.4 GB/s
12:03
dmj_nova
plus (not that we can count on this) apparently lossless DNG will get us on average 2.5x compression
12:05
Bertl
morning everyone!
12:05
dmj_nova
for typical footage, that would put us at about 200 MB/s on average
12:05
dmj_nova
morning Bertl
12:05
dmj_nova
Bertl: so boy was I calculating bitrates wrong
12:08
dmj_nova
Bertl: So one possible solution to the storage/bitrate problem would be to log all the metadata and the file in a separate location and then hash it later if the hashing unit falls behind
12:08
dmj_nova
and have it show up in the dmedia filestore a bit late
12:11
Bertl
that's basically fine, but in this case, you already break the chain of guaranteed data
12:11
Bertl
i.e. you cannot tell if the data got corrupted between acquisition and hashing
12:11
Bertl
(just saying)
12:12
dmj_nova
Bertl: yeah, it breaks that
12:12
Bertl
(which wouldn't be the case with crc/hash :)
12:12
dmj_nova
But only in the rare case you can't keep up
12:13
dmj_nova
I suppose you could have both a crc and a skein unit
12:13
Bertl
let's postpone this until you finished the 2.5GB/s skein
12:13
dmj_nova
not sure if crc is super dead simple
12:13
Bertl
yeah, it is
12:13
dmj_nova
Bertl: https://plus.google.com/114471118004229223857/posts/H6eV35rEek2
12:13
dmj_nova
hash performance on single core of intel processor
12:13
Bertl
the thing is, the skein 'process' is like 6 stages, and 72 iterations
12:14
Bertl
while a reasonable crc can be done in 1 stage and one iteration
12:14
dmj_nova
a crc would protect against random bit corruption
12:14
Bertl
that's like 1/6th of the cells and 1/72th of the time
12:15
Bertl
it would not protect, but it would identify those
12:16
dmj_nova
Bertl: sorry, I used the wrong word
12:16
Bertl
no problem
12:16
dmj_nova
but yes, it would identify them (and protect if storing to two locations at once)
12:17
dmj_nova
in the case of dmedia our hashing does actually protect against random corruption due to the storage of three copies when possible
12:17
dmj_nova
because we can know which is the correct one
12:17
dmj_nova
On the camera itself, the bigger issue is random corruption
12:17
Bertl
yes, all I'm saying was that crc+hash would also have those properties
12:18
dmj_nova
Once you start passing that data to other devices and uses, one needs to consider security, which skein does a better job of
12:18
Bertl
i.e. it would efficiently protect against random corruption
12:18
Bertl
I totally agree, that if you want to prevent tampering of the data, a full skein is the way to go
12:19
Bertl
I'm just arguing for the data corruption part
12:19
dmj_nova
and that's why novacut uses skein for naming and locating files
12:21
dmj_nova
Once the files are hashed, dmedia can know about them globally, and people can start logging, editing, processing them
12:22
dmj_nova
and if you manage that in realtime, it opens other doors
12:23
dmj_nova
opens up new workflows for Axiom
12:24
dmj_nova
things that can't be done with Canon
12:24
dmj_nova
(well not in unhacky, horrible ways that degrade quality anyway)
12:25
dmj_nova
but yeah, I'm suspecting that 2.4 GB/s skein will not fit on a 7030
12:26
dmj_nova
anyway, this is a touch theoretical at this point
12:26
dmj_nova
but at least we have a better idea of what to expect datarate wise
12:26
Bertl
it probably would have to fit on a quarter of 7030 or less
12:27
dmj_nova
Bertl: yes, I've been figuring on not having the whole space
12:27
dmj_nova
how much is your work so far taking
12:29
Bertl
the examples I've done so far use up negligible space
12:29
Bertl
I expect that we need a lot more for effects and things like overlay or high speed data routing
12:30
Bertl
and with 'effects' I mean image preprocessing
12:31
Bertl
like for example removing bad pixels, debayering, etc
12:32
Bertl
Number of Slice Registers: 424 out of 106,400 1%
12:32
dmj_nova
huh
12:32
Bertl
Number of Slice LUTs: 555 out of 53,200 1%
12:32
Bertl
Number used as Memory: 0 out of 17,400 0%
12:32
Bertl
that was the latest example usage
12:33
dmj_nova
so given one implementation (there could be better, I'm sure), one quarter area would give 270MB/s
12:34
dmj_nova
and that was on virtex5
12:34
dmj_nova
which had slices consisting of 4 ffs and 4 LUTs
12:35
dmj_nova
our board has slices consisting of 8 FFs and 4 LUTs
12:36
dmj_nova
So I'm not sure how doubling the number of FFs per slice impacts on skein implementation size
12:36
Bertl
I don't think it will use many FFs, but the article from bruce should have some numbers, IIRC
12:37
Bertl
well, I may be wrong there
12:38
dmj_nova
the article seemed to measure in FF-LUT pairs
13:00
dmj_nova
Well, I guess we won't know until it's tried
13:00
dmj_nova
but first priority is probably a simulated sensor module
13:09
sebastian|afk
joined the channel
13:12
sebastian|afk
changed nick to: s3bastian
13:12
s3bastian
back
13:18
dmj_nova
so we have HDMI output working
13:18
dmj_nova
I think I might try simulating the sensor once I get back to my workstation
13:20
s3bastian
sounds good
13:20
s3bastian
did you get familiar with the zedboard yet, how to manage PL and PS configurations, etc.?
13:24
dmj_nova
not quite, I still need to configure my router so I can use TFTP to boot it
14:26
s3bastian
left the channel
18:08
s3bastian
joined the channel
18:08
se6astian
joined the channel
18:13
s3bastian
left the channel
19:45
s3bastian
joined the channel
19:47
se6astian
left the channel
22:08
se6astian
joined the channel
22:10
s3bastian
left the channel
22:17
aombk
joined the channel
22:17
aombk
left the channel
22:17
aombk
joined the channel
22:52
aombk_
joined the channel
22:54
aombk_
left the channel
22:54
aombk
left the channel