quality of exported image

[ksobon]

I have a rather large definition and exported image is unfortunately not big enough making the nodes unreadable (pixelated). Maybe we can add additional input for quality or figure out a way to make sure that when images are exported they are large enough that can be read later.

[mdahlhausen]

@ksobon
The issue with large files is that the pan/zoom is really slow and unresponsive. It can freeze the client.
Options are:

1. let it be slow and unresponsive, and crash the browser

2. disabling pan/zooming for large files

3. link to a file sharing website so people can download it and view it that way

4. break up the image into sections and view each separately when zoomed
   Any other ideas?

5. is probably the best, but would take some work.

[mostaphaRoudsari]

If I remember right @chriswmackey made a limitation for the size but still the images from Grasshopper canvas are pretty high resolution and readable.

I like the approach number 4. If we figure out the exact maximum size we can break up larger images into a grid of images and let the user slide between them.

[alfarok]

Just to get the node working I used the built in method Dynamo uses for the screenshot but I am in the process of trying to rewrite this for both the 3D background preview and canvas. I need to revisit the Grasshopper component and see how Chris went about it as well.

[chriswmackey]

@mostaphaRoudsari , @mdahlhausen , @ksobon , and @alfarok ,

I put in a max size to the image of the GH canvass to stop my personal browser from crashing but I realize that everyone's browser and system is a bit different and it's hard to make a "one size fits all" script this way.

@mdahlhausen ,
What would it take to get 4) to work? Would you need the different portions of the image exported as separate images from the component? If so, I can plan to implement this soon.

-Chris

[mdahlhausen]

@chriswmackey yep just split the image into different portions, and we can scroll through them on the viewer.

This will help a bit, but I still expect some issues. I'm thinking maybe disabling the pan/zoom is a better option, and just including a note that it was disabled because the file was too big might be a better fix. That way we know we won't crash the client. And is a user wants to pan/zoom, they can download the image. We can try both.

[chriswmackey]

@mdahlhausen ,
You know a lot more about how the viewer works than I do so I trust your judgement. Would you need a smaller version of the canvas image exported in order to disable the pan/zoom? I so, I can do that soon. In this case, we should refine the value at which the canvas is considered too big.

Right now, I think that we all agree that this one is too big:
http://hydrashare.github.io/hydra/viewer?owner=NENEN&fork=hydra&id=Armature_for_Energy-Positive_Building_Experiment

Is this one too big?
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map

-Chris

[mdahlhausen]

@chriswmackey I think they both are; the first one crashed my client, and the second one is really sluggish. And I've got a pretty heavy duty pc. I'm reconsidering splitting the image. I don't think it will help the problem; it'll scale by the number of times we break up the image, but we need an order of magnitude reduction (or several) in image size.
I think we should stick with what we have implemented - a maximum size for the client. The quick fix is to add a disclaimer next to the download button that images have been compressed to make them viewable, and if they want the full size image, they can download it on the github fork for that example from a link.
I'm wondering if we need client side compress pre-rendering to make sure it is small enough, or at least to support the broken examples now.

[chriswmackey]

@mdahlhausen ,
Understood. I feel like the best implementation would just involve the upload of a lower-res image of the canvass for large files (similar to what I do for the thumbnail image but more strategic in its size). If you give me a maximum size in pixels, I will write a function to meet it an I will throw the very large higher-res image into the zip folder with the download.
-Chris

[mdahlhausen]

@chriswmackey let's cap it at 2 million pixels. It really should be smaller for mobile devices, about a half million pixels. I think we can program the logic about what size to display into the webpage, but for now lets go with the larger cap. For reference, your outdoor microclimate map grasshopper image is ~75 million pixels and ~4 MB.