This is a similar bug to #6072.

#6066 should fix this, by using non-scaling paths with a constant stroke width.

Here’s the line that causes this bug. It doesn’t properly compensate for changes in scale when image size changes. Eg. when the image scale is halved, the rendered stroke width should be doubled in order to render the same line width in CSS pixels.

In the examples above, if the 600px subject is rendered at a scale of 1 then the 1200px subject renders at a scale of 0.5. The formula here then give stroke widths of 3px (600px subject) and 3.5px (1200px subject), which renders a thicker line on the smaller image (3/600 is larger than 3.5/1200.) The rendered line width would then be 3px on the 600px subject, but 1.75px on the 1200px image.

In #6066 I’ve avoided all this by having the browser handle the line scaling calculations.

Here's the maths for this bug in production. For drawing tools in general, the rendered width is a constant 2px for all image scales. For freehand lines, the rendered stroke width depends on the square of both the client width (set by the width of the volunteer's browser window) and natural width (size of the uploaded image):

// scale of the rendered subject image in the browser.
scale = clientWidth / naturalWidth;

// SVG stroke width for all drawing tools except freehand lines.
strokeWidth = 2 / scale;

// rendered line width in the browser is simply SVG width multiplied by SVG scale.
renderedStrokeWidth = (2 / scale) * scale = 2;

// Freehand lines with scale < 3.
strokeWidth = 4 - scale;
renderedStrokeWidth = (4 * scale) - scale ** 2;

// Freehand lines with scale >= 3.
strokeWidth = 1;
renderedStrokeWidth = scale;