Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Daydream]

I have some question about how thumbnails work in MC; any help is greatly appreciated:

1) In Theatre view is the space between the areas encompassing the thumbnails + name (what you perceive as the space between thumbnails) hardcoded as far as size?

2) Is the effect applied to thumbnails (drop shadow), the intensity of the effect, and the shape of the effect hardcoded (in all views)? If yes, can we have instead some options here (it's somewhat related to the next question)?

3) Are all thumbnails, internally, JPEG? Can they be anything else? Would that affect speed? I mean if I import a cover that's not a JPEG, the version that gets saved in my designated folder for covers it is a JPEG, losing any additional properties. In other words you can't do transparency and work with PNG alone.

Many thanks.

[JimH]

On 1, try adjusting the scaling for Theater View.  It's set to 100%, but try 130%.  I'm not sure it will work.

On 2 & 3, all thumbnails are stored together in single files, once for small size of thumbnail, once for medium, and once for large.  Not sure whether they're jpg.  I think maybe png.  But you can't adjust anything on these files.  You can use the slider in standard view (upper right).

The thumbnails are here in Vista:
C:\Users\[User]\AppData\Roaming\J River\Media Center 13\Thumbnails

On XP, they are in Documents and Settings.

[Daydream]

On 1, try adjusting the scaling for Theater View.  It's set to 100%, but try 130%.  I'm not sure it will work.

Thank you, I missed that. Indeed it pushes things in some interesting directions.

On 2 & 3, all thumbnails are stored together in single files, once for small size of thumbnail, once for medium, and once for large.  Not sure whether they're jpg.  I think maybe png.  But you can't adjust anything on these files.  You can use the slider in standard view (upper right).

I don't know what to think here. It looks like there's a different behavior between video files with thumbnails internally made (at import/scan time), and the ones where covers have been added manually. Internally made ones are indeed stored in the 3 files you mentioned (untouchable). Externally added one are (in addition to database?) added to the folder specified in File Location - Cover Art - "In specified folder" settings. What gets added to the specified cover art folder is always JPG, regardless of the original format.

So, as a dirty hack, I replaced the saved covers with PNG files with transparency and kept the extension as jpg (nuts, I know). Chose one more time "Quick Find in File \ Cover art directory" option and... the transparency popped up... to some degree (screenshot 1). Not exactly what I wanted which would be the second screenshot below (Photoshop makeover, not a real one).



Things got a bit even more interesting in Theatre View. This is not Photoshop.



The big cover starts with visible corners but by the end of the animation appears with real transparency and remains that way until I move to the next movie. Of course that being a 3D element (I guess a parallelepiped), it has depth, so depending on the direction of the animation one might see some rendered parts (corners) without support.

Maybe it's a direction worth exploring, to add to the "cool" aspect (if it doesn't brake any of the current features).

[darichman]

Just wondering, where do you get your coverart from Daydream?
The rounded edges are pretty

[Daydream]

IMP Awards, same as you . Otherwise wildly browsing the net if it's something rare.
The problem is that the covers on IMP Awards respect the proportions of a real poster while the other covers one might find online are made for media cases (DVD, Blu-Rays, etc). There's a visible difference in height/width proportions if you don't get everything from the same source...

The rounded corners are automated with an action in Photoshop. However it's a bit tricky, the "roundness" is different (more pronounced) if you have a lower resolution cover. I've no idea if they can be made to appear like that with an overlay from within MC.

[darichman]

IMP Awards, same as you . Otherwise wildly browsing the net if it's something rare.
The rounded corners are automated with an action in Photoshop.

Ah, I see. You can get some good ones at http://www.movieposterdb.com/ as well (although the site is down this weekend) if you haven't checked it out
I'm a bit of an amateur at Photoshop. Will have to have a look.

[Matt]

Thumbnails are stored as JPEG data, and transparency is replaced with a checkered background (like an image editor).

If the full image is loaded (like in the info panel of Theater View), transparency will be supported.

[Daydream]

True and true.

However this only happens after messing with files and extensions. By default MC turns everything into JPEG, and expects everything to have a jpg extension (even the external covers). So, to sum this up I was wondering if there's a way to get better support for PNG (say, leaving an external PNG cover as PNG, and having it as the first choice to display, not the database stored JPEG).

Just thinking out loud here, the implications may be more important and unknown to me.

[hit_ny]

Curious as to why you would use PNGs instead of JPG for cover art ?

[JimH]

Matt says they are jpg.

[Daydream]

Curious as to why you would use PNGs instead of JPG for cover art ?

For transparency (see screenshots above) which is a feature that JPG doesn't support. With that and some skills in Photoshop or the likes you can make your own rounded thumbnails or, generalizing, freeform thumbnails. Which is a thing I don't think I've seen in any other MC app. But I'm just the guy with the graphic tablet and crazy ideas.

[hit_ny]

Is it not possible to save these effects as a jpg file then ?

As you might have suspected, i'm not all that strong with the graphics side of things 

Looking at your grabs, which are pretty btw, i'm seeing less the transparency you alluded to than beveled edges with shadows.

[Daydream]

