No, I exported a PNG directly from Inkscape, The GIMP and sxiv screenshots were mainly to ascertain that color management wasn’t causing the variation in color.
I’ll re-trace and check the saving thing.
EDIT:
Results are as follows:
- Saving the svg and re-loading into Inkscape makes no difference (still shown yellow)
- Importing SVG into GIMP gives a similar result as exporting from Inkscape (ie. correct colors)
- Importing the exported PNG back into Inkscape shows correct colors.
Like afre, I suspect that this may be related to color management.
Going on that theory, I also took the time to strip the PNG you provided (optipng -strip all 1ebc2a5b146dd249142dd686577b65581b9b7afd.png). This should remove any color management information (eg. gamma, ICC profile) that could have been influencing things.
Then I imported into Inkscape and traced this file.
Result: Still yellow!
Conclusion: Color management data on input image is not the cause. Bug is triggered by some particular aspect of the pixel data itself. Bug does not affect quantization (otherwise, export would use wrong colors).
Theory: Correct colors are assigned to vectors, then the wrong color management info is assigned to them. Export ignores this CM info (not implemented yet?) and so renders correctly.
However, examining the SVG generated by Inkscape does not reveal any color management information. So I’m still relatively clueless, but at least there is enough evidence in this thread to file a bug report.
@afre: If by ‘uniform’ you mean ‘doesn’t occur on all pictures’, I agree.
Last I checked PoTrace didn’t have any multitrace support; anyone who wants to implement it needs to at minimum generate an indexed image, sort its palette by perceptual brightness, and pretend that index == grey value as they repeatedly feed the same image into potrace, varying the --threshold value.