Editing a GIF, BMP, ICO or SVG writes PNG bytes under the original name

[skjnldsv]

images.ts:94 sets canEdit: true for the whole image handler, so the Edit button is offered on all 13 mimes it registers: image/apng, image/bmp, image/gif, image/jpeg, image/png, image/svg+xml, image/webp, image/x-icon, and image/heic, image/heif, image/tiff, image/x-xbitmap, image/emf where the server generates previews for them.

@nextcloud/image-editor can only write three. ExportOptions.format is typed 'image/png' | 'image/jpeg' | 'image/webp', and the viewer narrows it further at lib/components/ImageEditor.vue:46:

const exportOptions = computed<ExportOptions>(() => {
	if (props.file.mime === 'image/jpeg' || props.file.mime === 'image/webp') {
		return { format: props.file.mime, quality: 0.9 }
	}
	return { format: 'image/png' }
})

So editing a GIF produces PNG bytes, and onSave PUTs them to props.file.encodedSource, which is the original name. holiday.gif afterwards contains a PNG. Same for BMP, ICO, APNG (which loses its animation on the way through the canvas), TIFF, HEIC and, worst of the set, SVG, where a vector file comes back as a raster one under a .svg name.

ExportResult already carries mimeType, and the save path ignores it.

Note

I have read this off the code path rather than reproduced it against a server, so the exact behaviour per mime is worth confirming before picking a fix.

Roughly, the options are to stop offering the edit where the format cannot be written back (narrow canEdit to the three, or make it per-mime rather than per-handler), or to save under a new name with the extension that matches what was actually encoded and leave the original alone. The second keeps the feature for more files but turns a save into a create, which the user should be told about rather than discover.

---

Second thing, same lines. The quality: 0.9 above overrides the quality matching in the editor's export. Left alone, qualityFor(source) reads the source's own quantization tables and writes the new file at the quality the old one was written at, held between 0.75 and 0.97. Passing an explicit 0.9 defeats that for every JPEG and WebP the viewer saves: a photo written at 0.95 loses more than it needs to, one written at 0.80 is re-saved larger than it needs to be. Dropping the quality key restores the matching, since options.quality is only consulted when set.