Question about changing pixels colors.

Orrep · **Joined:** Mon Feb 27, 2012 9:56 pm **Posts:** 7

Hello everyone! I'm fairly new to using gtk and c and I have a question regarding changing the color of pixels. So I have an image file I read it and do some calculations using the pixel data which I access doing this:

Code:

pixbuf = gtk_image_get_pixbuf(img);

  n_channels = gdk_pixbuf_get_n_channels(pixbuf);
  pixs=gdk_pixbuf_get_pixels(pixbuf);
  rowstride=gdk_pixbuf_get_rowstride(pixbuf);

Then I position myself on the image pixel using this

Code:

/*p is also a guchar
x and y are the image coordinates*/

p = pixs + y * rowstride + x * n_channels;

and then I change the color of a pixel using this

Code:

p[0]=50;
p[1]=0;
p[2]=0;

For example, afterwards I just write the modified image to hard drive

Code:

gdk_pixbuf_save(pixbuf,"/.../.../Desktop/image.png","png",NULL,NULL);

The strange thing is that the image appears on my Desktop and the pixels are colored like it should but my program crashes.
If I comment this part out:

Code:

p[0]=50;
p[1]=0;
p[2]=0;

Then the program never crashes.

So my question is, is it fine the way I am coloring the pixels or should I do it another way? Apparently the program doesn't like the way I color the pixels since that's the only part that causes it to crash.

Any tips?

Paul Childs · **Posted:** Tue Feb 28, 2012 11:19 am

hmmm.
Well you pretty much did it just like the documentation, except minor stuff like g_assert for checking things are the right format which you would know anyway.
you might need to cast your 0, 50 etc to guchar, e.g.
p[0]=(guchar)50;
*(p+1)=(guchar)0;
Also when debugging it helps to include the GError and have a look what it might say.
If you run it through gdb and set breakpoints you can determine whether its crashing as a result of the p[0]=50 or when you try to save.

Orrep · **Joined:** Mon Feb 27, 2012 9:56 pm **Posts:** 7

Thanks Paul! I don't have the code right now but I forgot to specify that the program compiles without a problem and saves the image which is the last thing it does. Just after saving the image it crashes but only if I changed the pixels before. I'll try casting the numbers to guchar like you suggested and posting the error tomorrow when I get to the lab. Thanks for the help!

Orrep · **Joined:** Mon Feb 27, 2012 9:56 pm **Posts:** 7

Ok, I tried invoking the values to guchar to no avail

The error it throws after trying to save is this one.

No source available for "g_closure_invoke() at 0xb756b3dc"

Any tips of what it might be?

Thx!

Paul Childs · **Posted:** Wed Feb 29, 2012 9:53 pm

hmm that's the kind of error you get when trying to debug something, but I don't know what would be trying to debug glib or why.
Try doing a debug with gdb to debug
compile with the -g flag incuded then type
gdb nameofprogram
r (to run)
bt (to get the trace when things go wrong -- you can omit the 0x.. hex values as they are memory addresses that will be different on every system)
Might also help t post or send a link of your code

Orrep · **Joined:** Mon Feb 27, 2012 9:56 pm **Posts:** 7

Thanks a lot Paul, you're really helpful! Sorry for the delay answering but I only get to work on this thing some days of the week. I did what you said and I got this:

Code:

Program received signal SIGSEGV, Segmentation fault.
0x0804b789 in computar_transformadas (widget=0x809c490, event=0x81566e0, 
    callback_data=0x0) at ../Principal/Menu.c:612
612            tendbegin = par.prueba[phi][j][1]-par.prueba[phi][j][0];

I kind of figured it was a segmentation fault but now I have to figure out why it is happening there. This is the trace.

Code:

#0  0x0804b789 in computar_transformadas (widget=0x809c490, event=0x807ae48, 
    callback_data=0x0) at ../Principal/Menu.c:612
#1  0xb7b6e662 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#2  0xb756b3dc in g_closure_invoke ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#3  0xb757e180 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#4  0xb7586d29 in g_signal_emit_valist ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#5  0xb7587083 in g_signal_emit ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#6  0xb7ca6fe3 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#7  0xb7b6c81e in gtk_propagate_event ()
   from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#8  0xb7b6ce88 in gtk_main_do_event ()
   from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#9  0xb79d3d08 in ?? () from /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#10 0xb7495a3f in g_main_context_dispatch ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
#11 0xb7496170 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#12 0xb749677b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#13 0xb7b6b94f in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#14 0x080491ee in main (argc=1, argv=0xbffff3c4) at ../Principal/Menu.c:80

Paul Childs · **Posted:** Sat Mar 03, 2012 1:11 pm

Well it's saying that its crashing at line 612 which isn't the region of code I imagine that has anything to do with saing the data, so I think the way your editing the image is fine its just that there is a bug elsewhere in your code that wasn't noticed until the image editing step came along. Most likely something has changed to par.prueba (or limits on phi or j) that it could no longer access [phi][j][1]. (maybe when the buffer was saved to file something got turned to a null pointer or freed?)
If you can't pin it down, you could either set breakpoints here to figure out what the allocated size of it is (along with the current j and phi) or print out a message for you to see.

Orrep · **Joined:** Mon Feb 27, 2012 9:56 pm **Posts:** 7

Paul Childs wrote:

Well it's saying that its crashing at line 612 which isn't the region of code I imagine that has anything to do with saing the data, so I think the way your editing the image is fine its just that there is a bug elsewhere in your code that wasn't noticed until the image editing step came along. Most likely something has changed to par.prueba (or limits on phi or j) that it could no longer access [phi][j][1]. (maybe when the buffer was saved to file something got turned to a null pointer or freed?)
If you can't pin it down, you could either set breakpoints here to figure out what the allocated size of it is (along with the current j and phi) or print out a message for you to see.

Sorry for taking so long to write back. You're right, it appears I'm having memory allocation problems. I use malloc a lot because I need multidimensional arrays created dynamically but, after using valgrind, there are a lot of errors... Well now I must search what my problem is elsewhere but anyways, thanks for the help Paul :)

Paul Childs · **Posted:** Wed Mar 14, 2012 9:26 pm

glib (which is wrapped in with gtk) has a lot of dynamically allocated data structures available (http://developer.gnome.org/glib/stable/glib-data-types.html). It takes care of most of the dynamic allocation issues (no need to call malloc) and is more compatible with gtks ethos of reference counting (might be wht went wrong). You still need to free up the memory when done (using glibs own functions for that).

GTK+ Forums

Question about changing pixels colors.

Who is online