objectcode (u/objectcode)

objectcode commented on Google unkills JPEG XL? tonisagrista.com/blog/202... · Posted by u/speckx

majora2007 · 2 months ago

I don't know much about webp other than you get about 50% savings in compression vs png/jpeg, but it does have some hard limits on sizes of images. It doesn't do well with webtoon reading formats (long strip format).

Otherwise, I love webp and use it for all my comics/manga.

objectcode · 2 months ago

Even nowadays, webp seems to be good specifically for its lossless mode. It seems to create files that are substantially more efficient even when compared with advanced png encoders. For comics, png should probably be used over jpeg, so webp is likely indeed an upgrade, aside from compatibility.

For photographs, jpeg has really been optimized without reducing compatibility, and also in another less compatible way (incompatible viewers can display it without erroring out, but the colors are wrong) and there's such an encoder in the JPEG XL repo.

objectcode commented on Simple trick to increase coverage: Lying to users about signal strength nickvsnetworking.com/simp... · Posted by u/tsujamin

dataflow · 3 months ago

> taking mine to the same areas on the same carrier and doing a comparison

Unfortunately I don't think it's that simple. I've seen one phone simultaneously show significantly different numbers of bars for two SIMs installed in it for the same exact network and operator. After a while they become similar... then differ again... etc.

I have no clue how to explain it yet, but what I do know is that it literally makes no sense with a naive model of how these work, whether you try to explain it as reception or deception.

objectcode · 3 months ago

The phone selects a RAT (radio access technology) and frequency for each SIM slot.

After selecting, each SIM slot is subject to inter freq / inter RAT reselection / handover.

Both are controlled by messages received from the tower (e.g. on 4GLTE, for reselection, System Information messages), though there is an additional constraint: what's supported by/enabled in the phone.

Perhaps one SIM slot was in the connected state and the other was in the idle state at one point. So the reselection logic applied for one and the handover logic applied for the other. There is for example a problem called ping pong handover. Once a phone is switched to a different frequency or RAT, the tower may have the phone be sort of stuck in the new frequency, until the conditions of the previous RAT or frequency improve substantially, in order to prevent the phone being like a ping pong ball between the two. This frees resources that would otherwise be spent on repeated handover-related messages.

Each frequency has its own signal strength (free space path loss, transmit power, one frequency might be on one tower and another might be on another, etc).

objectcode commented on Simple trick to increase coverage: Lying to users about signal strength nickvsnetworking.com/simp... · Posted by u/tsujamin

NoPicklez · 3 months ago

There's a part of me that thinks there's perhaps a logical and reasonable explanation, I just can't think of one.

objectcode · 3 months ago

Maybe because the signal strength might not work as users expect?

Signal strength is like the loudness of music being heard. It's possible for music to be quiet but otherwise excellent, or loud but low-quality. However, if it is too quiet, then the "music" becomes almost unintelligible, which the offseted bars should still be able to indicate.

In Wi-Fi, 6GHz and 5GHz are often used instead of 2.4GHz. 2.4GHz would likely win in signal strength. Yet, the others are used anyway, because the others are good for other reasons. However, if range ( ...or compatibility) is critical, then 2.4GHz is used.

Similarly, in cellular, there is a lower frequency e.g. band 8/12/14/17/20/28/71 and a higher frequency e.g. band 1/3/7/30/38/40/41/66/77/78. (Less basically, it can be more granular.)

So this sequence of events is possible: Tower switches the phone to a higher frequency -> speed increases but the signal strength reduces (confusing, but at least doesn't seem bad if there are 3 or 4 bars.) A switch to a lower frequency normally occurs instead if the high frequency signal is weak.

Cellular can be slow due to interference (maybe more common than signal strength issues; the metric to use instead might be SNR/SINR), congestion (maybe more common than signal strength issues; the metric to use instead is confusing, maybe the CFI value (if automatically changed) or RSRQ with a high SNR/SINR might rule it out), the speed of the rest of the network (the metric to use might be RSRQ during a download with a high SNR/SINR), data plan (the metric to use instead might be RSRQ during a download with a high SNR or SINR/QCI (requires interpretation)), and the width of it (the metric to use is BW). So it's confusing, and not exactly that full bars are always better.

For 2G, with each nearby cell (coverage area) basically getting its own channels, signal strength might've been more important, though interference was there somewhat (so there was MAIO planning etc.)

But aside from speed, there's the battery to consider. If the signal strength from the tower to the phone is "satisfactory", it's implied that so is the signal from the phone to the tower, so the phone will have to have an elevated transmit power.

objectcode commented on Show HN: OnlyJPG – Client-Side PNG/HEIC/AVIF/PDF/etc to JPG onlyjpg.com... · Posted by u/johnnyApplePRNG

johnnyApplePRNG · 4 months ago

I ran into this exact issue during testing! I noticed that XYB-encoded images sometimes had a green or desaturated cast, especially on color-managed systems like macOS.

The way jpegli handles this is pretty clever and is designed for maximum compatibility. When you enable XYB mode, it doesn't create a non-standard file. Instead, it:

1) Performs its perceptual magic in the XYB color space internally.

2) Encodes the resulting image data into the standard Y'CbCr channels that every JPEG decoder understands.

3) Attaches a custom ICC color profile to the file.

This gives you the best of both worlds.

On modern, color-managed software (like current browsers, macOS Preview, etc.), the decoder reads the ICC profile and uses it to transform the colors back to perfect sRGB. This is how I fixed the green tint I was seeing—by ensuring the correct ICC profile was always embedded.

On old or non-color-managed software, the decoder simply ignores the ICC profile. Since the image data is already in standard Y'CbCr channels, it just displays it as if it were a regular legacy JPEG. The colors might be slightly off, but the image will still render correctly without crashing or showing major artifacts.

It's a great advancement in color spaces and it's the main reason for creating this pet project, really... Jpegli and XYB seem to be relatively unknown, despite gargantuan coding efforts by the Google Zurich team.

I'm just trying to shed some light on it, mostly!

objectcode · 4 months ago

cjpegli --xyb jpegs seem to have colors significantly (not just slightly) off if the color profile does not get loaded, and there are strong green and/or magenta tints. To test this, exiftool -all= file.jpg seems to do the trick. But even with this tint, images seem to make structural sense and can be understood, so compatibility might be fine anyway.

objectcode commented on Google blocks Android hack that let Pixel users enable VoLTE anywhere androidauthority.com/pixe... · Posted by u/josephcsible

Animats · 4 months ago

Does that work for inbound calls, or just for outbound? How does the voice network find you?

objectcode · 4 months ago

VoLTE is normally for both inbound and outbound. It is not 4GLTE base functionality, but is available if the phone supports it on the carrier and the carrier supports the use of it. An alternative is CSFB, which is about switching to 3G/2G (where calls are base functionality) for the duration of the call, but 3G/2G is not available everywhere. VoNR is like VoLTE(the ability to make and receive calls on 4GLTE), but for 5GNR. The carrier's equipment can find the phone for example by the phone sending tracking area updates/location area updates so it "knows" where the phone can be asked to connect so it can receive an inbound call etc.

objectcode commented on Solar panels + cold = A potential problem linspyre.com/ecoholics/te... · Posted by u/behnamoh

BobbyTables2 · 4 months ago

Why would lower temperatures lower the maximum voltage?

Sure, diode forward voltages change a little but seems like something else is going on…

objectcode · 4 months ago

I think it works this way but I could be wrong: 1. The forward voltage across a diode depends on the current, and the graph is r-shaped. For a certain diode, 0.01A might make the voltage across it 0.4V, 0.1A might be 0.6V, 1A might be 0.65V. 2. The forward voltage also depends on the temperature of the diode. For a certain diode, per °C decrease there could be a 0.002V increase.

Let's say with certain current there is 0.687V. If two diodes are connected in series i.e. (point a) → diode 1 → diode 2 → (point b), and each has a 0.687V voltage across, that's 0.687 + 0.687 = 1.374 V between point b and point a.

For the solar diodes, the "current" depends on how "strong" the sun is. If at a certain "current", across each diode is 0.687V, you'll need 216 diodes in series (between two points) to get 0.687×216≈148.4 V.

If there is 0.002 V increase per diode per 1°C decrease, with 216 diodes, that's a 0.002×216=0.432V increase per °C decrease, so with a 4°C decrease it exceeds the MPPT's limit.

Another thing about solar that differs from how diodes are "normally" used in circuits is that the "true" voltage depends on the max current achievable with the how bright the sun is right now, instead of the "true" current. When the "true" current is 0 A, the voltage across each diode might be 0.687 V. When the "true" current is 0.5 A, maybe 0.65 V. 1A, maybe 0.6V. 2A, maybe 0.3V. Try to get more "true" current, the "true" voltage drops. Try to get more "true" voltage, the "true" current drops. Power is voltage × current so when full speed charging, the MPPT uses an algorithm to find the (possibly) best minimum (not maximum) input voltage based on the temperature etc and trades voltage for current at the output. If there is no minimum input voltage restriction, solar will follow the battery's terminal voltage + cable drop instead, and instead of something like 111V, there could for example be a ~4x less powerful 25.5V (if the battery is a "24 V") with just 10% more current.

At the MPPTed min input voltage for full speed charging, maybe 111V, all might seem well even with low temperatures, but when the battery is full and there is approximately nothing using electricity from solar, the real input current will be ~0 A, so there will no voltage "sag", so the solar will realize the full voltage corresponding to the temperature and the illumination, potentially >150 V...