Current Server Time: 19:21 (Central Europe)

#apertus IRC Channel Logs

2013/10/19

Timezone: UTC


00:04
Sasha_C
joined the channel
00:17
Bertl
welcome Sasha_C!
00:17
Sasha_C
Good morning
00:17
Sasha_C
(or evening, if you're in Austria?)
00:18
Bertl
doesn't matter :) .. how's life?
00:18
Sasha_C
Good, it's a beautiful Saturday morning here in Sydney
00:19
Sasha_C
I finally have some time to create a draft blog post on the apertus site. And after I've done that, I think I might head out to a local street festival (only happening this weekend).
00:19
Sasha_C
How are you?
00:20
Bertl
nice! I'm fine ... got some time to work on axiom alpha now
00:20
Bertl
so I'm coding and debugging :)
00:20
Sasha_C
How are things coming along with alpha development?
00:20
Sasha_C
Yes, I see
00:20
Bertl
quite nicely actually ...
00:21
Sasha_C
Always wonderful to hear that :)
00:21
Bertl
some minor issues popped up, but nothing we cannot work around or solve
00:22
Sasha_C
So, do you have an actual copy of the cmosis cmv12000 now attached to the SFE hardware and zedboard?
00:22
Bertl
copy?
00:23
Bertl
I've a cmosis sensor here sitting on my desk, plugged into the sensor board, which in turn is attached to the zedboard I'm working on :)
00:23
Sasha_C
Sorry, not copy, what I meant was an actual sensor rather than a dummy model sensor
00:23
Sasha_C
Wow! Sounds very cool!
00:23
Bertl
and I'm chatting with the sensor :)
00:23
Sasha_C
Great work man!!
00:23
Bertl
thanks! appreciated!
00:24
Sasha_C
And is the lens mount also attached? Are you saying the hardware is ready to go and capture footage with once the software side of things has been taken care of?
00:25
Bertl
no, lens mount and lens is currently with sebastian
00:25
Sasha_C
But I imagine, when the time is ready, it won't be difficult to attach the lens mount to the SFE?
00:25
Bertl
and the hardware isn't ready to capture data yet, but I'm receiving data similar to what we will be able to capture soon
00:26
Bertl
i.e. working on that :)
00:26
Sasha_C
Sounds sooo cool!
00:26
Bertl
it's actually quite complicated to get that data from the sensor, which probably isn't that obvious to the public
00:27
Bertl
there are 70 wires involved, working in pairs, they send signals at 300MHz in both directions
00:28
Bertl
those signals carry the clock and data to and from the sensor
00:28
Sasha_C
Yeah, very complicated
00:28
Bertl
the data itself is broken down into serial streams of 8, 10 or 12 bits
00:28
Bertl
and for example, you have to tune the delay for each line separately
00:29
Bertl
to get meaninful data, then you have to align the bitstream on word boundary
00:29
Bertl
again for each channel separately
00:29
Sasha_C
Do you think it would be beneficial for me to write about this on the apertus site, explaining the difficulty of getting data from the sensor?
00:29
Sasha_C
So people know what we (or you) are currently working on?
00:30
Bertl
well, all this is not really unexpected, i.e. it is how LVDS works, but yes, I guess for the typical movie folks following the axiom development it might be quite interesting
00:31
Bertl
it's like using a microscope to look at your fingertip :)
00:31
Sasha_C
interesting analogy
00:31
Sasha_C
I'll write a draft and send it to the team for review :D
00:31
Bertl
or if you want the computer analogy:
00:31
Sasha_C
yess?
00:32
Bertl
to consider how transistors (switches) form gates, and millions of gates form a processor which then executed assembler code which was generated by a compiler processing a C program
00:32
Bertl
*executes
00:34
Sasha_C
Amazing how all this fits onto a small chip/board!
00:34
Bertl
yes, and we are working at all levels here
00:35
Bertl
down to the smallest transistor and gate and up to the highest level where we execute shell scripts on the arm cores of the zedboard
00:35
Bertl
everything needs to work together in perfect harmony
00:36
Sasha_C
How long do you estimate this could take to work out?
00:36
Bertl
if everything goes as expected, we should have some 'images' next week
00:37
Sasha_C
That is FANTASTIC news man!!!
00:37
Sasha_C
Well done!
00:37
Bertl
I'll probably get the first real image data this weekend, but it won't be that useful from the photographic point of view
00:37
Sasha_C
Of course, not until the lens mount is attached
00:38
Bertl
precisely
00:39
Sasha_C
Can you describe what all of the hardware looks like at the moment? I'm imagining that there are two separate small-medium sized boards (about the size of an A4 piece of paper) connected by wires to a laptop, externall hdd/ssd and power source.
00:39
Bertl
you haven't seen the pictures yet?
00:40
Sasha_C
I've seen pictures of the circuit boards, from OHS park, but not of everything connected together
00:40
Bertl
well, I guess you saw the ones on the axiom site, yes?
00:40
Sasha_C
yeah
00:40
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/axiom_alpha_6.png
00:40
Bertl
so this one is pluggin into the zedboard
00:41
Bertl
on the right side, directly into the FMC connector
00:41
Bertl
on the left side, there are two of those pmod_debug modules attached
00:41
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/pmod_assembled_top_600dpi.png
00:41
Sasha_C
Ah yess, I've seen this.That is amazing! It looks like it has the potential for such a small form-factor
00:42
Bertl
at the bottom, we have a cable to connect the PMOD on the frontend
00:42
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/axiom_alpha_3.png
00:42
Sasha_C
This is SOOO cool! Thanks for sharing this with me
00:43
Bertl
this is custom made - it connects the PMOD at the bottom left with the frontend right across the zedboard
00:43
Bertl
I've also a rainbow colored cable attached at the second PMOD connector at the bottom, which feeds debug data into my analyzer
00:44
Sasha_C
Incredible Herbert! You're amazing!
00:44
Bertl
then the usual cables attached to the zedboard, like power, ethernet, dual micro usb, hdmi
00:44
Bertl
the zedboard boots via ethernet, so that's important
00:46
Bertl
on the PC I have quite a number of PDFs open (mostly datasheets and documentation)
00:47
Bertl
also a number of files describing the pin assignments, the actual VHDL code for the FPGA and a dozen tools to allow to capture and interpret data
00:50
Sasha_C
This is all so amazing to hear! I'll start writing up an article referring to this now
00:50
Bertl
hehe :)
00:50
Bertl
well, let me know if you need more detail on anything in this regard
00:51
Sasha_C
Will do :)
05:06
Bertl
night everyone!
05:06
Sasha_C
night man. sleep well
05:12
Sasha_C
left the channel
06:20
Sasha_C
joined the channel
12:12
Bertl
morning everyone!
15:56
Sasha_C
left the channel
17:45
se6astian
joined the channel
17:46
se6astian
evening!
18:51
Bertl
hey se6astian! did you see the gerber url yesterday?
19:06
se6astian
nope sorry
19:06
se6astian
let me dig them up
19:10
se6astian
got it
19:10
se6astian
http://vserver.13thfloor.at/Stuff/AXIOM/cmv12k-adapter-v1.1.tar.xz
19:10
se6astian
thanks, will forward that to sierracircuits
19:12
se6astian
done
19:25
se6astian
and sent datasheet links to akhilesch
19:57
gcolburn
joined the channel
19:57
gcolburn
hello
20:32
se6astian
hey there
20:32
se6astian
long time no see
20:32
se6astian
how are you gabe
20:34
se6astian
ok, I have to head out for a bit
20:34
se6astian
please check with Bertl on the latest development news ;)
20:34
se6astian
see you later maybe
20:37
gcolburn
sorry
20:38
gcolburn
must have missed you, yeah I was hoping to catch up with on what I could help out with
21:10
Bertl
hey gcolburn!
21:14
gcolburn
hey!
21:14
gcolburn
how's it going?
21:14
Bertl
fine, thanks, just finished working on some wood stuff
21:16
Bertl
so you're eager to start with axiom/alpha development/testing, yes?
21:16
gcolburn
nice. what do yo umake?
21:17
Bertl
it was simple board (kind of cupboard) which gets attached to the wall to carry a speaker
21:17
gcolburn
neat
21:17
Bertl
helped a friend there
21:18
gcolburn
eventually when I get around to designing the physical part of the digital camera back I'd like to make I've considered making it out of a nice wood (since many large format cameras are made out of wood), and all the electronics would be enclosed inside
21:18
Bertl
well, we have a wooden handle planned :_
21:18
gcolburn
yeah, that's cool
21:19
Bertl
the thing with wood and electronics is that they do not go that well
21:19
Bertl
first, wood kind of attrackts humidity, if not treated
21:19
gcolburn
yeah, I as thinking there would have to be something sealed inside so the electronics aren't in contact with it. It was just an idea. not sure which route I'd go
21:19
Bertl
second, it is really poor at shielding, compared to most metal solutions
21:20
Bertl
(both electrical and magnetically)
21:20
gcolburn
would a camera need much shielding though?
21:20
Bertl
yes, a lot
21:21
gcolburn
interesting. are you mainly concerned with noise being introduced to the imager?
21:21
Bertl
it's all high frequency (300MHz and more) and a lot of data which needs to be transported without any distortion
21:21
Bertl
so basically the camera is a radio transmitter and receiver
21:22
Bertl
an involuntary one that is :)
21:22
gcolburn
now that you put it that way it makes sense (based on the frequency)
21:22
gcolburn
so what's the status of the prototype?
21:22
Bertl
it is sitting right beside me, powered up, and I'm talking with the sensor
21:23
Bertl
receiving test patterns and implementing the training stuff to get reliable LVDS transmissions
21:23
gcolburn
so mainly using the SPI at the moment?
21:24
Bertl
spi for control settings and retrieving status information
21:24
Bertl
300MHz 12 bit serial over LVDS for the data
21:25
se6astian
back
21:25
gcolburn
ok, so these are the test patterns generated by the sensor, not test patterns for the HDMI?
21:25
Bertl
correct, the LVDS training patterns
21:25
gcolburn
ok cool
21:25
gcolburn
I read about that in the datasheet
21:27
Bertl
so what is your current equippment regarding axiom alpha and what would you like to work on?
21:28
gcolburn
well, I currently mainly have the ZedBoard
21:28
gcolburn
at some point whenever you think it would make sense, I'd be interested in purchasing a board and sensor
21:28
Bertl
okay, makes sense, we will figure out a way to get boards and sensors to developers
21:29
gcolburn
I don't know what work needs to be done at this point, if its more writing C code/scripts on the linux side or FPGA code
21:29
Bertl
have you set up a development environment (on Linux?) for your ZedBoard?
21:30
gcolburn
are you referring to just the normal Xilinx tools (Planahead, ISE, SDK, etc.)? I've been using that in Ubuntu linux.
21:31
Bertl
okay, we switched to Vivado a few weeks ago, after Aaron (from Xilinx) suggested that we have a look
21:31
gcolburn
how's it working?
21:32
Bertl
from the VHDL PoV not much changed, XDCs have replaced UCFs
21:32
Bertl
and what IMHO is a big advantage, they completely switched to TCL
21:32
gcolburn
for scripting?
21:32
Bertl
for everything
21:33
Bertl
you basically start with a TCL shell where everything happens (or can happen :)
21:33
Bertl
including GUI stuff
21:33
gcolburn
okay. so it probably makes a custom build chain a bit easier?
21:33
Bertl
works pretty well so far, of course, it's the second (or maybe third) release of that product, so it's somewhat buggy
21:34
gcolburn
well if you guys are switching to completely to that I'll make the jump
21:34
Bertl
but the interactive TCL shell helps a lot
21:34
gcolburn
are they still using SDK based on eclipse?
21:35
Bertl
the SDK didn't change AFAICT, but I haven't had much contact with that yet
21:35
Bertl
I've built my own kernel and userspace and there is no need for the SDK ATM
21:35
gcolburn
okay. that's nice
21:35
gcolburn
I haven't had time to get into building a custom kernel, so I've just done bare metal apps in SDK
21:36
Bertl
I'm kind of building kernels all the time, so that was easy for me
21:37
Bertl
btw, you can grab the kernel and userspace and if you like I can tell you how to roll your own as well
21:37
gcolburn
yeah, many years ago I built some custom kernels for some features in gentoo linux, but its been a while!
21:37
gcolburn
sure, that would be great
21:37
gcolburn
so you're mainly using scripts to interface with the sensor and not writing C correct?
21:38
Bertl
the kernel and initramfs is part of the HDMI test package
21:38
Bertl
I'm doing both, scripts where speed isn't that important (mostly bash atm) and C where I need higher performance
21:38
gcolburn
yeah okay
21:39
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/ALPHA/axiom_alpha_hdmi_test_v0.1.zip
21:40
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/ALPHA/hdmi_test_v0.1/ (here you can see the vivado.tcl stuff)
21:40
Bertl
this is basically the TCL script building the PL bitstream
21:40
gcolburn
ok
21:41
gcolburn
have you had many testers for the HDMI?
21:41
Bertl
did you configure TFTP booting yet?
21:41
gcolburn
yes, I just don't have the latest boot image
21:41
Bertl
okay, good
21:42
Bertl
it simplifies testing stuff a lot IMHO
21:42
gcolburn
i've had a weird problem where when I have the TFTP/DHCP running from ubuntu linux my wifi connection seems to freeze up. I had specified the MAC of the zed board specifically
21:42
Bertl
regarding HDMI testing, I only know of se6astian actually testing the code, but maybe a few others did so too :)
21:43
gcolburn
ok, well if I can find a cheap DVI->HDMI converter I can test it
21:43
Bertl
you might want to simply switch to separate network for the zedboard
21:43
Bertl
maybe even a separate cable to the zedboard
21:44
Bertl
(simple on a PC, harder on a laptop)
21:44
gcolburn
yeah
21:44
gcolburn
right now I'm using Ubuntu in Virtualbox on my MAC laptop
21:44
Bertl
but OTOH, there are USB to Ethernet dongles available nowadays
21:44
Bertl
do you have thunderbolt?
21:45
Bertl
(the interface)
21:45
gcolburn
no
21:46
gcolburn
it just has ethernet, USB, and mini display port (which I use an adapter to DVI)
21:46
Bertl
okay, so still USB 100MBit ethernet would be an option
21:46
Bertl
(and maybe more than sufficient for the ZedBoard boot)
21:48
gcolburn
its been a little while since I've played with the zed board as things have been a bit busy. I was out of town for work for a bit. I'm trying to remember if I was using ethernet on the zed board before
21:49
gcolburn
i don't think I was, because it would try to get an IP over dhcp from my router, which I couldn't configure for TFTP
21:49
gcolburn
so I setup Unbuntu to be the dhcp/TFTP server
21:51
gcolburn
this could work I would think: http://www.amazon.com/DVI-HDMI-Cable-6ft-Male-Male/dp/B0002CZHN6
21:51
gcolburn
left the channel
21:52
gcolburn
joined the channel
21:55
Bertl
yes, it should work
21:56
gcolburn
I'll go ahead and order one
21:56
Bertl
if you bought a higher end graphics card for a PC (or know somebody who did) then it might have an adapter plug as well
21:56
gcolburn
yeah
21:56
Bertl
but the cable is definitely a better choice, less noise
21:57
gcolburn
I've considered purchasing a new desktop to use as a server and have a nice graphics card on it (I've done some GPGPU computing for research when I was at the university)
21:58
gcolburn
I'll start with the cable though
21:58
gcolburn
so what are some of the main areas of development you need help with?
21:59
Bertl
ATM, unless you want to hack on FPGA code, the main area is probably testing stuff and writing small scripts to interpret settings and to configure the sensor or the HDMI part
21:59
Bertl
also documentation is always welcome (for all areas)
21:59
gcolburn
okay. how would I test the scripts without a sensor?
22:07
Bertl
we did a fake busybox devmem
22:07
Bertl
which basically uses a file to store the data normally written into the sensor registers
22:07
gcolburn
okay
22:07
Bertl
most of the registers are read/write and read back the written value anyways
22:08
Bertl
(notable exceptions are the temperature sensor for example)
22:08
Bertl
so this should already get you an enviroment which almost behaves like a real sensor (from the SPI PoV)
22:09
gcolburn
I looked through the data sheet a bit ago and looked at how many of the register settings depending on what modes of operation one wants to use. do you guys have an idea of which modes of operation you'd like to demonstrate on the prototype?
22:09
Bertl
for the HDMI part, you have everything we have (regarding hardware) so there you are testing on the real thing :)
22:09
Bertl
we definitely want to play around and test different stuff
22:10
Bertl
after all, we need to get a feeling for the sensor itself
22:10
gcolburn
yeah
22:10
Bertl
we have 32 lanes, 16 on each side
22:10
gcolburn
looks like it has a lot of capabilities, but that requires a lot of register configurations
22:10
Bertl
so we can test 16 single side vs 8/8 double side readout for example
22:11
Bertl
we also want to target highest possible resolution and framerate with 32lanes
22:11
gcolburn
okay
22:11
Bertl
and we probably want to test the exposure curves
22:12
Bertl
I'm not sure that we want to use less than 300MHz, so everything related to lowering the LVDS clock rate is probably not that important
22:12
Bertl
we definitely want to test the subsampling and windowing
22:13
gcolburn
would it be useful to create some spreadsheets of register settings for different configurations (for documentation), and then create the corresponding scripts?
22:14
Bertl
I guess so, probably a smart script which can 'calculate' the settings for given input values/parameters would be a good solution as well
22:14
gcolburn
yeah
22:15
Bertl
AFAIK, Thomas is working on some sensor related scripts, but I don't know what the current status is
22:16
Bertl
se6astian: do we have the set_exposure script somewhere?
22:16
gcolburn
I saw some of the emails from the other guy that helped with some of the exposure script. some of the calculations are a bit hard to read in the script, for me it would be easier to test the calculations in a spreadsheet and then write the script. other people could also easier check the equations than having to read the polish notation
22:17
Bertl
I agree that it might be confusing at the first glance, but actually I consider it a rather smart solution, mainly because with the limited environment, dc/bc is a great tool to have
22:18
Bertl
not that you really need it for those calculations
22:18
Bertl
what I think would be great to have is some kind of 'info' script
22:19
gcolburn
okay. what do you have in mind?
22:19
Bertl
and I already communicated that to Thomas (not sure how well I communicated it though)
22:19
Bertl
the basic concept is to have something which can tell you exactly what state the sensor is in
22:20
Bertl
i.e. how many bits are configured, what exposure time is set, if it is auto or external
22:20
Bertl
how many lanes are used, where they are located, what the image area is, etc
22:20
gcolburn
yeah
22:21
Bertl
because when something doesn't work as expected while testing with the prototype, I usually have to dig into those registers to find out why
22:21
gcolburn
so something like: info -exposure -lanes -imagearea
22:21
gcolburn
with a mode that just dumps everything?
22:22
gcolburn
so you could select limited information if you wanted, or all of it
22:22
Bertl
yes, I guess even cmv_info | grep -i exposure would suffice
22:22
Bertl
it's unix after all :)
22:22
gcolburn
yeah that could work
22:25
gcolburn
well if you'd like I can start working out some of the register settings/configurations for the different main modes and documenting them, and then I could move on to writing some scripts
22:25
Bertl
on a different page, we will be bursting sensor data into memory buffers (for snapshots and maybe even short recordings)
22:26
gcolburn
is that to get the 4k?
22:26
Bertl
the data will arrive in a twelve bit raw format with (yet unknown) alignment
22:26
Bertl
yes
22:26
Bertl
and we need some userspace tools to collect that data and write it in some format we can process/view
22:27
gcolburn
so I don't come from a cinematography background, more photography. is there a defined standard format for 4k?
22:27
gcolburn
i tried a web search and couldn't find much
22:27
Bertl
I'm sure there is, but that's not my area either :)
22:27
gcolburn
ok
22:27
gcolburn
well for initial still frame testing I can convert it into dng
22:28
gcolburn
my first code for that was in python (as it was quick to code), but I'm porting it to C
22:28
gcolburn
for speed
22:28
gcolburn
if that would be of any use
22:28
Bertl
sounds good to me, as long as it can handle the raw formats we throw at it
22:28
gcolburn
oh yeah
22:29
Bertl
I can already say that it will be similar to the sensor data transfer
22:29
gcolburn
yeah
22:29
Bertl
so we get a number of pixels (up to 128) at once
22:29
Bertl
and they are in the well known bayer pattern
22:29
gcolburn
yeah, I'm not too worried about that
22:29
Bertl
we probably will align every line to 4k
22:30
gcolburn
what I've done is taken raw images from my camera and I wrote a DNG image to read the bayer array, and then be able to write it back out
22:30
Bertl
and we will burst/store the pixels (regardless of the number) one after the other
22:30
gcolburn
that should read "I wrote a DNG reader"
22:30
Bertl
okay, so pleas walk me through the work flow
22:30
Bertl
*please
22:31
Bertl
I ssh to the ZedBoard and start your tool 'A' which connects to the memory area (or receives the data from stdin?)
22:31
Bertl
and outputs the lossless compressed DNG data to stdout?
22:31
gcolburn
that could be done
22:32
Bertl
on the linux box, I then can view that image with?
22:32
gcolburn
there are two options
22:32
gcolburn
either existing software that views raw files
22:32
Bertl
like?
22:32
gcolburn
photoshop, lightroom, etc. (there's a bunch of open source ones too)
22:32
gcolburn
or another idea
22:33
gcolburn
we can use a program called dcraw
22:33
gcolburn
to generate a demosaiqed image
22:33
se6astian
darktable, raw therapee, gimp, dcraw, ufraw are all open source software solutions
22:33
gcolburn
yeah
22:33
gcolburn
http://www.cybercom.net/~dcoffin/dcraw/
22:33
se6astian
but I am off to bed :)
22:33
Bertl
have a good one!
22:33
se6astian
thanks
22:33
se6astian
good night!
22:33
gcolburn
see you later!
22:34
se6astian
left the channel
22:34
gcolburn
dcraw is free to use
22:34
Bertl
well, yeah, I think I need something which can be used in a pipe style setup (and definitely on linux)
22:34
Bertl
i.e. something like display from ImageMagic
22:34
gcolburn
I think dcraw can output to stdout
22:34
Bertl
and I guess it should be reasonably fast and allow to view the raw data somehow
22:35
Bertl
i.e. so that I can zoom in somehow and see each pixel
22:35
gcolburn
yeah
22:35
gcolburn
would you be transferring a file off the zed board to view it
22:35
gcolburn
?
22:36
Bertl
yes, definitely, via the beforementioned ssh pipe
22:36
Bertl
i.e. I would ssh into the zedboard executing the image capture tool which outputs the dng
22:36
gcolburn
ok
22:36
Bertl
the output on the linux box is then piped into the viewer/converter
22:37
gcolburn
okay, would this be just for still frames or for video?
22:37
Bertl
primarily for still images
22:37
Bertl
for video I guess we want/need to do some processing on the zedboard
22:38
gcolburn
ok, so it wouldn't be the end of the world if after you run the capture program it writes to a file, and then you ssh the file back to your computer to view?
22:38
Bertl
and I'm not sure we want to spend too much time on that at the alpha stage
22:39
Bertl
not the end of the world, but definitely annoying ... although I could simply store the file in memory (if it is small enough) and 'cat' it to get the pipe data I'd prefer
22:39
gcolburn
ok
22:39
Bertl
but of course, simply dumping the data to stdout would be a lot simpler
22:39
gcolburn
yeah
22:40
Bertl
does the dng writer need to seek?
22:40
gcolburn
if its not build into dcraw we can modify the code to do that
22:40
gcolburn
not necessarily
22:40
Bertl
the dcraw is on the PC side, I do not care about memory or filesystem resources there
22:40
Bertl
so writing to a file and opening that file is perfectly fine
22:41
Bertl
(i.e. I was talking about the tool running on the zedboard)
22:41
gcolburn
okay, I was thinking dcraw would be compiled on the zedboard
22:41
gcolburn
either way works
22:41
Bertl
I don't see why we should bother with dcraw on the zedboard
22:41
gcolburn
ok
22:41
Bertl
(except for the fun of doing it :)
22:41
gcolburn
yeah :)
22:42
Bertl
so I gues you have at least two areas now where you can go crazy the rest of the weekend, yes?
22:42
gcolburn
regarding the seek
22:42
gcolburn
to read a dng you definitely have to do a lot of seeks
22:42
gcolburn
i'll have to see if I'll need to do any for the writing
22:43
gcolburn
I basically have to create an index with the offsets to different TIFF tags and where the image data is located
22:45
gcolburn
a DNG file is basically an extension of a TIFF
22:45
gcolburn
to add support for raw data
22:45
gcolburn
and any data can be stored anywhere in the file, so you have to start with the index tree that tells you the offsets to any data you want, then to write it you just have to come up with your own file layout and write the offsets to the main index
22:47
gcolburn
the capture utility can write to STDIO no problem though, since we (or I) would write that.
22:51
gcolburn
I just checked, dcraw can write to standard output out of the box as well
22:51
gcolburn
so from there you could view it with ImageMagic
22:53
Bertl
excellent! sounds like a plan then
22:56
gcolburn
okay. I'll start working on some code from that
22:56
gcolburn
what resolution do you plan on capturing at before down sampling to 4k?
22:58
gcolburn
I guess probably just leave it at full resolution? it seems like 4k isn't completely a defined size