[FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio

[Moritz Barsnick]

units (1 byte) Units for the X and Y densities.
units = 0: no units, X and Y specify the pixel aspect ratio
units = 1: X and Y are dots per inch
units = 2: X and Y are dots per cm
Xdensity (2 bytes) Horizontal pixel density
Ydensity (2 bytes) Vertical pixel density

The "density" (unless they intentionally reversed the meaning of the
word) is always the inverse of the aspect ratio.

That's what I was wondering as well.

Did they reverse the meaning in your opinion?
Does it make sense to argue that if the unit is "0", the meaning of the
density changes?

That was my interpretation. It's a density, if units != 0, otherwise
the aspect ratio. (Would a density not correspond to the SAR? I.e. not
make sense with square pixels?)

I was wondering what other implementations do? jpglib, *Magick.
Reference images? I didn't find anything quickly, but one may need to
check closer.

Cheers,
Moritz

[Nicolas George]

Post by Moritz Barsnick
That was my interpretation. It's a density, if units != 0, otherwise
the aspect ratio. (Would a density not correspond to the SAR? I.e. not
make sense with square pixels?)

I did not follow the beginning of the discussion, but just in case it
can help and was not obvious in the first place:

Having a density makes sense even for square pixels to carry the
information of the physical size of the image. It makes sense if the
original has a well-defined physical size, like a scanned document.

Also, the density can give the aspect ratio, but there is a catch: if
the density is 20 px/mm horizontally and 10 px/mm vertically, that means
pixels are (1/20)×(1/10) mm², hence their aspect ratio is 10/20 = 1/2,
not 20/10 = 2/1.

Regards,

[Kevin Wheatley]

I came across a similar discussion here:

https://github.com/OpenImageIO/oiio/pull/1412
Kevin

[Carl Eugen Hoyos]

Post by Kevin Wheatley
https://github.com/OpenImageIO/oiio/pull/1412

So the solution is:
We don't fix it because it is broken elsewhere?

Carl Eugen

[Michael Niedermayer]

Hi!
Reading the specification and Wikipedia, it appears to me that FFmpeg
is writing wrong values as aspect ratio for jfif files.
I hope somebody can prove me wrong!
This would need a slightly more sophisticated update to the decoder.
Please comment, Carl Eugen
mjpegenc_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
03077e11ffcc0b2faf5a2be46b0cb2ea224eca57 0001-lavc-mjpegenc_common-Fix-aspect-ratio.patch
From 9c42114da17c20ef6d81d3989b5521eaefc15819 Mon Sep 17 00:00:00 2001
Date: Mon, 10 Dec 2018 02:50:39 +0100
Subject: [PATCH] lavc/mjpegenc_common: Fix aspect ratio.
Reported-by: Ulf Zibis
---
libavcodec/mjpegenc_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

if its correct, this requires a bump to the version of libavcodec so
the decoder can detect if a file is from before or after the change
[...]

[Michael Niedermayer]

Post by Michael Niedermayer

Hi!
Reading the specification and Wikipedia, it appears to me that FFmpeg
is writing wrong values as aspect ratio for jfif files.
I hope somebody can prove me wrong!
This would need a slightly more sophisticated update to the decoder.
Please comment, Carl Eugen
mjpegenc_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
03077e11ffcc0b2faf5a2be46b0cb2ea224eca57 0001-lavc-mjpegenc_common-Fix-aspect-ratio.patch
From 9c42114da17c20ef6d81d3989b5521eaefc15819 Mon Sep 17 00:00:00 2001
Date: Mon, 10 Dec 2018 02:50:39 +0100
Subject: [PATCH] lavc/mjpegenc_common: Fix aspect ratio.
Reported-by: Ulf Zibis
---
libavcodec/mjpegenc_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

if its correct, this requires a bump to the version of libavcodec so
the decoder can detect if a file is from before or after the change

also there is related code in libavcodec/vaapi_encode_mjpeg.c

[...]