23:09 | aombk | FergusL: haha, no its my computer thinking it should teach me more about experimental/noise music.
| |
23:11 | FergusL | You should listen more! These sounds were interesting.
| |
23:14 | Bertl | aombk: what kind of computer?
| |
23:15 | aombk | desktop pc usb external card
| |
23:15 | aombk | but the internal card does that sound too if i remember correctly
| |
23:16 | aombk | *i mean sound card
| |
23:19 | aombk | half of the time i join #apertus i believe FergusL and Bertl are the same person :P
| |
23:19 | Bertl | hehe, how so?
| |
23:21 | aombk | because when i first met FergusL online some time ago we were talking and then some day he started changing nicknames always ending with L
| |
23:21 | FergusL | Look-alike nicknames ?
| |
23:21 | FergusL | Hahaha
| |
23:24 | Bertl | I see, well, your IRC client is obviously better than most, because folks usually read the 'l' at the end as 'i' :)
| |
23:28 | aombk | chatzilla . the power of the ugly new times roman!
| |
23:52 | aombk | hey FergusL wanna hear some voluntary experimental/noise? http://aombk.attinom.net/otr/?page_id=131
| |
05:28 | Bertl | night everyone!
| |
07:06 | troy_s_ | left the channel | |
07:06 | rexbron | left the channel | |
07:12 | rexbron | joined the channel | |
07:15 | troy_s | joined the channel | |
07:23 | se6astian | joined the channel | |
07:23 | se6astian | good morning
| |
07:31 | dmj_nova | joined the channel | |
07:35 | troy_s | left the channel | |
07:35 | rexbron | left the channel | |
07:38 | [1]se6astian | joined the channel | |
07:40 | se6astian | left the channel | |
07:40 | [1]se6astian | changed nick to: se6astian
| |
07:42 | rexbron | joined the channel | |
07:46 | troy_s | joined the channel | |
07:50 | troy_s | left the channel | |
07:50 | rexbron | left the channel | |
07:54 | rexbron | joined the channel | |
07:56 | troy_s | joined the channel | |
08:02 | troy_s | left the channel | |
08:04 | troy_s | joined the channel | |
08:54 | troy_s | left the channel | |
08:54 | rexbron | left the channel | |
08:59 | rexbron | joined the channel | |
09:03 | rexbron | left the channel | |
09:19 | rexbron | joined the channel | |
09:23 | troy_s | joined the channel | |
09:53 | intracube | joined the channel | |
11:03 | dmj_nova | se6astian: is that concept waterproof?
| |
11:09 | se6astian | no
| |
11:26 | [1]se6astian | joined the channel | |
11:28 | se6astian | left the channel | |
11:28 | [1]se6astian | changed nick to: se6astian
| |
11:30 | [1]se6astian | joined the channel | |
11:32 | dmj_nova | se6astian: so stuff can leak through to the sensor/electronics?
| |
11:33 | se6astian | left the channel | |
11:33 | [1]se6astian | changed nick to: se6astian
| |
11:43 | se6astian | not if we can prevent it, I wrote "chimney sealed to camera inside" in the concept, though that does not mean you can throw the camera into a pond obviously
| |
11:46 | dmj_nova | ah, okay
| |
11:46 | dmj_nova | not without sealing the modules together anyway
| |
11:49 | dmj_nova | se6astian: meeting is in one hour?
| |
11:50 | mars_ | to have a common basis when we talk about waterproofing oder moisture resistance, we should refer to ip codes: https://en.wikipedia.org/wiki/IP_Code
| |
11:52 | se6astian | yes in one hour
| |
11:54 | dmj_nova | I feel that the design should be at least liquid IP4
| |
12:07 | se6astian | left the channel | |
12:19 | Bertl | morning everyone!
| |
12:20 | intracube | morning Bertl :)
| |
12:32 | se6astian | joined the channel | |
12:32 | Bertl | wb se6astian!
| |
12:32 | se6astian | hi there
| |
12:32 | se6astian | my irc client froze
| |
12:33 | Bertl | happens sometimes, most irc clients detect it an reconnect
| |
12:34 | Bertl | happens when some switch or router in your connection decides to drop the connection
| |
12:35 | se6astian | yes thats what my client does but in this incident the softwre itself froze/crashed
| |
12:35 | se6astian | maybe because I am running 3d renderings with high performance demand in the background :)
| |
12:36 | Bertl | interesting ... what operating system/kernel?
| |
12:37 | Bertl | btw, nice cooling concept - love the chimney idea :) - but it probably needs some modifications though
| |
12:38 | dmj_nova | se6astian: what's the meeting topics?
| |
12:39 | Bertl | first, I'm not sure we can put the connectors on the side, it might be necessary to have them at the top/bottom, which means that the chimney would need to be more 'U' or 'V' shaped instead of the 'T' shape
| |
12:40 | Bertl | second, I would avoid connecting the FPGA heat sink to the sensor heat sink at all cost
| |
12:41 | se6astian | win7 :)
| |
12:41 | Bertl | ah well, a single tasking OS :)
| |
12:41 | se6astian | yes :)
| |
12:41 | se6astian | what about two heatsinks
| |
12:41 | se6astian | one for image sensor one for FPGA
| |
12:42 | se6astian | next/on top/side by side to each other?
| |
12:42 | Bertl | yeah one on each side, the air stream in the middle sounds more doable
| |
12:42 | se6astian | the bottom side is rather bad for having vents
| |
12:42 | se6astian | because this side is most likely completely covered
| |
12:43 | Bertl | we also need to plan for heat spreaders or peltier elements which match the size of the sensor/FPGA/RAM
| |
12:43 | se6astian | tripod mound, should plate, etc.
| |
12:43 | Bertl | the entry and exit points can still be on the sides if designed carefully
| |
12:44 | Sasha_C | joined the channel | |
12:44 | se6astian | peltier element, I guess the bigger the better, but the area we can cut into the PCB is limited by the pins of the sensor
| |
12:45 | Bertl | nah, size doesn't matter that much here, it is more about power and placement
| |
12:45 | se6astian | ok, then thats a details that the concept does not really need to cover at this point I guess
| |
12:45 | se6astian | can you make a drawing of U, V shaped chimneys?
| |
12:46 | Bertl | I see the top/bottom as separated units, thus I said T, U and V
| |
12:47 | Bertl | if you look at the whole chimney, it is more an 'I' now, and it could be an 'H' or 'X' :)
| |
12:47 | Bertl | hope that clarifies
| |
12:47 | se6astian | ah I see
| |
12:48 | Bertl | what confuses me in the design are the fans, because somehow they do not fit the proportions here
| |
12:48 | se6astian | yes they are retouched in quite badly ;)
| |
12:48 | Bertl | they look like 4x4cm fans, but
| |
12:49 | Bertl | but that would not even remotely fit the sensor sizes
| |
12:49 | Bertl | OTOH, if I assume that they are 10mm in diameter, I do not know of any readily available fans in that size
| |
12:50 | se6astian | 25mm seems to be the smallest standard size: https://geizhals.at/?cat=coolfan&xf=355_25
| |
12:51 | Bertl | yes, but the problem with small fans is that they get noisy and inefficient
| |
12:52 | Bertl | I wonder if it would be a problem to have a large fan (like 80x80 or so) on the top of the camera?
| |
12:52 | se6astian | hmm, interesting idea
| |
12:52 | Bertl | IMHO it might even be detachable in case you don't need it
| |
12:53 | se6astian | then it would need to be outside the enclosure....
| |
12:54 | se6astian | not entirely sure how that could be done yet....
| |
12:55 | Bertl | it is already 'outside' the enclosure as the entire chimney topologically is on the outside
| |
12:55 | se6astian | ?
| |
12:55 | Bertl | but I think some kind of plug on with clips or something would work
| |
12:56 | Oscar_Apertus | joined the channel | |
12:56 | Bertl | welcome Oscar_Apertus!
| |
12:56 | se6astian | but what about the threads on the top and the handle?
| |
12:56 | se6astian | hi oscar
| |
12:57 | Bertl | don't see any threads or handle in the images atm
| |
12:58 | Bertl | (so I can't say if that would be a problem or not)
| |
15:26 | intracube | hi folks
| |
15:26 | Bertl | hey intracube! :)
| |
15:27 | intracube | can I comment as a hypothetical end user?
| |
15:27 | Bertl | sure, go ahead, that's what this is for
| |
15:28 | intracube | there are some obvious advantages to this project compared to what established companies are offering
| |
15:28 | intracube | some of the main players will deliberately hold back features on lower end models to avoid eating into the profits of their more expensive models
| |
15:29 | intracube | so they're deliberately crippling their own products
| |
15:29 | Bertl | yes, we see that in many areas
| |
15:29 | Bertl | (i.e. not just cameras)
| |
15:29 | intracube | and this won't be an issue for the axiom
| |
15:29 | intracube | indeed. sony are particularly bad at this
| |
15:30 | intracube | Nikon release the D600 which was initially $3200 in the UK and there was no way to adjust aperture while in video mode
| |
15:30 | intracube | the black magic 4k looks really interesting, but it only supports standard frame-rates
| |
15:30 | dmj_nova | wait, what?
| |
15:31 | intracube | dmj_nova: hmm?
| |
15:31 | dmj_nova | how can you use a camera without adjusting aperture?
| |
15:31 | dmj_nova | that sounds more broken than limited
| |
15:31 | intracube | AIUI, you have to drop out of video mode (back to photo mode), adjust aperture, go back to video mode
| |
15:32 | dmj_nova | I feel sorry for Nikon users
| |
15:32 | intracube | and what's worse is they release the successor to the D600 a year later (D610) and it has the same issue
| |
15:33 | Sasha_C | intracube: Are you aware that sony has just released two new full-frame mirrorless cameras (a7 & a7r) that can accept lenses from different brands (via adapters) and shoot clean 'raw' video out via HDMI?
| |
15:33 | intracube | of course the D610 isn't primarily a digital cinema camera, but it's a hopeless design decision if they're selling it on it's video capabilities
| |
15:33 | Bertl | this, IMHO, is one of the essential advantages of open source and open hardware, and I can't get tired to emphasize that ... in open source/hardware, you _always_ have a way to fix such things
| |
15:33 | dmj_nova | Bertl: Indeed
| |
15:33 | intracube | Sasha_C: I haven't been keeping up with what's available
| |
15:33 | intracube | Bertl: indeed
| |
15:34 | dmj_nova | It's the entire reason I'm here :)
| |
15:34 | dmj_nova | Sasha_C: My guess is that's uncompressed 8 bit video
| |
15:34 | Bertl | and I also think that this is something we still need to communicate to the broader public
| |
15:34 | philippejadin | left the channel | |
15:35 | intracube | and even if early versions of the Axiom only support standard frame-rates. as an end user, if I hear that the hardware is capable of lower framerates and it's just a question of a software update - then that's would be good enough for me
| |
15:35 | Bertl | i.e. folks need to get aware that with axiom there is always a way to get exactly what they want
| |
15:35 | dmj_nova | Bertl: hmm...I'll see if I have time for a demo to communicate that
| |
15:35 | Sasha_C | dmj_nova: Yes, that's what I think too. Still, I've heard people describe these new sony models (sporting 24mp & 36mp respectively) as being in the spirit of 'open source', as you can get an adapter and use any brand of lens
| |
15:35 | Bertl | it might take some while, it may cost a little, but it is possible
| |
15:36 | intracube | Sasha_C: what sony models are they?
| |
15:37 | Sasha_C | intracube: http://www.digitaltrends.com/photography/sonys-alpha-a7-a7r-image-quality-may-make-splurge-full-frame/
| |
15:37 | dmj_nova | more importantly intracube, the update can give everyone official support
| |
15:37 | intracube | Sasha_C: thanks
| |
15:37 | dmj_nova | I'd love it if axiom got full frame eventually :)
| |
15:38 | intracube | Sasha_C: thanks (and I didn't see you actually said a7, a7r earlier) oops :)
| |
15:38 | Sasha_C | no worries man
| |
15:38 | Bertl | so, IMHO it is also important to focus on advertising the real advantages of that project and not just the camera features the typical user is comparing with the so called 'competitors'
| |
15:39 | troy_s | Bertl: I will play devil's advocate
| |
15:39 | Bertl | I totally agree that we need to be competitive, don't get me wrong
| |
15:39 | Bertl | but there is a lot more to axiom than just having nice features
| |
15:39 | dmj_nova | yeah, we should focus on communicating our advantages
| |
15:40 | troy_s | I will go out on a limb and suggest that notions of 'upgradeability' and such are myths by and large.
| |
15:40 | Bertl | for example, I haven't heard anything about the firmware/upgrade yet
| |
15:40 | troy_s | Doubly so when one considers the niche that an Axiom will target.
| |
15:40 | dmj_nova | and make sure that what we *deliver* is competitive even aside from those advantages
| |
15:40 | intracube | troy_s: are you talking hw or sw upgradability?
| |
15:40 | Bertl | note that we already agreed (in an early stage) that we will put the firmware on a micro SD card
| |
15:40 | troy_s | intracube: In theory both.
| |
15:41 | Bertl | which in turn means, that all you have to do is to switch that card to upgrade the camera (firmware and software)
| |
15:41 | dmj_nova | why would firmware upgradability be a myth for axiom?
| |
15:41 | Bertl | now compare that to the typical camera upgrade procedures :)
| |
15:41 | intracube | troy_s: magic lantern for Canons?
| |
15:41 | intracube | Nikon updated their firmware to fix HDMI out
| |
15:41 | intracube | etc
| |
15:42 | troy_s | intracube: The rapidly shifting landscape puts an emphasis on shipping a product. At the price range, do it and do it now is vastly more important than do it later. (as well as being historically unrealistic).
| |
15:42 | intracube | if the big players are doing it, then it's surely a possibility for this project
| |
15:42 | Bertl | no lock in, no danger of bricking the camera, etc
| |
15:42 | Bertl | you test the new firmware/software with a simple card change, if you like it, great, if not, change back to the old card
| |
15:42 | dmj_nova | axiom firmware upgrades (not talking upgrading prototype to final physical hardware) should be a regular thing that improves the camera in significant ways.
| |
15:44 | troy_s | intracube: The reality is that the imagers that can afford a camera at this level are a fickle lot, and even a stellar product (can that be expected in a reasonable time frame with this project?) can be eclipsed in less than a year.
| |
15:44 | Bertl | want to use the high speed software for your project which hasn't any HDMI out, just insert the appropriate micro SD ... and so on and so forth
| |
15:45 | troy_s | So at some point the flexibility is eclipsed by the ability for an imager to use the camera and use it now. I would heavily suggest that waterline is low.
| |
15:46 | Bertl | could you rephrase that for non native speakers?
| |
15:47 | troy_s | Bertl: Set hard contextual goals that are realistically attainable and ship it. In spite of the likely moaning that will ensue
| |
15:47 | troy_s | Bertl: And simply ignore "upgradability"
| |
15:47 | troy_s | (not utterly jettison on it, but ignore it as a key contextual design notion)
| |
15:48 | Bertl | ah, yes, that is my opinion as well, but we can have the cake and eat it, with built-in upgradeabliliy from the scratch
| |
15:48 | dmj_nova | troy_s: Well, in the case of how this product is already designed, upgradability is simply a thing that will happen
| |
15:48 | Bertl | like for example the firmware concept
| |
15:48 | dmj_nova | shipping the best possible product as soon as possible, well that's the goal
| |
15:48 | intracube | it really depends on *what* upgradability we're talking about
| |
15:48 | dmj_nova | and that best product can keep improving
| |
15:49 | intracube | firmware updates could be pretty simple to implement
| |
15:49 | troy_s | Bertl: Still theoretical. And that comes at a cost of delay. Many projects that have striven for such open ended designs fail miserably. There was a wonderful interview with the creator of World Forge on that.
| |
15:49 | intracube | allowing the hardware design to support interchangable sensors would probably require a lot more effort/resources
| |
15:49 | troy_s | dmj_nova: What I am saying is that you just used a long stream of privileged language
| |
15:49 | Bertl | troy_s: do you have a link at hand?
| |
15:50 | intracube | think troy_s is suggestion not spending any significant extra time designing the camera to support various sensors
| |
15:50 | intracube | as an example
| |
15:50 | troy_s | "best" looks great and _everyone_ will agree on it because it is a privileged term
| |
15:50 | Bertl | yes, I agree that 'perfect' is the enemy of 'good'
| |
15:50 | troy_s | Bertl: Still privileged. Those are all comparisons.
| |
15:50 | dmj_nova | yeah, we have plans for the sensor to be on a separate board, but to not integrate additional sensors
| |
15:51 | Bertl | but I think that the key is in building a solid foundation
| |
15:51 | troy_s | Bertl: I just believe that context stands here as a blinking light. Why would I buy an Axiom?
| |
15:51 | dmj_nova | I just meant that we would try to ship as capable and competitive a device as we are able
| |
15:52 | troy_s | Right now, I can be blunt: What frame rate? What sized sensor? What latitude? What gamut?
| |
15:52 | troy_s | The rest is all bullshit.
| |
15:52 | Bertl | troy_s: ultimately, because it makes sense, given the ability to shape it :)
| |
15:52 | troy_s | Bertl: See my point?
| |
15:53 | troy_s | I have 5k to drop on a camera, and it is _that_ context that needs to shape the project
| |
15:53 | intracube | another question; is there going to be significant resources put into the recording side of the camera over the next year or so?
| |
15:53 | Sasha_C | troy_s: funny, I believe I also raised this exact question about an hour or so ago
| |
15:54 | intracube | or will most of the deveopment just be on the head (sensor + debayer + HDMI output + controls for aperture)?
| |
15:54 | troy_s | Given above, can I shoot on it tomorrow? Will it be plagued with problems?
| |
15:54 | dmj_nova | I think I also raise the same issue and hour ago :P
| |
15:54 | intracube | and use an off the shelf recording solution like: http://www.rcblogic.co.uk/p-2936-atomos-ninja-2-recorder.aspx
| |
15:54 | troy_s | (the cost of a camera is tiddly winks to cost of shooting)
| |
15:55 | intracube | troy_s: it depends on the type of production
| |
15:55 | troy_s | intracube: No. It does not.
| |
15:55 | Bertl | what we see here, is the problem that we already have several 'ballparks' and try to find common ground :)
| |
15:55 | intracube | obviously network TV drama, shows + film would drop 50 or 100K on a proven reliable camera
| |
15:55 | intracube | but there are plenty of indie shoots that don't have that budget
| |
15:56 | troy_s | intracube: Even wandering out into a field somewhere comes with a cost.
| |
15:56 | Bertl | for somebody spending $1mio on a movie, the camera equippments price is not that important I guess
| |
15:56 | troy_s | intracube: I have worked on enough projects to tell you that you are flat out wrong.
| |
15:56 | troy_s | intracube: Try feeding a teeny crew of ten for a month.
| |
15:57 | troy_s | intracube: And renting a teeny bit of lighting.
| |
15:57 | intracube | troy_s: but I'm not talking about that sort of production
| |
15:57 | troy_s | intracube: Or paying insurance on a teeny set of three lenses your friend loans you.
| |
15:57 | intracube | I'm talking about one step up from shooting on DSLR cams
| |
15:57 | Bertl | let's stop here and take a step back
| |
15:57 | troy_s | intracube: I am too.
| |
15:57 | Bertl | let's accept that there are many different applications and usage areas for a movie camera
| |
15:58 | Bertl | and with that, there come different price ranges
| |
15:58 | troy_s | Bertl: I am _specifically_ focusing on the exact niche you aim at.
| |
15:58 | Bertl | I'm not aiming at anything :)
| |
15:58 | troy_s | Bertl: Say a 5k-10k camera.
| |
15:58 | mars_ | so what exactly is our target population?
| |
15:59 | troy_s | Bertl: Short film / cinema.
| |
15:59 | troy_s | Bertl: Fair context so far?
| |
15:59 | Bertl | my disadvantage (of not knowing the camera/movie scene) is my advantage here, I'm not that biased
| |
15:59 | philippejadin | joined the channel | |
15:59 | troy_s | (I am certain having rexbron here would help now. He too is horrifically aware of the inherent costs)
| |
16:00 | Bertl | I agree that the apertus/axiom project has a much narrower target in mind than I do per se
| |
16:00 | Bertl | so what I learned is called 'indie movie' is probably the main target
| |
16:01 | troy_s | Bertl: Good. About what I described above.
| |
16:01 | troy_s | Bertl: And exactly what I just outlined. Given lower budgets, you are going to make trade offs (often on time or 'quality')
| |
16:02 | troy_s | Bertl: And given time (say more weekends because everyone is working during a week)
| |
16:02 | Bertl | but the thing I tried to point out is, that buying an axiom is like buying a cnc router not just a table saw
| |
16:02 | troy_s | (or your crew is skeleton)
| |
16:03 | Bertl | so just comparing it to table saws might not be that appropriate :)
| |
16:03 | troy_s | Bertl: And the benefits to an imager are what then?
| |
16:03 | Bertl | endless possibilities and customization
| |
16:03 | troy_s | And endless development time.
| |
16:03 | Bertl | of course, we don't want/need a bad sensor or ugly colors
| |
16:04 | troy_s | It can't live in Utopia forever.
| |
16:04 | Bertl | as a matter of fact, infinite development is what I have in mind
| |
16:04 | Bertl | doesn't mean that it isn't useful from the start
| |
16:04 | Sasha_C | troy_s: in the spirit of open source, development will be ongoing. But that doesn't mean you won't be able to use the software / hardware
| |
16:04 | troy_s | Bertl: But given a year, everyone moves on.
| |
16:05 | Bertl | it is a misconception that development means that the camera is not useable
| |
16:05 | troy_s | Bertl: Do you or I want to be shooting on a 20D?
| |
16:05 | troy_s | Bertl: How about a 7D?
| |
16:05 | troy_s | See my point?
| |
16:06 | Bertl | 20 sounds a lot more than 7, no?
| |
16:06 | troy_s | (and I only am being extremely skeptical here because darnit if I am not likely precisely in your target audience.)
| |
16:06 | Bertl | and no, obviously I do not see your point, as I do not know those models
| |
16:07 | troy_s | Say I have 5k to drop on a camera. That means I have to evaluate my purchase. If I can _easily_ afford more, then I am likely not your estimated audience member.
| |
16:07 | Bertl | wrong
| |
16:07 | troy_s | So what will that 5k offer me? Ideological solace - not to be underrated - also has a fuzzy limit.
| |
16:07 | troy_s | Wrong?
| |
16:08 | Sasha_C | Bertl: in short, the 20d is an older, outdated digital camera from circa early 2000's. The 7D was THE hot DSLR from about 2009-2012 for so called indie film-makers
| |
16:09 | Bertl | while I agree that the main target is probably the poor movie maker which can only spend 5k on the camera, that doesn't mean that we do not offer significant advantages to high end customers as well
| |
16:09 | troy_s | (and I don't want to be antagonistic, but to cut to the bone with the contextual issues here)
| |
16:09 | troy_s | Bertl: Quit being so open ended :)
| |
16:09 | Bertl | and I appreciate that for sure
| |
16:09 | troy_s | Bertl: Use me. Here.
| |
16:09 | troy_s | Skip all the other bullshit
| |
16:09 | Bertl | so, why did you come here, for example?
| |
16:10 | troy_s | I have faith in _you_ as an engineer and I think your heart and mind is in a great spot. Let's move on and use a real world example...
| |
16:10 | Bertl | something must have brought and kept you here ... don't get me wrong, I appreciate all the input we got so far)
| |
16:10 | Sasha_C | Troy_s: Can you be more specific when you say "quit being so open ended"?
| |
16:10 | troy_s | rexbron and I are looking to purchase two cameras to shoot a short on in six months.
| |
16:11 | Bertl | okay, so what's wrong with the products out there?
| |
16:11 | troy_s | Sasha_C: I come from an art / design background. Trying to be everything to everyone is the downfall of all design. "open ended" tends to be symptomatic of such things.
| |
16:11 | troy_s | Bertl: BMC has fixed 24 fps.
| |
16:11 | Sasha_C | you mean jack of all trades, master of none
| |
16:11 | troy_s | Bertl: Smaller sensor
| |
16:12 | troy_s | Sasha_C: A bit of a eurowestern hypercapitalist idiom for me. I prefer "a lack of concrete design context"
| |
16:12 | Bertl | for sure there are models out there which do 8k at 200FPS and more, no?
| |
16:12 | troy_s | Sasha_C: (and the inherent tradeoffs each design choice has)
| |
16:12 | Bertl | (or 4k on really large sensors)
| |
16:12 | troy_s | Bertl: I can be happy with off speed and super 35 sensor
| |
16:13 | Bertl | so why axiom?
| |
16:13 | troy_s | Bertl: With 2k (real 2k, not R3D 2k)
| |
16:13 | Bertl | clearly we have no product to sell atm
| |
16:13 | troy_s | Bertl: Because that is precisely where the ideological edge comes in
| |
16:13 | Bertl | did we somehow deceive you? did you think we had a product?
| |
16:14 | troy_s | Bertl: I would take an Axiom with open raw (compare against a R3D for example) with those features.
| |
16:14 | Bertl | okay, so there is an obvious benefit from the 'open' part
| |
16:14 | troy_s | Bertl: So I _do_ believe that I would be interested in such a camera
| |
16:14 | Sasha_C | troy_s: I know exactly where you're coming from. However, try to think of the Axiom as like the Raspberry Pi
| |
16:15 | troy_s | Sasha_C: It isn't. It is a camera to shoot shorts / creatives / etc. on. I think the context is radically a world apart.
| |
16:15 | troy_s | Sasha_C: Largely because it must also "fit into" an existing ecosystem.
| |
16:16 | Bertl | and don't forget, the benefits you see in the (future) axiom are your personal benefits, there are many other benefits you won't use/acknoweledge immediately
| |
16:16 | Bertl | (but still they are there)
| |
16:16 | troy_s | Bertl: So if rexbron and I need two cameras, and let's assume you are past prototype, we care about when we could shoot.
| |
16:16 | Sasha_C | troy_s:the context is different, but the ideology of a device which you can control and reprogram for unconventional situations is what makes this similar to a raspberry pi
| |
16:17 | troy_s | Bertl: (and of course we would all need to agree that issues _will_ arise and we will try to negotiate them etc)
| |
16:17 | Bertl | troy_s: so you will have to shoot with an early prototype I guess, but still, that is within possibility
| |
16:17 | Bertl | (in contrast to products of the 'competition')
| |
16:17 | troy_s | Bertl: Exactly. That is progress. So ignoring "competition", when can we shoot?
| |
16:18 | Sasha_C | troy_s: As an example, the following image was captured with the 'frankencam" , which was programmed to capture multiple exposures with different sensitivities: http://graphics.stanford.edu/projects/camera-2.0/images/cards-s.jpg
| |
16:18 | troy_s | Bertl: And not to be facetious here. I ask that hard question because it contextualizes all of the abstract into concrete reality.
| |
16:18 | Bertl | if there is enough interest, and the (crowd) funding goes well, I don't see why it shouldn't be possible in 6 months
| |
16:18 | Sasha_C | For more info on the Frankencam project: http://graphics.stanford.edu/projects/camera-2.0/
| |
16:19 | troy_s | Bertl: And what set of "features" would that be given six months?
| |
16:19 | troy_s | (remember, I could care less about random Utopian ideals. I speak in concrete terms with hard limits and constraints.)
| |
16:19 | Bertl | if we get the minimum funding, and have to work in a really small team ... it might take 15 months
| |
16:19 | troy_s | Ok.
| |
16:20 | Bertl | the feature set really depends on the community
| |
16:20 | troy_s | I worry in the latter case.
| |
16:20 | Bertl | there is no point in focusing on a feature nobody wants
| |
16:20 | troy_s | Because it would be exceptionally hard to commit to shooting a year and a half away with 10k to spend.
| |
16:20 | Bertl | obviously receiving the data from the sensor and sending it out raw is the main focus
| |
16:21 | Bertl | so that I consider the 'essential' feature set
| |
16:21 | troy_s | (there is no nobody. Someone, somewhere will want Quake 2 codec for example :) Hence the need for hard context and hard constraints)
| |
16:21 | intracube | Bertl: what do you mean by raw? HDMI?
| |
16:21 | Sasha_C | troy_s: I'd strongly advise you not to plan your upcoming shoot around the availability of the AXIOM
| |
16:21 | Bertl | I doubt that hdmi will be part of the base set for several reasons
| |
16:22 | troy_s | Bertl: I am much more inclined to believe in the project the more limits I see actually.
| |
16:22 | troy_s | Sasha_C: It is a mental exercise
| |
16:22 | Bertl | raw high speed serial stream, probably SDI related
| |
16:22 | troy_s | Sasha_C: To strip the crap out of the air
| |
16:22 | Sasha_C | troy_s: sorry, my bad
| |
16:22 | intracube | Bertl: ah ok. so raw RGB data
| |
16:22 | Bertl | troy_s: sure, I'm all for it
| |
16:23 | Bertl | intracube: the raw, bayered data from the sensor
| |
16:23 | intracube | yup
| |
16:23 | Bertl | everything else can be done outside of axiom already
| |
16:23 | troy_s | Sasha_C: If I ask the hard question "in six months" I am reasonably sure it puts pressure on the thinking of all parties to commit to estimations and judgment. _That_ is good design thinking.
| |
16:23 | intracube | oh, -bayered- . I see
| |
16:24 | troy_s | Bertl: So what for onboard?
| |
16:24 | philippejadin | this woud not need a future upgrade to head imho
| |
16:24 | Bertl | troy_s: sensor management, data transport
| |
16:24 | Sasha_C | troy_s: I see. Thanks for clarifying :)
| |
16:24 | troy_s | Bertl: Viewfinder / onboard display?
| |
16:24 | Bertl | not in the beginning
| |
16:24 | troy_s | (my context of "onboard" there)
| |
16:25 | philippejadin | troy_s: think like this : http://www.ioindustries.com/provideo/products/index.html
| |
16:26 | troy_s | philippejadin: SDI would be preferable to HDMI for certain, but I am unaware of Bertl 's plan
| |
16:27 | Bertl | hdmi has two disadvantages for us ATM
| |
16:27 | Bertl | first the licensing issues and then the limit on the bandwidth
| |
16:27 | troy_s | I am merely asking the bare minimum shoot needs - body with onboard viewing and storage.
| |
16:28 | Bertl | let's assume we get SDI/Camera Link/whatever working fine
| |
16:28 | troy_s | Bertl: How far off is the SDI for you?
| |
16:28 | Bertl | then you can simply add an existing viewfinder
| |
16:28 | intracube | troy_s: but onboard storage and video preview isn't essential is it
| |
16:28 | intracube | http://www.rcblogic.co.uk/p-2947-atomos-samurai-blade-10-bit-hd-sdi-field-recorder-and-hd-monitor-retail-kit.aspx
| |
16:29 | philippejadin | see here : http://www.ioindustries.com/provideo/products/2ksdi_workflow.html
| |
16:29 | Bertl | troy_s: essential part of the first axiom prototype
| |
16:29 | troy_s | intracube: Just saying storage. Umbilical is just another design constraint.
| |
16:34 | Sasha_C | I've gotta head off and get some sleep now :(
| |
16:34 | troy_s | Bertl: When do you intend to lock down a harder timeframe? (I assume you need it for Kickindiego etc.)
| |
16:35 | Sasha_C | left the channel | |
16:35 | Bertl | I guess we will start with a 'business plan' soon, but ATM we have to figure out the step size :)
| |
16:36 | Bertl | obviously the original plans were more like 2 year development then a final product, while I think that 3x(6-9) months or so might be a better choice
| |
16:37 | Bertl | with tangible targets and useful prototypes
| |
16:37 | troy_s | Bertl: Indeed. Amen.
| |
16:37 | troy_s | Bertl: 6 months. Smaller goals.
| |
16:37 | troy_s | Bertl: Tangible products.
| |
16:37 | Bertl | well, I've joined the project in august
| |
16:37 | troy_s | (and likely a plethora of learning in there)
| |
16:38 | Bertl | not knowing much about FPGAs and movie making/cameras ... I've learned quite a lot already :)
| |
16:39 | Bertl | from the projects I managed so far, I've also learned that it isn't the development which really affects the time frame
| |
16:39 | troy_s | What does?
| |
16:39 | Bertl | development, especially software development, scales quite beatifully with the number of developers
| |
16:40 | Bertl | the time consuming parts are more production related
| |
16:40 | Bertl | i.e. in the cycles from idea to actual product (even if it is just a prototype)
| |
16:40 | Bertl | just take the alpha prototype as example
| |
16:41 | troy_s | Bertl: Well you can get lost in the spiral of what-if
| |
16:41 | troy_s | Bertl: Hence why I find those hard / constrained real-world-with-faces-and-names examples much more illuminating.
| |
16:42 | troy_s | Bertl: It forces decisions, which in turn clarifies design.
| |
16:42 | troy_s | (either alienating audience members or attracting them)
| |
16:43 | Bertl | agreed, that's why I made a number of decisions for axiom alpha, ignoring many 'what if's and 'maybe we should's :)
| |
16:44 | Bertl | I'm also convinced that a release soon, release often policy is something necessary for such a project to succeed, and in our case, this includes the hardware as well
| |
16:44 | Bertl | the only unfortunate part is that hardware cannot be upgraded that easily
| |
16:44 | Bertl | (I mean the actual hardware, not firmware)
| |
16:45 | gcolburn | joined the channel | |
16:45 | gcolburn | hello
| |
16:45 | Bertl | hello gcolburn!
| |
16:45 | gcolburn | so sebastian wanted me to commit fixes for the bayer pattern
| |
16:46 | gcolburn | are we sure the image looks correct with what we tried before?
| |
16:46 | Bertl | no, but I'm sure we have a number of folks here who would love to check :)
| |
16:46 | gcolburn | I tried it myself and the colors do seem off
| |
16:46 | gcolburn | do we have a photo on the internet of what it should look like?
| |
16:46 | Bertl | for the IT8 chart?
| |
16:47 | Bertl | (if so, just google IT8)
| |
16:48 | Bertl | and it might be a good idea to show the resulting image to troy_s, he knows a lot about this stuff
| |
16:48 | troy_s | Bertl: Have you considered less expensive sensors to step up to final?
| |
16:48 | troy_s | Bertl: Such as a sort of extremely-limited-but-not-quite-as-limited-and-slightly-more-expensive Flip camera?
| |
16:49 | troy_s | (with a lens mount)
| |
16:49 | troy_s | and work up to the final "ideal" that is currently there?
| |
16:49 | Bertl | yes, certainly has some advantages but doesn't give us any development advantage
| |
16:49 | troy_s | I am sure there is a tremendous mountain of learning in stepping which becomes hugelt valuable
| |
16:50 | troy_s | (like sorting out micro-targets (EG SDI, storage, etc.)
| |
16:50 | troy_s | (micro targets as it steps along and evolves)
| |
16:51 | troy_s | (as well as generating more faith and interest in an audience that may be able to contribute)
| |
16:51 | Bertl | that is the idea, but I don't think the sensor choice does really matter that much
| |
16:51 | troy_s | gcolburn: If you are familiar with how color works, you can generate a matrix from that it8
| |
16:52 | troy_s | Bertl: I threw it out as the "expensive" component
| |
16:52 | Bertl | I think the base unit (i.e. the central processing) will be realively cheap, and as we plan for exchangeable sensor boards, most likely, there will be a low cost frontend available soon
| |
16:52 | troy_s | Bertl: The cheapest and swiftest path to product (albeit likely crippled) to get first steps of growing pains out of the way
| |
16:53 | troy_s | Bertl: Something that also allows imagers to begin aiding in the inevitable mess of issues in a field environment
| |
16:53 | Bertl | so what kind of sensor do you have in mind for your project? :)
| |
16:54 | troy_s | Bertl: I could care less on a personal level. I would think that folks interested in imaging could exploit anything unique if there were such a trait.
| |
16:55 | troy_s | Bertl: But shooting is a great way to also get to tangible and interesting output (see the interest your first rudimentary images have generated)
| |
16:55 | philippejadin | hello gcolburn ! sorry for not following up with your work. How is it doing ?
| |
16:55 | troy_s | Bertl: Hell even a crippled and mangled imaging device can be quite interesting in creative hands.
| |
16:56 | Bertl | definitely
| |
16:56 | troy_s | (Matt Mahurin often shot using extremely gibbled bodies and broken lenses)
| |
16:56 | troy_s | Bertl: It is something certainly appealing if it can be integrated into an evolutionary line.
| |
16:58 | Bertl | gcolburn: it might be worth to try to simply flip the image outside the DNG
| |
16:58 | intracube_ | joined the channel | |
16:58 | Bertl | maybe the canon parts you copied do not work with the new color arrangement?
| |
16:59 | troy_s | Bertl: Folks like rexbron come from a slightly avant-garde background and I am certain that there are others that could make such an evolutionary path interesting.
| |
16:59 | philippejadin | I would center our work into finding a proper way to connect stuff. Sensor board to processing board to recorder. And allow people to interconnect different sensor boards versions to different processing boards version as well. And aditionaly I'd use an existing processing board for the second prototype as well. But that's just me :-)
| |
16:59 | Bertl | gcolburn: i.e. what I mean is, try to flip the raw data vertically and see if the original converter makes it look different/better?
| |
17:00 | intracube_ | I've just been looking at the HD-SDI specs and it looks like there's no provision for anything other than 16:9
| |
17:00 | intracube_ | at least not beyond standard definition
| |
17:00 | Bertl | troy_s: I'm all for it ... but to make it scale, everybody has to do what he/she does best in the interest of the common good/project
| |
17:00 | intracube_ | will this make it difficult to support full frame output/recording?
| |
17:01 | intracube | left the channel | |
17:01 | intracube_ | changed nick to: intracube
| |
17:01 | troy_s | Bertl: I would expect things to progress the sooner you bolt down your needs.
| |
17:01 | Bertl | intracube_: first, we do not need to limit ourselves to a single protocol (as long as it is high speed serial)
| |
17:02 | Bertl | troy_s: my needs are something to work with, something to eat, a place to live and a challenge to tackle :)
| |
17:03 | philippejadin | Bertl, gcolburn, have you seen this already : https://bitbucket.org/hudson/magic-lantern/src/570c301158185f8dd29372ae7260d88bfda49c1c/src/chdk-dng.c?at=unified (dng writing routines from chdk, adapted for magic lantern use, gpl)
| |
17:03 | Bertl | troy_s: but I get what you mean
| |
17:03 | intracube | but I guess once you move away from the most common (HDMI/SDI) it means there isn't the same availability/choice of off-the-shelf recording systems
| |
17:03 | troy_s | Bertl: *cough* for the camera iteration
| |
17:03 | troy_s | :)
| |
17:04 | Bertl | intracube: that is the point which seems to be exceptionally hard to communicate
| |
17:04 | troy_s | intracube: Quite sure 4:3 is supported via SDI transport
| |
17:04 | Bertl | let me take this as an example to illustrate it
| |
17:04 | troy_s | intracube: Peek at the Alexa Studio
| |
17:04 | Bertl | let's assume, we put four SDI connectors on the prototype
| |
17:04 | Bertl | (those are basically BNC connectors)
| |
17:04 | intracube | troy_s: I'm just going on what the HD-SDI wiki page says :)
| |
17:05 | Bertl | let's also assume we implement HD-SDI ontop of the physical interface
| |
17:05 | Bertl | (so you now can connect your favorite SDI recorder/view finder/whatever)
| |
17:05 | intracube | troy_s: and the tech specs for kit like this: http://www.rcblogic.co.uk/p-2947-atomos-samurai-blade-10-bit-hd-sdi-field-recorder-and-hd-monitor-retail-kit.aspx
| |
17:06 | Bertl | now for some reason, we figure that this doesn't allow us to do 150FPS @ 4K :)
| |
17:06 | Bertl | but that doesn't mean that we can't do it, we just need to utilize the SDI outputs differently
| |
17:07 | intracube | Bertl: true, but it makes post production that much more complex
| |
17:07 | Bertl | now the important part is, this does not mean that we drop the SDI compatibility
| |
17:07 | Bertl | it might mean that you need to use different firmware for one or the other
| |
17:07 | Bertl | it might even mean that you need a simple hardware addon/plugin/module
| |
17:08 | intracube | troy_s: from arri site: "4:3 is currently only available for ARRIRAW; a pillar box format is used for 16:9 EVF-1 as well as HD-SDI MON OUT; ProRes or DNxHD recording is currently not supported."
| |
17:08 | Bertl | but it will not require a new model :)
| |
17:08 | troy_s | intracube: All that matters is the onboard image for SDI
| |
17:09 | troy_s | intracube: Not transport for native raw file
| |
17:10 | troy_s | intracube: SDI for onboard / monitor out. The actual file dumped via other.
| |
17:10 | intracube | Bertl: troy_s: oh ok.
| |
17:11 | troy_s | (or the chained SDI for file funkyness)
| |
17:11 | troy_s | Bertl: So are you thinking a chained SDI for file dumping?
| |
17:11 | troy_s | (something like you outline above)
| |
17:11 | Bertl | yes, definitely
| |
17:11 | troy_s | Gotcha
| |
17:12 | Bertl | the zynq design might allow for a few neat things
| |
17:12 | gcolburn | sorry, I had to step out to handle some issues at work
| |
17:12 | troy_s | Bertl: Then a funky decoder to get it into a suitable file shape
| |
17:12 | troy_s | ditto.
| |
17:12 | troy_s | Ciao all.
| |
17:12 | Bertl | like for example using the serdes high speed ports for other serial protocols
| |
17:13 | Bertl | maybe even directly for attaching storage devices at some point
| |
17:13 | Bertl | (but the first step is simple high speed serial out, everything else comes later)
| |
17:14 | gcolburn | philippejadin:That code looks nice and short. We might be able to modify that for a C version
| |
17:21 | philippejadin | Bertl, it means if we have 4 bnc connectors connected to serdes, we are pretty much settled for anything at a later point
| |
17:22 | philippejadin | gcolburn: and it is used excusively for cinema dng post processing, so it's a perfect fir for us
| |
17:22 | philippejadin | (fit)
| |
17:22 | Bertl | to some degree, yes, if those 4 connectors are on a separate I/O board, even better, we then can simply exchange that board to allow for SATA or hdmi out
| |
17:23 | philippejadin | could we create a small bnc to sata adapter?
| |
17:23 | Bertl | that wouldn't really work because of differences in the termination
| |
17:24 | philippejadin | said in another way, can we transport the high speed signal using bnc connectors ?
| |
17:24 | Bertl | but having a small board which connects the high speed serial ports to BNC/SDI or SATA or hdmi would work
| |
17:24 | philippejadin | when I say bnc, I'm only talking about the physical, locking connectors
| |
17:25 | Bertl | yes, I understand, but serial protocols consist of two parts
| |
17:26 | Bertl | the physical connection and the electrical _and_ the serial protocol itself
| |
17:26 | philippejadin | sata and sdi are electricaly different I guess?
| |
17:26 | Bertl | precisely
| |
17:27 | philippejadin | could there be a way to switch between the two?
| |
17:27 | philippejadin | like doing the proper termination for both standards, and allow on the fly switching?
| |
17:27 | Bertl | with additional components probably
| |
17:28 | Bertl | but I think it will be a lot easier to just have something like I/O shields
| |
17:28 | Bertl | which connect to the high speed ports of the FPGA and provide the required termination and physical connection to the outside)
| |
17:28 | philippejadin | with 4 serdes on board and different termination circuitry, we might have everythin we need in a camera head we don't even need to physically open
| |
17:28 | philippejadin | it's a big deal for reliability imho
| |
17:29 | Bertl | I don't think that is something we want to do, at least not in the beginning
| |
17:29 | philippejadin | 4 ports = 2 sata, 1 clean sdi, 1 sdi with menu
| |
17:29 | philippejadin | or any other combination
| |
17:30 | philippejadin | I think it's much more simple than the big connectors in the current open design concept
| |
17:30 | Bertl | it is already hard to get one protocol right at those speeds, making a number of them work seamlessly together side by side won't be doable within a short amount of time
| |
17:31 | Bertl | there would be an enormous amount of comformance testing and similar
| |
17:31 | philippejadin | I'm just thinking about having future proof hardware as soon as possible
| |
17:32 | Bertl | yes, but havin a proper I/O interface and a special SDI I/O module (or SDI/SATA module later on) is a lot more future proof and easier to do
| |
17:32 | philippejadin | 4 high speed serial out, and a single usb or i2c or wathever control protocol is already covering a huge amount of uses
| |
17:38 | philippejadin | how would this io interface connect to the camera head?
| |
17:38 | Bertl | via the module interface/connectors
| |
17:39 | philippejadin | is possible to transmit the signal over a short (20 cm) wire?
| |
17:40 | Bertl | a lot of things are 'possible'
| |
17:41 | philippejadin | practical ? :-)
| |
17:41 | se6astian | I ll be leaving for the theatre shortly and have only been following with one eye from time to time
| |
17:41 | Bertl | the one eyed se6astian will leave us shortly :)
| |
17:42 | philippejadin | so be it!
| |
17:42 | se6astian | my coment on all this (no paticular topic) is that we have had similar discussions in the last 2-4 years with different people multiple times already (the technical details changed a bit over time)
| |
17:42 | Bertl | philippejadin: why would you want to do that? :)
| |
17:43 | se6astian | So I want to investigate a method/workflow to make sure we can always advance the discussion on the results achieved prior
| |
17:43 | se6astian | to prevent us going in circles
| |
17:43 | philippejadin | yep
| |
17:43 | se6astian | I guess the wiki could be a place
| |
17:44 | philippejadin | there are some new stuff : how to provide something quicker - cheaper / that can be expanded / with easy to use (and hard to mis-design)connectors
| |
17:44 | se6astian | but someone would be required who always summarized all the things discussed, with good structuring and not just writing the results but also the path to get there
| |
17:44 | philippejadin | I' will do my homework (reading this http://www.xilinx.com/publications/archives/books/serialio.pdf ) and come back to you :-)
| |
17:45 | se6astian | so in the end we would need to document a lot of stuff that we ruled out so that at a later point we can go back there and clearly see why we ruled it out exactly
| |
17:45 | se6astian | one eye off for now :)
| |
17:46 | Bertl | have fun!
| |
17:46 | se6astian | thanks
| |
17:46 | se6astian | left the channel | |
17:46 | Bertl | philippejadin: good choice
| |
17:47 | Bertl | (although a little biased, but that's fine in our case)
| |
17:47 | philippejadin | :-)
| |
17:48 | philippejadin | I'm eager to believe their marketing stuff about how great and powerful their builtin serial io is
| |
17:49 | gcolburn | Bertl: How hard would it be to shoot the IT8 outside in daylight conditions?
| |
17:49 | gcolburn | I think that would help with checking the color
| |
17:56 | Bertl | gcolburn: atm, very hard
| |
17:56 | gcolburn | okay. that's what I figured. it might be worth first trying to neutralize the camera calibration
| |
17:57 | Bertl | but I think the ~2900K illumination should give useable results
| |
18:00 | gcolburn | I'll try and back out what the current calibration illumination temperatures are in the file
| |
18:00 | gcolburn | there are calibrations for two temps right now
| |
18:08 | gcolburn | 1 calibration is for standard illuminant A (about 2856 k), the other is for D65
| |
18:27 | troy_s | gcolburn: The color temp of shooting conditions has no real imoact
| |
18:28 | troy_s | gcolburn: The quality of the light source certainly, but of little consequence at this juncture.
| |
18:29 | gcolburn | but the colors should come out reasonable
| |
18:29 | troy_s | gcolburn: And given Bertl used a household tungsten bulb, guess what illuminant it nearly will match...
| |
18:29 | troy_s | gcolburn: Uh what?*?*
| |
18:29 | gcolburn | right now the IF8 chart image doesn't seem to look like reasonable colors. I can't get the background area to come out grey for example
| |
18:30 | troy_s | gcolburn: You are looking at unprofiled sensor data via (likely) a rough and uncalibrated sRGB display... that amounts to zero chance of even remote color accuracy
| |
18:30 | troy_s | because it is an unprofiled sensor!!!
| |
18:31 | Bertl | I think the important part is that red is red and green, green and blue comes out as blue :)
| |
18:31 | troy_s | You are taking one set of arbitrary display referred values (the sensor - min to max) and arbitrarily feeding them to another display referred context (sRGB ideally, and likely unlike sRGB) with no transform
| |
18:31 | troy_s | you have no idea how color works then
| |
18:31 | gcolburn | what I should mention incase you missed it, is in my DNG writer that I wrote it seemed that photoshop/lightroom requires a camera calibration. for quick testing I just used the profile out of a Canon camera. The first images Bertl sent I was able to adjust the whiteblaance and get a reasonable image. but since the pixel order has change, I'm not getting a reasonable image on the IF8 chart
| |
18:31 | troy_s | Would you like me to explain?
| |
18:32 | troy_s | The sensor is _unknown_
| |
18:32 | gcolburn | so I know the calibration is different, I'm just trying to verify the correct bayer pattern for the new images
| |
18:33 | troy_s | not the calibration - no such creature
| |
18:33 | Bertl | troy_s: the question atm is more, how do we get a quick and dirty calibration for the dng writer?
| |
18:33 | troy_s | the profile of the sensor is unknown
| |
18:33 | gcolburn | right
| |
18:34 | Bertl | i.e. can we deduce that from the IT8 chart?
| |
18:34 | Bertl | (I'd say, to some degree, yes)
| |
18:34 | Bertl | also, do we need different lighting setups to do that? (note it doesn't have to be perfect atm)
| |
18:35 | troy_s | Bertl: Sorry was in hotel elevator
| |
18:35 | troy_s | You take the IT8 image
| |
18:36 | gcolburn | if you use two profiles with very different temperatures the raw converter can interpolate better
| |
18:36 | gcolburn | but one is enough to get started
| |
18:36 | troy_s | and your known white point (and assuming Bertl used a standard tungsten fixture we can estimate it is 2800-2900)
| |
18:36 | troy_s | and calculate a profile for the sensor.
| |
18:36 | troy_s | gcolburn: That is all moot
| |
18:36 | troy_s | gcolburn: There is ZERO estimation if you do not know the constants - hence the IT8 and color temp
| |
18:37 | philippejadin | have you tried passing it in http://www.argyllcms.com/ ?
| |
18:37 | troy_s | Argyll can be used to estimate
| |
18:37 | troy_s | (albeit within the bounds of a D50 v2 PCS)
| |
18:37 | Bertl | excellent, so please give that a try and coordinate to avoid duplication
| |
18:38 | philippejadin | tutorial here :
| |
18:38 | philippejadin | http://www.argyllcms.com/doc/Scenarios.html#PS1
| |
18:38 | troy_s | exactly
| |
18:38 | troy_s | I was JUST about to paste that
| |
18:38 | troy_s | LOL
| |
18:38 | philippejadin | but if you see complete garbage, it means the wrong filter order is in the dng file ?
| |
18:39 | Bertl | no, we kind of 'guessed' that I think
| |
18:39 | philippejadin | I mean, which color is the first pixel and stuff like that
| |
18:39 | troy_s | philippejadin: It isn't garbage
| |
18:39 | troy_s | philippejadin: RGB is arbitrary and meaningless
| |
18:39 | troy_s | philippejadin: Red could very well represent a green when viewed in sRGB and untransformed
| |
18:40 | philippejadin | well, at a lower level, if you don't present the bits in the correct order, it will result in garbage
| |
18:40 | troy_s | Absolutely
| |
18:41 | troy_s | but from what I have seen of Bertl's images, they aren't random noise so it is merely about transforming primaries
| |
18:41 | troy_s | (and TRC)
| |
18:41 | philippejadin | random noise is another mater
| |
18:41 | philippejadin | probably something to take care at a later stage
| |
18:42 | gcolburn | well if someone creates a profile for the sensor I'd be happy to put it in the DNG converter
| |
18:42 | philippejadin | and this will be needed per camera (per sensor). Color profile creation, I don't know if it must be done for each sensor
| |
18:42 | gcolburn | Adobe uses standard profiles for each type of sensor. they go to a lot of work to make their own profiles and ship with with Photoshop RAW and Lightroom
| |
18:43 | gcolburn | but you don't have to use theirs
| |
18:43 | troy_s | gcolburn: You really don't get it.
| |
18:43 | troy_s | gcolburn: Adobe has no clue what is going on in that image
| |
18:43 | troy_s | zero
| |
18:43 | Bertl | philippejadin: I guess, for now, all we need is a basic sensor profile
| |
18:43 | Bertl | (doesn't even have to be accurate, just same ballpark)
| |
18:43 | troy_s | that sensor has yet to be profiled (by nearly anyone I bet)
| |
18:44 | philippejadin | then, altough I've never used it, I think argyllcms is the tool to use
| |
18:44 | troy_s | Bertl: Getting an approximate matrix is not too complex.
| |
18:44 | gcolburn | I'm not talking about Adobe knowing about the CMV12000
| |
18:44 | gcolburn | I'm talking about general cameras on the Market
| |
18:44 | troy_s | gcolburn: So explain how that pertains to interpreting the data off of the 12000?
| |
18:44 | Bertl | troy_s: we'll improve on that later when we can do proper images with controlled lighting
| |
18:45 | gcolburn | it doesn't. I was answering philippe's question regarding a profile for each sensor or per type of sensor if I understood his question correctly.
| |
18:45 | troy_s | Right now, the data Bertl offers is a triplet of ints. It happens to be stored in RGB triplets, but even if the term R ROUGHLY represented red, you have no idea what red.
| |
18:46 | troy_s | gcolburn: So in short someone (I am on the road) needs to take the data and generate a transformation matrix for the primaries
| |
18:46 | troy_s | gcolburn: Once we have that, we can estimate gamut volume etc.
| |
18:46 | gcolburn | can you explain how the CMV12000 data is in a triplet of ints? its in a bayer array
| |
18:46 | troy_s | gcolburn: It is an exceptionally common error to assume that RGB values are absolute. RGB color models are _not_ absolute color spaces
| |
18:47 | gcolburn | I know RGB values are not absolute
| |
18:47 | Bertl | gcolburn: I can explain that by now :)
| |
18:47 | troy_s | gcolburn: Each bayer sensel is stored in an integer "well"
| |
18:47 | troy_s | depending on bit depth
| |
18:48 | troy_s | Each sensel is filtered by an arbitrary filter color / tint
| |
18:49 | gcolburn | yes. the sensor has a 12 bit A/D converter. Bertl is mapping the data to 16 bit in memory. Every other pixel has a green filter, the ones in between have red or green
| |
18:49 | Bertl | red or blue
| |
18:49 | gcolburn | sorry
| |
18:49 | gcolburn | that's what I meant
| |
18:49 | philippejadin | aren't we supposed to know the filter that is on each pixel ?
| |
18:49 | Bertl | but it is important, that those are not precise wavelengths
| |
18:49 | gcolburn | yes
| |
18:49 | gcolburn | there is a spectral response for each filter
| |
18:49 | Bertl | i.e. the camera would not work if it were a single red/green/blue
| |
18:49 | gcolburn | difference for each manufacturer
| |
18:50 | gcolburn | right
| |
18:50 | philippejadin | this brings us back to creating a color profile
| |
18:50 | troy_s | philippejadin: Impossible
| |
18:50 | Bertl | and the RGB reresentation does not cover all the colors either (that is what troy_s is referring to)
| |
18:50 | gcolburn | because the light incident on the camera is a spectrum of wavelengths. based on how are vision works with rods and cones, and what our eyes are sensitive to RGB are the primary filters used
| |
18:51 | troy_s | bingo
| |
18:51 | troy_s | And all devices, even with known filters, respond differently
| |
18:51 | troy_s | (Much like displays. Hence why if you do color critical work you need to profile them)
| |
18:52 | philippejadin | as I see it, you have a reference shot, and a known representation of it (included with the color profile creation tool), so you can create a color profile
| |
18:52 | troy_s | So known values need to be photographed and a CIE model absolute set of values provided
| |
18:52 | gcolburn | troy_s:I understand all this, I think you have just been misunderstanding me some how. perhaps I haven't been clear in when I was talking about the CMV12000, verse the general raw conversion process
| |
18:52 | troy_s | Then you can take the data and infer the transform - most linear devices like a sensor respond relatively uniformly except near the edges
| |
18:53 | philippejadin | it will at least work with this sensor and herbert's light :-)
| |
18:53 | Bertl | precisely :)
| |
18:53 | troy_s | gcolburn: Well I apologize but I was a little concerned when I saw "roughly close" - there is no way to get to roughly close without a unique transform.
| |
18:54 | gcolburn | true. I was surprised that the first images (that had a different pixel read out order than the new ones) were able to achieve a "roughly close" image when I set the white balance
| |
18:55 | philippejadin | (without counting all the sensor registers that might have some influences as well :-()
| |
18:55 | troy_s | gcolburn: For all intents and purposes, the data in the Green sensel position could very well be very far away from greenish if you view it dumped to sRGB. (and a way out of whack TRC)
| |
18:56 | gcolburn | yeah. we just need to get a profile and go from there
| |
18:56 | philippejadin | gcolburn: maybe the sensor provides "roughly close" colors when using fluo lights. Bertl did you use he same light for the tape picture and the IT8 ref cart ?
| |
18:57 | troy_s | gcolburn: That would be relative to your display, and even then, that only suggests that (assuming the data isn't broken) that the values are roughly close to the primaries of your display, which unless you have profiled it, aren't even likely close to sRGB.
| |
18:57 | Bertl | philippejadin: nope, the color bars were illuminated by a TFT screen
| |
18:57 | philippejadin | hahaa!
| |
18:57 | philippejadin | much colder
| |
18:57 | troy_s | philippejadin: It is all hypothesis as we don't even have a reference point on the display viewed. LOL
| |
18:58 | troy_s | crap
| |
18:58 | troy_s | Bertl: So it isn't even a tungsten bul!
| |
18:58 | mars_ | tbh, i like the brown tint on my main display ^^
| |
18:58 | troy_s | bulb?!
| |
18:58 | Bertl | the IT8 is
| |
18:58 | Bertl | the tape color bars weren't
| |
18:58 | troy_s | oh phew
| |
18:58 | troy_s | lol
| |
18:58 | troy_s | Gotcha
| |
18:58 | philippejadin | fortunately we won't profile using the tape
| |
18:59 | troy_s | Anyways... tungsten bulb of about 100watts and an IT8 will get a close ballpark idea
| |
18:59 | Bertl | philippejadin: although it might be a lot cheaper :)
| |
18:59 | Bertl | troy_s: that's what I used
| |
18:59 | troy_s | It can get finessed as the needs dictate and the camera gets more mobile.
| |
19:02 | gcolburn | troy_s: do you think you could make a profile for us from the IT8 chart image?
| |
19:02 | philippejadi | imagine that some day the camera could auto profile during a shoot using a test chart
| |
19:04 | Bertl | that is probably not so far off :)
| |
19:04 | troy_s | left the channel | |
19:06 | troy_s1 | joined the channel | |
19:06 | troy_s1 | QUASSEL
| |
19:07 | troy_s1 | I may have missed a chunk of conversation. Apologies.
| |
19:07 | troy_s | joined the channel | |
19:07 | gcolburn | no problem
| |
19:07 | gcolburn | troy_s: do you think you could make a profile for us from the IT8 chart image?
| |
19:10 | troy_s1 | gcolburn: If I weren't trapped on location with no computer sure. :)
| |
19:10 | troy_s1 | gcolburn: You seem very well equipped though, and I could assist.
| |
19:11 | troy_s1 | gcolburn: I would suggest getting a matrix off of Bertl's raw data, and confirming. Then test your DNG against that.
| |
19:11 | troy_s1 | (To eliminate errors that might have crept into the DNG conversion)
| |
19:11 | troy_s1 | Better, having another head in the color side is a much better win.
| |
19:14 | gcolburn | yeah if there is some free software you recommend to create the profile with you can walk me through it
| |
19:15 | troy_s1 | gcolburn: Let me try to find a decent link. That Argyll link is good enough to start.
| |
19:16 | troy_s1 | gcolburn: As we can't move the camera, and as long as Bertl uses the same lamp, our color temp is constant. You can also estimate color temp from the neutral IT8 swatches if you get adept at the process.
| |
19:17 | troy_s1 | (We know it is roughly 2800k)
| |
19:17 | troy_s1 | gcolburn: Here is another link using Argyll http://stephenstuff.wordpress.com/2012/07/06/digital-camera-profiling-with-raw-therapee-and-argyll-cms/
| |
19:19 | philippejadin | gotta go, happy profiling guys !
| |
19:19 | philippejadin | left the channel | |
19:20 | troy_s1 | gcolburn: Although his primaries extend off into XYZ imaginarys, so I worry :)
| |
19:21 | troy_s1 | gcolburn: Try the basic Argyll steps, and then we can move onto calculating a more neutral matrix by figuring out the white point
| |
19:21 | troy_s1 | (The matrix you will have will have the color temp baked into it)
| |
19:22 | troy_s1 | (If we estimate the white point after that, we can unbake the light's color temp out and get a reasonable estimate of the sensor)
| |
19:22 | troy_s1 | And now I must go. Back soonish.
| |
19:22 | troy_s1 | Private messages are most ideal for Quassel to prevent me from scrolling back.
| |
19:23 | troy_s1 | left the channel | |
19:33 | rexbron | left the channel | |
19:34 | rexbron | joined the channel | |
19:34 | rexbron | left the channel | |
19:34 | rexbron | joined the channel | |
19:35 | gcolburn | left the channel | |
20:08 | philippejadin | joined the channel | |
20:12 | gcolburn | joined the channel | |
22:23 | FergusL | left the channel | |
22:25 | FergusL | joined the channel |