Oh man...
No, you can't do transparency with a lossy format like JPG, or with any other lossy format for that matter. In layman terms you pick something, say a color, and choose it to be transparent; or store alpha information; or whatever. With a lossy format the return of any of these values is random depending on a million of things. So it can't be done, therefore it's not in the specs. It's a whole different matter with PNG which is a lossless format and will return the same values for every pixel whatever you do with it.

What you see in my caps is not what you think. Those thumbnails are SQUARE thumbnails. You don't see the corners because the corners are transparent. I can just as well make a 1 inch hole in every thumbnail and you'll see the background through it.

[hit_ny]

It's a whole different matter with PNG which is a lossless format

Just thinking out loud here, the implications may be more important and unknown to me.

I'm thinking increased storage reqmts for the cached thumbnails as well as performance hit as they are what you see when browsing.

What's the size factor difference for PNG vs JPG ?

If its 3 and above, it would be a sizeable difference.

From that pov, maybe they have chosen the best possible under the circumstances.

[Daydream]

That's indeed the research direction, and I can only speculate.
My thumbnail database is, I don't know 1.5GB (music, video, pictures). Size related I don't care if it's 5GB or 10 GB, these are times when TBs rule.

How are the thumbnails cached? I've no idea, but I can say from a certain angle that a decompressed picture takes just as much memory regardless if it's JPG or PNG. The speed of decoding might be a problem (PNG requires more power), that's where we weight the averages and see if it affects the experience of not. I could make some educated guesses but in principle I defer to JRiver who would know best indeed.

Sure one can come up with with alternative solutions that at least on paper look promising. Like creating an overlay mask that will determine the transparency area and superimpose it over the original JPG thumbs. That's kinda done already for some other elements.

[hit_ny]

That's indeed the research direction, and I can only speculate.
My thumbnail database is, I don't know 1.5GB (music, video, pictures).

They have no way of knowing what those thumbs are for but they have to pick a format which works for anything. You can't have either or it has to be just the one. Thats why its called a cache, otherwise there is no need for it. The direction over the last few years has been towards speeding up display time and its fair to say it put them ahead of the pack by a decent margin

You can boil it down to pretty and fast vs. awesome and slow(er).

Which would you pick ?

How are the thumbnails cached?

JPG as per Matt's reply above.

I've no idea, but I can say from a certain angle that a decompressed picture takes just as much memory regardless if it's JPG or PNG. The speed of decoding might be a problem (PNG requires more power), that's where we weight the averages and see if it affects the experience of not.

Exactly, if you have a viewscheme thats all thumbs for thousands of albums, it all adds up in display time.

Sure one can come up with with alternative solutions that at least on paper look promising. Like creating an overlay mask that will determine the transparency area and superimpose it over the original JPG thumbs. That's kinda done already for some other elements.

Yes, indeed there is the exception ie the info panel of Theater view.  I guess it does not come from the cached thumbnails.

[Daydream]

JPG as per Matt's reply above.

I wasn't referring to the format but to the (background) mechanics - load at startup, load at view scheme change time, load partial, load full, load which database (there are 3 versions depending on thumbnail sizes), load which source (dbase first, external covers later) and so on.

Overall we're on the same page. I wouldn't promote sacrificing any kind of speed. It has to have zero or indistinguishable impact for everybody.

[Mr ChriZ]

I'm thinking increased storage reqmts for the cached thumbnails as well as performance hit as they are what you see when browsing.

What's the size factor difference for PNG vs JPG ?

That depends on the image type.  Images with not a high varying number of colours will suit PNG better, and the file could well be smaller
JPG on the other hand suits things with many colours.  PNG is lossless compression, but at a guess better compression than JPG.

[hit_ny]

Images with not a high varying number of colours will suite PNG better, and the file could well be smaller

That maybe but in the context of this thread which is cover art, there will almost always be a large number of colours

I just did a conversion of a 300x300, 22kB JPG with 50k colours to PNG of the same dimensions and the resulting filesize is 252kB !!

Thats a ten fold increase so don't expect to use PNG cover art anytime soon.

[Daydream]

That logic is flawed. (me almost speaking Vulcan )

A test like that is not representative for anything; it gives a vague idea for one thing that was already known by anybody that deals with graphics. Dismissing an idea based on this would be just like me saying today it's a rainy day over here, that's why this is not gonna fly.

I would understand if somebody from the devteam comes and say "yo', we've run our metrics, here's the numbers - it totally kills the experience"; or say "hey this might be doable but it requires a lot of time and effort that right now we are channeling towards other goals". That would be sensible reasoning for anybody that works in the real world.

Speculating from the sidelines (which is the best I can do):
- MC already deals with tens, maybe hundreds of thousands of thumbnails for its databases. Even with the awesome compression of JPG it should've gone haywire long time ago. It is the magic of their engine that deals with this which I'd venture a guess that it's optimized for dealing with binaries (pictures), since a normal database doesn't store binaries.
- considering only size of things it's dangerously simplistic when it comes to databases. There's also I/O, multithread reading, specific optimizations, etc that affects the responsiveness. Of course I would not ask this to be changed just to accommodate my request, I'm just saying there's a bigger picture out there, not just one thing.
- keep in mind the alternative solution I mentioned above (overlay) that doesn't touch the databases at all.