Opened 8 weeks ago
Last modified 8 days ago
#11284 new defect
Aspect ratio defined by the JFIF (JPEG) APP0 segment is misinterpreted as its reciprocal
Reported by: | goodbye | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | mjpeg |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
The JFIF APP0 segment describes the resolution/pixel density of an image, which can be in abstract units (in which case it only defines the pixel aspect ratio), in pixels per inch, or in pixels per centimetre. See for example ECMA TR/98 1st Ed. §6.4 and §10.
FFmpeg interprets the X:Y resolution ratio directly as a X:Y PAR, but in actuality, it’s the reciprocal. This is because the resolution is specified as a “pixels per unit” value and not “units per pixel”, as is typically the case with PARs. The X:Y PAR is equal to the Y:X ratio of resolutions specified in the segment.
The attached image is supposed to have a DAR of 1:1, but FFmpeg misinterprets it to have a DAR of 4:1.
The issue has been present from the very beginning, since aspect ratio decoding was re-enabled in commit 5ff85f1d8b5721a9e7f0ca6e03f61f5d3a4c3664 (libavcodec/mjpeg.c lines 384–385; now libavcodec/mjpegenc.c lines+ 1904–1905). In fact, it has never worked very well – previous code seemed to misinterpret the density ratio as the DAR.
The MJPEG encoder has the complementary problem of writing the reciprocal ratio into the APP0 segment (libavcodec/mjpegenc_common.c lines 189–190)
Attachments (1)
Change History (3)
by , 8 weeks ago
Attachment: | nonsquare.jpg added |
---|
comment:1 by , 7 weeks ago
Summary: | Aspect ratio defined by the JFIF segment APP0 is misinterpreted as its reciprocal → Aspect ratio defined by the JFIF APP0 segment is misinterpreted as its reciprocal |
---|
comment:2 by , 8 days ago
Summary: | Aspect ratio defined by the JFIF APP0 segment is misinterpreted as its reciprocal → Aspect ratio defined by the JFIF (JPEG) APP0 segment is misinterpreted as its reciprocal |
---|
This was previously reported as https://trac.ffmpeg.org/ticket/7623 and wrongly closed as invalid.
sample file with non-square DPI