| 00:01.26 | zero_level | ``Erik I think we will require smth of this kind |
| 00:01.45 | zero_level | #define icv_add(a,b,c,n) do { \ |
| 00:01.46 | zero_level | <PROTECTED> |
| 00:01.46 | zero_level | <PROTECTED> |
| 00:01.46 | zero_level | <PROTECTED> |
| 00:01.46 | zero_level | <PROTECTED> |
| 00:01.48 | zero_level | <PROTECTED> |
| 00:01.50 | zero_level | <PROTECTED> |
| 00:01.53 | zero_level | <PROTECTED> |
| 00:04.09 | zero_level | <PROTECTED> |
| 00:30.50 | ``Erik | if the types are packed instead of named, HADD2() seems to be the macro |
| 00:31.19 | ``Erik | and as much as I adore pointer math, that certain case might be better served with a for loop and 'i' iterator for readability |
| 00:32.58 | ``Erik | (it's a tricky balance, but the real goal is to make it easily readable to a human... excessive abstraction makes it hard to read, excessive conciseness makes it hard to read... :) it's an art!) |
| 00:34.22 | ``Erik | my gut feeling is that a pixel op can be a macro, a full image thing should be a func... |
| 00:41.36 | zero_level | also ``Erik I want to ask an important point here. |
| 00:42.28 | zero_level | Since we are making this library for use in brlcad only do we assume the correctness of the arguments in the function by application programmer or check them every where ? |
| 00:43.08 | zero_level | for eg. check in icv_oper for size of the input images and the fact that they must be equal |
| 02:43.11 | zero_level | ``Erik, brlcad: do we create seperate icv_math.h for these macros ? |
| 02:43.52 | zero_level | in src/libicv |
| 03:00.54 | brlcad | [A |
| 03:08.35 | *** join/#brlcad zero_level__ (~zero_leve@117.205.28.89) |
| 05:37.57 | Notify | 03BRL-CAD Wiki:Level zero * 5511 /wiki/User:Level_zero/GSOC13/logs: logs 24th July |
| 06:48.42 | Notify | 03BRL-CAD:phoenixyjll * 55833 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/intersect.cpp): Begin to implement curve-curve intersections. More tests and improvements are needed. |
| 07:02.08 | *** join/#brlcad kesha (~kesha@49.249.1.15) |
| 07:32.50 | Notify | 03BRL-CAD:phoenixyjll * 55834 brlcad/trunk/src/libbrep/intersect.cpp: overlap_tolerance is used now. |
| 07:43.39 | Notify | 03BRL-CAD:phoenixyjll * 55835 brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Add the new CCI and CSI functions to brep_debug.cpp. |
| 07:50.44 | Notify | 03BRL-CAD Wiki:Phoenix * 5512 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 2 */ |
| 08:14.54 | *** join/#brlcad kesha (~kesha@49.249.1.15) |
| 08:41.48 | *** join/#brlcad kesha (~kesha@49.249.1.15) |
| 08:54.47 | Notify | 03BRL-CAD:phoenixyjll * 55836 brlcad/trunk/src/libbrep/intersect.cpp: Fix a fatal typo. |
| 09:00.43 | Notify | 03BRL-CAD:phoenixyjll * 55837 brlcad/trunk/src/libbrep/intersect.cpp: Add logic in case that one side may fail. |
| 09:37.13 | *** join/#brlcad kesha (~kesha@49.249.1.15) |
| 09:40.30 | Notify | 03BRL-CAD:phoenixyjll * 55838 brlcad/trunk/src/libbrep/intersect.cpp: Fix an opposite logic, and use pointers for ON_X_EVENTs. |
| 09:52.25 | *** join/#brlcad kesha (~kesha@49.249.1.15) |
| 09:54.58 | *** join/#brlcad kesha__ (~kesha@49.249.1.15) |
| 10:02.03 | Notify | 03BRL-CAD:phoenixyjll * 55839 brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Fix wrong index... |
| 10:09.15 | *** join/#brlcad kesha__ (~kesha@49.249.191.238) |
| 10:51.07 | *** join/#brlcad kesha__ (~kesha@49.249.9.138) |
| 11:31.35 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b115:5b2d:0:41:62b8:7a01) |
| 11:44.55 | *** join/#brlcad vladbogo (~vlad@86.121.102.76) |
| 12:15.09 | archivist | after reading an email, wonders why object oriented means optimised ! |
| 12:20.29 | *** join/#brlcad vladbogo_ (~vlad@86.124.248.7) |
| 12:36.05 | *** join/#brlcad vladbogo__ (~vlad@86.121.100.209) |
| 12:58.31 | *** join/#brlcad vladbogo__ (~vlad@86.121.103.81) |
| 13:04.08 | *** join/#brlcad vladbogo_ (~vlad@86.121.100.72) |
| 13:18.48 | brlcad | archivist: you're welcome to point that out ;) |
| 13:22.06 | *** join/#brlcad vladbogo__ (~vlad@86.121.102.222) |
| 13:40.42 | ``Erik | src/libged/simulate/simcollisionalgo.h:85: error: cannot allocate an object of abstract type 'btRTCollisionAlgorithm' |
| 13:41.45 | ``Erik | kinda looks like a struct blah_s { struct blah_s thing; }; type issue to me, but it's been a long time since I've mucked with that much c++ O.o is there a pattern this should be shifted to (maybe seperate declaration and definition?) |
| 13:55.42 | brlcad | ``Erik: how/where are you just now seeing this? |
| 13:56.17 | vladbogo__ | hi all |
| 13:56.44 | vladbogo | I have just managed to integrate Qt in the brlcad cmake build |
| 13:57.57 | vladbogo | but I have a small problem: i get some warnings in the qt files. In order to do the testing I've disabled the strict compilation but there is any way to disable it just for the Qt? Or should I search for another solution? |
| 13:59.05 | *** join/#brlcad vladbogo_ (~vlad@86.121.102.115) |
| 14:16.35 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 14:16.37 | *** join/#brlcad kesha__ (~kesha@49.249.9.138) |
| 14:18.25 | *** join/#brlcad cstirk (~quassel@96.255.19.39) |
| 14:18.42 | *** join/#brlcad kesha (~kesha@49.249.9.138) |
| 14:27.59 | ``Erik | brlcad: been seeing it for a while on a machine that has bullet installed, have just been not building there or disabling bullet... (I thought I'd mentioned it a long time ago, but *shrug* I may be mistaken, or was unclear at the time, or things were busy, or ...) |
| 14:29.48 | ``Erik | the machine is osX.8 with the gcc and clang from the latest xcode, bullet installed from svn (my laptop at home) |
| 14:35.34 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 14:42.42 | *** join/#brlcad kesha__ (~kesha@49.249.9.138) |
| 15:52.28 | ``Erik | seems the bullet api changed a bit between 2.80 (mar 2012) and 2.81 (oct 2012) |
| 15:56.45 | brlcad | I think we may have a GCI patch that fixes it |
| 15:56.51 | brlcad | sounds familiar |
| 16:00.33 | zero_level | hi brlcad, ``Erik |
| 16:04.06 | ``Erik | zero_level: extra checks are probably unnecessary but probably wouldn't hurt as we're not at a point of worrying about performance |
| 16:04.40 | ``Erik | zero_level: if you need new 'private' macros/functions, use a local header so we can keep the interface minimal/simple |
| 16:05.01 | ``Erik | (so src/libicv/icv_math.h which does not get installed) |
| 16:06.23 | zero_level | also ``Erik and brlcad have u seen my mail regarding existing use of libicv on brlcad-devel? |
| 16:06.40 | zero_level | do i submit a patch for icv_math.h ? |
| 16:10.28 | ``Erik | zero_level: don't do _icv, just update rt, libged and remrt... rt has functionality to translate the rgb doubles to [0-255] packed char arrays (!), so merely using a function to write the doubles in would be preferable |
| 16:12.19 | ``Erik | yeah, a patch should be fine.. I've having issues with sourceforge, so I've only gotten around to applying one patch and haven't really looked at the others much :/ |
| 16:12.26 | zero_level | I hope they use only Pix format . :-) |
| 16:13.01 | ``Erik | brlcad: I have no edit icon in the top right of the ticket, unless I'm really blind O.o I see an rss icon and a mail 'subscribe' icon, that's it |
| 16:14.18 | ``Erik | zero_level: rt converts the rgb doubles to pix format as it's raytracing, I'm not sure about the others but I'd assume they're all rigged up to use pix as the intermediate format right now... |
| 16:19.35 | *** join/#brlcad vladbogo__ (~vlad@86.121.103.51) |
| 16:20.34 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-vfaxbrnvcosfmimy) |
| 16:29.53 | zero_level | brlcad : read your email. |
| 16:34.15 | zero_level | ``Erik,brlcad this kind of representation may have issues while saving and reading. Although colour channel -> representation may become easier. |
| 16:34.41 | zero_level | *colour space -> conversions may become easier |
| 17:00.22 | ``Erik | yeh, converting to something like cmyk for print would be neat down the road |
| 17:07.19 | zero_level | ``Erik what do u suggest should we go with double** data or struct pixel_s *data; |
| 17:13.05 | ``Erik | the struct approach is probably easier to read, and seems to be how OpenEXR approaches it, so probably not a bad ide |
| 17:13.08 | ``Erik | idea |
| 17:13.39 | zero_level | yes const Rgba *pixels |
| 17:13.54 | zero_level | as they implement in openexr ! |
| 17:18.19 | *** join/#brlcad caen23_ (~caen23@92.83.178.201) |
| 17:30.15 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-nocyhhlktjpqlwpm) |
| 17:30.16 | *** join/#brlcad vladbogo__ (~vlad@86.121.103.51) |
| 17:31.18 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b10b:81fb:0:45:24f7:b801) |
| 18:05.14 | *** join/#brlcad vladbogo__ (~vlad@86.124.248.7) |
| 18:26.05 | *** join/#brlcad vladbogo_ (~vlad@86.121.99.159) |
| 18:31.12 | brlcad | zero_level: techincal discussions in public please :) |
| 18:33.14 | brlcad | ``Erik: not to ask the obvious, but are you logged into sourceforge (edit icon) |
| 18:35.13 | brlcad | ``Erik: ah, I think I foudn the issue -- allure defaulted all developers to no permissions |
| 18:35.16 | brlcad | should be fixed now |
| 18:41.25 | archivist | brlcad, re buildbot question, I used to run two slaves from the mariadb fork of mysql, interesting experience, specially if the controller of the system tries to up the parallelism of the build and test process |
| 18:46.16 | *** join/#brlcad vladbogo__ (~vlad@86.121.98.183) |
| 18:58.54 | brlcad | archivist: interesting in what way? |
| 19:00.37 | *** join/#brlcad vladbogo_ (~vlad@86.121.100.180) |
| 19:01.24 | brlcad | zero_level: so one of the undertones that was not mentioned in my message about separating the channels is that I'd also like to have a per-pixel depth buffer |
| 19:03.03 | brlcad | RGBA is great if all you need to deal with is RGBA data (which is exactly what exr does) |
| 19:04.03 | brlcad | fully generalizing the image construct entails not assuming RGB, not assuming an alpha channel |
| 19:04.11 | brlcad | it's just channels of information |
| 19:04.22 | brlcad | 1 or more, each with some prescribed meaning |
| 19:05.01 | archivist | brlcad, made the PC unusable, was using this box for ubuntu 8.04 and another box for the same OS but with realtime extensions on a cnc machine |
| 19:05.31 | archivist | depending on the phase of the build/test |
| 19:07.16 | archivist | so there are trade offs between devs chasing results and the volunteer running a slave |
| 19:12.18 | *** join/#brlcad vladbogo__ (~vlad@86.121.102.245) |
| 19:14.00 | brlcad | I wasn't even considering volunteer compute nodes yet |
| 19:14.02 | brlcad | :) |
| 19:26.42 | zero_level | ``Erik, brlcad what i see here is that each of two methods have there +pos and -ves. |
| 19:31.15 | *** join/#brlcad kesha (~kesha@49.249.9.138) |
| 19:32.04 | brlcad | zero_level: do you think you can itemize/summarie them? |
| 19:36.51 | zero_level | brlcad here u go |
| 19:36.56 | zero_level | Storing them as double** Allows multiple formats for storing and loading images lot of preprocessing has to be done. Three arrays will have to brought. we could use vmath.h Although some operations like pow, scale, divide are still not in vmath thus will have to be implemented. |
| 19:37.33 | zero_level | storing them as RGBA Doesnot allow any other format. Not okay if we data of say BW format, HSV format, or CMYKA format Good for storing images in openexr format Expected to give good performance in processing since only one array will have to be brought to the cache while acessing an array of images. have to design icv_math.h |
| 19:38.19 | zero_level | i dont know if i have left few others |
| 19:39.12 | brlcad | hm, so the intent is not actually to USE vmath, just that the structures are similar and can be indexed directly |
| 19:39.44 | brlcad | vmath would only work for an interleaved array, i.e., a double *rgba |
| 19:40.53 | zero_level | ok cut the vmath thing. it is easier to build those macros. |
| 19:41.39 | brlcad | the performance claim would need to be profiled, I'd be doubtful either solution will be a performance issue |
| 19:41.58 | zero_level | ok |
| 19:42.22 | brlcad | an array of structs may or may not have cache alignment issues, may or may not stride cleanly |
| 19:42.50 | brlcad | an individual array (of either just one channel or interleaved rgba) will stride cleanly |
| 19:44.00 | brlcad | the question for caching is whether the next pixel is likely in cache or not and how many independent cache lines you have |
| 19:44.18 | brlcad | we could go for the best of both worlds |
| 19:44.26 | brlcad | a dynamic number of channels, but one array |
| 19:44.29 | brlcad | interleaved |
| 19:44.43 | brlcad | add another field to indicate how many channels there are |
| 19:45.10 | brlcad | so it could default to num_chan=4 for an RGBA array |
| 19:45.44 | brlcad | (i.e., a double *data; size_t channels;) |
| 19:46.26 | zero_level | then i believe we could use the char and double format by using void* |
| 19:46.39 | zero_level | and having macro like thesee |
| 19:47.21 | zero_level | UCHAR1C, UCHAR3C UCHAR4C and DOUBLE1C, DOUBLE3C ... |
| 19:47.42 | zero_level | this will be very handy i believe |
| 19:48.06 | zero_level | both keeping the old formats intact and looking for new versions |
| 19:50.40 | zero_level | brlcad : what do u say ? |
| 19:51.01 | brlcad | converting void pointers is very problematic |
| 19:51.51 | *** join/#brlcad Kimz (~AndChat32@49.249.9.138) |
| 19:52.48 | brlcad | that also sounds crazy messy API-wise to deal with implementation-wise for the same aforementioned reasons |
| 19:53.14 | brlcad | something that takes an image needs to handle all the possible encoding types, and that becomes bad juju |
| 19:53.33 | brlcad | handling everything as double would avoid that |
| 19:54.26 | brlcad | a possible compromise might be to have a function that returns data in a specific format, like "double RGBA" to "char RGB", for functions we don't want to rewrite |
| 19:55.45 | brlcad | the only reason for abstracting the type would be memory/performance savings, and we don't yet have profile information to indicate it's a problem |
| 19:55.57 | vladbogo__ | hi all |
| 19:57.58 | vladbogo | brlcad: O have successfully integrated Qt in the brlcad cmake but I have a small problem: I get warnings during compilation in the Qt files. For testing I have disabled strict compilation but there is any way to do this just for Qt? |
| 19:58.55 | brlcad | vladbogo: it entirely depends what the warnings are, whether you can quiet them |
| 19:59.28 | vladbogo | the warnings I get are for float comparison using == |
| 19:59.35 | brlcad | we can turn off warnings for specific files, and do for much of our c++ sources, but sometimes we can quell them too |
| 19:59.49 | brlcad | and are you doing a float comparison? :) |
| 20:00.28 | vladbogo | no:) in the Qt files I've included I suppose there are some float comparisons |
| 20:00.54 | brlcad | just including a header shouldn't involve any comparisons... |
| 20:01.08 | brlcad | using a macro that involves a comparison might |
| 20:19.13 | vladbogo | brlcad: sorry for the delay: it took a while until it compiled. There are some inline functions defined in the header |
| 20:19.32 | brlcad | ahhh |
| 20:20.40 | vladbogo | I am currently not using that particular file but it's included in the cmake build |
| 20:26.15 | vladbogo | also I have another question: to successfully build Qt5 using cmake position independent code must be enabled. Where should I set the flag in order to maintain consistency? At the moment I set the flag in the libdm/CMakeLists |
| 20:32.40 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11f:68a:0:4c:cc98:8e01) |
| 20:36.43 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11f:68a:0:4c:cc98:8e01) |
| 20:42.15 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11f:68a:0:4c:cc98:8e01) |
| 20:45.24 | *** join/#brlcad Kimz (~AndChat32@49.249.9.138) |
| 20:48.34 | *** join/#brlcad mpictor (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb) |
| 21:02.04 | zero_level | also brlcad it is interesting to see that the opencv library stores it is char* imagedata for all its formats |
| 21:03.20 | zero_level | now to use double pointer it points this way douple_p = (double*) img->imagedata; |
| 21:05.49 | zero_level | this does it in interleaved fashion. Also preserves current functionality. And will be helpful for implementing high resolution images. |
| 21:06.39 | zero_level | this will require addition of nchannels, and resolution info. |
| 21:37.36 | ``Erik | zero_level: png stores packed byte arrays... we want the most flexible internal format... the encapsulation is the important part, the internal stuff could all be c++ and expose a nice simple C interface and it'd be all good... internal representation doesn't even have to be RGB, it could be something else as long as it's a superset of the data we want to wrangle |
| 21:37.48 | *** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb) |
| 21:38.38 | *** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb) |
| 21:54.43 | zero_level | ok ``Erik |
| 22:20.21 | *** join/#brlcad vladbogo (~vlad@86.121.102.245) |
| 22:29.11 | *** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb) |
| 22:52.15 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 23:01.45 | brlcad | zero_level: you really seem adamant about needing or wanting to store multiple data lengths... at least you keep coming back to that point...but why? |
| 23:02.46 | brlcad | a char* encoding that can be cast to double* just means that it's bytes presumably corresponding to an array of doubles |
| 23:02.51 | *** join/#brlcad vladbogo (~vlad@86.121.102.245) |
| 23:03.44 | brlcad | that's only useful if that char* might also be other lengths, which I don't yet see a need for until a profile shows that it's an order of magnitude problem |
| 23:04.29 | brlcad | zero_level: but you have raised a couple really good points about performance and at least three data structure options -- I think you should test them |
| 23:04.35 | zero_level | brlcad : i think when we could do that why not do it. In this case the positives are we will get support for current functionalities. |
| 23:05.34 | brlcad | well, I've stated several reasons why not |
| 23:06.04 | brlcad | there are positives and negatives |
| 23:06.08 | zero_level | brlcad: point regarding testing them all is great suggestion. But then that will be a 2month project in itself ;) |
| 23:06.14 | brlcad | the negatives seem huge to me |
| 23:06.26 | brlcad | no no |
| 23:06.57 | brlcad | you should be able to write a test in less than an hour for all three |
| 23:07.26 | brlcad | at best a couple hours to try some things, testing is supposed to be quick and just evaluates a simple concept |
| 23:07.49 | brlcad | if it takes you more than a couple hours, you're probably doing something VERY wrong ;) |
| 23:08.21 | zero_level | ok, you mean a code which is not part of brlcad src. Yes that could be done. |
| 23:09.08 | zero_level | i thought changing the existing usage evertime i implement a new type of data. |
| 23:09.27 | brlcad | I mean a simple test.c file with a main() that tests struct { double r, double g, ... } vs double *rgb; vs double **rgb |
| 23:11.17 | brlcad | zero_level: how much memory do you have? |
| 23:11.27 | zero_level | 6 GB |
| 23:11.33 | zero_level | physical memory |
| 23:11.55 | brlcad | okay, so you should be able to create a test image that's 10000x10000 |
| 23:14.15 | *** join/#brlcad vladbogo_ (~vlad@86.124.248.122) |
| 23:14.32 | brlcad | allocate it, test time to generate random values, test time to fill a data structure with random values, test time to read all the data structure values from start to finish, test time from finish to start, test time to read half of them randomly, test time to zero the image |
| 23:14.52 | brlcad | do that for all three |
| 23:14.59 | brlcad | if you use libbu, it'll make timing easy |
| 23:15.32 | brlcad | gcc -L/path/to/brlcad/lib -L/path/to/brlcad/include test.c -lbu |
| 23:15.50 | brlcad | er, gcc -L/path/to/brlcad/lib -I/path/to/brlcad/include test.c -lbu |
| 23:22.44 | zero_level | i am using the fact that we store rgb of a pixel and also read rgb of pixel at a time |
| 23:23.32 | zero_level | *a particular pixel at a time. and not the r channel and g channel and.. as a whole |
| 23:24.00 | brlcad | relevance? |
| 23:25.31 | zero_level | because i guess that is how we will need in the operations. that is say pix(244,233) that is (244,233)th pixel and all the channels of that pixel |
| 23:25.50 | brlcad | you misunderstand ... |
| 23:25.56 | brlcad | and so what? |
| 23:26.20 | brlcad | we read/write pixels and that is how we will need in the operations ... and so what? |
| 23:26.57 | brlcad | you're not saying something, and I don't know what that is |
| 23:27.34 | zero_level | i think i got u. see u with the results. :-) ;) |
| 23:27.44 | brlcad | okay |
| 23:27.50 | brlcad | yes, that is the *entire* point of testing |
| 23:28.10 | brlcad | it might matter a lot, it might not matter at all |
| 23:28.26 | brlcad | it might be good for some things and bad for others |
| 23:28.43 | brlcad | that's the point of the 6 test timings |
| 23:28.55 | brlcad | and the three data structures (and any others you want to compare) |
| 23:29.21 | brlcad | keep it as simple and small as possible, so we can look and compare fairly |
| 23:30.05 | brlcad | maybe show me or erik after you get one structure set up so we can make sure you're testing right |
| 23:30.27 | brlcad | bu_gettime() will help with timing |
| 23:30.31 | zero_level | the source code or the resutl ? |
| 23:30.42 | brlcad | source code |
| 23:31.09 | brlcad | this should literally be less than 100 lines of code for one structure, probably less than 50 |
| 23:32.20 | zero_level | i am not sure about that |
| 23:32.38 | zero_level | but do we need the time for random values ? |
| 23:32.47 | zero_level | will it not be same for all of them |