01:20.44 |
brlcad |
vladbogo: so ... basically it SHOULD be
working how you wrote it |
01:21.16 |
brlcad |
perhaps Tk is not creating a real
"Window" |
01:21.39 |
brlcad |
try creating a third X11 window
(manually) |
01:22.01 |
brlcad |
find an X11 tutorial on the web, create a
simple empty window, pass that Window to Qt and see if you can get
it to use it |
01:22.27 |
brlcad |
or ask on the Qt and/or Tk forums and/or
stackoverflow what you might be doing wrong |
01:23.06 |
brlcad |
unfortunately, the answer isn't obvious but
your logic seems sound so the next step is to either walk the logic
in a debugger or ... ask for help ;) |
03:03.33 |
*** join/#brlcad evgeny
(~Miranda@109.194.34.184) |
03:36.07 |
Notify |
03BRL-CAD:brlcad * 56044
brlcad/trunk/src/libbrep/opennurbs_ext.cpp: initialize usplit and
vsplit to the midpoint, otherwise there's potential for them to get
used without being initialized. |
03:37.12 |
Notify |
03BRL-CAD:brlcad * 56045
brlcad/trunk/src/libbrep/opennurbs_ext.cpp: what the heck happened
to the style??? |
03:41.01 |
*** join/#brlcad caen23
(~caen23@92.81.215.44) |
03:42.31 |
Notify |
03BRL-CAD:phoenixyjll * 56046
brlcad/trunk/src/libbrep/intersect.cpp: Normalize the curves, and
check tangent events. |
04:06.18 |
Notify |
03BRL-CAD:phoenixyjll * 56047
brlcad/trunk/src/libbrep/intersect.cpp: Check the domain
parameters. |
04:42.36 |
Notify |
03BRL-CAD:brlcad * 56048
brlcad/trunk/src/rt/do.c: should not be using raw codes with
open(), use the symbolic form for rw |
04:50.54 |
Notify |
03BRL-CAD:brlcad * 56049
brlcad/trunk/src/rt/do.c: improve the error message when we cannot
write to the output file. the fdopen failure was masking the open
failure causing an unhelpful 'bad file descriptor' message instead
of the original permissions denied message. |
04:52.40 |
Notify |
03BRL-CAD:phoenixyjll * 56050
brlcad/trunk/src/libbrep/intersect.cpp: Add seaming curves to
handle intersecting intersection curves. |
04:56.27 |
Notify |
03BRL-CAD:brlcad * 56051
brlcad/trunk/src/rt/do.c: let the user know that we read the
existing output data into the framebuffer (even though we still
call shootray for all pixels) |
05:00.25 |
Notify |
03BRL-CAD:brlcad * 56052
brlcad/trunk/src/rt/do.c: ordering for pre c99 |
05:03.16 |
Notify |
03BRL-CAD:brlcad * 56053
brlcad/trunk/src/rt/do.c: put new log message behind the existing
verbosity flag |
05:09.09 |
Notify |
03BRL-CAD:phoenixyjll * 56054
brlcad/trunk/src/libbrep/intersect.cpp: Sometimes we can merge the
new seaming curves - don't need to generate new ones. |
05:25.54 |
Notify |
03BRL-CAD:phoenixyjll * 56055
brlcad/trunk/src/libbrep/intersect.cpp: Eliminate compiler
warnings. |
05:34.57 |
vladbogo |
brlcad: I've tried creating a third X11 window
and pass that window to Qt but I get the same result (2
windows) |
05:36.03 |
vladbogo |
I will also ask on the qt forum/stackoverflow
and hopefully find a solution. |
06:29.52 |
*** join/#brlcad caen23
(~caen23@92.81.215.44) |
07:04.23 |
Notify |
03BRL-CAD:phoenixyjll * 56056
brlcad/trunk/src/libbrep/intersect.cpp: Should consider 2D
distances. And if there are already intersections, we don't
generate seaming curves. |
07:32.20 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
07:46.34 |
Notify |
03BRL-CAD Wiki:Phoenix * 5695
/wiki/User:Phoenix/GSoc2013/Reports: /* Week 4 */ |
07:47.59 |
Notify |
03BRL-CAD Wiki:Phoenix * 5696
/wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
07:48.18 |
Notify |
03BRL-CAD Wiki:Phoenix * 5697
/wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
07:49.48 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
09:39.29 |
*** join/#brlcad kimz
(~AndChat56@110.225.245.211) |
11:04.17 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
11:51.18 |
Notify |
03BRL-CAD:brlcad * 56057
brlcad/trunk/src/librt/primitives/rec/rec.c: overhaul the rec shot
routine. eliminates a recently introduced magic constant (1.0e10)
that wasn't correct (a big root does not indicate a need to check
the end plates). completely restructure the logic to eliminate the
gotos and the associated spagetti. now we always check the cylinder
and end plates, collapsing any duplicate points. these |
11:51.20 |
Notify |
changes were tested extensively with a default
rec from all possible orientations showing no change other than
face normal on grazing edge. performance was actually faster for
most views (but within 5% noise). |
11:52.53 |
*** join/#brlcad d_rossberg
(~rossberg@66-118-151-70.static.sagonet.net) |
13:40.03 |
*** join/#brlcad hickoryknoll
(~hickorykn@66-118-151-70.static.sagonet.net) |
14:40.05 |
*** join/#brlcad evgeny
(~Miranda@77.106.106.192) |
14:40.11 |
*** part/#brlcad evgeny
(~Miranda@77.106.106.192) |
16:50.38 |
zero_level |
brlcad : I want to discuss aout three
issues |
16:50.50 |
zero_level |
a) About Implementation of filters |
16:51.03 |
zero_level |
b) About histograms in double images |
16:52.22 |
zero_level |
c) About converting the image utilities to use
implemented functions of libicv |
16:53.19 |
zero_level |
about A) |
16:54.29 |
zero_level |
BRL-CAD has three different utilities for
filttering bwfilter, pixfilter, pix3filter |
16:55.12 |
zero_level |
all these three use a 3X3 (bwfilter,
pixfilter) amd 3x3x3 (pix3filter) |
16:55.51 |
zero_level |
I am converting them as two
functions |
16:56.05 |
zero_level |
icv_filter() for bwfilter and
pixfilter |
16:56.17 |
zero_level |
icv_filter3() for pix3filter |
16:56.33 |
zero_level |
My questions is : |
16:58.09 |
zero_level |
I am not sure about the size of the image
BRL-CAD predominately uses (My guess 512x512). But do you think I
should include a functionality for |
16:58.17 |
zero_level |
variable size filter ? |
16:59.57 |
zero_level |
If the image size is small (<512^2) My gut
feeling is that 3 dimensional size filter will sufice |
17:00.22 |
zero_level |
about B) |
17:01.44 |
zero_level |
Or do u think i shld put them in mail
? |
17:03.18 |
*** join/#brlcad vladbogo
(~vladbogo@188.25.237.173) |
17:32.31 |
*** part/#brlcad hickoryknoll
(~hickorykn@66-118-151-70.static.sagonet.net) |
18:00.28 |
*** join/#brlcad cstirk
(~quassel@c-71-56-216-45.hsd1.co.comcast.net) |
18:17.06 |
brlcad |
zero_level: we can discuss here and then you
can summarize via e-mail for others |
18:17.21 |
brlcad |
default image size for all tools should be
512x512 |
18:17.30 |
brlcad |
but you shouldn't assume that size |
18:18.04 |
brlcad |
is there a way to combine all three into one
generalized function? |
18:18.43 |
brlcad |
i'm not familiar with the 3x3x3 kernel you
speak of for pix3filter |
18:19.18 |
brlcad |
having a variable size filter is VERY
desirable, but that would obviously be new functionality so you
certainly don't have to accommodate it |
18:19.51 |
brlcad |
but if you happen to accommodate it in the
process of generalizing those three into one or two functions,
great |
18:21.51 |
vladbogo |
brlcad: hi. I've asked on sourceforge and qt
forums and hopefully I will get a response soon. |
18:22.07 |
vladbogo |
on stackoverflow* |
18:23.17 |
zero_level |
brlcad: right. The only reasoni asked for
variable lenth filter was because of implementation
issue. |
18:24.11 |
zero_level |
Now i will modify the current function as a
generalization of filter length |
18:26.53 |
zero_level |
currently it is hard coded so that only 3-Dim
Filter are used. |
18:27.43 |
brlcad |
interesting new site: http://choosealicense.com/ |
18:27.57 |
brlcad |
vladbogo: excellent, let us know what you find
out |
18:28.39 |
zero_level |
pix3filter is there in
src/util/pix3filter.c |
18:28.49 |
brlcad |
zero_level: the trick/danger is dealing with
larger filters correctly on the boundaries |
18:29.13 |
brlcad |
I know where the sources are, just haven't
needed to use it or have read the sources in a very long
time |
18:29.21 |
brlcad |
can you summarize? |
18:30.51 |
zero_level |
alright |
18:31.13 |
zero_level |
Its basicaaly for three images |
18:31.59 |
zero_level |
and besides the normal low, high, and average
u could create a smear amination using this |
18:32.20 |
zero_level |
and the combined is put to a single
image |
18:34.57 |
zero_level |
and yes boundaries ar the issue. n/2 lines in
both sides might look awful |
18:35.16 |
zero_level |
but then if the images are large. It wouldnt
matter. |
18:36.10 |
zero_level |
about b) although i will be implementing this
latter in the week. |
18:36.34 |
zero_level |
How do we written for histogram
functions. |
18:36.47 |
zero_level |
What should be the hisogram for double
data. |
18:37.16 |
zero_level |
The only way I got is ask the user the number
of bins and written a long int array of that size. |
18:37.34 |
zero_level |
Just wanted to make sure I was write abt
that |
18:37.40 |
zero_level |
*if |
18:39.14 |
zero_level |
so this looks long int*
icv_histogram(icv_image_t* bif, int num_bins) |
18:39.45 |
zero_level |
and also there is an issue if the imgage is
rgb data. ? |
18:41.26 |
zero_level |
earlier i thought it to be int
icv_histogram(icv_image_t*bif, int num_bins, long int* bin1, long
int *bin2, long int *bin3 ) |
18:41.50 |
zero_level |
but i am worried for different channel images
(1,4) |
18:47.30 |
*** join/#brlcad cstirk
(~quassel@c-71-56-216-45.hsd1.co.comcast.net) |
18:57.50 |
brlcad |
zero_level: so then merging the three sounds
unhelpful |
18:57.56 |
brlcad |
just the two like you had planned |
18:59.06 |
brlcad |
if you're familiar with the generic filter in
photoshop or gimp, that might be a good example to follow |
19:03.18 |
brlcad |
as for histogram, you could specify the image,
num_bins, start channel #, channel count, and output array (should
be size_t ... NOT long int) |
19:14.25 |
vladbogo |
brlcad: in order to process Qt events the
QApplication::processEvents function should be called in mged's
main loop. Should I add a new processEvent callback to struct dm
which does nothing for the other dms or should I put an #ifdef
DM_QT call process events #endif? |
19:16.10 |
brlcad |
vladbogo: hehe, you clearly KNOW the right way
already :) |
19:16.28 |
brlcad |
callback ftw |
19:17.35 |
vladbogo |
brlcad: that's what I thought but just wanted
to be sure |
19:19.15 |
vladbogo |
brlcad: also offtopic I saw that Notify does
not print updates |
19:22.43 |
brlcad |
notify sometimes gets stuck |
19:25.14 |
Notify |
03BRL-CAD:vladbogo * 56058
brlcad/trunk/src/libdm/dm-qt.cpp: Remove trailing ws and other
minor changes. |
19:25.19 |
Notify |
03BRL-CAD:vladbogo * 56059
(brlcad/trunk/include/dm-qt.h brlcad/trunk/src/libdm/dm-qt.cpp):
Implemented qt_reshape and added the QtTkMainWindow to
priv_vars. |
19:25.22 |
Notify |
03BRL-CAD:vladbogo * 56060
brlcad/trunk/src/libdm/dm-qt.cpp: Implemented
qt_configureWin_guts. |
19:25.25 |
Notify |
03BRL-CAD:vladbogo * 56061
brlcad/trunk/src/libdm/dm-qt.cpp: Set window background
color. |
19:25.27 |
Notify |
03BRL-CAD:vladbogo * 56062
brlcad/trunk/src/libdm/dm-qt.cpp: Remove trailing ws and other
small cleanups. |
22:15.25 |
Notify |
03BRL-CAD Wiki:Level zero * 5698
/wiki/User:Level_zero/GSOC13/logs: /* Week 4 */ |
22:15.27 |
Notify |
03BRL-CAD Wiki:Harman052 * 5699
/wiki/User:Harman052/GSoc2013/Logs: |
22:15.29 |
Notify |
03BRL-CAD Wiki:Vladbogolin * 5700
/wiki/User:Vladbogolin/GSoC2013/Logs: |
22:15.32 |
Notify |
03BRL-CAD Wiki:49.249.1.63 * 5701
/wiki/User:KeshaSShah/GSoC13/Reports: |
22:15.33 |
Notify |
03BRL-CAD Wiki:Izakkayems * 5702
/wiki/User:Izak/GSOC_2013_logs: /* From July 15th to July 20th
*/ |
22:15.35 |
Notify |
03BRL-CAD Wiki:NyahCh3ck20 * 5703
/wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 15 July - 21 July
*/ |
22:15.43 |
Notify |
03BRL-CAD:vladbogo * 56063
(brlcad/trunk/include/dm-Null.h brlcad/trunk/include/dm.h and 10
others): Added the processEvents callback to struct dm. |