EXCELLENT WORK DPR - It's Appreciated.

Started Jan 5, 2013 | Discussions thread
Detail Man
Forum ProPosts: 14,837
Like?
Re: DPReview Image Viewer System
In reply to Detail Man, 11 months ago

Detail Man wrote:

Simon Joinson wrote:

There is zero, and i mean zero, difference between the '100%' view in this new system and the 'download original' image. Just to make sure i wasn't going mad i just layered the two in photoshop using 'difference' mode and got a totally black frame. It's the same image.

I have seen some posters complaining recently about the long download times when the image-viewer is set to either "View 100%" or "Loupe". Evidently that feedback has resulted in a decision by DPReview to no longer download and display the Original upoloaded JPG image (even when the uploading user has set permissions allowing their Original to be downloaded).

Yes, the downloading now goes faster - but (as verified by JPEGsnoop 1.61) now we are also back to the same old JPEG re-encoding using 2x2 Chroma Sub-sampling and 90% Quality Factor applied in every case, such that it is no longer possible to view the actual DPReview Gallery image.

In the case of "View 100%" and the view within the "Loupe", no down-sampling occurs.

In the case of "Fit to Screen" (when using my 1200 pixel-height screen-size monitor, anyway), a 1200 pixel-height down-sampled and re-encoded (using 2x2 Chroma Sub-sampling and 90% Quality Factor) JPG is provided by the DPReview server. That image is then down-sampled a 2nd time when displayed at a still smaller pixel-size in my interent browser (which may well be exactly the same procedure as has been used before in the new image-viewer interface).

Yes we downsample to fit the window (if the file is bigger), but we now offer an easy way to see the original image either in the forum window or using the loupe. What more can we do, honestly? How can a downsampled image not show fewer finer details?

Simon
Simon Joinson, Editor-in-chief
dpreview.com
connect.dpreview.com

http://www.dpreview.com/forums/post/50599753

