| 01:55.29 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) | |
| 02:24.29 | *** join/#brlcad xth1 (~thiago@201.82.137.47) | |
| 02:47.49 | brlcad | starseeker: http://brlcad.org/tmp/eto_diff.jpg |
| 02:48.28 | brlcad | 9 off-by-many (9*3 = 27 bytes off-by-many) |
| 02:53.57 | brlcad | at a glance, I'd question whether the brep/nurbs grazing hits and misses are correct |
| 02:54.13 | brlcad | iff the surfaces actually are defined correctly/exactly |
| 04:40.21 | starseeker | brlcad: yeah, quite possible |
| 05:40.58 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.25.149) | |
| 06:54.56 | *** join/#brlcad anuragmurty (~anurag@14.139.128.11) | |
| 07:31.24 | CIA-65 | BRL-CAD: 03Anoop 07http://brlcad.org * r3675 10/wiki/User:Anoop/Logs: |
| 09:04.18 | *** join/#brlcad ksuzee (~ksuzee91@46.149.82.166) | |
| 09:10.57 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 10:20.50 | *** part/#brlcad anuragmurty (~anurag@14.139.128.11) | |
| 10:22.24 | *** join/#brlcad kane_ (~kane@e181160138.adsl.alicedsl.de) | |
| 11:48.14 | CIA-65 | BRL-CAD: 03bob1961 * r50573 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Added a perspective angle preference. |
| 11:50.12 | CIA-65 | BRL-CAD: 03bob1961 * r50574 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added cadwidgets::Ged::perspective_all |
| 13:02.01 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 13:26.26 | brlcad | hello anuragmurty |
| 13:26.37 | anuragmurty | hi! |
| 13:28.09 | anuragmurty | hello sean! |
| 13:41.52 | brlcad | so what are you up to today? |
| 13:45.20 | CIA-65 | BRL-CAD: 03brlcad * r50575 10/brlcad/trunk/configure.ac: need libz even if we build opennurbs ourselves |
| 14:00.01 | *** join/#brlcad anuragmurty1 (~anurag@14.139.128.12) | |
| 14:03.04 | anuragmurty1 | brlcad: i was reading a paper on obtaining the voxels using raycasting. |
| 14:03.05 | anuragmurty1 | (A Low Cost Antialiased Space Filled Voxelization Of Polygonal Objects). |
| 14:03.56 | anuragmurty1 | i am just seeing if the algorithm is suited to the needs. |
| 14:06.28 | brlcad | anuragmurty1: you hopefully do realize that your problem is considerably simpler than what that paper is deadling with |
| 14:06.51 | brlcad | the only thing that paper offers of value that I see is to use spatial partitioning for building up the voxel result |
| 14:07.10 | brlcad | our raytrace library will already give you perfect information on where material exists and does not exist |
| 14:07.47 | brlcad | and is not limited to polygonal mesh geometry |
| 14:09.57 | brlcad | have you looked at the BRL-CAD references that were mentioned earlier yet? |
| 14:10.51 | anuragmurty1 | brl-cad : yes. i was just reading up on some references etc right now. |
| 14:11.01 | anuragmurty1 | rt, rtweight i have |
| 14:12.01 | brlcad | gqa is the big one that does exactly what you need, but is the most complex |
| 14:12.04 | anuragmurty1 | i have not been able to do gqa yet. I am going to complete reading the code |
| 14:12.09 | anuragmurty1 | yes |
| 14:12.40 | anuragmurty1 | I did realise it wasn't too simple. will be doing that now. |
| 14:13.16 | brlcad | ideally, you'd perform the same adaptive sampling that gqa does, but as a library function -- then make gqa use that library |
| 14:13.46 | brlcad | then use that library to create actual volumetric geometry within mged |
| 14:14.34 | brlcad | anuragmurty1: getting commit access established is still priority #1 right now, so see if you can get someone to review your recent patch |
| 14:14.51 | brlcad | perhaps create a second patch based on the e-mail I sent you last night for booleanize |
| 14:15.33 | brlcad | that shouldn't take more than a half-hour and if done flawlessly, would get you established |
| 14:17.02 | anuragmurty1 | brlcad:ok thank you for the pointers. I will start working on it now. And on understanding the gqa part too. |
| 14:17.44 | brlcad | start with rtweight or rtarea before tackling gqa -- or even our rtexample on the wiki |
| 14:18.23 | brlcad | there's a lot of complexity involved and if you don't understand those basic parts first, you won't understand gqa |
| 14:18.44 | anuragmurty1 | ok i will get started right away. |
| 14:19.08 | anuragmurty1 | though i am done with rt,rtweight |
| 14:19.10 | brlcad | after the booleanize unit test patch, I suggest writing this from scratch: http://brlcad.org/wiki/Example_Application |
| 14:19.53 | brlcad | make sure you understand *everything* in that example, and ask questions |
| 14:20.06 | anuragmurty1 | sure, i will do that! |
| 14:20.45 | anuragmurty1 | just one more thing. the test_bitv was my first patch. How do i get someone to review it? |
| 14:21.20 | anuragmurty1 | i want to see if i am going wrong somewhere before i write another one, thats all. |
| 14:22.28 | brlcad | anuragmurty1: technically your second no? didn't you send a booleanize unit test? |
| 14:23.43 | anuragmurty1 | oh yes. that was there. But i did not submit it on the tracker. |
| 14:23.56 | brlcad | you ask an existing dev to review it -- if you did your part and it applies, builds, and runs cleanly then it'll be trivial to review |
| 14:24.34 | anuragmurty1 | ok, i will do that. thank you. |
| 14:49.19 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 14:51.06 | *** join/#brlcad anuragmurty2 (~anurag@14.139.128.12) | |
| 14:59.28 | CIA-65 | BRL-CAD: 03brlcad * r50576 10/brlcad/trunk/NEWS: nick fixed a bug in the keypoint selection of extrude geometry while fixing a coverity-detected invalid array index (cid 426) |
| 15:01.21 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 15:03.36 | CIA-65 | BRL-CAD: 03brlcad * r50577 10/brlcad/trunk/NEWS: |
| 15:03.36 | CIA-65 | BRL-CAD: nick fixed a bug in the conversion of ascii hyp objects into .g format where it |
| 15:03.36 | CIA-65 | BRL-CAD: would fall-through and try to create an eto of the same name. this undoubtedly |
| 15:03.36 | CIA-65 | BRL-CAD: resulted in either a crash, (likely) error message saying it couldn't make the |
| 15:03.36 | CIA-65 | BRL-CAD: eto, or eto replacing the hyp. fixed due to coverity cid 335, in r48532. |
| 15:07.50 | CIA-65 | BRL-CAD: 03brlcad * r50578 10/brlcad/trunk/NEWS: |
| 15:07.50 | CIA-65 | BRL-CAD: tom browder fixed memory leaks in the comgeom-g importer. nick also fixed a |
| 15:07.50 | CIA-65 | BRL-CAD: couple memory leak errors detected by coverity. as a single-use-then-exit tool, |
| 15:07.50 | CIA-65 | BRL-CAD: the impact of the memory leaks is minor, but potentially user-visible if there |
| 15:07.50 | CIA-65 | BRL-CAD: are lots of geometry import failures (for whatever reason). |
| 15:09.46 | kane_ | Is the ogl displaymanager closed by the ogl_close() function or is there an alternative to close it? |
| 15:10.39 | brlcad | kane_: an application could always exit |
| 15:11.44 | kane_ | I have done a backtrace, ogl_close will never called if the window is closed, is this normal? |
| 15:11.55 | kane_ | (not the main window) |
| 15:13.47 | CIA-65 | BRL-CAD: 03brlcad * r50579 10/brlcad/trunk/NEWS: numerous enhancements were made to NMG processing during the coverity defect fixing including book-keeping fixes (incrementing pointer instead of value), memory allocation problems, logic problems, and more. |
| 15:16.41 | CIA-65 | BRL-CAD: 03brlcad * r50580 10/brlcad/trunk/NEWS: |
| 15:16.41 | CIA-65 | BRL-CAD: nick improved the obj-g importer making it more robustly handle bad geometry. |
| 15:16.41 | CIA-65 | BRL-CAD: more specifically, if faceuse creation fails, it'll now propagate that failure |
| 15:16.41 | CIA-65 | BRL-CAD: and skip those faces (instead of propagating bad geometry). fixed in r48312. |
| 15:21.37 | CIA-65 | BRL-CAD: 03brlcad * r50581 10/brlcad/trunk/NEWS: nick added support in r47659 for braces around shader parameters, e.g. "plastic {sp .5 di .5}" as well as "plastic sp=.5 di=.5" to help improve usability and interaction with the mater command. |
| 15:24.19 | CIA-65 | BRL-CAD: 03brlcad * r50582 10/brlcad/trunk/src/libbu/parse.c: use BU_STR_EQUIV for case-insensitive checking when a shader string includes stack or envmap. |
| 16:10.00 | CIA-65 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3676 10/wiki/User:Phoenix/GSoc2012/Reports: /* Community Bonding */ |
| 16:12.16 | CIA-65 | BRL-CAD: 03cprecup * r50583 10/brlcad/trunk/src/libbu/test_booleanize.c: Fixed the style and formatting |
| 16:58.05 | CIA-65 | BRL-CAD: 03n_reed * r50584 10/brlcad/trunk/src/other/step/src/ (5 files in 3 dirs): Apply changes based on SCL git 6e9b5a7. Creates GetLiteralStr function to implement and extend functionality common to SDAI_String::STEPread and PushPastString. |
| 17:09.20 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.16.9) | |
| 17:35.16 | brlcad | hello Stattrav_, any progress lately? |
| 17:36.23 | Stattrav_ | yeah, looking into submitting the patch right now. Was going through the bugs list |
| 17:36.27 | Stattrav_ | and TODO list |
| 17:36.49 | Stattrav_ | and there is none except the one I mentioned before. |
| 17:38.13 | brlcad | Stattrav_: "there is none" means what? :) |
| 17:38.25 | brlcad | there are lots of bugs and todo items.. |
| 17:38.37 | Stattrav_ | sorry the one close to what I am working on. |
| 17:38.49 | Stattrav_ | Sorry about that ambiguity again |
| 17:39.16 | Stattrav_ | http://i.imgur.com/oRQdM.png <- Fixing this part counts as a patch ? |
| 17:40.08 | brlcad | patch just means "change to the code" |
| 17:40.21 | brlcad | so if you change that and fix the FIXME, sure that'd be a patch |
| 17:40.40 | Stattrav_ | no, what you wanted is the code being better isnt it ? |
| 17:41.02 | brlcad | well of course -- a patch that doesn't improve anything isn't useful :) |
| 17:41.41 | brlcad | so you could work on that fixme, sure |
| 17:41.43 | Stattrav_ | so fixing this is useful right, |
| 17:41.54 | brlcad | any place you see a FIXME is probably useful |
| 17:42.06 | brlcad | almost certainly useful by definition |
| 17:42.08 | Stattrav_ | sure, already on it. |
| 17:42.23 | Stattrav_ | thanks. |
| 17:42.26 | brlcad | another thing you could work on would be fixing the output from pixdiff |
| 17:43.21 | brlcad | it presently tracks and reports bytes different but should be doing so pixel at a time (and ideally still work for 1-channel bw or 3-channel pix inputs) |
| 17:43.49 | brlcad | benchmark calls pixdiff, so it's even related to your project |
| 17:44.38 | Stattrav_ | I saw that it calls a pixcmp tool. this should be a part of it right |
| 17:45.47 | brlcad | that's what I meant, pixcmp |
| 17:45.53 | brlcad | not pixdiff |
| 17:46.10 | brlcad | though those tools are very much interrelated and could be merged too |
| 17:47.59 | Stattrav_ | ohh, give me a few moments looking into the source |
| 17:59.07 | Stattrav_ | yup |
| 17:59.49 | kane_ | I have submitted a trivial patch. I thought maybe it is better to provide it, than work for days on the dm-ogl bug... But I will try to solve it, too. |
| 18:00.07 | brlcad | Stattrav_: if you attempt to merge them, you should document a precise usage statement first that describes how it'll work |
| 18:01.40 | brlcad | i'd suggest mirroring it after diff(1) as much as possible but still supporting pixcmp's scriptability with summary output and return code(s) and pixdiff's scriptability as an image filter (redirecting inputs/outputs) |
| 18:02.09 | brlcad | kane_: okay, someone should check it out soon |
| 18:03.45 | brlcad | kane_: there are a variety of libdm-related TODO entries that you could look into that are probably a lot simpler than any of the dm-ogl bugs |
| 18:04.31 | Stattrav_ | brlcad: I need some more time to understand how the .pix files are formatted shall get back to you in 20 |
| 18:04.35 | Stattrav_ | minutes that is |
| 18:07.07 | CIA-65 | BRL-CAD: 03brlcad * r50585 10/brlcad/trunk/BUGS: out of date dm bugs seem to be no longer an issue |
| 18:07.09 | brlcad | or I could just tell you :) |
| 18:07.31 | ``Erik | http://youtu.be/1pgm8I0B8bY gallardo accident |
| 18:07.36 | brlcad | or run "brlman pix" |
| 18:08.39 | Stattrav_ | oh sure |
| 18:08.41 | Stattrav_ | thanks |
| 18:10.17 | brlcad | it's a simple 3-channel raw image |
| 18:10.20 | brlcad | rgbrgbrgb |
| 18:10.45 | brlcad | bw is the same, but 1-channel |
| 18:13.20 | Stattrav_ | ohh 3 unsigned chars |
| 18:15.26 | Stattrav_ | aah now I understood the code around 232 |
| 18:15.36 | Stattrav_ | line numbers that is of pixcmp.c |
| 18:20.05 | brlcad | do you understand what the problem is? |
| 18:21.09 | Stattrav_ | so it goes comparing characters in each pixel if the value is the same or what it differs by |
| 18:21.36 | brlcad | that's what it does, yes |
| 18:21.40 | brlcad | what's the bug, though? |
| 18:21.45 | Stattrav_ | not clear yet |
| 18:22.56 | brlcad | reporting off-by-one differences and off-by-many differences incorrectly |
| 18:23.32 | Stattrav_ | it gives a cumulative |
| 18:23.37 | brlcad | it'll say for example that 27 pixels were off-by-many, where there were really only 9 pixels different (9*3=27) |
| 18:23.48 | brlcad | bytes vs pixels mismatch |
| 18:24.09 | Stattrav_ | aah |
| 18:24.16 | Stattrav_ | yes |
| 18:24.27 | Stattrav_ | its counting for each of the channels |
| 18:24.37 | brlcad | it's not as simple as divide by 3 though |
| 18:25.53 | brlcad | do you have gimp or some other simple image editing program installed? |
| 18:26.13 | Stattrav_ | so if either of the channels is off, count+1, else continue. divide by 3 doesnt work because one of the channels might be equal |
| 18:26.21 | Stattrav_ | should let me check |
| 18:27.30 | Stattrav_ | installing gimp. Have a minimal install of arch at the moment. |
| 18:29.32 | brlcad | copy one of the same image files in pix/ and make simple edits to it, maybe paint 9 black/background pixels white, 9 red, 9 green, and 9 blue |
| 18:29.51 | brlcad | so you should get 9 off-by-many, and 27 off-by-one |
| 18:30.11 | brlcad | or something similar -- enough to tell that you got it correct |
| 18:30.37 | brlcad | needs to be verified -- VERY easy to introduce an error, so be careful and TEST |
| 18:31.15 | Stattrav_ | pix could not be loaded it says |
| 18:31.24 | brlcad | you should be able to open our pix files in gimp by renaming them to .raw and using File -> Open -> Select File Type -> Raw image data |
| 18:31.38 | Stattrav_ | aah |
| 18:32.02 | CIA-65 | BRL-CAD: 03starseeker * r50586 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: Do something slightly more intelligent about fbserv ports - also, have a use for a verbose flag now... |
| 18:34.20 | Stattrav_ | something is not right http://i.imgur.com/pgMNM.png |
| 18:34.30 | Stattrav_ | let me check that |
| 18:34.45 | brlcad | indeed |
| 18:34.55 | brlcad | looks like the starship pix file |
| 18:35.06 | brlcad | try moss.pix |
| 18:36.48 | Stattrav_ | http://i.imgur.com/emUsl.png |
| 18:37.15 | brlcad | yeah, so clearly not right :) |
| 18:37.24 | brlcad | you're not specifying something correctly to gimp |
| 18:37.24 | Stattrav_ | :( |
| 18:37.28 | Stattrav_ | yup |
| 18:37.29 | brlcad | you have to tell it what the image is |
| 18:38.12 | brlcad | it's a 512x512 3-channel, 8-bits-per-channel, image |
| 18:38.12 | Stattrav_ | I did select it as raw format |
| 18:38.37 | Stattrav_ | there is an alias pix image format |
| 18:38.44 | brlcad | the skewed lines implies you've specified the size or bytes or something else wrong |
| 18:39.01 | brlcad | it is not an alias pix file |
| 18:39.09 | CIA-65 | BRL-CAD: 03bob1961 * r50587 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: The previous fix to call glReadPixels with GL_RGB instead of GL_RGBA was flawed. This fixes the problem that was seen in to_png(). |
| 18:39.49 | Stattrav_ | yup it failed too. |
| 18:40.07 | Stattrav_ | could I write to the file directly ? |
| 18:40.08 | brlcad | we have an alias-pix converter, entirely different file type |
| 18:40.27 | brlcad | you could but that is ignoring the elephant in the room |
| 18:40.47 | brlcad | are you provided with any dialog or panel when you open the file as raw? |
| 18:41.03 | Stattrav_ | yeah |
| 18:41.07 | brlcad | how is it determining the number of channels, bit depth, size, etc |
| 18:42.05 | Stattrav_ | http://i.imgur.com/OMloF.png |
| 18:42.43 | brlcad | okay, there's your bug |
| 18:43.01 | Stattrav_ | which is ? |
| 18:43.25 | brlcad | http://i.imgur.com/OMloF.png is very clearly declared wrong |
| 18:43.51 | Stattrav_ | aah |
| 18:44.52 | CIA-65 | BRL-CAD: 03starseeker * r50588 10/brlcad/trunk/src/tclscripts/rtwizard/ (RaytraceWizard.tcl rtwizard.tcl): rtwizard.tcl is doing the sanity insurance for dbFile |
| 18:44.56 | brlcad | what are the image type options? |
| 18:45.47 | Stattrav_ | available in gimp ? |
| 18:46.08 | brlcad | http://i.imgur.com/OMloF.png lists Image Types as the first option you can specify |
| 18:46.11 | brlcad | what are the image type options? |
| 18:47.33 | Stattrav_ | RGB, RGB Alpha, RGB565, planar RGB, Indexed, Indexed Alpha |
| 18:49.34 | brlcad | having read our pix man page, which of those do you think is our pix file format? |
| 18:50.00 | Stattrav_ | reading about those formats now :) |
| 18:50.35 | brlcad | I gave you a hint earlier .. ;) |
| 18:51.08 | brlcad | 14:10 <@brlcad> it's a simple 3-channel raw image |
| 18:51.10 | brlcad | 14:10 <@brlcad> rgbrgbrgb |
| 18:51.14 | Stattrav_ | its rgb |
| 18:51.15 | Stattrav_ | yeah |
| 18:51.37 | brlcad | the rgb alpha adds a fourth channel: rgbargbargba |
| 18:51.43 | brlcad | for transparency |
| 18:51.49 | Stattrav_ | rgb should be the thing |
| 18:51.50 | brlcad | rgb565 is a bastard |
| 18:52.11 | brlcad | planar rgb is all the rrrrr...ggggg.....bbbb... without interleaving the values |
| 18:52.16 | Stattrav_ | not planar either |
| 18:53.32 | brlcad | indexed would be a lookup table based raw format of some sort |
| 18:53.41 | brlcad | presumably 1-channel |
| 18:53.50 | brlcad | so okay, RGB |
| 18:53.59 | brlcad | having read our pix man page, what's our offset? |
| 18:54.06 | *** part/#brlcad kane_ (~kane@e181160138.adsl.alicedsl.de) | |
| 18:54.08 | brlcad | is there a header? |
| 18:54.38 | Stattrav_ | none now |
| 18:54.46 | brlcad | good, so 0 |
| 18:54.53 | brlcad | what's the input image size? |
| 18:55.13 | Stattrav_ | 512x512 |
| 18:55.58 | brlcad | so that's all the image parameters |
| 18:56.50 | Stattrav_ | so why does one get 786432 matchings |
| 18:57.00 | brlcad | palette type RGB sounds right too, and there certainly isn't a palette file, so what does that give you? |
| 18:57.18 | Stattrav_ | sorry |
| 18:57.21 | Stattrav_ | that was with -b |
| 18:57.41 | brlcad | is still focused on your gimp import failure |
| 18:57.59 | Stattrav_ | omg |
| 18:58.08 | Stattrav_ | that was such a big fail on my part |
| 18:58.15 | Stattrav_ | 350 changed to 512 |
| 18:58.22 | brlcad | progress |
| 18:58.47 | Stattrav_ | now I see that |
| 18:58.51 | Stattrav_ | :D |
| 18:59.11 | Stattrav_ | Enterprise nice |
| 18:59.39 | brlcad | the only last detail is that we use first-quadrant coordinates, and gimp uses fourth quadrant by default so you probably have to flip horizonally to see it right-side up (but don't save that way or it'll be upside down in brl-cad) |
| 19:00.13 | Stattrav_ | yeah |
| 19:00.36 | brlcad | so now if you open moss.pix and make some pixels white, some red, some blue, some green -- you can create a test case and see the bug |
| 19:00.56 | Stattrav_ | ohh k |
| 19:01.33 | Stattrav_ | yes |
| 19:03.25 | brlcad | edit the black background pixels so it's clearly off-by-one vs off-by-many channels |
| 19:04.06 | brlcad | if you want to start even simpler, make the off-by-# value an option to pixcmp instead of just using 1 |
| 19:05.18 | Stattrav_ | aah |
| 19:08.14 | Stattrav_ | pixcmp pixels: 260319 matching, 0 off by 1, 1825 off by many |
| 19:09.13 | brlcad | bingo was his nameo |
| 19:09.30 | brlcad | note |
| 19:09.34 | brlcad | ~512 * 512 |
| 19:09.34 | ibot | 262144 |
| 19:09.39 | brlcad | ~512 * 512 * 3 |
| 19:09.39 | ibot | 786432 |
| 19:09.54 | brlcad | ~1825 / 3 |
| 19:09.54 | ibot | 608.333333333333 |
| 19:10.04 | Stattrav_ | oh yeah |
| 19:10.28 | Stattrav_ | figured that out. was using a -b |
| 19:10.33 | Stattrav_ | option |
| 19:10.54 | brlcad | sounds like you edited with a "brush" tool instead of a "pencil" tool .. 608 and 1/3rds pixels changed is a lot |
| 19:11.07 | Stattrav_ | yeah |
| 19:11.15 | Stattrav_ | http://i.imgur.com/3Q6Jt.png |
| 19:11.37 | brlcad | another thing you can do is create an all-red, all-blue, all-green, all-white, all-black image and diff those |
| 19:12.34 | Stattrav_ | aah k |
| 19:14.05 | brlcad | ah, yeah, your edit is a bit useless |
| 19:14.35 | brlcad | you need to edit a specific number of pixels, and some in only one color channel |
| 19:14.46 | brlcad | so you know exactly how many are off-by-### |
| 19:15.09 | brlcad | that white and red blob doesn't really tell you anything about whether the counts are right or wrong |
| 19:15.27 | Stattrav_ | aah, |
| 19:15.38 | Stattrav_ | pixcmp pixels: 261705 matching, 0 off by 1, 439 off by many <= wrong too |
| 19:15.49 | Stattrav_ | as in useless too |
| 19:15.56 | brlcad | if you just edit one of the black pixels, and turn it white -- you'll know you changed all three channels from 0/0/1 to 255/255/255 .. an off-by-many change |
| 19:16.10 | Stattrav_ | aah |
| 19:16.12 | brlcad | 0/0/1 is the default background color |
| 19:16.59 | brlcad | make the brush in gimp as small as it can go (use a pencil tool if they describe it as such) so it's 1x1 pixels big |
| 19:17.01 | Stattrav_ | pixcmp pixels: 262143 matching, 0 off by 1, 1 off by many |
| 19:17.06 | brlcad | that's better |
| 19:17.13 | brlcad | now go for 4 or 5 like that |
| 19:17.38 | brlcad | then do the same thing with red/green/and blue separately |
| 19:17.58 | brlcad | so 0/0/1 changes to 255/0/1 if you painted the pixel red, for example |
| 19:18.03 | Stattrav_ | pixcmp pixels: 262135 matching, 0 off by 1, 9 off by many |
| 19:18.18 | Stattrav_ | ohk shall do it with different colours |
| 19:18.42 | brlcad | pure red (255/0/0), green (0/255/0), and blue (0/0/255) |
| 19:19.04 | brlcad | you may need to make them 255/0/1 and 0/255/1 |
| 19:19.15 | brlcad | so as to not be counted as an off-by-many |
| 19:19.28 | brlcad | given the background is 0/0/1 |
| 19:20.08 | Stattrav_ | sure. doing that |
| 19:23.16 | Stattrav_ | pixcmp pixels: 262138 matching, 1 off by 1, 5 off by many |
| 19:23.19 | ``Erik | ~1 / 0 |
| 19:29.19 | Stattrav_ | so now, the code upon seeing the pixel 255/0/1 compares r1 and r2 and does offmany++ and goes on. |
| 19:29.35 | Stattrav_ | that was based on r1 != r2 |
| 19:30.46 | Stattrav_ | this code gives you atleast off by count doesnt it ? |
| 19:31.04 | Stattrav_ | w.r.t to the channels |
| 19:31.25 | Stattrav_ | ]] |
| 19:31.48 | Stattrav_ | sorry for that "]]" |
| 19:35.51 | Stattrav_ | pixcmp pixels: 262108 matching, 9 off by 1, 27 off by many |
| 19:41.42 | Stattrav_ | brlcad: wait, so when I compare 0/0/1 and 1/1/1, then, it should report as off by many right |
| 19:42.28 | brlcad | you tell me |
| 19:45.56 | Stattrav_ | so it should be off by one pixel is screwed |
| 19:46.19 | Stattrav_ | so wait that doesnt make sense what i just said |
| 19:47.13 | Stattrav_ | aah, so that should be counted as two off by 1s not off by many |
| 19:48.07 | Stattrav_ | 0/0/1 & 1/1/1 => 2 off by one, 0 off by many |
| 19:48.09 | Stattrav_ | brlcad: ^ |
| 19:50.04 | Stattrav_ | now I get it. it is one pixel gone wrong, 2 channels mismatched by 1 and none go beyond 1 in the above case |
| 19:50.24 | Stattrav_ | so a pixel wise count has to be maintained. |
| 19:50.27 | Stattrav_ | as well |
| 19:50.36 | Stattrav_ | did I get that right ? |
| 19:52.02 | *** part/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 19:52.15 | CIA-65 | BRL-CAD: 03brlcad * r50589 10/brlcad/trunk/NEWS: tom browder expanded the bb command help for mged, filling in synopsis, options, and more. r48146 |
| 19:54.26 | CIA-65 | BRL-CAD: 03brlcad * r50590 10/brlcad/trunk/NEWS: the archer bot selection gui lets the user pick what bot they want to edit by displaying a combobox. the list was previously unsorted, now sorted. r49182 |
| 20:00.31 | CIA-65 | BRL-CAD: 03brlcad * r50591 10/brlcad/trunk/HACKING: move the discussion about branches out of the secion on commit access and into the sections on organization. similarly, clean up the testing section to avoid superfluous information. |
| 20:03.45 | Stattrav_ | brlcad: could you verify my understanding of the bug as mentione above ? |
| 20:03.47 | CIA-65 | BRL-CAD: 03brlcad * r50592 10/brlcad/trunk/NEWS: |
| 20:03.48 | CIA-65 | BRL-CAD: cliff added support to rtwizard so that it'll write out a png file from the |
| 20:03.48 | CIA-65 | BRL-CAD: framebuffer. if the filename indicates a png extension, it's used and otherwise |
| 20:03.48 | CIA-65 | BRL-CAD: still defaults to pix. previously, richard also added preliminary support for |
| 20:03.48 | CIA-65 | BRL-CAD: png output to just the ghost image with insert (type e) output mode. |
| 20:04.24 | Stattrav_ | so the output should contain both the pixels and bytes |
| 20:07.25 | brlcad | Stattrav_: i think you understand the issues, just not necessarily the desired/exepected goal |
| 20:07.30 | ``Erik | O.o png from rtwizard? I thought that'd require significant re-architecting (or ugly tmp file ugliness) |
| 20:07.53 | brlcad | I think they added a final pix-png step |
| 20:08.20 | brlcad | Stattrav_: so I think the beginning of that line frames what I'd expect in the output |
| 20:08.25 | brlcad | "pixcmp pixels: ..." |
| 20:08.31 | brlcad | so those numbers should be counts of pixels |
| 20:08.38 | brlcad | not channels or bytes or otherwise |
| 20:08.49 | Stattrav_ | yes |
| 20:09.00 | brlcad | so XXX matching pixels, YYY off by 1 pixels, and ZZZ off by many pixels |
| 20:09.17 | brlcad | X+Y+Z should equal number of pixels in the image |
| 20:09.30 | Stattrav_ | yes, |
| 20:11.01 | Stattrav_ | so 1/1/1 from 0/0/1 is away by 1 ? |
| 20:11.42 | brlcad | looking at the code, I don't think that's the intention |
| 20:12.06 | brlcad | that's off by 1 value in 2 channels, so off overall by 2 values .. that's off-by-many |
| 20:12.29 | brlcad | the real question is whether 2/0/1 and 0/0/1 is off by one or many |
| 20:12.38 | brlcad | I believe that's also considered off-by-many |
| 20:12.48 | Stattrav_ | off by many by the definition in the code right |
| 20:13.20 | Stattrav_ | aah the off_by is on a scale of 0-255*3 |
| 20:13.31 | brlcad | so off-by-many means off by more than one value across one or more channels |
| 20:13.53 | Stattrav_ | so cumulative off-by of individual channels |
| 20:14.52 | brlcad | of all channels, yes |
| 20:15.00 | Stattrav_ | aah the bug is that the code considers 1/2/1 and 0/0/1 as off by 1 where as it is off by 3 |
| 20:15.34 | Stattrav_ | s/as off/are off/ |
| 20:15.50 | brlcad | sounds like you have enough to keep you busy for an hour or two now ;) |
| 20:15.59 | brlcad | maybe less, could be very simple |
| 20:16.09 | Stattrav_ | that is the bug aint it ? |
| 20:16.14 | Stattrav_ | cool |
| 20:16.20 | brlcad | the trick is making sure it all still works with -b byte mode too |
| 20:16.39 | brlcad | byte mode is basically treating it as just one-channel input |
| 20:16.43 | Stattrav_ | yup |
| 20:17.31 | Stattrav_ | shouldnt be, as the values are the same for (g1 and g2) and (b1 and b2) |
| 20:17.43 | brlcad | so therein could be a rewrite. an option for #channels instead of assuming 1 or 3, then counting up off-by-1 and off-by-many becomes much simpler |
| 20:18.07 | brlcad | loops instead of needing r g b variables and such specific tracking |
| 20:18.18 | Stattrav_ | oh yeah |
| 20:18.19 | brlcad | your choice |
| 20:18.27 | brlcad | could just fix the bug |
| 20:18.47 | CIA-65 | BRL-CAD: 03r_weiss * r50593 10/brlcad/trunk/src/librt/ (db5_types.c db_tree.c): (log message trimmed) |
| 20:18.47 | CIA-65 | BRL-CAD: Updated function "db5_sync_attr_to_comb" in file "librt/db5_types.c". Changed |
| 20:18.47 | CIA-65 | BRL-CAD: the name input to the directory structure. This was necessary so that the |
| 20:18.47 | CIA-65 | BRL-CAD: directory "d_flags" region bit could be set/unset based on the "region" |
| 20:18.47 | CIA-65 | BRL-CAD: attribute. Before this change, when using the mged "red" command to add/remove |
| 20:18.47 | CIA-65 | BRL-CAD: attribute "region=R", the mged "attr show" command would not indicate the change |
| 20:18.48 | CIA-65 | BRL-CAD: even though the attribute "region=R" was successfully added or removed. Updated |
| 20:18.48 | brlcad | or like I mentioned earlier, add an option for specifying the off-by-VAL |
| 20:18.56 | brlcad | where VAL can be specified and just defaults to 1 |
| 20:19.19 | Stattrav_ | aah, that could be a better fix then |
| 20:19.21 | brlcad | so you could threshold the pixcmp to -d4 to get off-by-4 and off-by-more ;) |
| 20:19.36 | brlcad | still doesn't address the bug, that's begging to be fixed regardless |
| 20:19.41 | brlcad | but would be useful feature |
| 20:20.02 | Stattrav_ | first I shall fix the bug and then move onto making it generic ? |
| 20:20.22 | brlcad | your choice |
| 20:20.56 | CIA-65 | BRL-CAD: 03r_weiss * r50594 10/brlcad/trunk/src/libged/red.c: Updated function "build_comb" in file "libged/red.c". Changed the call to function "db5_sync_attr_to_comb" to pass in the directory instead of the combination name. |
| 20:23.06 | CIA-65 | BRL-CAD: 03r_weiss * r50595 10/brlcad/trunk/include/raytrace.h: Updated "raytrace.h" to change the definition of function "db5_sync_attr_to_comb" to pass in the directory instead of the combination name. |
| 20:26.52 | CIA-65 | BRL-CAD: 03brlcad * r50596 10/brlcad/trunk/NEWS: tom added an italian translation of the intro to brl-cad. not sure if he's the original author but the commit didn't indicate otherwise so going with that assumption. |
| 20:33.15 | *** join/#brlcad cristina (~cristina@188.24.81.180) | |
| 20:36.27 | Stattrav_ | brlcad: wait the code actually does what we want, it doesn't overcount |
| 20:40.27 | Stattrav_ | the thing is that if the off-by-VAL is introduced, then it would have to changed |
| 20:48.00 | starseeker | ``Erik: http://www.hwaci.com/sw/mktclapp/ - unfortunately it's GPL (although it's output apparently isn't) |
| 20:52.20 | *** join/#brlcad stas (~stas@188.24.35.114) | |
| 21:02.55 | brlcad | Stattrav_: I just saw a summary printing a couple days ago that was wrong |
| 21:03.41 | Stattrav_ | brlcad: ohh |
| 21:03.41 | brlcad | so there's some situation that isn't being reported correctly |
| 21:03.56 | Stattrav_ | aah let me check each case |
| 21:04.16 | Stattrav_ | do you still have the summary ? |
| 21:04.18 | brlcad | specifically, it was reporting off-by-many as bytes |
| 21:04.31 | Stattrav_ | ohh |
| 21:08.26 | Stattrav_ | http://i.imgur.com/ILVbh.png <- this is the only chunk of code which increments offmany and only one of them is used if at all offmany is increment |
| 21:08.40 | Stattrav_ | cristina: congrats on your committ access :) |
| 21:14.38 | brlcad | Stattrav_: so offbymany was being incremented too many times. don't know why, but I think starseeker has the image |
| 21:14.47 | brlcad | images |
| 21:16.26 | Stattrav_ | ohh, can I have them ? |
| 21:17.11 | Stattrav_ | starseeker: could you please give me those images where there was a discrepancy w.r.t to the reported pixcmp values ? |
| 21:27.12 | cristina | Stattrav: thank you :) |
| 21:33.10 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.16.9) | |
| 21:57.04 | CIA-65 | BRL-CAD: 03starseeker * r50597 10/brlcad/trunk/src/tclscripts/rtwizard/lib/ (FbPage.itk PictureTypeA.itcl PictureTypeBase.itcl): Start transitioning rtwizard pages over to using rtimage script. There is probably some intermediate breakage while this progresses |
| 21:58.06 | starseeker | Stattrav_: if we're talking about the eto diff stuff, they're here: http://bzflag.bz/~starseeker/eto_implicit.pix |
| 21:58.11 | starseeker | http://bzflag.bz/~starseeker/eto_brep.pix |
| 22:06.44 | CIA-65 | BRL-CAD: 03n_reed * r50598 10/brlcad/trunk/src/other/step/src/fedex_plus/classes.c: Add collectAttributes function based on the one added by SCL git 290850a. |
| 23:26.27 | CIA-65 | BRL-CAD: 03starseeker * r50599 10/brlcad/trunk/src/tclscripts/rtwizard/lib/ (PictureTypeA.itcl PictureTypeBase.itcl): Preview is just a smaller version of full scale, and they both need the same rtimage calling logic. Refactor to reduce code duplication |
| 23:56.46 | *** join/#brlcad xth1 (~thiago@187.106.52.240) | |
