| 00:18.38 | DarkCalf | waves to #brlcad |
| 00:37.54 | *** join/#brlcad kesha_ (~kesha@49.248.244.66) |
| 00:58.32 | *** join/#brlcad kesha_ (~kesha@49.248.244.66) |
| 01:05.49 | *** join/#brlcad kesha_ (~kesha@49.248.244.66) |
| 01:55.18 | *** join/#brlcad kesha_ (~kesha@49.248.244.66) |
| 02:14.47 | *** join/#brlcad kesha_ (~kesha@49.248.244.66) |
| 03:40.04 | *** join/#brlcad zero_level (~zero_leve@117.205.23.195) |
| 03:45.40 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 04:05.53 | *** join/#brlcad zero_level (~zero_leve@117.212.30.199) |
| 04:30.36 | *** join/#brlcad zero_level (~zero_leve@117.220.8.156) |
| 04:35.50 | *** join/#brlcad zero_level (~zero_leve@117.220.8.156) |
| 04:39.43 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 04:45.02 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 04:53.59 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 04:54.27 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) |
| 04:57.13 | *** join/#brlcad zero_level (~zero_leve@117.212.25.75) |
| 05:09.08 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 05:09.51 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) |
| 05:17.27 | *** join/#brlcad zero_level (~zero_leve@117.205.28.97) |
| 05:33.05 | Notify | 03BRL-CAD Wiki:Harman052 * 5433 /wiki/User_talk:Harman052: |
| 05:37.10 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 05:43.47 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 06:17.57 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 06:47.59 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 07:15.59 | *** join/#brlcad crdueck (~cdk@24.212.219.10) |
| 07:34.57 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 07:52.11 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 07:58.41 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 08:01.15 | *** join/#brlcad crdueck (~cdk@24.212.219.10) |
| 08:41.08 | Notify | 03BRL-CAD:phoenixyjll * 55795 brlcad/trunk/src/libbrep/intersect.cpp: Use macros to represent default tolerance and change it to 0.001 (the same as the default tolerance of curve/curve, curve/surface, surface/surface defined by openNURBS). |
| 08:42.43 | *** join/#brlcad zero_level (~zero_leve@117.205.30.31) |
| 08:49.14 | Notify | 03BRL-CAD:phoenixyjll * 55796 brlcad/trunk/src/libbrep/intersect.cpp: The input u_domain and v_domain should be considered. |
| 08:50.23 | Notify | 03BRL-CAD Wiki:Phoenix * 5434 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 1 */ |
| 09:04.21 | *** join/#brlcad zero_level (~zero_leve@117.205.27.5) |
| 09:05.50 | *** join/#brlcad vladbogo (~chatzilla@188.25.101.47) |
| 09:22.36 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5435 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 10:06.08 | *** join/#brlcad zero_level (~zero_leve@59.91.152.164) |
| 10:32.48 | *** join/#brlcad zero_level (~zero_leve@117.220.15.37) |
| 11:01.31 | *** join/#brlcad zero_level (~zero_leve@117.205.16.166) |
| 11:30.17 | *** join/#brlcad caen23 (~caen23@92.81.220.39) |
| 11:39.31 | zero_level | hi Erik |
| 11:39.43 | zero_level | just read ur comment on my bwhisteq patch |
| 12:07.35 | Notify | 03BRL-CAD Wiki:Level zero * 5436 /wiki/User:Level_zero/patches: /* patch adding structure definitions in ICV.h */ |
| 12:12.40 | *** join/#brlcad zero_level (~zero_leve@117.205.29.105) |
| 12:41.35 | *** join/#brlcad zero_level (~zero_leve@117.205.23.229) |
| 12:54.26 | *** join/#brlcad vladbogo (~chatzilla@188.25.101.47) |
| 13:04.28 | *** join/#brlcad zero_level (~zero_leve@117.205.26.159) |
| 13:06.03 | *** join/#brlcad kesha (~kesha@49.249.9.55) |
| 13:13.33 | *** join/#brlcad kesha_ (~kesha@49.249.19.83) |
| 13:27.15 | *** join/#brlcad zero_level (~zero_leve@117.212.30.1) |
| 14:33.56 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 15:25.36 | Notify | 03BRL-CAD Wiki:Fjibarguen * 0 /wiki/User:Fjibarguen: |
| 15:46.57 | *** join/#brlcad zero_level (~zero_leve@117.205.31.223) |
| 15:51.59 | zero_level | hi ``Erik: |
| 15:52.57 | brlcad | zero_level: talked briefly about bwhisteq |
| 15:53.17 | brlcad | he looked at your patch, looks like you do preserve the existing behavior |
| 15:53.29 | brlcad | it just looks like the existing behavior may be wrong :) |
| 15:53.47 | brlcad | that tool hasn't been used or modified in a very LONG time |
| 15:53.56 | brlcad | can you verify that it works? |
| 15:54.09 | brlcad | or demonstrate that it doesn't? |
| 15:54.28 | zero_level | but brlcad : who do i compare it with ? |
| 15:54.35 | zero_level | the matlab histeq ? |
| 15:54.45 | brlcad | good question |
| 15:54.59 | zero_level | both will be way different |
| 15:55.16 | brlcad | you could make a test file that has known values perhaps, like a 256x256 image with a gradient going from 0 to 255 |
| 15:55.34 | brlcad | something so you'd know whether the result is "correct" |
| 15:55.40 | brlcad | or compare to matlab |
| 15:55.52 | zero_level | moreover, i still think both the implementation are same ! |
| 15:55.56 | brlcad | don't want to spend too much time on it since it is so old |
| 15:56.04 | zero_level | my patch and previous implementation |
| 15:56.12 | brlcad | if it works, great, something might need to be documented |
| 15:56.43 | brlcad | zero_level: yeah, that's understood now -- you just uncovered what seems like might be a pre-existing bug |
| 15:56.46 | brlcad | no worries |
| 15:57.07 | brlcad | if it doesn't work, we can do a quick eval to decide whether it's worth fixing |
| 15:57.18 | brlcad | need to know if it's right/wrong though |
| 15:57.23 | zero_level | ok |
| 15:57.28 | brlcad | can you figure it out? :) |
| 15:57.32 | brlcad | quickly :) |
| 15:58.03 | brlcad | (just don't want anyone to spend days on this) |
| 15:59.30 | zero_level | i procedding it this way. --create a png file of uniform gradient using matlab--converting it using bw-png --using bw-histeq(existing) and bwhisteq(after patch) |
| 15:59.44 | zero_level | the resultant must not have much difference |
| 15:59.52 | zero_level | is this methodology fine ? |
| 16:07.59 | zero_level | brlcad: any inputs about my methodology ? |
| 16:08.33 | brlcad | hopefully you'd use png-bw... ;) |
| 16:09.19 | brlcad | zero_level: so short answer - no |
| 16:09.37 | brlcad | there's no question about your patch any longer, I believe |
| 16:10.08 | brlcad | the question is wether bwhisteq (before or after patch) is actually correct or not |
| 16:10.21 | brlcad | nothing to do with the patch |
| 16:10.30 | zero_level | that i understood :-) |
| 16:10.52 | zero_level | so, my methodology about working of bwhisteq ? |
| 16:10.58 | zero_level | yes png-bw |
| 16:11.17 | brlcad | oh, I see you're telling me what you DID |
| 16:11.19 | brlcad | that's fine |
| 16:11.29 | brlcad | we're past that |
| 16:11.31 | brlcad | :) |
| 16:13.05 | zero_level | no it is what i am doing to verify bwhisteq, after ur suggestion |
| 16:13.45 | brlcad | but how does that verify whether bwhisteq is correct? |
| 16:13.56 | brlcad | it just verifies your patch preserves behavior |
| 16:14.01 | brlcad | now whether the behavior is right |
| 16:16.09 | brlcad | s/now/net/ |
| 16:16.11 | zero_level | yes since the image is of equal bins. therefore bwhisteq must not change the image. |
| 16:16.34 | brlcad | can't type toay apprently |
| 16:18.14 | brlcad | what does bwhisteq actually do? |
| 16:18.35 | brlcad | rather what is it "supposed" to do? |
| 16:19.17 | zero_level | it equalizes the histogram |
| 16:20.10 | zero_level | so i am giving it an image which has same number of pixels of intensities from 0 to 255 |
| 16:20.21 | brlcad | <PROTECTED> |
| 16:21.19 | brlcad | so takes a single 1-byte channel image file with intensity values |
| 16:21.52 | brlcad | presumably finds the max to min range, maps that to 0-255, writes out new single 1-byte channel image? |
| 16:24.39 | zero_level | to equalize, yes! |
| 16:25.14 | brlcad | okay, just making sure we're on the same page of understanding |
| 16:25.57 | brlcad | so then gradient test is fine, but only mildly useful in that it should provide no change |
| 16:27.44 | brlcad | I'd suggest also testing three more images: one with half black and half 128, another with half white and half 128, and last with half 128 and half 127 |
| 16:28.04 | brlcad | can then just visually inspect to make sure all three turn into half black half white |
| 16:28.33 | zero_level | ok |
| 16:57.46 | *** join/#brlcad harmanpreet (~chatzilla@210.56.121.229) |
| 17:09.41 | zero_level | brlcad : only for the first case(uniform) the answer is right |
| 17:09.48 | zero_level | for the rest it is not right |
| 17:10.18 | zero_level | it is converting to (127 - 128) combination |
| 17:11.34 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 17:14.15 | zero_level | no it is converting to (63,191) |
| 17:14.45 | zero_level | the lighter gets conveted to 191 and the darker gets coverted to 63 |
| 17:15.14 | zero_level | the lighter half and the darker half |
| 17:24.48 | Notify | 03BRL-CAD Wiki:Harman052 * 5437 /wiki/User:Harman052: Formatting Improved. |
| 17:26.04 | *** join/#brlcad kesha_ (~kesha@49.249.200.67) |
| 17:27.09 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 17:34.52 | *** join/#brlcad zero_level (~zero_leve@117.205.17.121) |
| 17:54.56 | *** part/#brlcad zero_level (~zero_leve@117.205.17.121) |
| 17:54.58 | *** join/#brlcad zero_level (~zero_leve@117.205.17.121) |
| 18:09.15 | Notify | 03BRL-CAD Wiki:Harman052 * 5438 /wiki/User:Harman052/GSoc2013/Logs: Details Updated |
| 18:29.03 | *** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 18:36.07 | *** join/#brlcad zero_level (~zero_leve@117.205.24.89) |
| 18:52.32 | *** join/#brlcad kesha_ (~kesha@49.249.200.67) |
| 18:57.31 | *** join/#brlcad kesha_ (~kesha@49.249.200.67) |
| 19:03.04 | *** join/#brlcad zero_level (~zero_leve@117.205.16.250) |
| 19:34.46 | *** join/#brlcad zero_level (~zero_leve@117.205.16.149) |
| 19:49.13 | *** join/#brlcad Ch3ck (29cac1fa@gateway/web/freenode/ip.41.202.193.250) |
| 19:49.47 | Ch3ck | just made a new patch for the new push routine with the additional ability to recognise |
| 19:50.12 | Ch3ck | a push -x in case there is no -x option as in push -x or xpush(deprecated) |
| 19:50.21 | Ch3ck | also concerning my pull routine |
| 19:51.20 | Ch3ck | i wish to know if brlcad has an implementation of the inverse of a 4x4 matrix so i could get started on studying the libged libraries and other associated libraries related to my project. |
| 19:51.48 | *** join/#brlcad mpictor (~mark@2601:d:b280:9:d63d:7eff:fe2d:2505) |
| 19:57.59 | *** join/#brlcad Izak (29cac1fa@gateway/web/freenode/ip.41.202.193.250) |
| 19:58.46 | Izak | <PROTECTED> |
| 20:17.02 | brlcad | Ch3ck: saw the patch, comments coming soon |
| 20:17.14 | Ch3ck | yeah |
| 20:17.16 | brlcad | there is some inverse logic, but very limited |
| 20:17.26 | Ch3ck | it was just the full source code |
| 20:17.35 | Ch3ck | i am trying to upload a modified one |
| 20:17.40 | brlcad | ah, did not see that |
| 20:17.41 | Ch3ck | but network sucks. |
| 20:17.46 | brlcad | patches should be just patches... :) |
| 20:17.52 | brlcad | svn diff |
| 20:17.53 | Ch3ck | yeah |
| 20:18.05 | Ch3ck | i did that today |
| 20:18.09 | Ch3ck | just recovered from malaria |
| 20:18.22 | Ch3ck | so came back stronger today.. |
| 20:18.59 | zero_level | brlcad: I saw the result |
| 20:19.08 | zero_level | those were not right |
| 20:19.15 | zero_level | just got the hold of the source |
| 20:19.41 | zero_level | working to modify that |
| 20:19.48 | brlcad | Ch3ck: glad to hear you recovered! |
| 20:19.55 | brlcad | no recovering would have kinda sucked... :) |
| 20:20.12 | brlcad | zero_level: okay, so any notion of whether it'll be easy to fix? |
| 20:21.30 | zero_level | i am considering to fully modify the code after calculation of bins |
| 20:21.58 | *** join/#brlcad Ch3ck_ (29cac1fa@gateway/web/freenode/ip.41.202.193.250) |
| 20:22.03 | zero_level | also i thing this may be one of the brlcad's premitive function |
| 20:22.21 | zero_level | may be it works for something else. |
| 20:22.30 | brlcad | maybe what works? |
| 20:22.59 | zero_level | may be this alorithim does something in the name of the histogram equalization! |
| 20:23.11 | brlcad | you mean something else, like just poorly named? |
| 20:23.14 | zero_level | so do u want me to modify this file or add a new one ? |
| 20:23.16 | zero_level | yes! |
| 20:23.41 | brlcad | well if that's not obvious from the file's contents, we don't need to spend time figuring it out |
| 20:24.08 | brlcad | you could search the history, see if the comments tell you anything |
| 20:24.21 | zero_level | history of bwhisteq ? |
| 20:24.35 | brlcad | prior to r22000, that file would have been in the top-level util directory I believe |
| 20:24.44 | brlcad | yes |
| 20:24.59 | brlcad | or if there are any other utilities similarly named |
| 20:25.05 | brlcad | that deal with histograms |
| 20:25.28 | brlcad | does pixhist work alright? |
| 20:25.58 | zero_level | we dont have a histogram equalization for pix |
| 20:25.59 | brlcad | pixhist3d is another, pixhist3d-pl |
| 20:26.17 | zero_level | that i suppose is performed by using pix-bw3 |
| 20:27.01 | zero_level | and then bwhisteq and then bw3-pix |
| 20:27.42 | zero_level | using bwhisteq meant performing equalization on each channel and then combining |
| 20:28.23 | brlcad | so what is ill-defined is what is meant by "equalized" |
| 20:28.49 | zero_level | the interesting point as i saw was when there were two different halfs of different intensities as the resultant of the three cases u said |
| 20:29.27 | brlcad | if you have a half 0/0/0 and half 255/255/255 image, those are either already "equal" (assuming equal area) .. or their intensities still need to be "balanced" |
| 20:29.29 | zero_level | and all these were 63 for the darker half and 191 for the lighter half |
| 20:29.32 | Ch3ck_ | brlcad: you were saying.. |
| 20:30.10 | zero_level | what i saw from the result were two buildings in the histogram at 63 and 191 |
| 20:30.17 | brlcad | zero_level: yeah that is _also_ an equalization of sorts ... just an unusual one (to me) |
| 20:30.18 | zero_level | which makes it balanced |
| 20:30.28 | zero_level | yes! |
| 20:32.33 | zero_level | but when we read the code it is not the the normal mapping as u explained |
| 20:32.47 | zero_level | do u want me test on lena image.. ? |
| 20:35.31 | brlcad | zero_level: sure, would be good to see what it does |
| 20:36.06 | brlcad | if it's useful, we can keep it as is |
| 20:36.08 | zero_level | brlcad: was already on it! |
| 20:36.21 | brlcad | if we keep it, we should document this behavior (better) |
| 20:36.37 | brlcad | if it's not useful or only marginally so, we can get rid of it |
| 20:37.13 | zero_level | brlcad: ok ! |
| 21:18.00 | zero_level | checked for barbara and lena works fine. |
| 21:18.14 | zero_level | i am finding a way to post them on wiki so that u can see that |
| 21:18.21 | zero_level | brlcad: |
| 21:27.27 | zero_level | brlcad find the images here barabara : http://tinypic.com/r/2rqeubl/5 barabara equalized : http://tinypic.com/r/71gq6q/5 lena : http://tinypic.com/r/33krogg/5 lena equalized : http://tinypic.com/r/10r2sti/5 |
| 21:33.28 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 21:39.21 | brlcad | zero_level: okay, so on the surface I'd say that's more than marginally useful |
| 21:39.34 | brlcad | so keep on, it's fine |
| 21:40.10 | zero_level | i still wonder about the working of the code. Either it is state of the art. or can be improved significantly |
| 21:40.28 | brlcad | yep |
| 21:40.45 | brlcad | in this case, it's certainly not state of the art, but it is still useful |
| 21:40.51 | zero_level | also saw CxImage library there also they implement in the general way where we map the pixels |
| 21:40.57 | brlcad | just not an active area of development and hasn't been for probably 20 years |
| 21:43.08 | brlcad | zero_level: so if you try equalize in cximage, do you get the same result? |
| 21:43.27 | brlcad | maybe also try "normalize" |
| 21:44.08 | zero_level | didnt install the library but the code is entirely different |
| 21:44.17 | zero_level | checked with matlab histeq function |
| 21:44.20 | zero_level | there are differe |
| 21:44.25 | zero_level | *different |
| 21:44.38 | brlcad | they have a demo app: http://www.codeproject.com/Articles/1300/CxImage |
| 21:44.49 | brlcad | that shows equalize and normalize |
| 21:48.05 | zero_level | the matlab histeq are slightly different. on seeing one cannot find the difference. but pixel wise differences are observed using subtraction |
| 21:48.55 | brlcad | pixdiff tool will show you the differences |
| 21:49.22 | brlcad | still "slightly different" is informative |
| 21:49.57 | brlcad | could imply a round-off error or off-by-one bug or edge case handled differently or just an entirely different (but similar) method altogether |
| 21:51.52 | brlcad | did you do histeq(I, 256) in matlab? |
| 21:52.22 | brlcad | default is 64 |
| 21:52.44 | zero_level | i did only histeq(I) |
| 21:52.54 | brlcad | so that's probably the difference |
| 21:52.58 | zero_level | ok |
| 21:53.00 | brlcad | try 256 |
| 21:54.10 | brlcad | I like that you're comparing with matlab.... :) |
| 21:54.39 | zero_level | i did with 256 this tym |
| 21:55.06 | brlcad | BRL-CAD has MANY parallels with Matlab in terms of design, history, commands, low-level functionality |
| 21:56.09 | zero_level | the sum of abs diff for pixels is 70434 for 263144 pixels |
| 21:56.17 | zero_level | *262144 |
| 21:56.30 | zero_level | for the barbara image |
| 21:56.39 | zero_level | i think this is negligible |
| 21:56.45 | brlcad | hm, how diff? |
| 21:56.50 | brlcad | what does pixdiff say? |
| 22:03.48 | zero_level | pixdiff bytes: 191709 matching, 70434 off by 1, 0 off by many |
| 22:04.06 | brlcad | nice, so that is basically matching with some round-off error |
| 22:04.12 | zero_level | this is the result of pixdiff on barbara equlaized with matlab and bwhisteq |
| 22:04.38 | brlcad | it'd be iteresting to figure out who has the rounding error |
| 22:04.57 | brlcad | could be either, that's a very tiny difference |
| 22:05.46 | brlcad | given our tools usage, my bets would be on it having a rounding issue but that's still surprisingly good |
| 22:05.54 | brlcad | and reinforces the value of the tool |
| 22:15.30 | zero_level | brlcad: about that mail |
| 22:15.47 | zero_level | because it has few things regarding the development plan |
| 22:16.20 | zero_level | also those whole sum is because of 1 pixel intensity difference |
| 22:17.45 | brlcad | <PROTECTED> |
| 22:18.03 | brlcad | like 128/128/128 vs 128/127/128 |
| 22:18.10 | *** join/#brlcad zero_level (~zero_leve@117.205.16.149) |
| 22:18.16 | brlcad | <PROTECTED> |
| 22:18.19 | brlcad | like 128/128/128 vs 128/127/128 |
| 22:18.34 | brlcad | not even 127/127/127 vs 128/128/127 |
| 22:22.34 | *** join/#brlcad zero_level (~zero_leve@117.205.16.149) |
| 22:37.01 | *** join/#brlcad zero_level (75cd1727@gateway/web/freenode/ip.117.205.23.39) |
| 22:37.57 | *** join/#brlcad zero_level_ (~zero_leve@117.205.23.39) |