Hacker Newsnew | past | comments | ask | show | jobs | submit | more pornel's commentslogin

24 megapixel almost-lossless photos dumped straight from the camera are too heavy to be used directly on the Web. They also have lots of metadata including GPS location, that people usually don't want to share.

In practice you'd want to resize it (HD is 2mpx, and 4K resolution is 8mpx), and recompress to quality suitable for viewing not editing (makes huge difference in file size).

The necessary recompression step makes the input format mostly irrelevant. The upside is that JPEG XL is free to use, so it's possible to legally write tooling using it without touching the mess of H.265 patents.


JPEG XL has many compression modes inside, and the lossless JPEG roundtrip works only for one of them that was specifically designed to hold old JPEG's data. You can't take an arbitrary JXL file and turn it into a JPEG without lossy recompression.

The old-JPEG-preserving compression mode also isn't the best that JXL can do. It's better than the old JPEG, but not as good as JXL using all the new bells and whistles.


Rust emits unreasonable amount of debug information. It's so freakishly large, I expect it's just a bug.

Anything you compile will dump gigabytes into the target folder, but that's not representative of the final product (after stripping the debug info, or at least using a toned-down verbosity setting).


> Rust emits unreasonable amount of debug information. It's so freakishly large, I expect it's just a bug.

Rust relies on the linker (via -ffunction-sections and -gc-sections) to delete functions that aren't ever used but the linker isn't capable of removing the corresponding debug info.

https://github.com/rust-lang/rust/issues/56068


Most of your target folder isn't debug info, but stale build artifacts because Cargo doesn't do any garbage collection.


Does it need a more compact representation of its debug info?


An expensive car is also a status symbol. But when the brand is inseparable from Elon's shitposting, it's not something to brag about any more.


I think the number of Uber drivers with Teslas makes it seem like less of a status symbol.

A Model 3 or Y isn’t a flex. They start around $30k, which isn’t exactly luxury pricing. Making cars people can afford is a good thing, but once that happens, it stops being a status symbol.


It may not be a flex, but having an electric car is still a statement (less than it used to be, but still) that you're a high tech, forward thinking, environmentally conscious person. The problem is that now it's also a statement that you're a Trump supporter.


Those 2 assumptions are at odds with each other. The Trump supporters I know don’t want anything to do with electric cars, and Trump was the one fighting for coal to remain viable, which is the exact opposite of environmentally conscious.

Personally, I have never seen a Tesla and assumed the driver was a Trump supporter. The much bigger stereotype is that the left buys EVs.

I don’t think many people are trading in their Cummings diesel 2500 truck for anything electric. The die hard Trump fans would be on Truth Social, not Twitter. They might like some stuff Elon is doing, but I don’t think they are going to give up their gas engines over him.


https://wgpu.rs can emulate newer APIs on WebGL2. It's really nice to work with.


The "actual compression magic" has been used before DCT in other codecs, but applied directly to pixels gave lousy results.

You can also look at 90's software video codecs developed when DCT was still too expensive for video. They had all kinds of approaches to quantization and entropy coding, and they all were a pixelated mess.

DCT is the key ingredient that enabled compression of photographic content.


What's so special about DCT for image compression?

The main idea of lossy image compression is throwing away file detail, which means converting to frequency domain and throwing away high frequency coefficients. Conceptually FFT would work fine for this, so use of DCT instead seems more like an optimization rather than a key component.


