New Mac Silicon Binary does not seem to be as fast as it should be

[jrp]

The new MacOS binary seems pretty good as a drop-in replacement for the Intel version.

However, it seems to take at least 1s to render a 61MPX image on an M3 Max MacBook Pro, which seems slow.

This suggests that there are some optimisation opportunities to come (eg, that the app is not really making full use of the GPU).  This is tricky stuff; it took Adobe several years to make best use of the new memory model, where the GPU and CPU share memory.  Lightroom used to eat all available memory but they seem to have put some effort into getting better performance out of the new hardware and it's much better now.

What are camerabits' plans to, once again, make image rendering speed class leading?

[Kirk Baker]

The new MacOS binary seems pretty good as a drop-in replacement for the Intel version.

However, it seems to take at least 1s to render a 61MPX image on an M3 Max MacBook Pro, which seems slow.

This suggests that there are some optimisation opportunities to come (eg, that the app is not really making full use of the GPU).  This is tricky stuff; it took Adobe several years to make best use of the new memory model, where the GPU and CPU share memory.  Lightroom used to eat all available memory but they seem to have put some effort into getting better performance out of the new hardware and it's much better now.

What are camerabits' plans to, once again, make image rendering speed class leading?

What is the specific file format that you're describing?

-Kirk

[Kirk Baker]

The new MacOS binary seems pretty good as a drop-in replacement for the Intel version.

However, it seems to take at least 1s to render a 61MPX image on an M3 Max MacBook Pro, which seems slow.

Can I assume that you've turned RAW rendering on?  If so, then rendering a 61 megapixel RAW image in about a second seems fairly brisk to me.  It's not really a fair comparison to compare the speed of RAW rendering versus using an embedded JPEG preview.  Unless your camera's RAW files have either no embedded preview or the preview is small, then there's no reason to turn on the RAW rendering.   I'm planning on adding an option to enable the RAW rendering but only utilize it when either the RAW has no preview or it is unsuitably small.  Then we'll have the best of both worlds.

This suggests that there are some optimisation opportunities to come (eg, that the app is not really making full use of the GPU).  This is tricky stuff; it took Adobe several years to make best use of the new memory model, where the GPU and CPU share memory.  Lightroom used to eat all available memory but they seem to have put some effort into getting better performance out of the new hardware and it's much better now.

I can tell you that the RAW rendering (which utilizes Apple's ImageIO technology) is definitely making use of the GPU.

What are camerabits' plans to, once again, make image rendering speed class leading?

Its class-leading speed comes from a good caching system that utilizes embedded JPEG previews in RAW files.  Turn off the RAW rendering and I expect that you'll see very good performance.  And our plans are unchanged: we look for and take advantage of optimizations as we find them.  We measure performance and only utilize those that make things faster.

-Kirk

[jrp]

Thanks, Kirk.

If it's rendering from the RAW, then it's impressive.  I thought that it would just pick up the associated JPEG or embedded JPEG.

I haven't enabled RAW rendering.  I have selected Edit RAW (over JPEG).

Is there any particular setting that I should be looking at?

You get a lower-res preview almost instantly, it's just when you try to zoom in that a beat is skipped.

[Kirk Baker]

Thanks, Kirk.

If it's rendering from the RAW, then it's impressive.  I thought that it would just pick up the associated JPEG or embedded JPEG.

I haven't enabled RAW rendering.  I have selected Edit RAW (over JPEG).

Is there any particular setting that I should be looking at?

You get a lower-res preview almost instantly, it's just when you try to zoom in that a beat is skipped.

PM doesn't pre-render previews at 100% until you try to zoom.  To do so would degrade performance for normal previews and chew up a ton of memory.

Check your Render Cache preferences and see if "Enable RAW Rendering" is checked and whether the Built-in Renderer is being used.  It would be much slower if RAW Rendering was enabled and you chose to use the Adobe DNG Converter.

If you don't have RAW Rendering enabled at all, then the embedded JPEG preview is being used.

PM is using Apple's ImageIO to decode JPEGs.  This system uses a combination of the CPU and the GPU to decode images.  Color Management is also being performed which takes a bit of time once the image is decoded.  Perhaps that too could be done on the GPU.

-Kirk

[jrp]

Thanks.  Perhaps it could be faster to render the accompanying JPEG, if there is one, rather than extracting the embedded one?

On a separate topic, the Beta 4 seems to produce an overlay with exposure info, etc, when you hover over a pic in the grid mode.

This overlay sometimes outstays its welcome.  Eg, it stays if you right click on the image for a context menu.

[ahoward]

Thanks.  Perhaps it could be faster to render the accompanying JPEG, if there is one, rather than extracting the embedded one?

That is what it does.

On a separate topic, the Beta 4 seems to produce an overlay with exposure info, etc, when you hover over a pic in the grid mode.

This overlay sometimes outstays its welcome.  Eg, it stays if you right click on the image for a context menu.

This has been a feature since Photo Mechanic 5 or possibly earlier. Press Command+Shift+T on the keyboard to turn it off.

[willievass]

For me, the Universal Binary on M2 and M2 Pro computers is both faster and much less processor intensive than the emulated Intel version running on the same hardware. Especially scrolling CR3 Canon raw thumbnails using the embedded JPEG. A welcome step in performance.