Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I dunno how this particular app worked but there is this thing called "deferred processing".

The thing to realize is that the max resolution I can ever see on screen is the resolution of that screen I am working on.

Even a retina MacBookPro has only 4 Mpixels on screen, at any time. Now lets say I am painting a mask on a 30 Mpixel medium format image with a brush of 500 pixel diameter. Lets say I am zoomed out, so the image is displayed filling the entire screen. This requires a zoom level of 13% for the retina example. That means I only have to paint with a brush of 67 pixels diameter on a 4 Mpixel image in realtime and record the stroke! Because the brush path is recorded, the brush is resolution independent. That is what the claim refers to, no to the source material.

When I zoom into such a 30 Mpixel image, to better see what I am doing, the area visible on screen remains 4 Mpixel. Many image editing apps (or most) completely ignore this.

What's more, while I am working, I do not have to use sub-pixel precision when blitting brushes onto the image )or doing whatever else) because this level of precision, in general, but specificially when editing, is almost always irrelevant at that high resolution.

Memory wise, too, I don't ever have to hold (many layers) of 30 Mpixel res in ram. When a user loads an image, I build a pyramid (a mip map) dump that to disk and load tiles into a cache, as I go.

This never changes. When I have finished my 6 hour editing session, I press 'render' and everything is carried out, at 30 MPixel res. and subpixel precision. This render may then take an hour, but I don't care, I can go to bed and deliver the result to the client the next day.

When I do this in Photoshop, everything is always done at full res, with full subpixel precision. Ok, since a few years PS, too, uses a pyramid (mip mapping) in RAM, but it is far from optimal.

That is the reason why Photoshop's speed always sucks (because as hardware specs increase, so does the res. and number of layer people use when editing images).

It always uses too much RAM and too much CPU because it carries out a shitload of stuff you can't ever see until the final image is used in print or you zoom in at 1:1 and pan the entire image. Two things that, together, almost never happen in image editing.

P.S.: the only acceptable minimal bitdepth for image editing is 16bits/component float (linear space). Anything else will compromise quality, one way or the other.

P.P.S.: I was the product manager for Eclipse after Alias/XYVision sold it to Form & Vision in 1998. AMA. :)



Deferred processing is fine, until it isn't. For instance it's fine for things that don't have a lot of non-local changes, such as addition, subtration, multiplication, etc. as in brightness, contrast, compositing and so on.

It breaks down however when you do have processing that produces nonlocal changes, such as convolution, blurring, sharpening, distortion, etc. as in soft filter, gaussian blur filter, distort filter and so on.

You can run these at screen resolution only, but the result you will get can vary wildly from what the ultimate render will be.


I disagree. Yes, there are operations that whose results will vary.

But many non local changes will work fine and deliver very close previews when ran on properly filtered mip versions of an image. Particularly the ones you listed work well, non of them is a good example of something that will give you trouble with the approach I described (convolution, blurring, sharpening, distortion). Try Darktable to see how well these work.




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

Search: