【问题标题】:JPEG quality problemsJPEG 质量问题
【发布时间】:2020-06-10 17:17:48
【问题描述】:

我目前正在使用 C# 从管道镜中检索帧(通过 FFMPEG 库)。但是,我几周前遇到了一个问题,我无法解决。

图像以 JPEG 格式返回(因为管道镜流是 MJPEG)。

有些图片没有质量问题,但有些图片中间有一条奇怪的线 其次是随机染色。 (在问题的最后有一个正常图像的例子和一个有问题的例子)。

分析文件的结构,发现还是有一些区别的,但是我对JPEG的二进制结构不是很了解,也分不清是什么损坏了。

了解图像中的哪些损坏,最终导致质量问题,对我来说非常重要,因为通过这个,我可以使用 C# 丢弃帧。但是,如果不了解这个问题,我什至不能丢弃框架,更不用说修复它了。

那么,以没有质量问题的图像作为参考,有质量问题的图像的二进制结构有什么问题?

示例:

JPEG 1: Image without quality problems

Image's preview(只是为了看质量,不要从这里下载

JPEG 2: Image with quality problems

Image's preview(只是为了看质量,不要从这里下载

可以通过在线 HEX 编辑器查看图像的二进制结构,例如:Online hex editorHexedHex-works

感谢您的阅读,祝您有美好的一天

