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 |