Hey Jim, I had assumed the code was for still for MRI. And in that context EXIF would have made more sense. My bad. Sorry for the noise.
-hendrik > On Oct 24, 2015, at 02:29, Jim Graham <james.gra...@oracle.com> wrote: > > Hi Hendrik, > > The comment I was making was on the format of the command line arguments we > use to override DPI scaling and has nothing to do with image loading. > > You are correct that we don't really deal with the EXIF tags currently, but I > am not sure that they represent something we should be dealing with here. > The current effort is to normalize the size of UI elements on various > displays of different display resolution, but EXIF resolution tag processing > would be more of a pre-press feature of an image display and layout editor. > That goes a bit beyond the current effort... > > ...jim > > On 10/22/2015 11:56 PM, Hendrik Schreiber wrote: >> >>> The reason for this is both to have an explicit token for the regular scale >>> factor and also so that this matches with the default image suffix of "@2x" >>> so that we can add more ways to provide alternate media such as "@120dpi" >>> which are consistent with the values we use here. >>> >>> BTW, we need to discuss ways to automate loading alternate media beyond @2x >>> at some point… >> >> I’m not sure it’s practical, but has anybody every thought about using >> existing EXIF tags to determine image resolution? >> >> AFAIK, both JPEG and TIFF support EXIF tags >> (http://www.w3.org/2003/12/exif/) and thus embedding of resolution metadata >> (Labels: resolution, xResolution, yResolution, resolutionUnit). >> >> There could be another special tag @exif (or @native, to avoid being tied >> down to one particular way of embedding info), which basically means: check >> the embedded resolution info. >> >> -hendrik >>