The "Fit to Screen" view (as ever) appears soon enough (because of it's dramatically smaller image-file byte-size, and the corresponding faster download time). However, when a user chooses "View 100%" or "Loupe", they are no longer able to view the original uploaded image.

If a site-user elects to view the original image at 100% (via "100% View" or "Loupe" modes) they desire that such actually be the case. If accomplishing that takes some amount of time (as a result of their particular download speed), that characteristic would seem to "go with the territory".

Rather ironically, the entire intent and purpose of the new image-viewer interface has now been entirely negated (even when the uploading user has set permissions allowing their Original to be downloaded). The differences in image quality are readily apparent, and now we are essentially back to where we started prior to the implementation of the new image-viewer interface.

This post presents a 17.3 Mbyte (logical size) JPG uploaded to my DPReview Image Gallery:

http://www.dpreview.com/forums/post/51359404

The Original can be directly downloaded here:

http://www.dpreview.com/galleries/4464732135/download/2533313

The DPReview Image Viewer system has apparently been modified from it's previous configuration so that the "100% View" no longer downloads and displays the actual uploaded Original. Instead the DPReview Image Viewer system downloads and displays this modified (4.5 Mbyte) JPG:

DPReview re-encoded JPG - CSS=2x2, QF~90%, Compression Ratio=6.86:1

The free application JPEGsnoop 1.61 shows that what is now being downloaded and displayed by the image-viewer is a re-encoded JPG where 2x2 Chroma Sub-sampling has been applied:

*** Searching Compression Signatures ***
Signature:           013BA18D5561625796E986FDBC09F846
Signature (Rotated): 01AC57E12793DFA7C46C704625C5AF0F
File Offset:         0 bytes
Chroma subsampling:  2x2
EXIF Make/Model:     OK   [Panasonic] [DMC-GH2]
EXIF Makernotes:     NONE
EXIF Software:       NONE

... Quantization Compression using a Quality Factor of approximately 90% has been applied, reducing the highest spatial frequency components in the image by a factor of 6.67 (2.74 EV):

*** Marker: DQT (xFFDB) ***
  Define a Quantization Table.
  OFFSET: 0x00000D8C
  Table length = 67
  Precision=8 bits
  Destination ID=0 (Luminance)
    DQT, Row #0:   3   2   2   3   5   8  10  12
    DQT, Row #1:   2   2   3   4   5  12  12  11
    DQT, Row #2:   3   3   3   5   8  11  14  11
    DQT, Row #3:   3   3   4   6  10  17  16  12
    DQT, Row #4:   4   4   7  11  14  22  21  15
    DQT, Row #5:   5   7  11  13  16  21  23  18
    DQT, Row #6:  10  13  16  17  21  24  24  20
    DQT, Row #7:  14  18  19  20  22  20  21  20
    Approx quality factor = 90.06 (scaling=19.88 variance=1.14)
 *** Marker: DQT (xFFDB) ***
  Define a Quantization Table.
  OFFSET: 0x00000DD1
  Table length = 67
  Precision=8 bits
  Destination ID=1 (Chrominance)
    DQT, Row #0:   3   4   5   9  20  20  20  20
    DQT, Row #1:   4   4   5  13  20  20  20  20
    DQT, Row #2:   5   5  11  20  20  20  20  20
    DQT, Row #3:   9  13  20  20  20  20  20  20
    DQT, Row #4:  20  20  20  20  20  20  20  20
    DQT, Row #5:  20  20  20  20  20  20  20  20
    DQT, Row #6:  20  20  20  20  20  20  20  20
    DQT, Row #7:  20  20  20  20  20  20  20  20
    Approx quality factor = 89.93 (scaling=20.14 variance=0.34)

... all resulting a reduction of image-file byte-size by a factor of 3.873, reducing the Bits/Pixel from the Original's 13.56 Bits/Pixel to 3.50 Bits/Pixel (a Compression Ratio of 6.86:1):

Compression stats:
Compression Ratio: 6.86:1
Bits per pixel: 3.50:1

...............................

The entire process happens again when viewing the above displayed image in the Image Viewer:

*** Searching Compression Signatures ***
  Signature:           013BA18D5561625796E986FDBC09F846
  Signature (Rotated): 01AC57E12793DFA7C46C704625C5AF0F
  File Offset:         0 bytes
  Chroma subsampling:  2x2
  EXIF Make/Model:     OK   [Panasonic] [DMC-GH2]
  EXIF Makernotes:     NONE
  EXIF Software:       NONE

*** Marker: DQT (xFFDB) ***
  Define a Quantization Table.
  OFFSET: 0x00000D8C
  Table length = 67
  ----
  Precision=8 bits
  Destination ID=0 (Luminance)
    DQT, Row #0:   3   2   2   3   5   8  10  12
    DQT, Row #1:   2   2   3   4   5  12  12  11
    DQT, Row #2:   3   3   3   5   8  11  14  11
    DQT, Row #3:   3   3   4   6  10  17  16  12
    DQT, Row #4:   4   4   7  11  14  22  21  15
    DQT, Row #5:   5   7  11  13  16  21  23  18
    DQT, Row #6:  10  13  16  17  21  24  24  20
    DQT, Row #7:  14  18  19  20  22  20  21  20
    Approx quality factor = 90.06 (scaling=19.88 variance=1.14)
 *** Marker: DQT (xFFDB) ***
  Define a Quantization Table.
  OFFSET: 0x00000DD1
  Table length = 67
  ----
  Precision=8 bits
  Destination ID=1 (Chrominance)
    DQT, Row #0:   3   4   5   9  20  20  20  20
    DQT, Row #1:   4   4   5  13  20  20  20  20
    DQT, Row #2:   5   5  11  20  20  20  20  20
    DQT, Row #3:   9  13  20  20  20  20  20  20
    DQT, Row #4:  20  20  20  20  20  20  20  20
    DQT, Row #5:  20  20  20  20  20  20  20  20
    DQT, Row #6:  20  20  20  20  20  20  20  20
    DQT, Row #7:  20  20  20  20  20  20  20  20
    Approx quality factor = 89.93 (scaling=20.14 variance=0.34)

Compression stats:
    Compression Ratio:  6.91:1
    Bits per pixel:     3.47:1

... which indicates that this JPEG re-encoding to a lower image quality occurs even in the case of a 4.5 Mbyte Original uploaded JPG image-file.

DM ...

Reply   Reply with quote   Complain
Post (hide subjects)Posted by
(unknown member)
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark post MMy threads
Color scheme? Blue / Yellow