Treat "images" as nested collection of a style, like sources or layers #4085
Comments
|
From @incanus on November 20, 2014 2:41 Is this speaking strictly to the storage format, or mechanism for use in GL, or both? Keep in mind that per mapbox/mapbox-gl-native#507 we will need to support arbitrary imagery for points and other annotations on the map in a rapidly-changing sprite. This could be (and probably should be) separate from the style but a similar approach could be used. |
|
From @jfirebaugh on November 20, 2014 2:44
Both, I think -- not sure what you mean by "mechanism for use in GL". |
|
From @ljbade on November 20, 2014 8:37 On Android we can have more than just 1x and 2x, Android supports 0.75, 1, 1.5, 2, 3 and 4x screen densities. |
|
From @mikemorris on November 20, 2014 16:44 I'd definitely be in favor of keeping the actual image assets out of the stylesheet, simply for ease of editing the style and updating the images separately. Let's figure out some sort of extensible spec for sprite protobuf containers, perhaps with a |
|
From @incanus on November 20, 2014 19:15
I mean both the preparation & storage in a sprite as well as the use of a single sprite bound to a texture unit. Mostly that we can think about multiple sprite sheets, since we'll likely need a rapidly changing one for more open/dynamic imagery. |
|
From @ljbade on November 20, 2014 20:8 @incanus, oh so you mean have the ability encode sprites in a texture atlas, e.g. contiguous pixel data, but then have a seperate 'structure' index that says sprite i is found at pixels x, y + size of sprite? @mikemorris, yeah make ratio a float and just choose the sprite closest to what the system says is needed |
|
From @jfirebaugh on November 20, 2014 22:19 This ticket is about storage format. In memory representation is a separable concern. In js we'll use a sprite atlas like native already uses and copy image data from its storage representation. |
|
From @incanus on November 21, 2014 0:12
👍 FYI what I'm talking about is this, but agree that an in-memory representation will probably be what we use directly in these cases: |
|
From @kkaefer on November 24, 2014 12:25 @jfirebaugh I agree with your proposal. The two ways you suggest are almost equal; both require special parsing and generation routines. However, I'd opt for the first (separate protobuf container) instead of encoding the information into the PNGs (e.g. as separate data sections). While it would have the advantage of being able to view the sprite, the disadvantage is that it may tempt users into quickly "updating" the image with a graphics program, without realizing that they also have to update the included metadata. Instead, we should follow a Maki-style approach of having a folder full of icons/SVG images, and write a small tool that produces sprite PBFs. |
|
From @kkaefer on December 9, 2014 10:43 Implemented a first draft in https://github.com/mapbox/spritenik |
|
From @kkaefer on December 9, 2014 10:49 Issue with embedding data into PNG images is also that there are proxies out there which process/shrink images (e.g. my mobile phone provider does that), which would potentially remove embedded information. Using JSON to store Base64 images would add double compression (compressed data inside base64 images, and another layer of compression on the actual JSON file in transfer) and parsing in the browser will become trickier. |
|
From @jfirebaugh on February 4, 2016 20:1 I think we should:
|
|
From @ansis on February 4, 2016 20:17
Would there be different styles for different device pixel ratios? |
|
From @jfirebaugh on February 4, 2016 20:26 Multi-resolution support is TBD. But for starters, I think we could have Mapbox APIs always serve styles containing |
|
From @scothis on February 4, 2016 20:30
If we make inlining optional, we can preserve a link to the icons resource that can be loaded resolution independent, or with a new images format. There are advantages to inlining and externalizing depending on the circumstance. |
|
From @ansis on February 4, 2016 21:11
This would kill pixel snapping for icons for 1x devices, which could be ok, but could also make icons too blurry at that size and resolution. 2x icons on 1x device: 1x icons on 1x device: |
|
From @mourner on February 4, 2016 21:17 Would images for patterns (fill textures etc.) also be called icons? |
|
From @jfirebaugh on February 4, 2016 21:29 @mourner Good point -- the terminology should be consistent within the rendering property names as well. How about: |
|
From @jfirebaugh on February 4, 2016 21:53 Thoughts on pixel ratios:
|
|
From @1ec5 on November 17, 2016 3:18 …should image sources be called something else? 🤔 We have raster layers and raster sources; seems like style images and image sources could coexist at least as well. How would you describe the difference between the two? Reusable images versus georeferenced images? |
|
Raster layers consume raster sources. That makes sense 👍. Image sources would not relate to "images" (by some definitions of the thing). That makes a less sense to me. |
|
We could continue to call these new things "sprites" though we change how sprites are specified. |
From @jfirebaugh on November 20, 2014 2:17
We want something more convenient than the current automagical practice of appending permutations of
.json,.png, and@2xto thespriteproperty and making requests to two separate resources which need to be in sync.Options that have been proposed:
@mapbox/gl
Copied from original issue: mapbox/mapbox-gl-style-spec#220
The text was updated successfully, but these errors were encountered: