You can get commercial software that is a bit better tuned for running on "ordinary" desktop hardware, but it's so expensive that you don't really come out ahead on total cost.
(Tangentially: I wouldn't bother with ECC RAM for this application unless that were required by the rest of the hardware. Memory errors may slightly affect time to a converged solution, but it's rare that a flipped bit would actually cause a job to converge to a different solution.)
Disclosure: I work on Google Cloud,
The reason I don't use cloud computing is that you constantly have to worry about moving data around, turning stuff on and off, API changes, data movement costs, product lineup changes (should I store this stuff on S3 or local HD), locally compiling all your stuff again or containerization and associated time overhead.
Local large box makes way more sense if you're doing solo projects. And if traveling, it would way more sense to rent a VPS from Hetzner. Flat cost structure and tons of bang for the buck.
BTW, I you can get 128 gb LGA2011-v3 motherboards.
https://www.newegg.com/Product/Product.aspx?Item=N82E1681315...
and it seems like it works: http://www.pcworld.com/article/2938855/hardcore-hardware-we-...
even though the spec says max 64gb: https://ark.intel.com/products/82932/Intel-Core-i7-5820K-Pro...
The clocks are a little lower than the retail Xeons, and you do need to pay attention to compatible boards/BIOS versions, but you can get a big Xeon E5 for like $200-300.
If you follow this very thread, you'll notice that another user already complained that "you need to pony up for a Xeon workstation if you need more than 64 GB."
I was pointing out that there were other processors already on the market that met his requirements: Xeon engineering samples, which most people don't think about when they are talking about the costs of high-end Xeon workstations.
(This is partially because they are not "finished" products like retail chips. Clocks are lower, and you need to use motherboards/BIOSs from a specific compatibility list, and they are not something you can source from Intel. Thus, they slip many people's minds because they aren't something you would consider for an actual server deployment - but they are perfect for a workstation with specialty needs that needs to hit a tight budget)
So yes, I did actually read the thread. You just didn't grasp enough of the context to make a sensible response and figured it was the perfect time for a superslam "did you even read bro?" gotcha response.
Typically this sort of response is not welcome on HN. If you don't have something substantiate to post, please don't post at all.
Absolutely no one that owns one of these professional cameras uses them with non-Xeon CPUs.
Really the only use for greater than 64Gb for non-Xeon CPUs would be student animation or machine-learning projects.
You don't buy/rent a camera you can't afford to process images from just like you don't buy a car you can't afford to service and you don't buy a house you can't afford taxes for. Or if you do, I have little to no sympathy.
The computers often are owned by the company renting the gear, where the end customer pays for the camera rental.
So it's not so simple. And one thing - go easy on using the word idiot... I work with some very smart people who fit your description of idiot on a regular basis.
If it's really true, then your pricing is clearly wrong.
https://www.adorama.com/ipxk1.html https://www.adorama.com/inkd810.html https://www.adorama.com/inkd7100.html
Which brings a slightly unrelated note: people seem to be blissfully unaware that you need less than 9mpix for a 12x9" 300 dpi print or that the zoom lens they bought with the camera has sharpness that effectively limits the resolution to 5-10, maybe 12 mpix if they are lucky. But megapixel count is easy to sell -> race for more megapixels -> smaller physical pixels -> more signal amplification needed -> more noise / general lower photo quality.
64Gb is completely unnecessary for photography. Photographers don't even go over 16GB.
All of your hypothetical examples are also for very niche high-resource usage professionals. It's absurd that these cases need extremely high memory support from consumer processors. Intel is not obligated to subsidize anyone, especially not people who can afford to pay for high end systems.
AFAICT nobody on this sub-thread is claiming that consumer desktops should cater to our niche use cases. We're just offering examples of application domains where a high RAM-to-CPU ratio is useful.
Additionally, as for your original question: For hobby or even 'normal' professional photography, I'd guess none. But rigs like the ones used for Gmaps Street View, the recent CNN gigapixel, etc. would probably have the capability to approach that size.
And yes, I also want to know what turns a 500MB photo into >16GB in memory. That's 32 full-res copies of the photo in memory. Just "a couple layers and a couple undo steps", really?
Presumably that's 16-bits for each channel of Red, Green, Blue. Since every pixel is composed of the three RGB components, that's how you get 48-bits for every pixel (and internally, Photoshop refers to 16-bits per color channel as 'RGB48Mode').
Layer size: Layers add more data on top of this: alpha channel (8-16 bits/pixel), clipping mask and maybe half a dozen other things, easily bumping the whole thing from 6 to 9 or 10 bytes per pixel.
Layer count: It's fairly common to have multiple layers that are copies of the original photo, with different processing applied and blending them into the final one. I'm very much an amateur and when I'm serious about just making a photo look (not even creating something new) I end up with around 10 layers.
Undo step memory: a lot of work in the photo processing workflow is global: color correction, brightness, contrast, layer blending settings and modes, filters (including sharpening or blur) apply to every pixel of a layer. Each confirmed change (by releasing mouse button / lifting stylus / confirming dialog) is likely to have to store an undo step for entire layer.
Of course you can just persist some of that to disk, but if a single layer/undo step can be 800MB this will hurt productivity - only very recently we got drives that can write this much fast enough and that's why just a couple years ago, when having enough RAM was not really an option a lot of pro photographers had 10 or 15k RPM HDDs running in RAID0 in their workstations.
For the layers/undo steps, the "couple" of each was not my phrase. It was yours. If by "a couple" you actually meant dozens, then sure, maybe an 80 mpix photo really needs that much memory to process.
1. Are they actually doing that? I'll be honest, I don't know for sure, but I do know that more capacity rarely comes for free. I assume that supporting 256GB of memory efficiently relative to 64GB requires either a faster clock speed or some more pins. Is Intel "gimping" the consumer product or simply not building in the extra capacity?
2. Is it necessarily a bad thing if they are? If consumer demand peaks at, say, 32GB and professional demand reaches, say, 512GB, Intel could develop two entirely different architectures, which seems wasteful and more costly to everyone. They could ship just one chip with professional capacity supported, which drives up consumer costs effectively subsidizing professionals (because professionals are no longer paying the premium for the "pro" chip; they're just buying the consumer one). Or they could ship a consumer chip that doesn't support professional needs and ship a professional chip at a price that makes pros pay for the capacity Intel had to engineer for them.
The last option seems like a good option for everyone except the people who think everyone else should pay a premium for unnecessary pro support so that a few people can get cheaper pro chips.
Do you really need this much headroom, e.g. for producing music professionally? (If so, why are you arguing over the $50-100 extra for a Xeon?)
Because for listening, it's proven fact that even professional musicians and mixing engineers using equipment costing >$100k can't tell 24 bit from 16 bit in a proper double-blind A/B test. Presumably you use a high sample rate as well (maybe 192 kHz), which is equally useless. Drop both of those, and you're within 64GB easily with no noticable SQ loss.
It's the same rationale for doing calculations in full 80-bit or 64-bit FP even if you don't need the full bits of precision -- if you start your calculations at your target precision, your result will have insufficient precision due to truncation, roundoff, overflow, underflow, clipping, etc. in intermediate calculations.
In theory, if you knew what your editing pipeline is, one could mathematically derive the starting headroom required to end up with acceptable error, but in practice that's probably a very risky proposition because 1) you don't know every intermediate calculation going on in every piece of software and 2) errors grow in highly non-linear ways, so even a small change in your pipeline might cause a large change in required headroom [1].
[1] https://en.wikipedia.org/wiki/Numerical_analysis#Generation_...
In practice, fixed-point or floating-point is better depends on the operation you plan to use and whether you have a good idea whether you'll be able to stay in a fixed range ahead of time [1].
[1] The loss of 'footroom bits' corresponds to the extra resolution lost whenever the FP mantissa increases - http://www.tvtechnology.com/audio/0014/fixedpoint-vs-floatin...
Also, you don't cause errors when you compress and decompress using a lossless compression format (as the name sort of implies).
That's not how it works. You can totally hear clipping or noise even as an amateur. Just as an amateur photographer first thing first learns to look out for overlit skies and hilights that aren't really recoverable at all unless they perhaps have access to the camera's RAW files. But unlike in photography, in sound work you typically need to process as well as sum multiple recordings, all while not blowing out the peaks that might just happen to line up.
If anything, dealing with the large dynamic range of 24-bit is easier for the amateur. An experienced pro would probably have a good bunch of tricks in his bag should he really have to mix music in 16 bits, enough to produce something that doesn't sound horrible. The amateur would be more likely to struggle.
While people here like to quote that infamous looks-like-science-but-isn't Xiph video, the reality is that a lot of professional engineers absolutely can hear the difference.
If you have good studio monitors and you know what to listen for the difference between a 24-bit master and a downsampled and dithered 16-bit CD master is very obvious indeed, and there are peer reviewed papers that explain why.
Dither was developed precisely because naively interpolated or truncated 16-bit audio is audibly inferior to a 24-bit source.
Many people certainly can hear the effect of dither on half-decent hardware, even though it's usually only applied to the LSB of 16-bit data. From a naive understanding of audio a single bit difference should be completely inaudible, because it's really, really quiet.
From a more informed view it isn't hard to hear at all - and there are good technical reasons for that.
For synthesis, you don't want dither. You want as much bit depth as possible so you can choose between dynamic range and low-level detail. So 24-bit data is the industry standard for orchestral samples.
Their words mean very little.
I totally get going for 24 bit over 16 for the noise floor, though.
Such audible differences constitute a testable claim. So far, the number of claims that have withstood reasonable test conditions is zero.
Nobody is arguing that 16 bits is enough during the recording and mixing process. If they are claiming that 16 bits is insufficient for consumer distributed music, they need to go back to remedial science class.
I'm all in favor of keeping sample sizes better.. but raising the price for everyone by 10-20%, so that less than 1% can take advantage of it is a bit ridiculous.
Dither was developed because it's technically better. Audibly inferior though? Perhaps, with utterly exceptional source material (e.g. test tones) and when the output gain is high enough for peaks levels to be uncomfortably loud.
In reality, many recording studios have a higher ambient noise level than the dither, making it redundant in practice — the lower bits are already noise, so audible quantisation artefacts weren't going to happen anyway. That said, dithering is pretty much never worse than not dithering, and almost all tools offer it, so everyone does it.
24 bits is important because it gives the recording engineer ample headroom, and it gives the mixing and mastering engineers confidence that every last significant bit caught by the microphone will survive numerous transformation stages intact. Once the final master is decimated to 16 bits per sample, you know that your 16 bits will be as good as they could have been.
Have you actually heard the difference between simple dither, noise-shaped dither, and non-dithered 16-bit audio? A test tone is the worst possible way to hear what they do.
24-bit audio is used because you want as clean a source as possible.
This also applies to mastering for output at the other end. With the exception of CD and MP3, most audio is delivered as 24-bit WAV at either 44.1, 48, 88, or 96k.
Even vinyl is usually cut from a 24-bit master. Here's a nice overview of what mastering engineers deliver in practice:
https://theproaudiofiles.com/audio-mastering-format-and-deli...
Dither is noise. Well chosen noise, very quiet noise, but noise nonetheless. Whether the signal is noisy for one reason or another, the consequences at the point of decimation/quantization are the same. Either way the least significant bits are filled with stochastic values and the desired signal isn't plagued with quantization noise artifacts.
> Have you actually heard the difference between simple dither, noise-shaped dither, and non-dithered 16-bit audio? A test tone is the worst possible way to hear what they do.
...is the sort of thing someone who hasn't done a blinded listening test would say. Stop assuming the commercially successful "experts" are also technical experts, because few are. I doubt more than a tiny fraction could describe what a least significant digit is.
(Cutting vinyl, a hilariously lossy process that requires compression and EQ to avoid the needle jumping the groove, doesn't need a 24 bit master. Barely needs a 14 bit master. But since an extra hundred megabytes of really accurate noise floor doesn't make anything worse, they do it anyway.)
Digital samples can and will generate intermodulation distortion, quantization and other audio artifacts when mixed. Using 24-bit lessens or eliminates the effect versus 16-bit.
Experiments and results on this software are here: http://www.sonusparadisi.cz/en/blog/do-not-load-in-16-bit/
For mixed and mastered music, the ~120dB perceived dynamic range of properly dithered 16-bit audio is more than sufficient. If you're listening at sufficient volume for the dither noise floor to be higher than the ambient noise floor of the room, you'll deafen yourself in minutes.
For production use, the extra dynamic range of 24 bit recording is invaluable. You're dealing with unpredictable signal levels and often applying large amounts of gain, so you'll run into the limits of 16-bit recording fairly often. In a professional context, noise is unacceptable and clipping is completely disastrous. Most DAW software mixes signals at 64 bits - the computational overhead is marginal, it minimises rounding errors and it frees the operator from having to worry about gain staging.
You can probably get away with 16 bit recordings for a sample library, but it's completely unnecessary. Modern sampling engines use direct-from-disk streaming, so only a tiny fraction of each sample is stored in RAM to account for disk latency. The software used by OP (Hauptwerk) is inexplicably inefficient, because it loads all samples into RAM when an instrument is loaded.
It can be quickly done on a consumer workstation, but you do need 128 GB in many scenarios.
The complaint is not about adding the capability to all chips. It's about smoothing out the step function between consumer machines and professional workstations.