How Photoshop solved working with files larger than can fit into memory | Hacker News Reader

How Photoshop solved working with files larger than can fit into memory

developer.chrome.com

208 pointsthunderbong62 comments

It's a bit of a roundabout article, given that it's ostensibly talking about the Web version of Photoshop. Basically, Adobe already solved the problem (for decades, now) with a traditional non-web application by using the filesystem. And the new bit here is that Chrome offers a filesystem for web apps to use [1], so from the web app's point of view, it can still use the same essential solution that the native app would.

It doesn't really go into the guts of how PS actually manages all that data in much detail. Just "it goes to the filesystem in a smart way."

[1] The "origin private file system": https://developer.chrome.com/articles/file-system-access/#ac...

... application-based virtual memory has been a thing since CICS on mainframes back in the 1970s.

Photoshop can't rely on mmap, because its scratch file implementation is older than most modern OSes, and some systems have virtual memory limits it exceeds, not just physical memory limits. Though I'm not sure the browser even has mmap capability.

It's unfortunate that there's still no mmap equivalent for I/O in the browser, so you can't do demand paging or anything like that. Nothing approaching zero-copy either, you're typically looking at two copies or more. At least the OS page cache will probably help you out.

Scratch files, now that's a memory I'd repressed.

Make sure you keep your scratch files on a separate disk for extra performance! 8)

I remember someone I knew that insisted on using a ram disk as his scratch disk...

Like, uh.... ok, you do that, good luck.

If the app was from an era where RAM was much smaller, but now there's enough RAM for the use case, this makes sense.

Linux is full of stuff that writes to disk all the time.

Browsers do it too. It's possible to do multiple GB an hour doing nothing on some versions with extensions, just from writing and rewriting the same file every minute for probably no good reason other than a dev hated complexity too much to check for unnecessary writes and not wear out the SSD.

There was a time when the OS could not use the whole RAM directly the hardware had, and it was a use case to put a ram disk or a swap file there.

If the OS can't see the RAM, then the OS provided ramdisk can't use it either.

But in this case, the use-case for using a ramdisk for a PS scratch disk came from using an A23-aware patched version of System 5.x/6.x with a version of Photoshop that was not A23 aware. AFAIK This was a VERY tiny window around PS1.0 and possibly PS2.0, by the time of PowerPC and System 7.5+ (which this user had), there was very definitely absolutely no advantage to partitioning the RAM away from programs.

At a guess, someone had told them to do it this way in the era of the early Mac IIs and such, but they hadn't grasped the 'why'

In the late 80's/early 90's, it was one of the few ways to run large videos (for the time) without stuttering bc hard drives were too slow.

Was it compressed?

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

They used coding and filesystems so the webpages didn't crash.

They created a GUI using Visual Basic to track the killer's IP

I worked on some memory stuff for Figma, a similar app, though it's surely changed since I did.

One interesting thing about Photoshop's perspective is that it's fundamentally about "files", which is like a single bytestream that contains all the picture and which must be transferred to the browser to work on. A Figma document also can refer to images, but in a different way. The sum of the document data (like layout) and the image pixels can be extremely large, like gigabytes, but you can transfer those two things separately from server to client.

Might be off-topic but always wondered why Figma limits files to 2Gb, even the paid users. I remember once I had to present my work to stakeholders of a large company and when I opened Figma I was met with the dreaded red banner saying I exceeded the 2Gb limit and wouldn't open the file even for viewing. I was frantically posting on the forums and emailing customer support for a solution. Luckily they replied quickly and suggested I create a new file and paste the important bits on it and leave out the old stuff.

It was a memory limit imposed by the browser.

A free photoshop alternative, one man show

https://www.photopea.com/

Yes! I am a daily user plus the dev seems like a great guy(he did an awesome AMA back in the day). One of the few places I make it a point to whitelist my ad blocker. So glad to see this shout out.

I wonder what the intersection of people who do not know what RAM and Virtual Memory are, but interested in this article?

