Opened 11 years ago

Closed 11 years ago

#132 closed enhancement (wontfix)

Unconventional PSNR definition

Reported by: minoo Owned by:
Priority: minor Milestone:
Component: HM Version:
Keywords: PSNR Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

The current implementation in HM2.0, calculates a fidelity measure and calls it PSNR, while it is not!
By definition PSNR is calculated as :
10*log10((1<<bit_depth - 1)2/(mse))
and not as:
10*log10((255*(1<<(bit_depth-8)))2/(mse))

The code can be found in TEncGOP.cpp
by searching for "maxval".

Change History (7)

comment:1 follow-up: Changed 11 years ago by fbossen

  • Resolution set to wontfix
  • Status changed from new to closed

The implementation is consistent with the decision made at the Daegu meeting. See meeting notes on JCTVC-D152.
Anyway the difference is only a small offset in the computed value which should be irrelevant since we are more concerned with PSNR differences than with absolute PSNR values.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 11 years ago by minoo

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Don't close this ticket. Either postpone the needed modification to a future releases or re-open it as a new ticket which requests the change in the print out of the summary log to not refer to this measured value as PSNR.

Regards,
-Koohyar.

Replying to fbossen:

The implementation is consistent with the decision made at the Daegu meeting. See meeting notes on JCTVC-D152.
Anyway the difference is only a small offset in the computed value which should be irrelevant since we are more concerned with PSNR differences than with absolute PSNR values.

comment:3 in reply to: ↑ 2 Changed 11 years ago by dthoang

Since you are being picky about this, I would like to point out that what is computed by HM is average of frame PSNR, which is not strictly PSNR and should be called something like APSNR or AVPSNR.

I pointed this out in Daegu and it was fully discussed. So I accept the decision to use APSNR, but it should be noted as such.

Regards,

  • Dzung Hoang

Zenverge

Replying to minoo:

Don't close this ticket. Either postpone the needed modification to a future releases or re-open it as a new ticket which requests the change in the print out of the summary log to not refer to this measured value as PSNR.

Regards,
-Koohyar.

Replying to fbossen:

The implementation is consistent with the decision made at the Daegu meeting. See meeting notes on JCTVC-D152.
Anyway the difference is only a small offset in the computed value which should be irrelevant since we are more concerned with PSNR differences than with absolute PSNR values.

comment:4 Changed 11 years ago by fbossen

  • Resolution set to wontfix
  • Status changed from reopened to closed

This isn't the place to have such discussions.
To quote the meeting notes from Daegu:
"PSNR should be calculated without rounding the output first, with PSNR calculated as PSNR = 10 * log10( (255*2(N-8))2 / MSE )"
If anyone has an issue with such a statement, please raise it on the general jct-vc reflector or submit an input contribution to the next meeting.
Unless a decision is made by the jct-vc to change this PSNR definition, I do not see the point in having an open issue on this topic.

comment:5 Changed 11 years ago by davidf

  • Component set to HM

Updating component after adding WD (Text) tickets

comment:6 Changed 10 years ago by davidf

  • Cc fbossen ksuehring davidf added

comment:7 Changed 10 years ago by davidf

  • Cc jct-vc@… added
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • David Flynn(Subscriber, Participant)
  • Dzung Hoang(Participant)
  • Frank Bossen(Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Always)
  • Koohyar Minoo(Reporter, Participant)