Hi,

you could get it via:


Typically at least 4096x4096 and higher - with some exception for some very old systems, there 2048x2048 is the maximum.

Best regards,
Klaus

Trigonometry is your friend:
https://en.wikipedia.org/wiki/Trigonometry

But generally it's a trade-off depending on what you want to achieve - sharpness on all edges or getting all pixels/details.

Here two possibilities:


You could also use a mixture of both.
For very small fov values they would be very similar,
and for very large fov values there would need to a special solution (e.g. slowly limit the size) otherwise the image would become too large.

Hi
where can I to find documentation how I can make take screenshots at higher resolution than displayed on the screen.
Using The new krpano.webGL.makeScreenshot ?
Ramiro

Does it has any sense to make an image bigger than the canvas, isn't it interpolating anyway a part from original image size ?

In the case of multires, can it create the image from unloaded levels ?

I have succesfully generated a 4096 * 4096 image but maxsize is supossed to be 4x times = 16384, working on a simple mac mini

I just checked what happened after 4096 and is just de 4096 pixels and the rest is transparent.

Hi,

Zitat von »jordi«

Does it has any sense to make an image bigger than the canvas, isn't it interpolating anyway a part from original image size ?

The image will be new rendered with the given resolution, it's not a scaling of the current screen.

Zitat von »jordi«

In the case of multires, can it create the image from unloaded levels ?

It can only use the current loaded files.
Loading new images would require time (and mem) and also would need to be async.

If you want to make 'screenshots' with a tiles from a higher res, you could try that:

1. set image.multiresthreshold to a higher value
   
2. set memory.maxmem to a higher value (all tile pixels should fit into it, mem = width * height * 4)
   
3. wait for the next onloadcomplete event
   
4. then make the screenshot call
   
5. and restore all settings
   

Zitat von »jordi«

I just checked what happened after 4096 and is just de 4096 pixels and the rest is transparent.

That means the browser returns a wrong value for MAX_RENDERBUFFER_SIZE.
That size is probably passed through from the systems OpenGL API, and during real rendering the browser is limiting the size.

Here the related Safari bug:
https://bugs.webkit.org/show_bug.cgi?id=178223

Best regards,
Klaus

Zitat von »klaus.krpano«

The image will be new rendered with the given resolution

that is very good ! and make difference with my previous version where the image was created from the canvas itself not a new render !

Zitat von »klaus.krpano«

make 'screenshots' with a tiles from a higher res, you could try that

I'm gonna try it. I've been testing that not using the preserveDrawingBuffer it's also generating the image. Could be dynamically toggle this attribute ? that would help keeping performance.

Zitat von »klaus.krpano«

That means the browser returns a wrong value for MAX_RENDERBUFFER_SIZE

this was what I thought, so basically it's a unknown value, having in mind that 4096 would be mostly doable in all desktops

Zitat von »klaus.krpano«

Here the related Safari bug

What I was trying was using chrome not safari.

Thanks for the info

Hi,

Zitat von »jordi«

that is very good ! and make difference with my previous version where the image was created from the canvas itself not a new render !

Just as note - because it's a new rendering, it would be also possible to change the view settings (e.g. hlookat/vlookat) directly before calling makeScreenshot and then after that restoring it again to make screenshots of pano areas different to the current screen view - but with one limitation - only the currently loaded tiles can be used for the rendering, so when making a screenshot of a part where no tiles are in memory yet, there might be only the preview pano to render.

Zitat von »jordi«

I'm gonna try it. I've been testing that not using the preserveDrawingBuffer it's also generating the image. Could be dynamically toggle this attribute ? that would help keeping performance.

I've noticed that too - it seems the latest browser versions don't require preserveDrawingBuffer=true anymore (I don't know when this was changed). Dynamically toggling preserveDrawingBuffer is technically not possible. But in the next release there will be also a possibility for screenshots without the need for preserveDrawingBuffer=true even when the browser would normally require it.

Zitat von »jordi«

this was what I thought, so basically it's a unknown value, having in mind that 4096 would be mostly doable in all desktops

In this next release the image-size will be automatically proportionally downscaled to the maximum possible size supported/reported by the browser.

Best regards,
Klaus