I've produced a few Bokeh output files as the result of a fairly time intensive process. It would be really cool to pull the plots together from their respective files and build a new output file where i could visualize them all in a column. I know I should have thought to do this earlier on before producing all the individual plots, but, alas, i did not.
Is there a way to import the preexisting figures so that I can aggregate them together into new multi-multi plot output file?
As of Bokeh 1.0.2, there is not any existing API for this, and I don't think there is any simple technique that could accomplish this either. I think the only options are: some kind of (probably somewhat fragile) text scraping of the HTML files, or distributing all the HTML files and using something like <iframe> to collect the individual subplot files into one larger view.
Going forward, for reference there is autoload_static that allows plots to be encapsulated in "sidecar" JS files that can be individually distributed and embedded, or there is json_item that produces and isolated JSON representation of the document that can also be individually distributed and embedded.
Related
I would like to use paraview for postprocessing of FE models. However, I am missing an essential feature in VKT format, which probably exists, but I don't know its name or how it is implemented in VTK.
In FE models it is common to group some nodes/elements. Depending on the program these are named differently: Groups, Sets, Selections, ... . Basically they are just an array with the reference numbers for quick selection. For example: A tube could have the selections "inlet", "outlet" and "wall". Is there any possibility to store such a selection in VTK format? The goal would be to be able to apply filters only to this node selection, for example to get results only from certain nodes.
By the way, I do the export of my calculated data to VTK on my own, because my FE program does not have native support for the VTK format. So I am more interested in the required data structure than in a workflow for program XY.
In VTK, you cannot apply filters only on subset of a data object. What you need is to be able to split your data into several ones for processing.
I see two ways for that:
create one object per selection and then use a MultiBlockDataSet with one part per block. Then you can use vtkExtractBlock to apply filters on a specific part.
Add a PartId array to your data. Then you can use thresholding to extract the region of interest.
I advise to use 1. as it has more semantic.
I wonder if there is an obvious and elegant way to add additional data to a jpeg while keeping it readable for standard image viewers. More precisely I would like to embed a picture of the backside of a (scanned) photo into it. Old photos often have personal messages written on the back, may it be the date or some notes. Sure you could use EXIF and add some text, but an actuall image of the back is more preferable.
Sure I could also save 2 files xyz.jpg and xyz_back.jpg, or arrange both images side by side, always visible in one picture, but that's not what I'm looking for.
It is possible and has been done, like on Samsung Note 2 and 3 you can add handwritten notes to the photos you've taken as a image. Or some smartphones allow to embed voice recordings to the image files while preserving the readability of those files on other devices.
There are two ways you can do this.
1) Use and Application Marker (APP0–APPF)—the preferred method
2) Use a Comment Marker (COM)
If you use an APPn marker:
1) Do not make it the first APPn in the file. Every known JPEG file format expects some kind of format specific APPn marker right after the SOI marker. Make sure that your marker is not there.
2) Place a unique application identifier (null terminated string) at the start of the data (something done by convention).
All kinds of applications store additional data this way.
One issue is that the length field is only 16-bits (Big Endian format). If you have a lot of data, you will have to split it across multiple markers.
If you use a COM marker, make sure it comes after the first APPn marker in the file. However, I would discourage using a COM marker for something like this as it might choke applications that try to display the contents.
An interesting question. There are file formats that support multiple images per file (multipage TIFF comes to mind) but JPEG doesn't support this natively.
One feature of the JPEG file format is the concept of APP segments. These are regions of the JPEG file that can contain arbitrary information (as a sequence of bytes). Exif is actually stored in one of these segments, and is identified by a preamble.
Take a look at this page: http://www.sno.phy.queensu.ca/~phil/exiftool/#JPEG
You'll see many segments there that start with APP such as APP0 (which can store JFIF data), APP1 (which can contain Exif) and so forth.
There's nothing stopping you storing data in one of these segments. Conformant JPEG readers will ignore this unrecognised data, but you could write software to store/retrieve data from within there. It's even possible to embed another JPEG file within such a segment! There's no precedent I know for doing this however.
Another option would be to include the second image as the thumbnail of the first. Normally thumbnails are very small, but you could store a second image as the thumbnail of the first. Some software might replace or remove this though.
In general I think using two files and a naming convention would be the simplest and least confusing, but you do have options.
I am going to build an interactive Choropleth map for Bangladesh. The goal of this project is to build a map system and populate different type of data. I read the documentations of the Openlayers, Leaflet and D3. I need some advice to find the right path. The solution must be optimized enough.
The map i am going to create will be something like the following http://nasirkhan.github.io/bangladesh-gis/asset/base_files/bd_admin_3.html. It is prepared based on leaflet js. But it is not mandatory to work with this library. I tried with Leaflet because it is easy to use and found the expected solution within a very short time.
The requirement of the project is to prepare a Choropleth map where i can display the related data. for example i have to show the population of all the divisions of Bangladesh. at the same time there should be some options so that i can show the literacy rate, male-female ratio and so on.
the solution i am working now have some issues. like the load time is huge and if i want to load the 2nd dataset then i have to load the same huge geolocation data, how can i optimize or avoid this situation?
Leaflet has a layers control feature. If you cut down your data to just what is required, split it into different layers and allow the user to select that layers they are interested in viewing that might cut down on the loading of the data. Another option is to simplify the shape of the polygons.
I'm trying to compare (for performance) the use of either dataURIs compared to a large number of images. What I've done is setup two tests:
Regular Images (WPT)
Base64 (WPT)
Both pages are exactly the same, other than "how" these images/resources are being offered. I've ran a WebPageTest against each (noted above - WPT) and it looks the average load time for base64 is a lot faster -- but the cached view of regular view is faster. I've implemented HTML5 Boilerplate's .htaccess to make sure resources are properly gzipped, but as you can see I'm getting an F for base64 for not caching static resources (which I'm not sure if this is right or not). What I'm ultimately trying to figure out here is which is the better way to go (assuming let's say there'd be that many resources on a single page, for arguments sake). Some things I know:
The GET request for base64 is big
There's 1 resource for base64 compared to 300 some-odd for the regular (which is the bigger downer here... GET request or number of resources)? The thing to remember about the regular one is that there are only so many resources that can be loaded in parallel due to restrictions -- and for base64 - you're really only waiting until the HTML can be read - so nothing is technically loaded than the page itself.
Really appreciate any help - thanks!
For comparison I think you need to run a test with the images sharded across multiple hostnames.
Another option would be to sprite the images into logical sets.
If you're going to go down the BASE64 route, then perhaps you need to find a way to cache them on the client.
If these are the images you're planning on using then there's plenty of room for optimisation in them, for example: http://yhmags.com/profile-test/img_scaled15/interior-flooring.jpg
I converted this to a PNG and ran it through ImageOptim and it came out as 802 bytes (vs 1.7KB for the JPG)
I'd optimise the images and then re-run the tests, including one with multiple hostnames.
Just have a question for anyone out there who knows some sort of game engine pretty well. What I am trying to implement is some sort of script or code that will allow me to make a custom game character and textures mid-game. A few examples would be along the lines of changing facial expressions and body part positions in the game SecondLife. I don't really need a particular language, feel free to use your favorite, I'm just really looking for an example on how to go about this.
Also I was wondering if there is anyway to combine textures for optimization; for example if i wanted to add a tattoo to a character midgame, is there any code that could combine his body texture and the tattoo texture into one texture to use (this way I can simply just render one texture per body.)
Any tips would be appreciated, sorry if the question is a wee bit to vauge.
I think that "swappable tattoos" are typically done as a second render pass of the polygons. You could do some research into "detail maps" and see if they provide what you're looking for.
As for actually modifying the texture data at runtime, all you need to do is composite the textures into a new one. You could even use the rendering API to do it for you, more than likely; render the textures you want to combine in the order you want to combine them into a new texture. Mind, doing this every frame would be a disoptimization since it'll be slower to render two textures into one and then draw the new one than it would be just to draw the two sources one after the other.