Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

H.264 is Magic (2016)

sidbala.com

Post reply on HN
Print view View original

211–220 of 229 posts

Re: H.264 is Magic (2016)

#211

Post by Auracle »

webmobdev wrote: post #118
Auracle wrote: post #99

Earlier quoted context omitted.

As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer. I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.

JPEG2000 is a good option for lossless compression. JPEG XL seems to offer better result and improvements now, but it isn't yet mainstream and has competition.

Have you ever tried to open/save JPEG2000s in Photoshop? It's ridiculously slow compared to pretty much anything else.

Plus, it doesn't really matter when I can't deliver files to clients in that format.

Re: H.264 is Magic (2016)

#212

Post by Auracle »

ibigb wrote: post #126
Auracle wrote: post #99

Earlier quoted context omitted.

As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer. I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.

A jpeg pixel is 64 (=8 x 8), 8 bit coefficients which are summed together for each pixel. That result is not 8 bits, but more; that is a misunderstanding, often repeated. A jpeg is capable of over 11 bits dynamic range. You can figure out that an 11 bit dynamic range image has more than 8 bits. See the wikipedia.

Fair enough, but the end result is what really matters, and I regularly see banding in the skies of photos. Some people add grain just to help deal with that, which is a ridiculous problem to have in 2022.

Re: H.264 is Magic (2016)

#213

Post by Auracle »

emkoemko wrote: post #110
Auracle wrote: post #99

Earlier quoted context omitted.

As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer. I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.

try out darktable, its way more capable of a raw editor then those two and usually gets support for new export formats fairly fast.

I actually meant to say Capture One and Photoshop. I know this is HN and we're gung-ho about open source but the last time I tried Darktable it didn't hold a candle to Capture One. To be fair that was a few years ago, but the color work put in to Capture One doesn't really have an equal IMO.

Re: H.264 is Magic (2016)

#214

Post by webmobdev »

Auracle wrote: post #211
webmobdev wrote: post #118

Earlier quoted context omitted.

JPEG2000 is a good option for lossless compression. JPEG XL seems to offer better result and improvements now, but it isn't yet mainstream and has competition.

Have you ever tried to open/save JPEG2000s in Photoshop? It's ridiculously slow compared to pretty much anything else. Plus, it doesn't really matter when I can't deliver files to clients in that format.

I use the J2K photoshop plug-in - https://www.fnordware.com/j2k/ . And even macOS Preview supports JPEG2000 (HEIF on macOS on the other hand is not suitable for professional graphic works; doesn't work with CMYK).

Re: H.264 is Magic (2016)

#215

Post by mikepurvis »

skoskie wrote: post #105
mikepurvis wrote: post #86

Earlier quoted context omitted.

Isn't their non-support more a consequence of the fact that they haven't shipped a single product with an optical drive since 2012? Like, you can obviously plug a $100 external Blu-Ray writer into any of their computers, but I think between the competition with their own digital distribution platform and the "bag of hurt" that is DRM nonsense, I can understand them not being interested in explicitly supporting it but…

> but still caring about the direction that it takes since they are a media and devices company, and the decisions made there impact them. Agreed, but with a sinister connotation. While I am absolutely not accusing Apple of it, let's not forget that all companies want the inside track on any tech that could threaten profits, and may join these organizations to guide them away from decisions that are not in the compan…

Presumably those conflicts of interest would be well understood by everyone at the table, and the other companies with a heavier stake on the devices side (Panasonic, Pioneer, Sony, etc) would hold Apple accountable for any obvious attempts to sabotage the standard.

Re: H.264 is Magic (2016)

#216

Post by joshspankit »

ksec wrote: post #193
joshspankit wrote: post #41

Earlier quoted context omitted.

You don’t have to wonder: There have been many truly patent free codecs and the answer is mostly “Try to convince companies to adopt it even though they have a vested interest in using codecs they control” For example: FLAC

The problem was FLAC wasn't patent free but claims to be not covered by any patent. That is quite a bit of difference from a legal perspective. One could argue about patent system and its usage, but most companies ( ignoring Tech and Internet companies ) tend to avoid them. Especially when there are alternative. And consumer tends to just use whatever they want. I remember I picked Wavepack over FLAC in that era. But…

> The FLAC and Ogg FLAC formats themselves, and their specifications, are fully open to the public to be used for any purpose (the FLAC project reserves the right to set the FLAC specification and certify compliance). They are free for commercial or noncommercial use. That means that commercial developers may independently write FLAC or Ogg FLAC software which is compatible with the specifications for no charge and without restrictions of any kind. There are no licensing fees or royalties of any kind for use of the formats or their specifications, or for distributing, selling, or streaming media in the FLAC or Ogg FLAC formats.

While I know through experience that you have a point about some companies avoiding anything that might be patent encumbered, and that the statement “[FLAC is not] covered by any known patent.“ would be a red flag to them, the argument falls down when we talk about how much code has been used over the years by companies who stepped all over the intellectual property rights of the authors.

