Bug of GeneralizedDiceLoss

[lixinxin9703]

Describe the bug
Code:
numer = 2.0 * (intersection * w) + self.smooth_nr
denom = (denominator * w) + self.smooth_dr
f: torch.Tensor = 1.0 - (numer / denom)

If self.batch is True, the shape of intersection, denominator and w are [C]. In the code, both the intersection and denominator are multiplied by w. If smooth item is ignored, then w doesn't work.

NiftyNet code:
generalised_dice_numerator = 2 * tf.reduce_sum(tf.multiply(weights, intersect))
generalised_dice_denominator = tf.reduce_sum(tf.multiply(weights, tf.maximum(seg_vol + ref_vol, 1)))

In niftynet code, they will first sum and then divide.

[wyli]

thanks for reporting, I think those are class-wise weighting, the shape [C] makes sense, or do I misunderstand the idea here?

[lixinxin9703]

thanks for reporting, I think those are class-wise weighting, the shape [C] makes sense, or do I misunderstand the idea here?

yes, the shape [c] makes sense. But I think w doesn't work, bacause both the intersection and denominator are multiplied by w.

For example:
intersection: [1,2,3,4];
denominator: [2,3,4,5];
w: [0.1, 0.2, 0.3, 0.4];
so numer / denom = 2*([1, 2, 3, 4] * [0.1, 0.2, 0.3, 0.4)]) / ([2, 3, 4, 5] * [0.1, 0.2, 0.3, 0.4))
then [0.1, 0.2, 0.3, 0.4] are eliminated.
numer / denom = 2*([1, 2, 3, 4]) / ([2, 3, 4, 5])
w doesn't work. I think w is meaningless.

[wyli]

I see, that's a good point, looks like an issue introduced when fixing this bug #5466, please let me know if you are interested in submitting a patch, otherwise I'll have a look soon.

[lixinxin9703]

The previous version of the code in #5466 seemed more reasonable

numer = 2.0 * (intersection * w).sum(final_reduce_dim, keepdim=True) + self.smooth_nr
denom = (denominator * w).sum(final_reduce_dim, keepdim=True) + self.smooth_dr
f: torch.Tensor = 1.0 - (numer / denom)

In my opinion, GDL cannot generate [C] output, as GDL will calculate all classes as one metric.