The DCT, just like the DFT, is a discrete version of the (analog) Fourier transform. (FFT is just a clever, fast implementation of the DFT, just like when people say “DCT” they usually mean a similarly fast implementation of the DCT. Call it FCT if you wish.) Where they differ is the assumed boundary conditions; DFT works like Fourier-transforming a signal that is repeated and then loops forever, while DCT is like Fourier-transforming a signal that is _reflected_ and then loops forever. (There is also a related transform called DST, where it assumes the signal is _inverted_ and reflected. It's occasionally useful in solving certain kinds of differential equations; only rarely so in compression.)

This matches much better with what happens when you cut out small pieces of a signal, so it gives less noise and thus better energy isolation. Say your little pixel block (let's make it 8x1 for simplicity) is a simple gradient, so it goes 1, 2, 3, 4, 5, 6, 7, 8. What do you think has the least amount of high-frequency content you'd need to deal with; 123456788765432112345678… or 123456781234567812345678…?

(There's also a DCT version that goes more like 1234567876543212345678 etc., but that's a different story)


A DST is optimal when the variance of the signal you are compressing grows linearly (as opposed to the DCT, which is optimal for uniform variance). That happens, for example, when you have a prediction on one side (e.g., intra prediction in image compression) and you are coding the prediction residual. The farther you get from the source of your prediction, the less accurate it is likely to be. Block-based motion compensation prediction residuals in video coding are also not uniform: the prediction error is higher at block edges than the block center, so a DST sometimes works better (e.g., when using a transform size smaller than the motion compensation block size).

So still useful for compression, just in more specialized circumstances.


Yes, I think “only rarely useful” covers it :-) I know there are some codecs that support it, e.g. VP9?


Probably every video coding standard published after c. 2012 has some version of it in its toolbox (including VP9).


Thanks!


In practice there is a difference because FFT would have more edge artifacts at block boundaries - lowering visual quality - and DCT has better energy compaction into lower frequencies meaning longer runs of zeros of higher frequency coefficients after quantization so better compression. Another plus is the DCT only needs real numbers.


There's at least one specific optimization in H.264 (aka "MPEG-4 Part 10") to smooth out these artifacts at block boundaries, called "deblocking".

https://en.wikipedia.org/wiki/Deblocking_filter


And then there's the current maintainer of libjpeg, who switched the down- and up-scaling algorithms for chroma subsampling to use DCT scaling because that's mathematically more beautiful, which does introduce some additional artifacts at the block boundaries of each upsampled chroma block.


It's been working like that for a decade, and it's been fine.

Rust/Cargo have been designed for it from the start.


It's very useful to get a multi-network RFID card. I've got ChargeMyHyundai and their card works with all these crappy little networks that feel so important to have an app.


I have some, BUT they tend to have some hyper-high costs on certain networks, so on unusual trips I still need a companion app to verify the price of one of the few I have plus the option to register, download the nth crapplication and so on to avoid roaming costs.

Just try ChargePrice somewhere in the EU no matter what charger, you'll find for the same charge an enormous price difference, often more than 4x or even 10x from the cheapest to the most expensive combo of roaming and own network cards. It's a jungle.

Thankfully as almost any BEV owner I do need public charging only for long trips, not frequently, for the rest I recharge at home, but this also means many in cities would simply never get an EV.

Than ad the absurd price delta from the BRICS countries, let's say an entry-level BEV, BYD Atto 3, ~38k€ here, ~9k€ in Thailand, same battery and accessories. For where I live there are enough public charger for essentially all destinations in the region, it's not a matter of mere availability, it's a matter of a awful market on them with absurdly different prices for the same amount of energy (and time, because some chargers have ha connection fee, a time fee and an energy fee together and you have to do a bit of math to find the cheapest if you want) while gasoline/diesel vary just about few cents around a region an not more than ten cents in the whole EU united to such incredible price difference for the car, essentially BEV are a sound option ONLY if you recharge at home 99% of the time and run them at least 20k km/year or more. Witch makes them sound for just 10% or so of the overall population. While at BRICS costs, not just China they probably be convenient for 50-30% of overall population.


I hate charging at gas stations. They're not a place where I want to spend time. Their retail is usually small, food choice is meh, and the surroundings are boring and smelly.

In my experience oil-company-owned charging networks are the least reliable. Shell Recharge is so bad it looks like intentional sabotage.

Gas station chargers aren't even an alternative to hotel chargers. They need different types of chargers — hotels and workplaces can have cheap and simple AC chargers that take a whole day or night to recharge (8-11 hours). Nobody is going to spend a whole day at gas station, so they need much more expensive DC fast chargers (20-30 minutes to recharge). But for fast chargers highway stops with a food court and nicer views are much better.

You don't fuel your ICE car in a stable to parade it in front of horses, and EV owners have no need to sit at a gas station.


I'm a huge fan of Fastned. They have never failed me. I can rely on their chargers working, and delivering maximum speed.

Ionity is not too far behind, and between the two the coverage is pretty good in Western Europe.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: