| 00:35.53 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 01:11.19 | *** join/#brlcad crazy_imp (~mj@a89-182-193-252.net-htp.de) |
| 02:15.47 | bhinesley | Whew, my proposal is in. Best of luck to you all. I'm taking the rest of the night off. |
| 02:49.13 | brlcad | bhinesley: awesome! |
| 02:49.31 | brlcad | perfect timing too |
| 02:57.24 | brlcad | kunigami: that's sort of the gist ... but not exactly interpolating rtedge output |
| 02:58.09 | brlcad | rtedge shoots a grid of rays, one ray per pixel, keeping track of what is hit |
| 02:59.26 | brlcad | anywhere there are two neighboring rays that hit two different objects, it colors one of the two pixels so an edge is drawn |
| 02:59.47 | brlcad | repeat over all pixels and you have an edge outline of the model in raster image form |
| 03:00.38 | brlcad | to make a vector image instead of a raster image, you need spline curves, so you're trying to evaluate and "fit" a curve that will match the edges that you detect |
| 03:01.39 | brlcad | you could use rtedge's output, but that will generally result in a very crappy set of curves unless you shoot a very very dense grid (i.e., a big image) |
| 03:03.22 | brlcad | better would be to detect edges at a given resolution, then refine to even higher resolution so you "hone in" on the real edge, then use that for the spline curve control points, trying to find a balance of not too many or too few control points, and producing a vector image within a reliable timeframe |
| 03:11.44 | starseeker | brlcad: would it be correct to say that the focus for an image conversion library would be on robustness and efficienty rather than covering a lot of formats? |
| 03:16.54 | starseeker | (robustness referring to things like handling very large images without wiping out on ram limitations and dealing with corrupt data...) |
| 03:29.30 | brlcad | starseeker: my priorities would be on 1) API design, 2) robustness, 3) breadth of support, and 4) performance |
| 03:30.12 | brlcad | it's hard to perform slow image processing, I'm not too worried about that unless it's abysmal :) |
| 03:30.38 | brlcad | getting the API right is the hardest part that probably deserves a couple solid weeks attention |
| 03:31.33 | brlcad | surveying and overviewing/reviewing all of the current image processing tools, figure out how they might fit into the API ... |
| 03:31.54 | brlcad | figure out a way to make the library emminently extensible pluggable |
| 03:32.41 | brlcad | bhinesley: really nice work on your proposal, additional feedback should be sometime this weekend |
| 03:37.09 | starseeker | was under the impression that handling really large images in low memory situations was something of a problem... |
| 03:40.19 | brlcad | sure, I think every one of our image converters presently assumes the image will fit in-core |
| 03:40.36 | brlcad | if the API is right, then it's just an implementation detail to optimize that later |
| 03:40.47 | starseeker | ah, k |
| 03:40.48 | brlcad | where you tile and use scratch disks or whatever |
| 03:41.12 | brlcad | we don't exactly hit that limit very often |
| 03:41.48 | starseeker | true |
| 03:42.22 | starseeker | guess I'm thinking about it due to those gargantuan scans from the National Archives, but that's a one-off situation |
| 03:43.33 | brlcad | yeah, you scan data that big .. but you rarely render an image that big :) |
| 03:43.58 | starseeker | heh - high res posters ftw |
| 03:44.49 | brlcad | still if it's done right, then merging in support for a given filter or conversion format could make sure the iterators are all 64bit unsigned ints |
| 03:45.43 | brlcad | or at least 32bit unsigned ints .. 4294967295 x 4294967295 is a pretty big image.. |
| 04:11.39 | bhinesley | brlcad: thank you, I look forward to it |
| 04:28.46 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 04:36.05 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) |
| 05:02.12 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) |
| 06:50.03 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 07:26.02 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) |
| 07:34.18 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 08:02.22 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) |
| 08:08.56 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) |
| 09:33.10 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) |
| 10:39.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 11:08.43 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) |
| 12:05.09 | *** join/#brlcad crazy_imp (~mj@a89-182-193-252.net-htp.de) |
| 14:49.15 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) |
| 14:52.43 | *** join/#brlcad ``Erik__ (Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 15:12.09 | ``Erik | huzzah, I has intarwebz again |
| 15:57.52 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 16:11.09 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) |
| 17:22.45 | starseeker | ``Erik: do you know of any lisp or scheme implementation that bootstraps itself using only assembly and has no C code? |
| 17:23.42 | ``Erik | most schemes |
| 17:23.49 | ``Erik | oh, wait, no C? hrm, no |
| 17:24.18 | ``Erik | C is lingua de franca, it's hard to find anything at all that doesn't use it to bootstrap :/ |
| 17:24.53 | ``Erik | ooooold lisp 1.5 is asm only, but for the, uh, ibm 704 and pdp1 iirc |
| 17:25.42 | ``Erik | graham says you can be working with 7 primitives, right? self-bootstrapping shoudln't be TOO hard |
| 17:25.53 | starseeker | yeah, that's why I was wondering if someone had done it |
| 17:26.03 | starseeker | maybe movitz, have to check |
| 17:27.11 | ``Erik | (mebbe we shoulda asked sbcl to submit a self-bootstrap to gsoc O.o) |
| 17:27.36 | starseeker | 7 primitives is very basic though - don't know if you can get to threads or system file io stuff with that... |
| 17:27.39 | starseeker | hehe |
| 17:28.15 | starseeker | is goofing off by digging around the whole "minimal bootstrap, literate lisp" thing again |
| 17:29.26 | starseeker | two most interesting sources so far are the islisp spec (which unlike ANSI is explicitly public domain, albeit quite a bit smaller) and sacla |
| 17:29.47 | ``Erik | given that on most os's, any syscall is a C function, I don't know how well you'll do avoiding C without working directly on the metal |
| 17:30.14 | starseeker | what about writing directly in assembly? |
| 17:30.40 | ``Erik | doable, if you happen to match the kernels call convention... which can be tricky |
| 17:31.18 | ``Erik | my brainfuck compiler to asm has "if mac, do this, if bsd, do this, if this version of linux, do this, if that versino of linux, do that..." |
| 17:31.56 | starseeker | hmm |
| 17:32.20 | ``Erik | most of that is just frontmatter... generally, it breaks down to unix/bsd/mac style vs linux/dos style... but there're still gotchas |
| 17:32.43 | ``Erik | (yes, linux is closer to dos than unix at that level.) |
| 17:32.48 | starseeker | ow |
| 17:34.31 | starseeker | huts for old lisp 1.5 sources... |
| 17:34.46 | ``Erik | I got mine at the simh site |
| 17:39.59 | starseeker | hah - no license info though http://www.softwarepreservation.org/projects/LISP/lisp1.5/ |
| 17:41.06 | starseeker | this one still has unisys propritary notes on it: http://www.frobenius.com/source.htm |
| 17:52.55 | starseeker | ah: ftp://ftp.informatimago.com/pub/free/develop/lisp/lisp15-0.0.2.tar.gz |
| 17:54.04 | starseeker | probably would have to check with MIT, but that might be usable... |
| 18:11.03 | starseeker | hmm. http://c2.com/cgi/wiki?LispImplementationsWrittenInLisp |
| 18:40.53 | kunigami | brlcad: thank you for the clarification. I couldn't get a draft of the proposal. I'm considering focusing in the two other proposals I've submitted. |
| 20:13.47 | CIA-52 | BRL-CAD: 0399.30.66.238 07http://brlcad.org * r2795 10/wiki/User:Bhinesley: GSoC proposal information removed (has been submitted) |
| 20:25.19 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) |
| 20:25.43 | AbhijitKane | I've submitted a draft proposal on the GSOC website. |
| 21:40.23 | kunigami | hi, is there some reference on rt stand-alone usage? I've seen mged reference, but I'm confused with rt, specially with defining the objects. thanks! |
| 21:44.40 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) |
| 22:21.28 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) |
| 22:21.50 | kunigami | sorry, I was too hasty in asking that. I found a lot of documentation in brlcad/doc/. |
| 22:24.04 | brlcad | np |
| 23:28.36 | *** join/#brlcad dassouki (~ahmed@142.167.162.112) |
| 23:29.39 | dassouki | this might seem like a silly question, but where can I find sets of plans for architecture related projects |
| 23:29.42 | dassouki | like full projects |
| 23:51.11 | *** join/#brlcad dassouki (~ahmed@142.167.162.112) |