Imageprocessor: PostProcessor fails to optimize pngs on Azure, although no errors occur

[lars-erik]

Prerequisites

• [x] I have written a descriptive issue title
• [x] I have verified that I am running the latest version of ImageProcessor
• [x] I have verified if the problem exist in both DEBUG and RELEASE mode
• [x] I have searched open and closed issues to ensure it has not already been reported

Description

I can consistently reproduce pngs being 128 KB with a non-outputting process, but well optimized (99%) when the process has output. Very weird. :)

Steps to Reproduce

Swap between these two branches:
https://github.com/lars-erik/ImageProcessor/tree/wtf-output
https://github.com/lars-erik/ImageProcessor/tree/develop

When the wtf-output dlls are used on the azure app, everything is fine.
When the develop dlls are used it does not err, but the pngs are 128 KB.

The change should not affect the process at all, given the WaitForExit, but it does!
The images are returned long before the 5 sec limit as well, so something is really weird.

Diff here:
https://github.com/lars-erik/ImageProcessor/commit/6b012d0ad0344f75b4dc9bd31fead23ca5443e22

The last File.AppendText calls didn't seem to put anything in D:\temp\local, but when remote debugging I could see the process output and everything was fine. Without it I have no idea what happens, and it doesn't work. Could be easier to figure out. :D

System Configuration

Azure App Service

ImageProcessor, ImageProcessor.Web and ImageProcessor.Web.PostProcessor are built from this commit:
https://github.com/jimbobsquarepants/ImageProcessor/commit/eba1804d18ab492862c8bdf8da7c72a7e215bf85

• Environment (Operating system, version and so on):
  Azure App Service

• .NET Framework version:
  4.6.2

---

Have to stop this now. Have another major PR to attend to.

[JimBobSquarePants]

Very odd..... I'll have to stick something online and run some tests.

[lars-erik]

Give me a shout if I should dig up the originals our front-enders stuck in the storage account. Dunno if it's relevant that we use the our.umbraco.filesystemproviders.azure thingy. Freshest version.

[lars-erik]

I wonder if it'll work with the events but no string concats. That shouldn't hit performance much, if at all.

[lars-erik]

It works with the latest commit of the dev branch.

But both the dev branch, and my branch messes up (goes black) a couple of other images than the ones that are now properly compressed.

Our staging site is currently running with a debug build of the dev branch. (Also tested with release)

Here's one that turns black:
Original: https://markedspartner2017.blob.core.windows.net/media/1014/google-partner-liten.png
Current version (128k): https://www.markedspartner.no/media/1014/google-partner-liten.png
Dev - Messed up: https://markedspartner2017-staging.azurewebsites.net/media/1014/google-partner-liten.png

Here's one that works fine:
Original: https://markedspartner2017.blob.core.windows.net/media/1510/viking.png
Current version (128k): https://www.markedspartner.no/media/1510/viking.png
Dev - Fine (1.2K): https://markedspartner2017-staging.azurewebsites.net/media/1510/viking.png

After digging around some, I see the new process runner has the same output mechanism as I debugged with. :)

Here's the output for the image that goes black. It's RGB 8 bit according to Photoshop, but seems the TruePNG thing thinks it's grayscale:

TruePNG 0.6.2.2 : PNG Optimizer
by x128 (2010-2016)
[email protected]

Input file: tmp2E69.png | 2796 bytes
Image: 160x80 pixels | 8 bits/sample | Indexed greyscale

Delta filter: None
Chunks: iTXt, tEXt


Output format: 1 bits/sample | Grayscale

Chunks: only critical


try...
IDAT=22 file=79 complete=6%                
IDAT=22 file=79 complete=9%                
IDAT=22 file=79 complete=12%                
IDAT=21 file=78 complete=15%                
IDAT=21 file=78 complete=18%                
IDAT=21 file=78 complete=21%                
IDAT=21 file=78 complete=25%                
IDAT=21 file=78 complete=28%                
IDAT=21 file=78 complete=31%                
IDAT=21 file=78 complete=34%                
IDAT=21 file=78 complete=37%                
IDAT=21 file=78 complete=40%                
IDAT=21 file=78 complete=43%                
IDAT=21 file=78 complete=46%                
IDAT=21 file=78 complete=50%                
IDAT=21 file=78 complete=53%                
IDAT=21 file=78 complete=56%                
IDAT=21 file=78 complete=59%                
IDAT=21 file=78 complete=62%                
IDAT=21 file=78 complete=65%                
IDAT=21 file=78 complete=68%                
IDAT=21 file=78 complete=71%                
IDAT=21 file=78 complete=75%                
IDAT=21 file=78 complete=78%                
IDAT=21 file=78 complete=81%                
IDAT=21 file=78 complete=84%                
IDAT=21 file=78 complete=87%                
IDAT=21 file=78 complete=90%                
IDAT=21 file=78 complete=93%                
IDAT=21 file=78 complete=96%                
IDAT=21 file=78 complete=100%                


extra...
fs:0    f:5
fs:1    f:5
fs:3    f:5
fs:4    f:5
fs:5    f:5
fs:6    f:5
fs:7    f:5
fs:8    f:5
fs:9    f:5
fs:2    f:\
fs:2    f:|
fs:2    f:/
fs:2    f:-

best:
zc:9    zm:9    zs:3    fs:2    f:5 IDAT=21 file=78

Also tried bumping the image to 16 bit, but it's still decoded as 8 bit grayscale.

TruePNG 0.6.2.2 : PNG Optimizer
by x128 (2010-2016)
[email protected]

Input file: tmp4732.png | 3286 bytes
Image: 160x80 pixels | 8 bits/sample | Indexed greyscale

…

Running the same file (16 bit) through pngquant and truepng locally yields totally different results. (quant result looks equal tho)
Hardware specific, so Azure is lost case?

TruePNG 0.6.2.2 : PNG Optimizer
by x128 (2010-2016)
[email protected]

Input file: quant.png | 3286 bytes
Image: 160x80 pixels | 8 bits/sample | Indexed
Delta filter: None
Chunks: iTXt, pHYs

Output format: 8 bits/sample | Indexed
Chunks: only critical

try...
IDAT=1397       file=1949       complete=100%

extra...

best:
zc:9    zm:9    zs:0    fs-:    f:0     IDAT=1397       file=1949

[lars-erik]

So there's two non exclusive options imo.

1. Release a patch (or get current dev done w/patch) where there's a config option to not use TruePNG. Seems PngQuant does a pretty good job already. (At least they won't be 128 K)

2. I'll bring my png over to the TruePNG repo and post an issue.

[JimBobSquarePants]

@lars-erik We just need to update to TruePng 0.6.2.5

Photoshop is wrong btw if it says the image is RGB 8bit, it's actually RGB 16bit (I manually parsed the header with a hex editor)

C:\Users\james\Downloads\TruePNG_0625>TruePNG.exe -o4 -y -out foo.png google-partner-liten.png
TruePNG 0.6.2.5 : PNG Optimizer
by x128 (2010-2017)
[email protected]

Input file: google-partner-liten.png | 7652 bytes
Image: 160x80 pixels | 16 bits/sample | RGB
Delta filter: Mixed
Chunks: iTXt, pHYs

Output format: 16 bits/sample | RGB
Chunks: only critical

try...
IDAT=3994       file=4051       complete=100%

extra...

best:
zc:9    zm:5    zs:0    fs-:    f:0     IDAT=3994       file=4051

Optimized file at 3.95kb

[lars-erik]

\o/

I can PR that and run a nightly on our sites to see if it works. :)

[HannesWinston]

Hello, we are having the same issue with cropped .png images resulting in black images on two of our sites running on Umbraco 8 in Azure Web Apps. We have the lastest version of ImageProcessor installed, so the issue still persist.

Interestingly though is that one of our other site running on Umbraco 7 in Azure Web App don't have this issue, also running on the latest version of ImageProcessor.

[JimBobSquarePants]

Are you absolutely, positively sure you have the same ImageProcessor.Web.PostProcessor version installed on both environments because what you are describing is about as close to technically impossible as it gets.

[HannesWinston]

I am positively sure that they are both running:

ImageProcessor v2.7.0.100
ImageProcessor.Web v4.10.0.100
ImageProcessor.Web.Config v2.5.0.100
ImageProcessor.Web.Plugins.AzureBlobCache v1.5.0.100
ImageProcessor.Web.PostProcessor v1.4.0.100

All of the sites work locally, also connected through Azure Blob storage for media management. So the problem only occur in Azure as far as I can tell.

[lars-erik]

@HannesWinston did you clear the image cache on the v8 site after upgrading? Might be you're just seeing the cached results from the old version?

[HannesWinston]

@lars-erik Yes, when completely removing the stored cache in the blob storage the image still results in a black image for cropped .png-files.

Here is the original image:
https://svk-web-app.azurewebsites.net/media/vnrkma1l/mattanken_logo_staende.png

Test with a crop:
https://svk-web-app.azurewebsites.net/media/vnrkma1l/mattanken_logo_staende.png?center=0.43110881186411448,0.485&mode=crop&width=863&height=390&rnd=132010030134370000

You can change the values and see it's generating a black image.

[lars-erik]

OK. I haven't been able to continue my tests, so not really able to help more right now. Suddenly back on the issue.

[HannesWinston]

@lars-erik Okay, thanks!

[HannesWinston]

I can now confirm that the error is happening on Umbraco 7 as well. So it has nothing to do with the Umbraco version.

I think the U7 site was loading the image from a working cache, but now when cropping the png image it turns black. Sorry for the confusion.

[JimBobSquarePants]

I'm reopening this issue. Looks like we've still got a problem.

[HannesWinston]

Hello, do you have any updates regarding this issue?

[JimBobSquarePants]

Well no. The library is in soft archive mode. If you want a fix, you have to submit a PR.

https://github.com/JimBobSquarePants/ImageProcessor#imageprocessor-is-in-soft-archive-mode

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kjac]

For future reference: We experienced the same issue on Azure using the package versions bundled with Umbraco 8. Upgrading those packages solved the issue.

We are now using:

• ImageProcessor v2.8.0
• ImageProcessor.Web v4.11.0
• ImageProcessor.Web.PostProcessor v1.5.0