Even if we look at Mp3s which are definitively patent-encumbered and commercially-licensed, here have been thousands of devices that played Mp3s before they a license (if they ever got one at all).

Re: H.264 is Magic (2016)

#217

Post by joshspankit »

account42 wrote: post #206
PaulDavisThe1st wrote: post #165

Earlier quoted context omitted.

FLAC is actually much more widely supported than, for example, Vorbis.

Vorbis has been pretty much entirely obsoleted by Opus so there wouldn't have been much incentive for new Vorbis support since then - is there a similarly decisive open successor for FLAC?

I certainly have not seen one. FLAC is either A) the best option for free lossless music encoding, or B) The music industry is way too big of a heavy hitter to let any others build momentum

Re: H.264 is Magic (2016)

#218

Post by nitrogen »

mikepurvis wrote: post #215
skoskie wrote: post #105

Earlier quoted context omitted.

> but still caring about the direction that it takes since they are a media and devices company, and the decisions made there impact them. Agreed, but with a sinister connotation. While I am absolutely not accusing Apple of it, let's not forget that all companies want the inside track on any tech that could threaten profits, and may join these organizations to guide them away from decisions that are not in the compan…

Presumably those conflicts of interest would be well understood by everyone at the table, and the other companies with a heavier stake on the devices side (Panasonic, Pioneer, Sony, etc) would hold Apple accountable for any obvious attempts to sabotage the standard.

Look at Microsoft's membership in Khronos and Google's membership in W3C for examples of this counterbalance not exactly working.

Re: H.264 is Magic (2016)

#219

Post by SideQuark »

ibigb wrote: post #210
SideQuark wrote: post #138

Earlier quoted context omitted.

A jpeg pixel is not 64 eight-bit coefficients. Jpeg compresses an 8x8 pixel block at a time by taking a DCT (which mathematically is lossless, but in practice is not due to rounding and quantization at this stage), which turns those original 8x8 values into another set of 8x8 values, then some of these are thrown away and/or quantized for lossy compression. Decompression is the reverse: take these 8x8 quantized DCT c…

I said a jpeg pixel is the summation of 64 8 bit coefficients. The coefficients are 8 bit, but obviously the cosine values are not 8 bit. They can be floating point. All a jpeg need give is coefficients, the coder/decoder knows what to do with them. Summing 64 products, with each product = 8 bit numbers x cosine value gives more than an 8 bit result for the resultant pixel. In addition, there is another dct for the c…

No, a jpeg pixel is not "the summation of 64 8 bit coefficients." I've written jpeg codecs (and many other image formats). It works just as I explained above.

Or simply read the libjpeg source.

Don't like that, read this [1]: "JPEG images are always recorded with 8-bit depth. This means the files can record 256 (28) levels of red, green and blue."

Don't like that, here [2] is the JPEG ISO standard, section 4.11, baseline jpeg, "Source image: 8-bit samples within each component".

A DCT takes an 8x8 pixel input, 8 bits per channel, and transforms them into an 8x8 output. It matters not what these are - the information theory content is nothing more than what was put into it. There is not suddenly magically more information content.

More simply, appending zeroes to a number does not mean you can represent more numbers. You simply can represent the exact same numbers, just wasting more space.

None of what you wrote adds more resolution at the output. It simply isn't there.

If I give you 5 possible inputs to a function, then you have 5 possible outputs, not matter how many digits you finagle into representing the output.

Jpeg has 8 bits of resolution per channel. End of story. That is why professional photos are taken and edited in raw - you get more bits of resolution per channel.

I'm not sure why you're still arguing this. It's a longstanding, well known issue, and I explained it all again very simply.

If you think it isn't true, encode one of your magic jepgs with more than 256 levels of gray and post it here. Good luck :)

If you cannot do that, then maybe you should consider that you're wrong.

[1] https://www.photoreview.com.au/tips/editing/bit-depth/

[2] https://www.w3.org/Graphics/JPEG/itu-t81.pdf

Re: H.264 is Magic (2016)

#220

Post by astrange »

rasz wrote: post #201
astrange wrote: post #124

Earlier quoted context omitted.

JPEG2000 wasn't technically better enough; wavelets are too blurry and less efficient to decode. For some reason there was an epidemic of terrible codec designs for a decade or two, though it could've all been patent avoidance.

So bad its still industry standard in Cinema quality video codecs? Like the obfuscated jpeg2000 in RED codec.

Who says they know what they're doing?

DCI (how movies are sent to theaters) does use JPEG2000, but I think they just wanted something with 12-bit video and that's pretty rare in any codec.

One advantage is if you want to decode the same picture at lower resolutions; JPEG can do this equivalent to nearest-neighbor, wavelets can do it equivalent to a better filter than that. But still not as good as just decoding and resizing down.

Post reply on HN