Paul, do you talk about the format which is used to store an artwork file in the MP3? Because that's what my comment refers to. I noticed that if I chose to import artwork (e.g. by drag'n'drop or by autocorrect), it will be embedded as PNG as soon as the file extends the configured maximal dimensions. I don't think that's because Jaikoz is unable to output the data as JPEG because it was able to read the source JPEG and was able to downscale it - why it shouldn't be able to embed it as JPEG...?
Ah, right the original issue refers to being able to choose what format to the save artwork to when saving artwork as a file using File/Save Artwork to Fileystem.
Now realize you are talking about something else, and I think you are right something needs to be done here but there is a problem. For example when using Drag and Drop Jpeg Jaikoz (via the Java code) doesn't actually see the original bytes making up the jpeg instead it receives a fully formed BufferedImage (which doesn't have reference to the original bytes in the file), I then have to convert that BufferedImage to a new jpeg using Javas jpeg routines, but sometimes a jpeg cannot be created from the BufferedImage, and sometimes the jpeg created has the wrong colours (looks sort of infra-red effect) so for safety when I do not have the original image I default to using pngs because they are more reliable.
So created new issue for your problem Jan, now I need to decide on the original issue, do you users need to be able to decide whether to output jpg or png, or just stick with the default of using jpeg, and only png if it fails.
From my perspective I don't need the saving at all because I want my graphics to be stored within the files. If I need to export the imagery for editing, it wont matter which format it is. Actually I'd think it's best to export it as-is. There are plenty of free tools available to batch-convert graphic files to other formats.
Can now specify if artwork should be embedded as PNg or JPEG.