“ The amount of memory also varies from device to device, as you know when you order a new computer or device and specify the amount of Random-Access Memory (RAM) desired. Many of these platforms also support virtual memory, which allows an application to use more memory than is physically available.”

SEO...

Photoshop wasn't the one to solve this, as others have mentioned.

Adobe likely owns the xRes intellectual property, though:

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

> Photoshop wasn't the one to solve this, as others have mentioned.

> Adobe likely owns the xRes intellectual property, though:

Photoshop has used scratch files and it's own virtual memory system since long before adobe bought macromedia

File buffering RAM and/or arrays was invented long before Adobe. The tricky part is probably optimizing the image processing algorithms to fit the filing method(s). For example, if images are split into "tile files", and a given algorithm requires referencing too many files/tiles at a time, creating too much file I/O, then it probably needs to be reworked into a tile-friendly algorithm.

If I recall correctly, TIFF has the ability to tile an image.

This is kinda funny. I worked on 400 MB+ files in Photoshop on a Mac with 128 MB memory in 1999.

Donald Knuth used a pre-release version of Photoshop (at Adobe headquarters after the employees had gone home for the day) to process the images for his book 3:16. He was using multiple Macs to parallelize his process, and there were frequent crashes. This was back in the days of Macs with 512K of RAM which makes your 128MB Mac seem positively capacious by comparison.

He stated that would have been in the summer of 1989-- so Macs actually could have had anywhere from 1-128MB.

128MB would be unlikely, but the SE/30 was released in January of the same year.

