Weka segmentation error after update 29.09.16

@Sverre, @ctrueden I confirm the problem comes from the Weka upgrade (3.7.11 to 3.9.0). I will try to figure out in the next days if there is a solution.

Ok, this solves the problem for me then at least. I’ll just make a new classifier. But will this classifier be compatible with the next update? Are they usually compatible?

I appreciate the quick help! I will probably be able to finish before I get data to analyse :slight_smile:

Yes, this is the first time I encounter this problem. I’m trying to figure out if there is a way to keep the compatibility between these two versions. Hopefully, I’ll make a new release fixing the problem soon!

1 Like

@ctrueden I have narrowed down the origin of the problem to the transition from weka 3.7.11 to 3.7.12 but I don’t know if there is any easy solution we can apply.

Let me go into the details. When saving a model (classifier) two things need to be actually saved: the serialized AbstractClassifier object containing the details of the model, and the serialized train header stored in an Instances object, which contains information about the attributes (name and number of all them, class index, possible class values, etc). In Weka 3.7.12 the Instances class has changed some fields (what seems to break backward compatibility) and that’s why the error occurs when loading the file with both objects.

You can reproduce the error with the following script and Sverre’s model file:

import weka.core.SerializationHelper;
import weka.core.Instances;
import hr.irb.fastRandomForest.FastRandomForest;

// read both model and train header
obj = SerializationHelper.readAll( "classifier 2.0 .model" );
// cast first object to FastRandomForest
frf = (FastRandomForest) obj[ 0 ];
// cast second object to Instances
data = (Instances) obj[ 1 ];

I don’t know if there is a way to read the old Instances format. What puzzles me is the fact that I couldn’t find anybody complaining about this problem in the Weka forums…

PS: the save/load model code is the same in TWS and the Weka core.

1 Like

2 posts were split to a new topic: Choosing training features in weka segmentation

@ctrueden After more searching I discovered they discussed the issue before in the Weka mailing list and it seems they broke backward compatibility to improve memory consumption. I have wrote to them to see if there is any solution…

1 Like

It seems they do not expect backward compatibility between those weka versions. This is what they said:

Users of Weka 3.6 will find that serialized models created in 3.6 cannot be used in 3.8. Unfortunately, there is no workaround for this. Models will need to be recreated in Weka 3.8. Similarly, developers using 3.6 will find that there are some small changes that they need to make to their code in order to compile against 3.8. A quick check of the javadoc for 3.8 will hopefully show what is necessary.

Yes, serialization is not intended to be used as a long-term storage mechanism. I did not realize that TWS was doing that. The proper solution is to persist the models in some more robust data structure. It would be nice if the Weka library provided such a structure, instead of every consumer of the library needing to invent their own.

However, the cat is already out of the bag. Presumably, many people have existing data saved using the serialization approach. I see two possible solutions here:

  1. Downgrade to Weka 3.7.11, at least for now.

  2. Create an upgrade tool which can convert old serialized data to the new format. This could easily live as a standalone tool, but it would be much nicer to do this transparently within ImageJ when someone opens old data. This could be done with a custom class loader which loads the old Weka 3.7 classes dynamically, but is not exactly trivial to code. Unfortunately, I cannot make time to work on such a project this year.

What do you think?

I have talked with some of the Weka developers and they have some upgrade tools already implemented. I’m going to test them and see how it goes. I hope we won’t need to downgrade Weka…

Thanks for your help!

1 Like

@Sverre, talking with the Weka developers I got a way of migrating old models into the new system, so you don’t need to recalculate yours. Here you are the new file for your model.

Cheers!

3 Likes

Thanks, this is a big help :slight_smile:

Awesome! Very glad to hear that. :relieved:

@ctrueden yeah! It’s a very active and friendly community.

They have included the model migrator in the WEKA Downloads page (see note 2).

So far, the migration requires an old weka.jar (v3.8.0) with a small edition I made to include our default FastRandomForest classifier and a simple command line call:

$ java -cp modelMigrator.jar:weka38.jar:Trainable_Segmentation-3.2.1.jar weka.core.ModelMigrator -i old-classifier.model -o new-classifier.model

Notice the call requires including the latest version of the Trainable Weka Segmentation jar as well in the CLASSPATH.

I’m not sure how to do it but maybe we can include weka38.jar within Fiji so I create a simple script or plugin recreating ModelMigrator?

1 Like

Just to cap off this old thread: we did end up downgrading to Weka 3.7.11 again. And I think we will be stuck there for quite some time, since implementing any sort of model migration logic is significant work. We can do it if/when the new Weka is so good we can’t ignore it.

Edit: As of this writing, Fiji and TWS do use weka-dev version 3.9.0; see posts below.

3 Likes

I did not know about that, should I change TWS’ pom then?

1 Like

Really? The Java-8 update site ships weka-dev-3.9.0.jar. I didn’t find any other version in my Fiji installation.

2 Likes

Sorry guys, I was wrong. I saw that pom-scijava manages weka at 3.7.11 but I guess I forgot to check the Java-8 update site (I thought I checked and it matched, but obviously not).

I will fix pom-scijava now to match 3.9.0 as well. And once a new pom-scijava release is cut, we need to change Trainable_Segmentation to stop hardcoding the version there.

By the way Ignacio: Weka is up to 3.9.1 now. Do you know what’s new? Any reason to upgrade?

Edit: I updated pom-scijava to weka-dev 3.9.0.

1 Like

I have to check it, I’ll be back soon with a proper answer :wink:

Got it, here you are. Nothing crucial :wink:

Thanks. I’m assuming it does not break backwards compatibility again, though. So all things being equal, we probably should upgrade, no? I try to keep pom-scijava on the latest releases of components unless we have a good reason to do otherwise.

See also the new SciJava component status website, which reports when managed component versions are out of date. At the moment, it is telling me weka-dev needs no action, because I hardcoded it, but I have now unhardcoded it so next time the page regenerates it will report that weka-dev should be bumped to 3.9.1.

1 Like

If there is no problem on your side, yes, let’s upgrade. Thank you very much!

1 Like