Current Server Time: 00:08 (Central Europe)

#apertus IRC Channel Logs

2013/07/03

Timezone: UTC


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