Hello,
I would like to report 2 issues.
Bug 1: “Automatic crop” Stops at Previously Deleted Areas in Transparent PNGs
Steps to reproduce:
1. Open the PNG image that contains transparency.
2. Delete part of the image so that the deleted area appears transparent.
3. Run the “Automatic crop” function.
Expected behavior:
The “Automatic crop” function should ignore fully transparent areas and crop the image tightly around the remaining visible content.
Actual behavior:
Although the deleted area still looks transparent, it seems to be treated as non-transparent internally. As a result, the auto-crop operation stops at the boundary of the deleted area, as if a new opaque edge were created there.
Bug 2: SVG Files Render with a Black Background
Steps to reproduce:
1. Open the SVG file.
2. View the image in the application.
Expected behavior:
The SVG should render with its intended background, and all shapes should display with correct colors.
Actual behavior:
The background becomes completely black, and only a small subset of shapes or elements display their correct colors. Most of the SVG content appears incorrect or invisible against the black background.
Thank you for looking into this.
1.9.8 - Incorrect "Automatic crop" Behavior on Transparent PNGs and Black Background Issue with SVG Files
-
Thomas2718
- Posts: 3
- Joined: Fri Jan 09, 2026 3:39 pm
1.9.8 - Incorrect "Automatic crop" Behavior on Transparent PNGs and Black Background Issue with SVG Files
- Attachments
-
- Transparent PNG - original.png (48.4 KiB) Viewed 56 times
-
- Transparent PNG - original (Screenshot of the operation).png (152.61 KiB) Viewed 56 times
-
- Transparent PNG - deleting part of the right side.png (41.44 KiB) Viewed 56 times
-
- Transparent PNG - deleting part of the right side (Screenshot of the operation).png (171.59 KiB) Viewed 56 times
-
- Transparent SVG - original (open with browser).png (52.86 KiB) Viewed 56 times
-
- Transparent SVG - original (open with XnView MP 1.9.8).png (90.53 KiB) Viewed 56 times
-
- Transparent SVG - original.7z
- (12.58 KiB) Downloaded 1384 times
Last edited by Thomas2718 on Sat Jan 10, 2026 10:02 am, edited 1 time in total.
Re: 1.9.8 - Incorrect "Automatic crop" Behavior on Transparent PNGs and Black Background Issue with SVG Files
I cannot reproduce your bug1
but there is an issue with Zealous crop, it crops too much
but there is an issue with Zealous crop, it crops too much
-
Thomas2718
- Posts: 3
- Joined: Fri Jan 09, 2026 3:39 pm
Re: 1.9.8 - Incorrect "Automatic crop" Behavior on Transparent PNGs and Black Background Issue with SVG Files
Thank you for your reply.user0 wrote: Sat Jan 10, 2026 6:25 am I cannot reproduce your bug1
but there is an issue with Zealous crop, it crops too much
I am using "Automatic Crop", not "Zealous Crop".
I also tested "Zealous Crop", and the result matches yours: "Zealous Crop" does not work correctly either.
To clarify the issue, I have updated the attachments and added more files.
Please refer to the original post.
Re: 1.9.8 - Incorrect "Automatic crop" Behavior on Transparent PNGs and Black Background Issue with SVG Files
bug1
press Ctrl+H to see edited image w/o alpha channel - there will be white rectangle that you cut out
before cutting, change Background color from white to black in the Viewer Edit menu
press Ctrl+H to see edited image w/o alpha channel - there will be white rectangle that you cut out
before cutting, change Background color from white to black in the Viewer Edit menu
-
Thomas2718
- Posts: 3
- Joined: Fri Jan 09, 2026 3:39 pm
Re: 1.9.8 - Incorrect "Automatic crop" Behavior on Transparent PNGs and Black Background Issue with SVG Files
Thanks for the reply. I have tested the workaround you provided and it works.user0 wrote: Sat Jan 10, 2026 10:35 am bug1
press Ctrl+H to see edited image w/o alpha channel - there will be white rectangle that you cut out
before cutting, change Background color from white to black in the Viewer Edit menu
I’ve confirmed that a "Delete" operation results in (RGB=background color, Alpha=0). Since the Automatic Crop tool seeks an exact match with the reference pixel (at the corner, usually (0, 0, 0, 0) ), it causes a mismatch that stops the crop.
I understand this isn't strictly a bug now. However, I would like to offer some feedback on the underlying logic for future improvement:
In any image editing context, "Delete" implies that the area is no longer wanted. Logically, Alpha = 0 represents an unwanted area. In the context of an automatic crop, this intent should arguably have higher priority than an RGB mismatch.
Suggestion:
To improve the workflow, would it be possible to add a checkbox in the Automatic Crop settings to "Crop any pixel with Alpha = 0 regardless of its RGB value"?
This would ensure the tool remains reliable even when the user prefers a specific UI background color.
Thanks again for the support.
- Attachments
-
- Transparent PNG - deleting part of the right side (without alpha channel).png (71.94 KiB) Viewed 27 times