iTunes 9.1.1 and artwork
in [UK Mac]
|
From: Jaimie Vandenbergh on 14 May 2010 09:09 On Fri, 14 May 2010 13:37:26 +0100, real-address-in-sig(a)flur.bltigibbet.invalid (Rowland McDonnell) wrote: >Jaimie Vandenbergh <jaimie(a)sometimes.sessile.org> wrote: > >> peter(a)cara.demon.co.uk (Peter Ceresole) wrote: >> >> >Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: >> > >> >> Thing is, I'm viewing it in coverflow view. >> > >> >Well, it might have helped to know that. >> >> Aye. > ><shrug> It hadn't occurred to me that anyone would be looking at the >artwork using the awkward pop-up thingy. > >I've never seen a use for it and had forgotten that it existed. My normal use case is to have a Finder in columns view on one side of the screen, and a quickview with the content on the other - then arrow up/down through them. >> And occasionally I find that the initial preview extra-low-res image >> doesn't ever get updated to the normal res image (or at least not >> before getting bored and moving on to another image). This happens in >> Finder's coverflow too, so it seems to be a Coverflow general problem. > >Surely the two coverflow versions are unrelated except by name? Surely not - code reuse is the big new thing in programming, I hear. > The >function is different in each case - iTunes coverflow displays an image >that's been attached to the file explicitly, while Finder coverflow >displays an image that's worked out on the fly (in the general case). >And iTunes does it to show you the album cover (what you might call >`human metadata), while the Finder does it to remind you of the file >contents (not the metadata at all). > >The appearance is similar, and the name's the same, but the function is >not. Each Coverflow window renders picture data that it is fed by another source (Finder, iTunes) into a swishy sideways flow. Same thing. The origin and human purpose of that picture data is irrelevant to the Coverflow code. Cheers - Jaimie -- "... you must remember that if you're trying to propagate a creed of poverty, gentleness and tolerance, you need a very rich, powerful, authoritarian organisation to do it." - Vice-Pope Eric
From: Rowland McDonnell on 14 May 2010 09:13 Jim <jim(a)magrathea.plus.com> wrote: > Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > > > >> >I never use coverflow, so it > >> >may well be different. I just had a look. In fact the image is heavily > >> >processed; not surprisingly it is visibly much softer. Rather what you > >> >might expect. > > > > Eh? Why should anyone expect a lower quality image in coverflow? No > > sane reason at all that I can think of. > > I'm guessing, but I wouldn't be surprised to find that Coverflow does a > very, very quick'n'dirty rendering. Why? >It's potentially got lots of images to > draw and animate on the fly so it needs to keep the processing time for each > individual image down as low as it can. But the graphics processing ability of a modern Mac is staggeringly huge. That argument would cut ice back in the days of - perhaps - anything up to a decent G4 machine; let's all recall that the original Macs couldn't even do `live window dragging' but had to display window outlines only on dragging rather than window contents. The first PPC Macs could do live window dragging (ISTR that my 25MHz 680LC40 Performa 475 was happy doing it, too, when I upgraded to whatever). And now? An iPod can animate a coverflow display at low res - but a modern desktop Mac with its super-powerful super-fast super-wide multiple CPU cores and super-powerful (ditto) huge capacity graphics card and staggeringly high bandwidth everything should have no trouble animating the display at full resolution. Nor should there be any problem displaying a full res version once the movement stops - much as you see with lossily-compressed video (particularly with the BBC iPlayer, which is notably bad for the display breaking up when high bandwidth is required). Maybe the full res display would be reserved for Intel multiple-core Macs - but I've got one of them. Two 64 bit wide 3 GHz CPU cores for heaven's sake, and never mind the beefy graphics card I had fitted! There is adequate processing power available to do what's needful at decent res without much bother, I'd've thought. Rowland. -- Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
From: Rowland McDonnell on 14 May 2010 09:21 Jaimie Vandenbergh <jaimie(a)sometimes.sessile.org> wrote: > real-address-in-sig(a)flur.bltigibbet.invalid (Rowland McDonnell) wrote: > > >Jaimie Vandenbergh <jaimie(a)sometimes.sessile.org> wrote: > > > >> peter(a)cara.demon.co.uk (Peter Ceresole) wrote: > >> > >> >Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > >> > > >> >> Thing is, I'm viewing it in coverflow view. > >> > > >> >Well, it might have helped to know that. > >> > >> Aye. > > > ><shrug> It hadn't occurred to me that anyone would be looking at the > >artwork using the awkward pop-up thingy. > > > >I've never seen a use for it and had forgotten that it existed. > > My normal use case is to have a Finder in columns view on one side of > the screen, and a quickview with the content on the other - then arrow > up/down through them. But I was talking about iTunes and had just mentioned its pop-up artwork display. Why talk about your Finder display in response to that? > >> And occasionally I find that the initial preview extra-low-res image > >> doesn't ever get updated to the normal res image (or at least not > >> before getting bored and moving on to another image). This happens in > >> Finder's coverflow too, so it seems to be a Coverflow general problem. > > > >Surely the two coverflow versions are unrelated except by name? > > Surely not - code reuse is the big new thing in programming, I hear. But the job's different - the data comes from a different source and is pre-processed for display using a different method entirely. That's what I saw when looking at it. The similarity of display is neither here nor there from the point of view of the full function in each case. > > The > >function is different in each case - iTunes coverflow displays an image > >that's been attached to the file explicitly, while Finder coverflow > >displays an image that's worked out on the fly (in the general case). > >And iTunes does it to show you the album cover (what you might call > >`human metadata), while the Finder does it to remind you of the file > >contents (not the metadata at all). > > > >The appearance is similar, and the name's the same, but the function is > >not. > > Each Coverflow window renders picture data that it is fed by another > source (Finder, iTunes) into a swishy sideways flow. Same thing. Ah. Mmm. And how was I to know that? *I* didn't know that's all that the coverflow code did. I looked at coverflow views in two different apps and saw two different functions - the fact that the data is displayed using a similar form didn't strike me as significant. I had assumed that Apple would have slapped similar code to do the job in each app - the Finder and iTunes. Re-use at compile time rather than using an OS-supplied code library. I'd not trust anything like that to work unless it were coded into the app. Then again, I don't trust my Mac to work, do I? > The > origin and human purpose of that picture data is irrelevant to the > Coverflow code. But I don't see why ANY of that means we should get a low-res view in iTunes! btw, the human purpose of the data is the sole reason for having data on a computer, and the origin and destinations of the data are both central to that purpose. So I have to say the `machine' point of view of this as expounded by you has no correspondence with the human - i.e., my - point of view. Rowland. -- Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
From: Woody on 14 May 2010 09:28 On 14/05/2010 13:45, Jim wrote: > On 2010-05-14, Rowland McDonnell<real-address-in-sig(a)flur.bltigibbet.invalid> wrote: >> >>>> I never use coverflow, so it >>>> may well be different. I just had a look. In fact the image is heavily >>>> processed; not surprisingly it is visibly much softer. Rather what you >>>> might expect. >> >> Eh? Why should anyone expect a lower quality image in coverflow? No >> sane reason at all that I can think of. > > I'm guessing, but I wouldn't be surprised to find that Coverflow does a > very, very quick'n'dirty rendering. It's potentially got lots of images to > draw and animate on the fly so it needs to keep the processing time for each > individual image down as low as it can. To use the image in coverflow it has to have a geometric transformation applied to it in both size and shape. The iTunes artwork window just displays the image as it is if it can fit in the screen (which it normally can as album artwork is mostly small). The coverflow artwork therefore going to seem more compressed, as it is. And yes, the code that does the coverflow on both finder and iTunes is the same, it is a private framework that apple use in ImageKit. -- Woody
From: Rowland McDonnell on 14 May 2010 09:32
Woody <usenet(a)alienrat.co.uk> wrote: > Jim wrote: > > Rowland McDonnell<real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > >> > >>>> I never use coverflow, so it > >>>> may well be different. I just had a look. In fact the image is heavily > >>>> processed; not surprisingly it is visibly much softer. Rather what you > >>>> might expect. > >> > >> Eh? Why should anyone expect a lower quality image in coverflow? No > >> sane reason at all that I can think of. > > > > I'm guessing, but I wouldn't be surprised to find that Coverflow does a > > very, very quick'n'dirty rendering. It's potentially got lots of images to > > draw and animate on the fly so it needs to keep the processing time for each > > individual image down as low as it can. > > To use the image in coverflow it has to have a geometric transformation > applied to it in both size and shape. Yes, one that is quick and easy to apply via the graphics card, am I right? > The iTunes artwork window just > displays the image as it is if it can fit in the screen (which it > normally can as album artwork is mostly small). Album artwork I have was - most of it - meant to be displayed on a 12" LP sleeve and is therefore mostly large. What do you mean when you say album artwork is mostly small? I use often 1200dpi scans when I scan in my own CD covers, for example (although I've used 600dpi and 300dpi). > The coverflow artwork > therefore going to seem more compressed, as it is. Why should it appear any different to the same image displayed at the same size by any other app? When stationary, that is? > And yes, the code that does the coverflow on both finder and iTunes is > the same, it is a private framework that apple use in ImageKit. When you say `does coverflow', you're talking about the code that runs the imaging on the UI, rather than the code that does the full job. Which machine-based point of view is confusing for those of us who automatically think of software from the point of view of the user. Rowland. -- Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking |