SixLabors
Jpeg encoder writes zeroed chrominance quantization table for grayscale images and RGB encoding
Prerequisites
- [x] I have written a descriptive issue title
- [x] I have verified that I am running the latest version of ImageSharp
- [x] I have verified if the problem exist in both
DEBUGandRELEASEmode - [x] I have searched open and closed issues to ensure it has not already been reported
Description
Current implementation of the JpegEncoderCore writes Block8x8F chroma = default (i.e. zeroed) table to the DQT marker for grayscale images. While ITU spec doesn't forbid it - encoder writes proper marker length so everything works fine but it would be extra nice if there's no 01 + x64 00 bytes in the binary.
This is super unimportant so it can be marked as 'Future' without a doubt.
One little nuance: it can break existing quality estimation if grayscale image have zeroed chroma table and you put some random values or simply a single 1 in the DQT binary for chroma table. While image with such 'corrupted' binary is technically correct - it's grayscale and parser shouldn't even care about chroma quant table even if exists. Current implementation does care and thus destroys quality at re-encoding. Not a very usual thing to encounter in real life and it'll be fixed as part of #1705 anyway.
Edit: fixed.
