The reason for these is that Cairo and GDK-Pixbuf expect different pixel formats. Images need to be in Cairo format to do any compositing operations on them and display them on the screen, but they need to be in GDK-Pixbuf format when saving / loading them. One format can be converted to the other by swapping the R and B bytes.
You should use the class Inkscape::Pixbuf instead of manually swapping bytes. It is in display/cairo-utils.h.
Also if you do any direct pixel modifications to a Cairo image surface, you MUST call cairo_surface_flush() before these operations and cairo_surface_mark_dirty() after them.
Regards, Krzysztof
2015-04-24 20:16 GMT-04:00 mathog <mathog@...1176...>:
Do any of you recall having seen code in Inkscape which swaps the bytes for colors R and B, but leaves the bytes for G and A alone?
In emf-print.cpp there has long been a section with this code (sorry about the wrap):
(void) RGBA_to_DIB(&px, &cbPx, &ct, &numCt, rgba_px, width,height, width * 4, colortype, 0, 1); // Not sure why the next swap is needed because the preceding does it, and the code is identical // to that in stretchdibits_set, which does not need this. swapRBinRGBA(px, width * height);
A bug has turned up
https://bugs.launchpad.net/inkscape/+bug/1447850where the swap is needed for interactive work, but NOT needed for cli work. As the note indicates, I never knew why those two bytes were reversed, they should not have been, it was always a workaround for unexplained behavior. Now it seems that these bytes are not always swapped. Here is what happens: (bytes are swapped in output routine: Y/N)
image fillimagegui Y Y cli Y N
Fillimage refers to an image used in a fill operation, image is just the usual sort of image in the SVG drawing.
The EMF input/output has no idea what mode it is operating in. The pixel array rgba_px comes from this line in emf-print.cpp:
rgba_px = (char *) pixbuf->pixels(); // Do NOT free this!!!and the contents of rgba_px are not the same for the fillimage test case in gui and cli modes. pixbuf comes via a call from metafile-print.cpp:
*epixbuf = ((SPImage *)parent)->pixbuf;So, as far as I can tell the R<->B swapping has occurred elsewhere in Inkscape, long before it hits the EMF output code. Any suggestions where that might be? Or why that might be?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel