I think portability is very confusing: they rolled out passkeys with no device portability (device-bound) and only recently added it (CXP). So for anyone with multiple devices it was a relative disaster - why should my Windows PC hold a device-bound passkey to anything? How do I login on Linux or macOS?
Picking a password manager to do portability also means another kind of lockin, though maybe you can live with that kind if you really trust the company. Even so, the password managers all seem to be competing to have relaxed security, so that vault and account passwords are the same, or you are asked to type your master password into a webpage - surely we didn't replace per-site passwords with this?
It's hard to remember with all the ownership changes, but the Photobucket era was really a different time, of "it's your data, you're in charge, and we give you maximal control of it" - people would upload there to post elsewhere, and I recall they ran ads to monetize. But this era had the ethic that uploading was expensive, and you'd maybe want to do it once and have control of your stuff after that.
Now we have photo hosting services that barely work on the web (iCloud), or work only within a walled garden (Instagram), and I do miss the "it's your stuff, we're just a website" kind of attitude from the mid-2000s.
Yes, I think part of it was the "dark fiber" at the time, made bandwidth relatively cheap. But most personal photos don't use that much bandwidth - being able to use them anywhere online (which iCloud and Instagram don't allow) was a big idea. We went from "my content hosted in the cloud" to "Instagram's content" in a lot of ways. That is only partly a pricing issue.
I think the main thing here is merely that it's costly to keep a massive archive (of mostly garbage[1]) online and available on a long timescale. Not just the S3 bill (which I wouldn't underestimate the cost of, for a site that let just anyone upload basically infinite amounts for a decade), but the cost of having engineers maintain and monitor the site forever, either with revenue having dried up a decade ago, or, also having a staff of people to operate the whole business.
You're remembering that if you uploaded something to some free site in 2001, it was still there in 2004. That was because the same people and companies were still around 3 years later, it wasn't because they cared more about you than 2026 startups do. Sure, 2004 Photobucket may have cared more about us than 2026 Meta does -- but I doubt 2001 AOL or AT&T cared about us more.
[1] I only mean most of the content uploaded to Photobucket 2 decades ago is completely useless and abandoned with no one ever coming back to look for it. Memes or screenshots posted to forums that themselves have been offline for a decade. And just content that people don't remember even creating.
I'll argue for the +0.5 solution. First, I don't like half-sized intervals at the edges, and second, a 255-based representation is typically a SDR (not HDR) image.
RGB values represent luminances against some adapted state, and a "zero" in a daylit scene is not "zero luminance" - it's just about 0.001x as bright as the brightest point - it's millions of photons, way more than zero. In a sense our eyes experience contrast on a sliding scale, and there is no absolute zero in the system. For example, broadcast systems historically used 16-235 as their luminance range for SDR. I think any argument that says "we must have zero" is going to have a bias, but I don't think zero is needed for most things.
As someone with a lot of experience in this area doing image processing and rendering for VFX (including writing image readers and writers for my own software and commercial VFX software), I think you might be forgetting that colourspace conversion (to sRGB 'linear' rec709 for old-school SDR, but other more wider gamuts for newer formats) would happen after this, so the 'squish' of the dynamic range would happen after loading.
Also, a lot of workflows for image processing and compositing do assume that 0 means zero, whether correctly or not (often incorrectly). So there are often assumptions that for 8-bit, 0u maps to 0.0f and 255 maps to 1.0f for things like masking or alpha: as soon as you have 0 values which become just over 0.0, you then have artifacts because some code somewhere is using a hard threshold of 0.0 to mask some other operation, and vice-versa for 1.0 with alpha, where suddenly because the 255 values are no longer 1.0f, you have very slightly see-through objects (often only visible in certain situations or when pixel-peeping) after pre-multiplication.
(Same thing can happen when 254 becomes 1.0f after +0.5 with masking).
I think more to the point, if 0 doesn't represent 0.0, and 255 doesn't represent 1.0, congratulations you've just lost your additive and multiplicative identities and most of the math used in colors falls apart.
The argument for 0-256 feels compelling when thinking about the physical display, but it seems like a very poor fit for any digital image processing or rendering.
> Remember how the 0 and 255 bins poked slightly beyond the [0,1][0,1] range’s edges? In the standard approach, the range of representable values is actually [−0.5/255,255.5/255][−0.5/255,255.5/255], meaning the bins are spaced further apart than strictly needed for [0,1][0,1] inputs
This is of course silly: the "range of representable values" of floating point colour components is [0,1] independent of quantization and how an invalid input would be quantized is irrelevant.
Looking at the actual "big picture" there are 256 representable values and (taking into account gamma correction, arbitrary ranges other than [0,1], deliberately nonuniform quantization bins, and other plausible complications) their correspondence to 256 floating point values should be regarded as a generic lookup table, abandoning all hope of using elegant and cheap formulas and making it obvious than encoding and decoding differently is not an option.
Although the post focuses on RGB, the same quantization issue exists for any type of signal being mapped between discrete and continuous representations.
The issue isn't in having a representation for 0 photons, but about maximizing information stored in a byte. Ideally you shouldn't be underutilizing the byte value 0, nor add bias to data that should have been assigned to the 0th bucket, regardless of what it represents (you could have a color space that goes from bright to super bright, and still want to ensure that every byte represents equal chunk of your brightness range).
Yep, the exact same problem arises in digital audio, mapping between integer sample formats and the floating point representation that is generally used internally.
> In a sense our eyes experience contrast on a sliding scale
There's a whole visual center to check the amount of incoming light and adjust your pupils for you. It's intentionally reactive.
> and there is no absolute zero in the system.
There maybe is. I think we call that "blind."
> broadcast systems historically used 16-235 as their luminance range for SDR
Mostly because it was a fully analog system and these all translate down to signal voltage. Jokingly NTSC used to be referred to as "Never Twice the Same Color" due to being a compromise bolted onto the side of an already compromised system.
They don't - trunc(result * 255 + 0.5) is just round(result * 255), i.e. error is on average 0 whereas trunc(result * 256) has an average bias of -0.5.
> For example, broadcast systems historically used 16-235 as their luminance range for SDR.
Unfortunately "modern" HDMI is still plagued by this insanity so if your display and source don't agree you can either get washed out or crushed blacks.
Interesting idea, but somehow I feel the world is shaking. For the processing program, what used to black(0.0) and white(1.0) has became very dark gray and very bright gray.
For 8-bit, 16 maps to 7.5IRE which is the well understood legal black. Mapping 235 means they mapped peak to 110IRE. This is based on a 0-120IRE scale. This gets weird as the broadcast limit for video was 100IRE allowing for the chroma to reach 110IRE. So if you're trying to limit your white values to 235, that'll be higher than is broadcast safe. Of course, nobody cares about NTSC broadcast limits any more. However, to this day, I still see out of spec tapes marked as "broadcast master" that have been ingested for streaming use. It drives me crazy to this day, and it's only getting worse as people don't even have scopes to adjust the VTR's TBC properly.
The "16" digital black level is independent of the "7.5 IRE" analog setup. E.g. in Japan with an 8-bit "NTSC-J" Rec. 601 system, my understanding is that 16 still maps to E'Y = 0 which is now at 0 IRE, and 235 is still E'Y = 1 at 100 IRE.
Ugh. Sudden flashbacks to having to switch analog output between Japanese NTSC (no pedestal) and US NTSC (with pedestal) without getting weird noise in the black regions.
But IIRC the MPEG-2 standard had luma==235 -> 100IRE for all of the analog formats (pal/ntsc-j/ntsc/secam) so I'm not sure why you say that would violate the broadcast limits?
Simply because the math works that 7.5IRE on a 120IRE scale maps to 16 8-bit that 110IRE maps itself to 235 8-bit on a simple scaling equation. To get 235 8-bit to match to 100IRE means some sort of exponential scaling. At that point, I stuck with the linear scale and moved on with the keep it simple stupid mindset
I agree. Additionally, both 0.0 and 1.0 don't really exist for dithered signals, so a byte should map to [0.5, 255.5] before division by 256. This also solves the signed integer asymmetry, as a signed byte maps to [-127.5, 127.5] before division by 128. I wonder if audio DSP folks have done this already.
It is still frequency, where it would have negative values. but I doubt any color handling algorithms deal with it as a frequency. Rightfully so, the physical wetware for decoding images is very different than that for decoding audio. Well... not that different if you think of audio as a single pixel monochrome image.
Now I am imagining a weird alternate history where we treat audio like we treat color. OK take three bytes which encode how loud the sound is, one for lows, one for mids and one for highs where lows mids and high frequencies are picked to match human ear response.
was never end to end, was you to server and then server to other party. Meaning Zuky boi always had access to your messages in clear (and NSA + all other 3 letters agencies)
Except this math is 10x too high (unless accelerated depreciation is all of it) - a million tokens at 28 tokens/sec and 75W and 20c/kwh should cost $0.15 not $1.50. (And less with MTP.)
2. The "description.md" example has things like "faces -> cluster_id". Is this from Davinci Resolve's face index? Things like faces+names and locations are really important with photo collections, but general LLMs don't handle them so well.
1) It's just simple plain-text `.description.md` sidecar files, one per clip, sitting next to each video.
Something which I can query later - Like when brainstorming with Claude "I wanna make some videos of the Luxury rooms in the lodge" and it knows what all videos could help here (going through the files).
There's also a folder root level files that aggregates the text descriptions to make it easier to find.
2) No - nothing from DaVinci Resolve. Framedex is a standalone pipeline. Resolve isn't involved.
Faces come from insightface (the open-source buffalo_l pack - RetinaFace for detection), running locally on CPU. For each clip it detects faces in the sampled frames, embeds them, and writes rows to ~/.framedex/faces.db.
Tbh, this part I know it's building up in my local DB but I haven't tested how good is it. Will check them out properly soon.
But yeah, on your broader point that's why framedex deliberately does not ask the LLM to handle faces or locations.
----
Faces → insightface / ArcFace embeddings. Deterministic, comparable across clips. The vision model only contributes a rough people_count; it never tries to identify anyone.
Locations → EXIF GPS via exiftool, reverse-geocoded through Nominatim/OpenStreetMap. Hard metadata, not a guess.
The LLM only does what it's good at: scene description, mood, shot type, keywords, keep/review/cull rating (this last part is also debatable though).
reply