{"action":"created","issue":{"url":"https://api.github.com/repos/FLIF-hub/FLIF/issues/17","repository_url":"https://api.github.com/repos/FLIF-hub/FLIF","labels_url":"https://api.github.com/repos/FLIF-hub/FLIF/issues/17/labels{/name}","comments_url":"https://api.github.com/repos/FLIF-hub/FLIF/issues/17/comments","events_url":"https://api.github.com/repos/FLIF-hub/FLIF/issues/17/events","html_url":"https://github.com/FLIF-hub/FLIF/issues/17","id":109609135,"number":17,"title":"Metadata (EXIF, color profiles, etc etc)","user":{"login":"FLIF-hub","id":1098969,"avatar_url":"https://avatars.githubusercontent.com/u/1098969?v=3","gravatar_id":"","url":"https://api.github.com/users/FLIF-hub","html_url":"https://github.com/FLIF-hub","followers_url":"https://api.github.com/users/FLIF-hub/followers","following_url":"https://api.github.com/users/FLIF-hub/following{/other_user}","gists_url":"https://api.github.com/users/FLIF-hub/gists{/gist_id}","starred_url":"https://api.github.com/users/FLIF-hub/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/FLIF-hub/subscriptions","organizations_url":"https://api.github.com/users/FLIF-hub/orgs","repos_url":"https://api.github.com/users/FLIF-hub/repos","events_url":"https://api.github.com/users/FLIF-hub/events{/privacy}","received_events_url":"https://api.github.com/users/FLIF-hub/received_events","type":"Organization","site_admin":false},"labels":[{"url":"https://api.github.com/repos/FLIF-hub/FLIF/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/FLIF-hub/FLIF/labels/metadata","name":"metadata","color":"fad8c7"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/FLIF-hub/FLIF/milestones/1","html_url":"https://github.com/FLIF-hub/FLIF/milestones/M2%20-%20FLIF16%20tools%20and%20metadata%20stuff","labels_url":"https://api.github.com/repos/FLIF-hub/FLIF/milestones/1/labels","id":1355916,"number":1,"title":"M2 - FLIF16 tools and metadata stuff","description":"First \"convenient to use\" release, ready to be included in image viewers, image editors, web browsers etc.\r\n\r\nAlso good support for metadata, photography (camera raws, e.g. DNG) and medical images (very high res, tiles, DICOM).","creator":{"login":"jonsneyers","id":15010068,"avatar_url":"https://avatars.githubusercontent.com/u/15010068?v=3","gravatar_id":"","url":"https://api.github.com/users/jonsneyers","html_url":"https://github.com/jonsneyers","followers_url":"https://api.github.com/users/jonsneyers/followers","following_url":"https://api.github.com/users/jonsneyers/following{/other_user}","gists_url":"https://api.github.com/users/jonsneyers/gists{/gist_id}","starred_url":"https://api.github.com/users/jonsneyers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jonsneyers/subscriptions","organizations_url":"https://api.github.com/users/jonsneyers/orgs","repos_url":"https://api.github.com/users/jonsneyers/repos","events_url":"https://api.github.com/users/jonsneyers/events{/privacy}","received_events_url":"https://api.github.com/users/jonsneyers/received_events","type":"User","site_admin":false},"open_issues":26,"closed_issues":7,"state":"open","created_at":"2015-10-14T18:20:51Z","updated_at":"2016-07-12T13:20:10Z","due_on":"2016-10-31T23:00:00Z","closed_at":null},"comments":29,"created_at":"2015-10-03T08:17:36Z","updated_at":"2016-08-21T17:28:06Z","closed_at":null,"body":"I have the following idea on how to add support for metadata:\r\nA FLIF file is either a \"bare\" image file, or it is actually a .tar (or some other archive format) which contains files with standardized names, e.g. _image.flif, _meta.gz, _colorprofile.gz, browser_hints.gz. This would make it easy to add arbitrary information (just add a custom file to the archive) and manipulate or remove the metadata.\r\n\r\nSo basically the .flif file would only contain the information needed to decode the pixels, and anything else (including information on how to interpret the pixel values, like gamma etc) would be in those optional extra files.\r\n\r\nWould that be a good idea?\r\n"},"comment":{"url":"https://api.github.com/repos/FLIF-hub/FLIF/issues/comments/241270201","html_url":"https://github.com/FLIF-hub/FLIF/issues/17#issuecomment-241270201","issue_url":"https://api.github.com/repos/FLIF-hub/FLIF/issues/17","id":241270201,"user":{"login":"haasn","id":1149047,"avatar_url":"https://avatars.githubusercontent.com/u/1149047?v=3","gravatar_id":"","url":"https://api.github.com/users/haasn","html_url":"https://github.com/haasn","followers_url":"https://api.github.com/users/haasn/followers","following_url":"https://api.github.com/users/haasn/following{/other_user}","gists_url":"https://api.github.com/users/haasn/gists{/gist_id}","starred_url":"https://api.github.com/users/haasn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/haasn/subscriptions","organizations_url":"https://api.github.com/users/haasn/orgs","repos_url":"https://api.github.com/users/haasn/repos","events_url":"https://api.github.com/users/haasn/events{/privacy}","received_events_url":"https://api.github.com/users/haasn/received_events","type":"User","site_admin":false},"created_at":"2016-08-21T17:28:06Z","updated_at":"2016-08-21T17:28:06Z","body":"> An application shouldn't need to make many small reads to walk a chain of metadata segments to find the overall length of metadata nor to find a particular metadata segment.\r\n\r\nA valid point, although I'm not sure how relevant this concern is for FLIF - we're building an image format, not a general purpose archive format. I wouldn't expect metadata to be very large, and the entire header should almost always easily fit into L1 cache either way. A few indirections in here are almost surely not worth losing sleep over.\r\n\r\n> - How will multi-dimensional science data be handled?  A deeply structured FLIF segment or a container format that allows rich metadata and multiple FLIF segments for elements of the multi-dimensional image space?\r\n\r\nI personally think this is somewhat out of scope for an image format. If you need some sort of complex multi-dimensional embedding for science data, I would try to approach that with a dedicated special-purpose format that might use flif (or png) images internally. The more simple an image format is, the more likely it is that people will have no objections to adopting it. I can imagine a browser vendor feeling queasy about pulling in support for an image format that requires some sort of complicated support for arbitrary numbers of dimensions and whatnot, whereas supporting something that's essentially PNG in disguise would almost certainly be noncontroversial. (and given PNG and JPEG's massive popularity due to their use on the web, this should definitely be a goal if we want the image format to ever be used in practice)\r\n\r\n> - You should consider metadata encoding support such as zlib compression, whether per segment or for an entire contiguous metadata block.\r\n\r\nI think this should be done on a per-chunk basis, never on a entire metadata basis. Most chunks are very small, usually just providing a few integers. For larger stuff like `iCCP` it would be worth compressing just that chunk, and only if it's necessary. But I wouldn't try to do some sort of cross-chunk compression at all, especially since it gives rise to the classic `.tar.gz` seeking problem that you were also concerned about.\r\n\r\n> - You should consider padding to allow for in-place editing of metadata segments without having to relocate everything else in the file every time.\r\n\r\nIt might be a good idea to have this on a per-chunk basis too, since most chunks are almost surely going to be either small or fixed-size. For example, an `iCCP` chunk's contents could start off with a integer specifying the length of the actual ICC profile. From the point of view of the FLIF container (and tools that don't care about parsing ICC profiles) this would be completely irrelevant.\r\n\r\nIt might be a good idea to add this explicitly to e.g. `tEXT`, `eXIF` and `iCCP` - but I wouldn't make it a part of the skeleton itself."}}
{"actor":{"display_login":"haasn"}}