Martjin,

I am very confused on how to load the paclets to run UNET. What is the file structure and where should I put it? When I use "File-Install-Package", what paclets should I use? I am not really familiar with the paclet structure in Mathematica.

Your help would be very much appreciated.

Claudio

Thank you!

Is there any reason, other than memory limitations, to limit the maximum input sizes to 256 for each dimension? Shouldn't it be enough with being multiple of 16?

I have overriden the definition of TrainUNET so as to allow that circunventing the size cap and am training on 400x304 images, and definitely training- time blows up, but hope the rest is OK. Maybe some hyper parameters would need to be adapted for the larger images?

Please keep in mind that doing this review is an experiment, and I am hoping to have a positive outcome. I do not mean to intrude, or hijack Martijn's package, and I do respect his choices, whatever those may be.

I am making these comments in the hope to benefit both the developer and the user community.

I also hope that others will spontaneously comment on my own work in a similar manner!

Due to lack of time, the below observations will be a bit superficial. I might try to dive deeper later.

init.m

Kernel/init.m is run when $Context is still Global`. Any non-System symbols you use in this file will pollute the Global namespace. Try to avoid this. When the package gets loaded, it should not create any symbols in Global.

I have seen the following update of the context path multiple times:

$ContextPath = Union[$ContextPath, System`$UNETContextPaths];

Note that this reorders the context path!! That includes not having System and Global at the very end, where they should be.

Please don't do this. It will cause unexpected and hard to track down problems for your users.

I noticed that all symbol names are Removed at the start. Maybe I am missing something, but such drastic measures are not usually necessary. ClearAll will do fine.

Note that constructs like ClearAll["foo`*"] or Protect["foo`*"] do work. SetAttributes["foo`*", ReadProtected] does not work, but SetAttributes[Evaluate@Names["foo`*"], ReadProtected] does. Note that none of these constructs introduce any new symbols, thus they are convenient to use in init.m.

Consider not printing anything during package loading without good reason. Note that people might load the package as part of another package. They might even load it on subkernels.

(I do believe that sometimes there is a practical reason. I do it with my IGraph/M package, though I suppress printing when I can detect that IGraph/M is loaded as part of another package. I keep the printed message as small as possible, yet some users still complain about it. It can be suppressed with Block[{Print}, Needs["..."]])

Usage messages

I wanted to note that it's great that you took care to make them work well with auto-completion.

Miscellaneous

size is not localized in VisualizeUNET2D.

AddLossLyaer is misspelt in the doc guide page.

UNET symbol link doesn't work in the docs. Was this renamed to MakeUNET?

Cosmetic

Make the version shown in PacletInfo match the actual version. It's show in the doc browser.

Compatibility

Indicate in the README which Mathematica version is required and try to test with that version. The IDEA WL plugin is capable of highlighting symbols not present in the WL version you set. It's useful for detecting certain compatibility problems early. http://wlplugin.halirutan.de

It looks like a nice package, and I am very happy to see that more and more people are publishing packages, despite of WRI's rather weak support for package developers and package development.

I was very disappointed to read this in the recent blog post:

Minimal dependencies (no collections of competing libraries from different sources with independent and shifting compatibility).

It sounds as if the goal were to explicitly avoid structuring Mathematica into packages in a logical way (everything goes into System) and want Mathematica to have everything built-in and Mathematica users to not rely on third-party packages. That's impossible, WRI doesn't have the resources to produce even a tiny fraction of what we users need.

But, as disappointing as this public statement is (there are several other things in the blog post suggesting the same attitude), that's a discussion for another time.

Unfortunately, it does seem to me that many users are distrusting of any functionality that doesn't come from Wolfram directly. "I know you have this package but I'd rather use a built-in ..." This situation was created by Wolfram in part by not encouraging package development and not providing functionality/resources (and implying that "it should be built-in"), but also by not educating the community about good package development practices. The unfortunate truth is that many of packages out there follow at least one questionable practice, which will eventually affect those that try to use it by causing unintended side effects, breakage, all sorts of problems. No wonder people don't trust packages developed by random people.

What can the community do about this?

I would like to propose setting up an informal network of WL package developers who help and support each other by looking at each other's work, doing informal code reviews, educating each other and learning from each other.

I am going to start here and I will point out a few small things that could be improved in this package (UNET). I hope you will find it helpful.

Be sure to put it on PackageData:

http://packagedata.net/

- Congratulations! This post is now a Staff Pick as distinguished by a badge on your profile! Thank you, keep it coming, and consider contributing your work to the The Notebook Archive!

Thanks! What do you mean with different amounts of outputs?

This is my understanding, but i might be mistaken. In my functions i layout the network architecture. Once the function is called you have to fill in the number of input classes, data dimensions, number of features and the number of output classes. From that moment everything is fixed. The UNET only has one output, an array with the binary segmentation.

The only place where there are multiple output ports is in the loss function, which is well explained in the help of mathematica LossFunction. But these are only used in training.

My approach was to create the neural net with only an Input, the data, and an Output, the segmentation, defined. Only when I start training the net I add the appropriate loss functions which have as input the Output of the net and the ground truth Target for comparison. The loss function it self just outputs a number. You can add as many loss functions as needed and you can even provide a different Target to each. As i understand the training tries to minimize the sum of all the loss functions.

Hope this helps.

Hope this helps

We have one input channel Nchan = 1

Step 1: split the lables into classes, for this exmaple Nclass = 4 (background, sphere, rectangle and overlap), so the network looks for 4 output lables.

Step 2: The first encoding layer split our input channel into 32 channels 1->32

Step 3: by the time we arrive at the deepest level our channels are downsampled but we have a lot of them

Step 4: After decoding we go back to 32 channels again. Hopefully by now each channel contains unique information about the image.

Step 5: We are looking for 4 labels so the 32 channels are mapped to 4 channels

Step 6: The 4 channels are converted to probability maps.

Step 7: The probability map become our 4 labels. In this case the network fail to correctly segment our example.

Our background and overlap are segmented whit a very high probability because they have a very distinct contrast which is easy to detect. However our circle and rectangle have the same contrast and have to be labeled based on their shape and not contrast. This is much more difficult and as such mistakes are made.