Satori Paint (https://www.satoripaint.com/) achieved the same result (working with too-large files for available RAM) in the late 1990s. Hugely innovative, vector-based painting that looked like bitmap painting! But it was resolution independent (https://www.satoripaint.com/Tutorials/Workingwithverylargeim...).

Here's a gallery (sadly, thumbnails only): https://web.archive.org/web/20070813084252/http://www.animat...

And the original of this page showed how it was possible to zoom into an apparent bitmap image to an incredible degree (demonstrating the vector resolution-independence of Satori): https://web.archive.org/web/20070804225012/http://www.animat... [As far as I recall, it zoomed into the writing on the clipboard on the right, to show a single period!]

Incredible software!

> Satori Paint (https://www.satoripaint.com/) achieved the same result (working with too-large files for available RAM) in the late 1990s.

Desktop photoshop also had the ability to work with files too large for ram in the 90s

Now do iOS. Content-aware fill still fails with OOM on iPad Pro, yet works fine on older Macs with less processing power.

iOS VM system doesn’t use the disk for paging, so it’s quite a different beast than a machine with TB of available space.

This isn't even Adobe's first attempt at solving this problem. Old, old versions of Photoshop in the early 90's (I believe it was introduced in Photoshop 2.5) had an ancient hack called "quick edit" which would allow you to select a file and then open a "slice" of the file, which is a specified bounding box within the file (and not only x,y coordinates -- it could also select a subset of the color channels). It would then present that chunk of the file as its own standalone document window which you could manipulate to your heart's content, then when you saved it, it wrote the slice back out to the original document. It only supported a subset of graphics formats because each one had to have custom code to read and write the slice data.

Why doesn’t WASM offer a 64-bit mode?

It's in the works: https://github.com/WebAssembly/memory64

Starting with 32bit had some performance advantages because 64bit runtimes can use virtual memory shenanigans to implement bounds checking with zero overhead. In wasm64 they'll have to do explicit bounds checking instead.

>... 64bit runtimes can use...

Did you mean 32bit?

No, I mean running 32bit wasm code on a 64bit runtime. The trick is that a 32bit wasm instance can only address up to 4GB of memory, and 64bit hosts give you terabytes of address space to play with, so you can reserve all 4GB of address space up front and incrementally commit the pages as the wasm memory grows. If the wasm code tries to access a page beyond what's been committed it will trigger a hardware exception, so there's no need to perform explicit bounds checking. This only works because the wasm address space is significantly smaller than the hosts address space.

You could do the same with 64-bit by choosing somewhere south of 48-bits of actual address space that you hand out, no?

That's one way they could do it, not quite free since they'd have to mask off the high address bits at each load/store, but that's probably cheaper than adding a full branch at every load/store.

I think the wasm spec would have to be amended for that to be legal though, currently out-of-bounds memory accesses must throw an exception one way or another, and silently dropping the high bits of addresses may turn an out-of-bounds access into an in-bounds access that doesn't throw.

Not sure why. They could just guarantee the allocator never hands out invalid addresses no? If you’re trying to access outside the valid range that’s an out of bounds access because the memory range isn’t mapped. I’m sure I’m missing some nuance though.

The allocator never hands out invalid addresses, but the wasm code can then try to access out of the bounds of the allocated memory (eg huge array index).

The wasm runtime and other browser code runs in the same address space but must stay out of reach of the wasm code.

I see, thanks.

It's being worked on, it's currently available for development testing in builds of Chrome and Firefox.

One the one hand I like 64bits from a technical perspective but, on the other hand, I am not so sure I want to live in a world where a single web app needs to access more than 4 GB of address space.

But if the need occurs, you'd rather be forced to download/install an app rather than use a web app? This seems short sighted, especially for occasional tasks that come up where I'd like to just bang it out once with a webapp than install something.

That future is likely inevitable given the increasing size of games and how people would like to run those as web apps.

For the newer people clearly unaware, this is known as a "scratch disk"[1][2].

Now git off mah lawn ya greenhorns. :V

[1]: https://helpx.adobe.com/photoshop/using/scratch-disks-prefer...

[2]: https://en.wikipedia.org/wiki/Scratch_space

some sort of spinning metal thing with platters and read heads and magnets and stuff?

I thought this was pretty well-known. Adobe has been running their own VM engine for a long time now. I'm not sure which Photoshop first shipped with it, but given how pretty much everyone in prepress used it it's likely since at least Photoshop 3.

Version 1, actually[1]:

The PS.temp file is a special file created by the Adobe Photoshop program to implement the program's virtual memory scheme. Virtual memory allows you to work on images of nearly any size, by using a hard disk instead of RAM (random-access memory) to hold information. The PS.temp file contains the program's virtual memory information. The file is normally deleted when you quit the program.

For implementation details, see the files UVMemory.p and UVMemory.inc1.p in the source distribution[2].

[1] https://archive.computerhistory.org/resources/access/text/20...

[2] https://computerhistory.org/blog/adobe-photoshop-source-code...

We were doing that, with the software (scanner drivers and image processing -BIG files) my team wrote, decades ago.

It's very similar to VM. We paged and indexed everything.

I think it's a shame the application has to implement this at all.

The application should be giving hints, and then the OS deciding what to load and when.

Pandas has to deal with the same crap, thankfully Dask & other out of core packages fix the issues

Now if only Figma could catch up to Adobe...

It perhaps will soon:

- https://www.cnbc.com/2022/09/15/adobe-to-acquire-design-plat...

- https://www.theverge.com/2022/9/15/23354532/adobe-figma-acqu...

Photoshop discovered mmap?

Except when exporting files, where it still has weird size restrictions (somewhere around 10k pixels per side)

That's ironic, given that it's a Chrome blog post. Because recently someone here said that Google / the Chrome team used their market power to kill JPEG XL (a proposed jpeg successor) in favor of AVIF, which has weird size restrictions.

This is about the web version of Photoshop, there is no mmap there.

No, we've (collectively) discovered that we have a lot of mature technologies (like mmap), mature platforms and extremely fast hardware, so we created a crippled software development platform on a bloated layout engine so people can get creative again hacking around the arbitrary constraints and design flaws of the platform to solve problems that had been solved 40 years ago.

Web browser did drastically simplify delivery and deliverability though.

Not that there wouldn’t have been alternatives had web apps not become a thing. It’s just more user-friendly than most current open alternatives (eg apt-get), and more open than most current user-friendly alternatives (eg app stores).

Reply on news.ycombinator.com