(In reply to Dominique Leuenberger from comment #3) > (In reply to Petr Gajdos from comment #2) > > Let's try to remove GraphicsMagick again: bug 1206322 > > That's ambitious: Yes, it was ambitious, even if I think only five packages really BuildRequires it: inkscape, scribus, octave, wt and pdf2djvu and requirements are optional in all of them. I think it is doable, but I am not sure how much time would this require in case we want to keep all the functionality [bug 1206322 comment 20]. (In reply to Dirk Weber from comment #19) > $ gm compare -metric PAE ./85-1_tw.png montage1.png > Image Difference (PeakAbsoluteError): > Normalized Absolute > ============ ========== > Red: 0.2149691005 14088.0 > Green: 0.1889066911 12380.0 > Blue: 0.1703669795 11165.0 > Total: 0.2149691005 14088.0 > $ gm compare -metric PAE ./86-1_tw.png montage2.png > Image Difference (PeakAbsoluteError): > Normalized Absolute > ============ ========== > Red: 0.1409323262 9236.0 > Green: 0.1148699168 7528.0 > Blue: 0.0963302052 6313.0 > Total: 0.1409323262 9236.0 > > ImageMagick-7.1.0.55-1.1.i586 > GraphicsMagick-1.3.38-1.6.i586 > > I am afraid I can not judge these results. > I do not know whether these are precise operations which always have to > give the same results or whether they are fuzzy operations and the result > can e.g. depend on the used floating point unit, > like x87 or SSE2, and it is normal to have a deviation when an image > "montaged" on one type > of fp-unit is compared to one "montaged" on another type of fp-unit even > when both are actually valid results. Thank you Dirk for your evaluation. I really do not think testing ImageMagick with GraphicsMagick and vice versa is a good idea; the problem, if any at all (reading previous comments), can be in either of them and I am almost convinced who will have to tackle these potential issues down. But ok, I understand you guys want me to have a nice hackweek, right ;)?