Save option "Whichever makes smallest file" is broken but is also (I think) superfluous

[qu0zz]

related to #67 "saving as" bug, but a separate issue

If you choose "Whichever makes smallest file" as your save option it ALWAYS saves a .png even if you name it as a .jpg. Furthermore even if this was fixed (I think) a .png defacto will always be larger file than the equivalent jpg, thus the option is currently superfluous Unless you are intending to add further save-as options (like avif, which would be a nice) but even then you would have to allow users to set the default compression levels (which I'm certainly NOT suggesting ) for the smallest file size option to work as avif would defacto be smaller than jpg (default compression levels for similar perceived quality assumed) Thus as it stands the easiest fix for "Whichever makes smallest file" could be to remove the option?

[vicnevicne]

Err, 2 things: First and foremost, a PNG is not always larger than a JPG, it all depends on the source. Take the following example Image 1 : PNG, 39kB: Image 2 : JPG, 57kB: Not only is the PNG smaller, it is also lossless (perfect image quality), while the JPG is quite bad, with blurry edges (e.g. zoom on the blue text). So in the context of captures for explanation purpose (which is one of the primary purposes of screenshots), PNG is way better, regarding both size and quality. (The original Jing did only save in PNG btw). However, with photographs or more "natural" (e.g. hand drawing) images, lossless encoding is much more expensive in terms of file size, that's why I added JPG. For JPGs I had to select a quality/size ratio and I chose a relatively aggressive value. That's why some artifacts appear around text, but compressing less would lead to even larger file sizes.

The "whichever makes the smallest file" option makes the choice automatic. Technically, it encodes both the JPG and the PNG, weights them and decides which one to keep. I personally use that option all the time (so much I even thought of removing all others :-) ). I only kept the choice because some people might not tolerate the loss of quality incurred by JPGs (and my goal is that Ginj, must mimic Jing as closely as possible by default).

I never had an issue with it, but I admit I never type any extension. When the "Save as" box opens, I optionally change the folder and the base name, but I never add any extension, and it does save in either in JPG or in PNG, depending on the sizes. Can you check whether that particular scenario indeed works ?

[qu0zz]

My profuse apologies, you are correct, I was aware of the compression implications, I always save in png on the basis that it doesn't bake in the mosquito noise and I can always re-encode quickly with irfanview. I was unlucky with my testing method, I never found a capture where the jpg was bigger. I've since done more exhaustive testing and yes, where there are flat areas with little complexity and colour, as you'd expect png is/can be smaller. Would you like to delete the issue and replies? It is working as intended (and I now feel stupid). (In my defence your honour, having compared the same captures with filesizes in irfanview at various compression levels your pngs are fairly compressed/optimised for size, the only way I can get near those filesizes in irfanview is to use the optiPNG (plugin) optimiser)

[vicnevicne]

I'm using the default PNG encoder of Java but I guess it's quite optimized. It probably also contains only the bare image with no extra metadata. I won't delete this issue (worst case I tag it as "invalid", that increases the "closed issue" count ;-)) but I'd first want to make sure there is indeed no hidden bug, because I'm worried by your first sentence "If you choose "Whichever makes smallest file" as your save option it ALWAYS saves a .png even if you name it as a .jpg". I mean I just tested taking a capture of a random landscape picture returned by Google, saving it using the "whichever makes smallest", naming the file with a jpg extension and sure enough the result indeed was a JPG file. Now if I take a simpler image (e.g. a blank part of a web page), then it saves as a PNG (because it is smaller), no matter the typed a JPEG extension. In other words, it does not take the extension into account, it follows the rule "whichever makes smallest file" as requested. So couldn you double check if you can reproduce the case (e.g. selecting a part of the screen that contains a photograph and it still creates a PNG). If it does, then indeed there is a valid issue to be traced.

[qu0zz]

Sorry for wasting your time on this one. I can confirm it is working as intended, I wasn't thinking and chose the wrong type of material to test - mainly graphics (albeit with lots of fine detail) and text and then expected it to behave in compression terms, like irfanview. Just out of curiosity, (and it confused me at first because I was looking at the reported file sizes on the history page expecting the sizes to reflect the saved sizes) I noticed that despite any saves as .jpgs (into my save location folder), the same captured files saved in the default history folder at \Users\username.Ginj\history are always saved as pngs. I assume that's deliberate? (I can see an argument both ways here as although it (sort of) contradicts the choice for smallest saved file sizes, it does allow a better quality history archive). Again my apologies.

[vicnevicne]

Great if it is working. The process is "Capture > History > Export". Indeed, the history always keeps the clean PNG files (clean in the sense that the overlays are stored separately, so that they can be removed or edited afterwards). And in that regard, keeping the clean source means lossless. The export itself, on the other hand, can be used to send by e-mail, share on forums or store online, and in that regard, file size may be more important.

I'm going to close this as "invalid" as it works as expected, but thanks for the discussion :-)