[HOLD for payment 2024-10-17] The Heic format image showing as 2.5MB is uploading with size over 10MB

[mountiny]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?:
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:

Action Performed:

Break down in numbered steps
IMG_3877.HEIC.zip

1. Using exactly the image above in heic format and with 2.5MB attempt to scan a receipt in native ios

Expected Result:

Describe what you think should've happened

The request is successful since the image is under 10MB.

Actual Result:

Describe what actually happened

The request fails because the uploaded file size in the end is over 10MB, seems like the conversion is not as efficient as it should be

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @isabelastisser

[melvin-bot]

Current assignee @mountiny is eligible for the AutoAssignerNewDotQuality assigner, not assigning anyone new.

[melvin-bot]

Triggered auto assignment to @isabelastisser (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[OlimpiaZurek]

Hi. I'm Olimpia from Callstack and I'd like to work on this issue.

[OlimpiaZurek]

The issue stems from the manual conversion of HEIC images to JPEG, introduced in a PR aimed at fixing automatic HEIC-to-JPEG conversion.

After the conversion, the convertedAsset object does not include a size value:

App/src/components/AttachmentPicker/index.native.tsx

Line 178 in c301698

const convertedAsset = {

As a result, RNFetchBlob.fs.stat() is used as a fallback to fetch the file size from the file system, which returns a larger size due to the differences between HEIC and JPEG formats. HEIC uses a more efficient compression algorithm compared to JPEG. When converting from HEIC to JPEG, the file often becomes larger because of additional metadata and less efficient compression, even if the image quality remains the same.

• To fix it we could adjust the compression level in the manipulateAsync() function to reduce the size of the JPEG file:

function AttachmentPicker({type = CONST.ATTACHMENT_PICKER_TYPE.FILE, children, s
                             .then((isHEIC) => {
                                 // react-native-image-picker incorrectly changes file extension without transcoding the HEIC file, so we are doing it manually if we detect HEIC signature
                                 if (isHEIC && targetAssetUri) {
-                                    manipulateAsync(targetAssetUri, [], {format: SaveFormat.JPEG})
+                                    manipulateAsync(targetAssetUri, [], {compress: 0.7, format: SaveFormat.JPEG})
                                         .then((manipResult) => {
                                             const uri = manipResult.uri;
                                             const convertedAsset = {

With this change, the final uploaded image size will be ~2.4 MB instead of over 10 MB

• The second solution would be to capture the original size of the HEIC image before conversion:

function AttachmentPicker({type = CONST.ATTACHMENT_PICKER_TYPE.FILE, children, s
 
                     const targetAsset = response.assets?.[0];
                     const targetAssetUri = targetAsset?.uri;
+                    const targetOriginalSize = targetAsset?.fileSize;
 
                     if (!targetAssetUri) {
                         return resolve();
@@ -181,6 +182,7 @@ function AttachmentPicker({type = CONST.ATTACHMENT_PICKER_TYPE.FILE, children, s
                                                 type: 'image/jpeg',
                                                 width: manipResult.width,
                                                 height: manipResult.height,
+                                                fileSize: targetOriginalSize,
                                             };
 
                                             return resolve([convertedAsset]);

cc: @mountiny

[mountiny]

@OlimpiaZurek it might be good to try to keep the size of the file

[OlimpiaZurek]

@OlimpiaZurek it might be good to try to keep the size of the file

I agree that keeping the original file size is better option, as compressing the image could degrade its quality. However, after testing the second solution, I'm still encountering the same error: An unexpected error occurred while uploading this file. Please try again later. It seems this change isn't sufficient, as the backend still reports that the image exceeds the size limit. I'm currently investigating this further.

[mountiny]

Thanks! Maybe the targetOriginalSize is not working correctly

[OlimpiaZurek]

@mountiny It looks like targetOriginalSize is working fine and gives the correct value. The issue comes up in the next step, during the request confirmation, when the image is uploaded using the new File API. The problem is that this API returns the size of the already-converted JPEG image, which ends up being about 4 times bigger than the original HEIC. Since the size property in the File API is read-only and represents the actual file size in bytes, we can’t modify it directly.

While going through the code, I noticed there’s already a mechanism that automatically reduces the size of receipt images, which was added a few months ago (PR) . However, there seems to be a discrepancy between the maximum image size in the code (25MB) and the 10MB limit enforced by the backend.

To fix this, we can update the code by adding a max size for receipts const API_RECEIPT_VALIDATIONS.MAX_SIZE = 10, instead of the current limit, which I believe is meant for attachments and not specifically for receipts. This would allow the existing mechanism to work as intended for receipt uploads.

[mountiny]

@OlimpiaZurek Ok yeah lets do that, the receipts have 10MB in the backend so lets try that

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.47-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix receipt upload size issue #50329

If no regressions arise, payment will be issued on 2024-10-17. 🎊

For reference, here are some details about the assignees on this issue:

• @OlimpiaZurek does not require payment (Contractor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@mountiny] The PR that introduced the bug has been identified. Link to the PR:
• [@mountiny] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@mountiny] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@OlimpiaZurek] Determine if we should create a regression test for this bug.
• [@OlimpiaZurek] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@isabelastisser] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[mountiny]

We only need to pay @eh2077 - the reward is $250

no need for checklist in this case as this was probably a side effect of using a library to process the heic image format

[isabelastisser]

Payment summary:

$250 to @eh2077 for PR review. Payment PENDING in NewDot.

[eh2077]

Requested payment in NewDot

[JmillsExpensify]

$250 approved for @eh2077