【问题讨论】:

    标签: image ffmpeg jpeg mjpeg


    【解决方案1】:

    该文件至少有 2 个问题。


    我可以通过运行以下命令使用 ImageMagick 检测到的第一个:

    magick identify -verbose image.jpg
    

    它告诉我数据段提前结束了。

    Image: outExemplo0169.jpeg
      Format: JPEG (Joint Photographic Experts Group JFIF format)
      Mime type: image/jpeg
      Class: DirectClass
      Geometry: 640x480+0+0
      Units: Undefined
      Colorspace: sRGB
      Type: TrueColor
      Base type: Undefined
      Endianess: Undefined
      Depth: 8-bit
      Channel depth:
        Red: 8-bit
        Green: 8-bit
        Blue: 8-bit
      Channel statistics:
        Pixels: 307200
        Red:
          min: 0  (0)
          max: 255 (1)
          mean: 107.234 (0.420527)
          standard deviation: 66.7721 (0.261851)
          kurtosis: -0.67934
          skewness: 0.577494
          entropy: 0.92876
        Green:
          min: 0  (0)
    :2020-02-26T18:59:19+00:00 0:00.057 0.070u 7.0.9 Resource identify[80956]: resource.c/RelinquishMagickResource/1067/Resource
      Memory: 3686400B/0B/32GiB
    identify: Corrupt JPEG data: premature end of data segment `outExemplo0169.jpeg' @ warning/jpeg.c/JPEGWarningHandler/399.
    

    当我运行这个命令时,我用exiftool 看到的第二个:

    exiftool -v -v -v outExemplo0169.jpeg 
    
      ExifToolVersion = 11.11
      FileName = outExemplo0169.jpeg
      Directory = .
      FileSize = 66214
      FileModifyDate = 1582743337
      FileAccessDate = 1582743559
      FileInodeChangeDate = 1582743337
      FilePermissions = 33188
      FileType = JPEG
      FileTypeExtension = JPG
      MIMEType = image/jpeg
    JPEG APP0 (14 bytes):
        0006: 4a 46 49 46 00 01 01 00 00 01 00 01 00 00       [JFIF..........]
      + [BinaryData directory, 9 bytes]
      | JFIFVersion = 1 1
      | - Tag 0x0000 (2 bytes, int8u[2]):
      |     000b: 01 01                                           [..]
      | ResolutionUnit = 0
      | - Tag 0x0002 (1 bytes, int8u[1]):
      |     000d: 00                                              [.]
      | XResolution = 1
      | - Tag 0x0003 (2 bytes, int16u[1]):
      |     000e: 00 01                                           [..]
      | YResolution = 1
      | - Tag 0x0005 (2 bytes, int16u[1]):
      |     0010: 00 01                                           [..]
      | ThumbnailWidth = 0
      | - Tag 0x0007 (1 bytes, int8u[1]):
      |     0012: 00                                              [.]
      | ThumbnailHeight = 0
      | - Tag 0x0008 (1 bytes, int8u[1]):
      |     0013: 00                                              [.]
    JPEG SOF0 (15 bytes):
        0018: 08 01 e0 02 80 03 01 21 00 02 11 01 03 11 01    [.......!.......]
      ImageWidth = 640
      ImageHeight = 480
      EncodingProcess = 0
      BitsPerSample = 8
      ColorComponents = 3
    JPEG DQT (130 bytes):
        002b: 00 03 03 03 03 03 03 04 03 03 03 04 04 04 05 06 [................]
        003b: 09 06 06 05 05 06 0c 08 09 07 09 0e 0c 0e 0e 0d [................]
        004b: 0c 0d 0d 0f 11 15 12 0f 10 14 10 0d 0d 13 19 13 [................]
        005b: 14 16 17 18 18 18 0f 12 1a 1c 1a 17 1c 15 17 18 [................]
        006b: 17 01 04 04 04 06 05 06 0b 06 06 0b 17 0f 0d 0f [................]
        007b: 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 [................]
        008b: 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 [................]
        [snip 18 bytes]
    JPEG DHT (416 bytes):
        00b1: 00 00 01 05 01 01 01 01 01 01 00 00 00 00 00 00 [................]
        00c1: 00 00 01 02 03 04 05 06 07 08 09 0a 0b 10 00 02 [................]
        00d1: 01 03 03 02 04 03 05 05 04 04 00 00 01 7d 01 02 [.............}..]
        00e1: 03 00 04 11 05 12 21 31 41 06 13 51 61 07 22 71 [......!1A..Qa."q]
        00f1: 14 32 81 91 a1 08 23 42 b1 c1 15 52 d1 f0 24 33 [.2....#B...R..$3]
        0101: 62 72 82 09 0a 16 17 18 19 1a 25 26 27 28 29 2a [br........%&'()*]
        0111: 34 35 36 37 38 39 3a 43 44 45 46 47 48 49 4a 53 [456789:CDEFGHIJS]
        [snip 304 bytes]
    JPEG SOS
    JPEG EOI
    Unknown trailer (50 bytes at offset 0x10274):
       10274: 42 6f 75 6e 64 61 72 79 45 42 6f 75 6e 64 61 72 [BoundaryEBoundar]
       10284: 79 53 00 00 01 00 90 08 01 00 fb 4b db 6a 2a 22 [yS.........K.j*"]
       10294: 00 00 2a 22 00 00 01 00 01 00 80 02 00 00 e0 01 [..*"............]
       102a4: 00 00        
    

    所以末尾有 50 个无关字节,包括文本字符串 "BoundaryEBoundaryS",您可能会认为它们来自处理链中的其他位置?

    您可以对 JPEG 质量进行的一项测试是检查最后 2 个字节是否是有效的 EOI,这意味着它应该以 FF D9 结尾 - 请参阅 here

    【讨论】:

    • 所以,当我提到的这个 C# 应用程序从 boroscope 获取帧时,我有很多帧,有些有问题,有些没有。为了验证您分析的内容,我编写了另一个代码,它只接受最终字节为 0xFF 和 0xD9(或 D8)的图像。然而,所发生的情况是,好的图像和坏的图像都没有正确的 EOI(实际上它们出现了,但只是在这 50 字节的垃圾之前)。所以,我认为质量问题不是来自这个 EOI 问题。
    猜你喜欢
    • 1970-01-01
    • 2018-12-04
    • 2015-07-09
    • 1970-01-01
    • 1970-01-01
    • 2018-10-15
    • 2013-07-18
    • 2017-04-12
    • 1970-01-01
    相关资源
    最近更新 更多