linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH v2] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
Date: Fri, 27 Apr 2012 15:08:21 +0200	[thread overview]
Message-ID: <4F9A9A45.5080100@redhat.com> (raw)
In-Reply-To: <20120425180949.2243472b@tele>

Hi,

On 04/25/2012 06:09 PM, Jean-Francois Moine wrote:
> Hi Hans,
>
> On Wed, 25 Apr 2012 16:19:57 +0200
> Hans de Goede<hdegoede@redhat.com>  wrote:
>
>>> You say that the marker cannot be in the range 0..31 (index 0..7), but
>>> I have never seen a value lower than 68 (index 17).
>>
>> If you change register 0x80 in bank/page 1 to>  42 on pac7311 or larger then
>> circa 100 on pac7302, you will get markers with bit 8 set. When this happens
>> you will initially get markers 0xa0 - 0xa4 ... 0xbc and the stream tends to
>> stabilize on 0xbc. Likewise if you remove the artificial limiting of
>> the pac7302 to 15 fps from the driver you will get markers 0x44 - 0x48 ...
>> 0x7c.
>>
>> The images look a lot better with bit 8 set, so I plan to run some tests
>> wrt what framerates can safely handle that (it uses more bandwidth) and set
>> bit 8 on lower framerates.
>
> I carefully looked at the ms-windows pac7302 traces I have. The
> register 1-80 stays always in the range 0d..11, except sometimes 19 at
> start time.

Right, that can mean one of 2 things:
1) The traces were made during daylight, so low exposure / high framerate,
and enabling the lower compression modes (which cause bit 7 of the marker
to get set) is a bad idea at high framerates

2) The windows driver never enables the low compression mode. I seriously
doubt that this is the case, ie older versions of the pac7311 driver have
(commented) writes to page 1 register 80 with high enough values to enable
it and I'm pretty sure those writes come from windows traces.

> In these traces, the images with marker 44 (dec 68) look
> really better with all 08's as the quantization table.

After having played with the quantization tables you've found I agree.

> [snip]
>> Yeah short of someone disassembling and reverse-engineering the windows driver
>> we will probably never figure out the exact correct tables.
>
> Well, I got the SPC230NC.SYS of the ms-windows pac7302 driver, but it
> is not easy to disassemble because it has no symbol table. But, inside,
> I found this tables just before the Huffman table:
>
> - 0006C888
> 	10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> - 0006C908
> 	10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> - 0006C988
> 	08 08 08 08 08 08 10 10 10 10 10 10 10 10 10 10
> 	10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20
> 	20 20 20 20 20 20 20 20 20 20 20 40 40 40 40 40
> 	40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
> - 0006CA08
> 	08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08
> 	08 08 08 08 08 08 08 08 08 08 08 08 10 10 10 10
> 	10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> 	10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20
> - 0006CA88
> 	10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> - 0006CB08
> 	08 0b 0b 0b 0b 0b 10 10 10 10 10 10 10 10 10 10
> 	10 10 10 10 10 20 20 20 20 20 20 20 40 40 40 40
> 	40 40 40 40 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> - 0006CB88
> 	11 12 12 18 15 18 2f 1a 1a 2f 63 42 38 42 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> 	63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
> - 0006CC08
> 	10 0b 0c 0e 0c 0b 10 0e 0d 0e 12 11 10 13 18 28
> 	1a 18 16 16 18 31 23 25 1d 28 3a 33 3d 3c 39 33
> 	38 37 40 48 5c 4e 40 44 57 45 37 38 50 6D 51 57
> 	5F 62 67 68 67 3E 4D 71 78 70 64 78 5C 65 67 63
>
> Don't they look like quantization tables?

Yes they do, good find! I've done yet more testing / trial
and error with these tables and I've just pushed another
Pixart JPEG patch to v4l-utils git switching to these new
tables. Thanks! Also with these tables the quality difference
between high/low compression mode becomes significantly
less. So much less that I've decided to not further pursue
enabling low compression mode in the gspca drivers, esp. since
this will cause pain for people with an older libv4l.

> BTW, I don't think the exposure and gain controls use the right
> registers as they are coded in the actual gspca  pac7302 subdriver.
> The ms-windows driver uses the registers (3-80 / 3-03), (3-05 / 3-04),
> (3-12) and (1-80) for autogain/exposure. The gspca test tarball of my
> web site includes a new AGC using these registers, but it does not work
> well. Maybe you could tell me what is wrong with it...

Let me get back on that in a separate mail.

Regards,

Hans

  reply	other threads:[~2012-04-27 13:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12 10:20 [PATCH v2] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG Jean-Francois Moine
2012-04-23 21:34 ` Hans de Goede
2012-04-24 10:34   ` Jean-Francois Moine
2012-04-25 14:19     ` Hans de Goede
2012-04-25 16:09       ` Jean-Francois Moine
2012-04-27 13:08         ` Hans de Goede [this message]
2012-04-28 13:50         ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F9A9A45.5080100@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=moinejf@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).