Does swapping R and B bytes in colors ring any bells?
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/1447850
where 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 fillimage gui 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
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
On 25-Apr-2015 18:19, Krzysztof Kosiński wrote:
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.
Ah, I see, in cairo-utils.h there is a pixelformat() function to return PF_CAIRO or PF_GDK. I can work from there.
This leaves open the question of why and when the logic table for pixbuf format on this sort of "print" became this (where Y is either PF_CAIRO or PF_GDK, and N the other):
image fillimage gui Y Y cli Y N
Seems inconsistent to me.
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Also a great day but seems to me I need more time to get more code working, but think we are closing a lot of discussions, news or older for the future of inkscape. The end of the dey have a great surprise !Spagetti Carbonara in a lovely place! Think i need to go whith the front of my head to the gym when arrive home. Finaly Im happy. I show some of my work on the Hackfest and nobody sleep with my quickly sckeched slides and ?sometimes erratic descriptions. See all in Toronto, IRC or mailing list. Dont forget tell about we have accessible fresh blood on group. ?xxx you are welcome.
participants (3)
-
Jabier Arraiza -
Krzysztof Kosiński -
mathog