PNG Max Size limitation

[turn2on]

Good that we use PNG many years.
I loving this format from the time of Macromedia Fireworks, when PNG can be editable at any time with layers.
Later - Macromedia product going to Adobe, and stopped to support.
Anyway, one-layer PNG is used at this days. All nice.

But when I try to use big-knob in the GUI, upper 560px width or height, its not possible with 64 steps.
One way is to reduce quantity of steps in filmstrip. Or make PNG width or height lower.

I know, this needs in big interface elements not really must-have option, but this is a real limitation of PNG format that coming to past.
No more multi-layers in many years (Fireworks, goodbye).
May be in future we can see in SDK something like Webp or other formats, that is more optimised in our days, with big width/height at the same resolution can have smaller size in MB?
So.. size of my current 500width knob is about 9mb. This is also about PNG optimisation, when something like webp can help to reduce MB size of filmstrip file.

Also, as I understand, with using hi-res, size of all rack extensions going bigger in MB? Small RE after hi-res is much bigger. And question about using PNG is more actual.

The same is about fonts.. outdated fonts with limited variants, good to have something more..

Know that we only can wait any solutions in future SDK. I'm not talk about new widgets, or some other things from devs Wishlist)
But Hi-Res update really make RE bigger? If yes, this touch graphic optimisation question. We can compress PNG quality, reduce colors, etc. But this is only half-solution.

May be I'm really not right? Interesting to hear any thoughts

[jengstrom]

Which part of the chain has a size limitation on PNG images?
Technically, the format has a very high limit on the dimensions, but I may be forgetting some limit in some tool or the hosting.

It's all PNG because it's lossless and packed reasonably compact.

Indeed it can usually be optimized, by removing color channel data from fully transparent areas, sometimes also by reducing color channel detail depending on how semi-transparent some areas of pixels are (e.g. shadows).

There might be better lossless compression in webp and such. If a change of image format is to affect the RE download for a user (and size of installed files), it must first be supported by the hosting. This means it would only be possible after the hosting has been updated, then Reason is released with those updates, then Reason Recon and a new RE SDK + build server support. Still might be worth looking into, if the size difference can be significant.

All REs built after hi-res came to the build pipeline include the graphics in the original resolution, in addition to the lo-res backward compatible files that were there before hi-res, and are still used if you run an earlier version of REs.

REs built before that download the same thing as an add-on (but are still small if downloaded using a version of Authorizer or Companion from before hi-res came to Reason).

So yes, hi-res REs are bigger.

[jam-s]

All REs built after hi-res came to the build pipeline include the graphics in the original resolution, in addition to the lo-res backward compatible files that were there before hi-res, and are still used if you run an earlier version of REs.

REs built before that download the same thing as an add-on (but are still small if downloaded using a version of Authorizer or Companion from before hi-res came to Reason).

As the old assets are still included wouldn't it be possible to use those for the 100% zoom level even in Reason 12? Right now the down scaled version that is used for the 100% zoom setting is usually a step backwards with respect to sharpness and detail compared to the R11 assets (also or especially so for the built-in devices).

[jengstrom]

@jam-s: That doesn't really make sense. The tool that creates the "old assets" from the original resolution, uses exactly the same image scaling algorithm as Reason. So the images should be identical. If you have a concrete example of where there is a noticeable difference, I would be interested in seeing it.

[Loque]

...

Maybe one thing to add the answer from jengstrom, the internal devices graphics were redesigned, because there were no hires graphics available. That could result in slightly different look. Also the font scaling was changed a little bit and i think the knobs were also redesigned and a lot of RE use default knobs. Maybe this is what yo are referring.

If not, than as jengstrom said, file a ticket with some concrete examples.

[turn2on]

I just touch interesting & actual question for PNG orientation today. When resolution is bigger, loading of bigger images in theory - slower.

1/ Design app talk that PNG format supports images with a maximum dimension of 32767 pixels. And cant create bigger dimension.
In MacOS Preview.app also cant resize PNG images bigger from 32767 px height. This is PNG limitations.

For example, this is my device knob, with this limitations. I need to scale it down more, for using with SDK.
https://disk.yandex.ru/i/URyx_Z-vCJ-1yw

So, for something big on the panel, with PNG dimension limitations, we need to make smaller quantity of filmstrip steps.

2/ Second situation (PNG vs WEBP):
4.79mb .PNG = 3.39mb .JPG 100% = 725 kb .WEBP 100%

If we get pack of the big images, from some big knobs, all panels, summary with PNG we have 25+ mb. How much we can economy with .WEBP in theory?
.WEBP also not have limitation for 40k+ px too.

3/ Fonts. On Mac & Window they looked not the same. May be support of WOFF (web fonts) also can help to use compressed quality fonts as pre-installed or opened for devs customisation? If pre-installed this is one question. If dev include in theory needed fonts in RE font folder, may be possible ways at installation moment, download this fonts to local place for using with Reason)

All this just a thoughts)

[jengstrom]

@turn2on:

1. Apps have different limitations for image size. The width/height limitation of the PNG format itself is in theory two billion pixels.

The limit you found at 32768 could be the limit in some image subsystem of macOS or something. Could be based on the max GPU driver texture size limit, as 32768 is a common number for that.

2. The lossless webp format is considered around 25% more compact than PNG on some average case, so there is something to gain there.

I don't think you want to use any lossy file formats for your design images. It would be visible as artifacts, and look more different depening on zoom levels. I don't think lossy formats support alpha/opacity channel. If any of them do, lossy alpha/opacity channel, or lossy color channels in alpha blended areas would look very bad in many cases.

3. It is difficult to make the fonts render the same on Mac and Windows. Reason uses the same font rendering stuff as Chrome and Firefox (Skia, SkShaper, Harfbuzz, GPU backend). Custom fonts per RE, rather than a host provided set is an interesting suggestion though.

[turn2on]

Thank You for this answers. You are right.
As I already said, this was been just a toughs. No real needs in webp.

I believe sometime in future we can have additional or custom fonts