[iOS] MediaPicker ShouldUsePngFormat method has conflicting/redundant code

[MitchBomcanhao]

Description

in src/Essentials/src/MediaPicker/MediaPicker.ios.cs#L611 you can see the following:

		bool ShouldUsePngFormat()
		{
			// Use PNG if:
			// 1. High quality (>=90) and no resizing needed (preserves original format)
			// 2. Original file was PNG
			// 3. Image might have transparency (PNG supports alpha channel)

			bool highQualityNoResize = compressionQuality >= 90 && !maximumWidth.HasValue && !maximumHeight.HasValue;
			bool originalWasPng = !string.IsNullOrEmpty(originalFileName) &&
									(originalFileName.EndsWith(".png", StringComparison.OrdinalIgnoreCase) ||
									 originalFileName.EndsWith(".PNG", StringComparison.OrdinalIgnoreCase));

			// For very high quality or when original was PNG, preserve PNG format
			return (compressionQuality >= 95 && !maximumWidth.HasValue && !maximumHeight.HasValue) || originalWasPng;
		}

• the check for highQualityNoResize is then discarded and computed again
• the compressionQuality value is initially checked at 90%, then replaced with 95% in the second computation . which one is it? the comment matches the 90% one.
• there are two different checks for originalFileName.EndsWith, with different casings of the same string, with an OrdinalIgnoreCase string comparer, so they're both effectively the same thing.

Lastly, this magical compression figure over which the PNG file format is used is rather unexpected. I didn't expect to have to inspect the maui source code to figure this out.

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

10.0.11

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

iOS, macOS

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

[kubaflo]

Hi @MitchBomcanhao! Maybe you'd like to contribute to MAUI and open a PR yourself? 🙂 If you don’t have time, we can take care of it - but it would be really cool if you could give it a try! Let us know!

[MitchBomcanhao]

@kubaflo while contributing is positive in general, I don't actually know what the spec is for that feature - the code is doing 2 different things for the same check, and I can only speculate as to which one is correct, so I don't think it is correct for me to say which one should be there. there is further logic which runs after this method is called that also depends on the picked value for compressionQuality. It all seems pretty spurious and probably written by copilot without much human review. I do think this needs better ownership from people more "in the know".

[kubaflo]

@MitchBomcanhao what do you think? #33140

[MitchBomcanhao]

seems ok. the relevant changes have been made - and that is what matters.