Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
1st November 2016, 15:42 | #141 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
A VC-1 I-frame image codec certainly would have outperformed JPEG, but would have still been 8-bit YUV only. JPEG-XR was designed to be colorspace independent, and support things like 16-bit CMYK, 10-bit RGBA, and IIRC even RAW Bayer patterns. Its target was really the photography industry, to offer all the stuff JPEG didn't and J2K was too slow or too large for. It would have been great for digital filmmaking if it had caught on. Also AFAIK, it never really got used for anything practical, despite being royalty free and everything. I'm not sure the psychovisual tuning ever got to the point where it offered a meaningful advantage over J2K, which by that point had substantial momentum. Its RAW Bayer support could have been awesome, and addressed a lot of ongoing industry issues in both file size and interoperability. Those >4Kp60 cameras can record a lot of data! |
|
8th November 2016, 13:21 | #142 | Link | |
Registered User
Join Date: May 2014
Posts: 292
|
Quote:
BPG smears trees and brickwork under the bridge! It is necessary to add an additional BPG + Psy. |
|
9th November 2016, 00:06 | #143 | Link |
Registered User
Join Date: Oct 2014
Posts: 268
|
jpeg-xr is still format for my own photography stuff. lossless, all the image formats I want (16-bit is a bit of a minimum) and it encodes 24+ megapixel images under 4 seconds, and has full exif support with / through exiftool. I happily take a file that is a few MBs more in size compared to other modern lossless image formats.. the convenience just beats it all for me. Nothing of this has anything to do with web-images, end-delivery (like, regular old jpg files) or the video world .
I'm just dreaming of the day when there is a modern ILC camera that has jpeg-xr as a write option. Either write complete done images (like the old jpg files) but in 16 bit so that they're actually still somewhat gradable and editable after the fact... or use jpeg-xr's floating-point / hdr support to write an image that is debayered and pretty much good to go, but still has all the information 'past 1.0' or under '0.0' that the image sensor captured (no need to throw anything away while still including the tone mapping). Seems perfect to me, but it just never took of . What I read from it it isn't even wavelet based, just 'plain old' DCT, just bigger and more of it so to speak. They described it as 'an enhanced DCT for decoders with more memory, and support for 16bit and lossless'. I think the HDR isn't real floating point but just 16-bit integers with a mapping curve or something. Still, it's so fast compared to all the webp / bpg / flif formats. BPG comes close though now that they're using x265 instead of the reference encoder. Much faster and lossless sizes are good, although 'limited' to 12bit. jpeg-xr is faster, has true 16bit and I don't have to save the metadata in a separate file next to the image. Close, but still a no brainer for me. |
8th January 2017, 15:28 | #144 | Link |
Registered User
Join Date: Jun 2008
Posts: 11
|
Is this format progressing at all?
I was using JPEG XR which had similar advantages (good ratios on lossless and lossy compression, >8bit) but only reached a small amount of support and lost Photoshop support. It still has Windows Imaging Component support but lack of Photoshop support shows it's dead as a high-end format. BPG looks even better but doesn't seem to have any software support. None of my applications can open it let alone save to it, and it doesn't have a decoder/encoder for WIC. What is the next step for this format? Is it waiting for HEVC ubiquity before launching? |
8th January 2017, 19:58 | #145 | Link |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 345
|
You speak of it as if it's a registered/standardized/certified format. Nope. Maybe that's why it's not progressing.
Besides in my own tests I found it inferior to WebP which is based on the ages old VP8 encoder. AV1 shows some promise though and that's what I'll probably use to compress my JPEGs (very high quality so there's no issue of trying to overcome compression artefacts). |
8th January 2017, 21:42 | #146 | Link | |
Registered User
Join Date: Oct 2014
Posts: 268
|
Quote:
Makes it my archival format of choice. I can just open a file by dropping it in Photoshop but I can't accidentally overwrite the archive-version :P. About BPG, isn't the whole HEVC licensing thing still being formulated? I thought BPG had a big question mark about it's openness / ready-to-be-used-status because of this which put the brakes to the adoption. |
|
15th January 2017, 03:36 | #147 | Link |
Registered User
Join Date: Jun 2008
Posts: 11
|
I can't open JPEG XRs on the current Windows 10+Photoshop CC.
I found that lossless JPEG XRs gave on average 50% lower filesizes for 16bpc images than TIFF with LZW compression. So yes great for archival purposes - when I could actually open and save them. I would be interested in lossless performance of BPG. But overall any modern format that does >8bpc, has a lossless mode, and a Photoshop plugin would be great in my book. |
19th January 2017, 18:37 | #148 | Link | |||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Quote:
Quote:
I don't know how well that profile would encode RAW sensor data, but it certainly would work for anything normalized to gamma, PQ, or similar EOTF. HEVC v3 includes some color video profiles up to 14-bit (which I don't know that anything supports), but 16-bit remains intra/still encoding only. There are monochrome 16-bit profiles back to v2, oddly. |
|||
30th April 2018, 07:54 | #149 | Link |
Registered User
Join Date: Jul 2015
Posts: 706
|
New version encoder BPG image 0.9.8 & HEIF image 1.0.0
https://hevc.hhi.fraunhofer.de/trac/...hes?order=name Compatible with JPG and PNG. Code:
Library enc/dec: libBPG 0.9.8 [28 Apr 2018] libHEIF 1.0.0 [27 Apr 2018] libX265 2.7+342 [19 Apr 2018] jctvc_hm 16.18 [04 Apr 2018] don't work Last edited by Jamaika; 4th June 2018 at 07:53. |
30th April 2018, 15:27 | #150 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
HEVC for motion pictures switches between the Discrete Cosine Transform and the Karhunen–Loève Transform to achieve maximum compression ratio; although the KLT achieves better compression than DCT, it's not always worth the computational effort required (which is greater than the DCT, mostly because the DCT doesn't use imaginary numbers and is constant in 2 phi). I understand that BPG is based on HEVC Still image, but does it use DCT only, KLT only or is it able to switch between these two according to the type of image?
Last edited by FranceBB; 30th April 2018 at 15:33. |
3rd May 2018, 17:37 | #153 | Link |
Registered User
Join Date: Jul 2015
Posts: 706
|
I was able to run the latest HM 16.18 codec. I find that the x265 codec has much better quality for 4K photos. Example: 6000kb
bpgenc.exe -v -b 8 -c ycbcr -f 420 -q 38 -m 9 -e jctvc -o yuv420p_jctvc.bpg source.jpg 100kb bpgenc.exe -v -b 8 -c ycbcr -f 420 -q 41 -m 9 -e x265 -o yuv420p_x265.bpg source.jpg 100kb codec jctvc HM 16.18 codec x265 2.7+342 Last edited by Jamaika; 5th May 2018 at 20:15. |
6th June 2018, 09:33 | #157 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
CRF like makes little sense for still images. CRF works by increasing QP during high motion scenes because they take a lot more bit rate and humans notice quality issues less during motion. In a still image there is no motion to hide extra artifacts, it is possible to increase the QP for larger blocks but that would be like AQ, not CRF.
Edit: And CRF isn't really based on a quality metric in that way, it is a rate control method not a quality setting method. QP would be just as good for setting quality if it wasn't for the time based bit rate curve compression.
__________________
madVR options explained Last edited by Asmodian; 6th June 2018 at 09:40. |
12th June 2018, 23:50 | #158 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
I've had good success using CRF like one would use the JPEG "quality" parameter (although on a very different scale), and have gotten superior results from CRF than QP. Basically, your options are CRF, QP, bitrate, or lossless. CRF is the best choice for still images for most use cases. Copying the common parameters from H.264's --tune stillimage can help, although I'm sure a well-optimized x265 --tune stillimage would have some adjustments. |
|
13th June 2018, 16:55 | #159 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
For still images, what is the difference between CRF and QP? CRF does not use a quality metric, it is based on complexity (as you know, of course).
Do you mean that when using the same CRF setting you get better results (quality/size) on a wider variety of images because CRF uses a higher QP for more complex images, like a full frame version of AQ?
__________________
madVR options explained |
Thread Tools | Search this Thread |
Display Modes | |
|
|