OK, my apologies to IOhannes for the rant, I was in the understanding that this is how the object works now.
Now that it's clarified that this is a bug, not a feature. It should be evaluated why it behaves differently and if it is worth it to keep the changes or we can go back to the original. Maybe ricoardo can tell us more about the changes? If the changes are worth to keep but can't be compatible to the original i see two options:
What can i do, to help fixing it? I didn't quite understand what you meant at the IRC.
m.
Am 16.06.2013 um 12:19 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
pix_multiblob algorithm changes just after the 0.93.3 release in november 2011 Ricardo Fabbri made those changes so maybe he is the best person to help us figuring out where the "bug" is, if this is really a bug
since the algorithm changed I'm not so surprised that the same patch with the same parameters doesn't work in both case
if pix_multiblob should be backward compatible, could it be possible to rename the Ricardo's version to pix_multiblob2 or something else and to restore the 0.93.3's version in the Gem's main trunk ? or is it better to put the two algorithms in the same pix_multiblob object and select it with a [mode( message or something else ?
cheers
a
-- do it yourself
http://antoine.villeret.free.fr2013/6/15 IOhannes m zmölnig zmoelnig@iem.at On 06/15/13 16:03, Max wrote:
So that is a confirmed Gem problem. I don't see the point to work with that object any more, now that I know that the new version breaks backward compatibility. I want to be able to make a patch that works with whatever gem version : (
i think that' a bitter conclusion to draw. obviously the object should be backwards compatible, and it being not is a bug.
rather than ranting about "not seeing the point any mor" it would be good to help fix the bug.
fgdstn IOhannes