(Français) Quelques photos du rallye WRC de France en Alsace

The text is translated in hexadecimal. Be careful : if you save the document, you save its hexadecimal form (not very serious : you can translate it back). In fact, Vi translates your “normal” text in hexadecimal characters, but after that, it uses them as a “normal” text.

In order to translate a hexadecimal text in a “normal” text, it’s the following command :

:%!xxd -r

Easy! =)

Posted in Linux, Technique | Tags: hexadécimal, vi, vim | Comments Closed

(Français) Petite étude du hack mondial

September 1st, 2010 | Author: Michael

Posted in Linux, Sécurité | 5 Comments »

Trick list

August 18th, 2010 | Author: Michael

Here is a list of trick, technic, tips, that I learned during my Summer of Code. It’s published here as it is, and my or may not interrest you.

Memory allocation with Glib:

memory allocation for objects:

– g_new (struct_type, number)

– g_renew (struct_type, old_allocation, number)

– g_unref_object (object)

simple allocation:

– g_malloc (byte_number)

– g_realloc (old_allocation, byte_number)

– g_free (allocation)

Allocation with g_malloc are expensive, use gslice instead if the memory needed is length fixed.

Hacking Gimp

gobject and glib debug

Run Gimp with –g-fatal-warnings

GTK event debug

When GTK send an event (key press, mouse clic, ..), Gimp grabs the event manager. If you set a breackpoint in an event handler, this manager isn’t given back to GTK when the debugger freeze Gimp. Result, you cannot use your keyboard or mouse anymore. Not especially handy. Solution is to compile you own GTK with –enable-debug=yes, compile Gimp with this GTK, and run Gimp with –gtk-no-grabs.

autogen.sh

Compilation options are available with ./configure –help

compilation without optimisation

CFLAGS=-O0 ./autogen.sh –prefix=….

quick install of binaries only

cd app/ && sudo make install-binPROGRAMS

Gobject

gobject is evil.

if you have a warning relative to glib or gobject, try make install

something wrong ? Try make install

Babl

Babl is a library used to abstract different pixel formal and color space (RVB, CMJN, …)

setup a format

babl_type (“float”)

babl_type (“u8”)

babl_format_n (babl_type (“float”), nombre_element)

Look in the doc http://www.gegl.org/babl/#Vocabulary to see format available. A small precision:

– R’: gamma adjusted

– Ra: pre-multiplied alpha

<http://www.gimp.org/docs/plugin_in/appendix-alpha.html>

convert buffer with a Babl fish

babl_process (babl_fish, buffer_source, buffer_destination, nombre_d’element)

Gegl

create a buffer

GeglBuffer *bfr = gegl_buffer_new (gegl_rectangle, babl_format)

buffer leak

In gegl/buffer/gegl_buffer.c, uncomment #define GEGL_BUFFER_DEBUG_ALLOCATION. When closing Gimp, you will have an allocation trace. You can convert adress in the binary in position in the source code with addr2line -e app/.libs/gimp-2.7 adress.

Git

push in a remote branch

git push origin soc-2010-cage

keep branch up-to-date

git fetch origin && git rebase origin

Posted in Gimp, Summer of Code | Comments Closed

Official end

August 18th, 2010 | Author: Michael

That’s it, Summer of Code is over, at least officially.

I finally updated this blog less than I expected. I have to say that after 2 month banging my head to the code, motivation is less than before. So, here is the news:

As announced in my last entry, I worked on a process to invert the computing of the transformation (ie know from where come pixels instead of where they go), to have a good image quality and avoiding aliasing. Here is how it works:

we set on the image a cage-sized grid
we apply the deformation to the grid
we split each grid case to two triangle
for each pixel inside these triangle, we compute the source coordinates
finally, we have for each pixel of the final, the coordinate from where to fetch color (sampling)

My first approach for iterating in a triangle was first, re-order it (find the top-high vertice, then left and right vertices), and then iterate it with straight equation. That’s not a great idea. There is a lot of special case, it’s complex and inefficient. Finally, a friend suggested me to proceed recursively, by splitting the triangle in 4, until it include only one pixel. Then, interpolation is done with a barycentric system. Tadaaa, it works every time, and that’s even efficient ! Thanks Théophile (yes, you now have contributed in free software with more than a libcaca patch =) ).

In fact, it’s so efficient that i will probably replace the “forward” method which is currently used for interactive preview (which is also quite ugly).

These is how the tool core looks like. Each circle is a Gegl operation.

Cage_coef_calc compute, for each pixel that need to be transformed, the coefficient series that the transform algorithm need.
Cage_transform compute and inverse the transformation
Render_mapping render the final image.

This architecture allow, with Gegl, easy reussing of this operation. In that case, my tool’s code can be easily reused and adapted to create an iWarp like tool.

To stay in the present, here is the state of things. My tool is in majority done. I mean that the core works well, and it’s usable for a classic utilisation. There is still some teething problem to correct (for instance, it doesn’t works on mask), love to give to UI, and it will be ready for code review and inclusion in master branch of Gimp. At least I hope =)

Here is some deform example:

It ain’t over, but it never was so close to be.

Posted in Gimp, Summer of Code | 3 Comments »

(Français) Ubuntu/Debian : faire le ménage dans les noyaux

August 14th, 2010 | Author: Jidey

Sorry, this entry is only available in Français.

Posted in Linux, Technique | Tags: Grub, Linux, Noyaux, technique, Ubuntu | 2 Comments »

Moving from prototype

July 24th, 2010 | Author: Michael

Hi,

Some news here. In recent days, I talked a lot with my mentor and the others Gimp’dev. In my projet, I’m now in a state where a good part of things works. The idea is now to move from a prototype to a more cleaner and efficient form. In my case, since I’ve done a lot of experiment and workaround, it mean almost a full rewrite. The background is good, but the form isn’t. However, this work is quite fast and already well advanced.

Along with that, I started a algorithm that will compute the inverse transformation. Let me explain. In the majority of processing is the inverse transformation is used (we run over the target image, and we fetch pixel that should be there). It allow to achieve good image quality, in particular by avoiding aliasing. The problem in my case, is that the Green Coordinates, which form the basis for my transformation, only describe the forward transform. We therefore obtain images like that of my last post. Cheating is possible, but it’s still not ideal. The idea here is to calculate the direct transformation, to see where it goes, and interpolate for each target pixel the position in the source. It sounds easy, but in fact, no. But things are moving !

Posted in Gimp, Summer of Code | Tags: Gimp, prototype, rewrite, summer of code | 4 Comments »