Image Browser plugin in 7.7

[JJZolx]

When viewing the full size images in the web UI I see URLs reminiscent of URLs used to resize artwork. Although they're not being resized, are the images going into the server's artwork cache?

The full sized images are resized when viewed on the Touch. Are these images being cached?

Is there no ability to step through the images in either the web interface or Touch interface? In the web UI, opening each image in a new window isn't much of an image viewer.

Swiping in the Touch interface leads to either the current playlist (right to left) or back to the Home menu (left to right). If a R-L swipe can't be used to step to the next image then it should be ignored. A L-R swipe needs to go back up a level in the browsing hierarchy (to an album, date, etc.).

[JJZolx]

Are 'albums' simply directory names? Directories with the same name in different locations all get merged when browsing albums.

If I have

\Photos
..\Utah
..\..\landscapes
..\..\people
..\Yosemite
..\..\landscapes
..\..\people

Then I end up with only one 'landscapes' album and one 'people' album.

[andyg]

Yeah it's pretty simplistic now. But I think you're going to have to wait for Michael to get back to really discuss Image Browser. He's taking a few days off.

On Sep 19, 2011, at 6:33 PM, JJZolx wrote:

>
> Are 'albums' simply directory names? Directories with the same name in
> different locations all get merged when browsing albums.
>
> If I have
>
> \Photos
> ..\Utah
> ..\..\landscapes
> ..\..\people
> ..\Yosemite
> ..\..\landscapes
> ..\..\people
>
> Then I end up with only one 'landscapes' album and one 'people' album.
>
>
> --
> JJZolx
> ------------------------------------------------------------------------
> JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10
> View this thread: http://forums.slimdevices.com/showthread.php?t=90463
>
>

[mherger]

> When viewing the full size images in the web UI I see URLs reminiscent
> of URLs used to resize artwork. Although they're not being resized, are
> the images going into the server's artwork cache?

By default LMS will never serve the full size picture, but a max. of
1920x1080 (or whatever full HD is). I think that pref is not exposed
(yet). Is this what you're referring to?

> The full sized images are resized when viewed on the Touch. Are these
> images being cached?

Yes. All resized images are cached. But the full screen images are not
_pre_-cached. Only the thumbs are.

> Is there no ability to step through the images in either the web
> interface or Touch interface? In the web UI, opening each image in a
> new window isn't much of an image viewer.

SP should start a slideshow starting with the selected image. Not
interaction possible right now. Web UI only shows the image in a new
window. I'll see whether I can port some of my Gallery plugin's features
to it. Unfortunately this plugin has very little priority, as it doesn't
show up on any marketing blurb...

--

Michael

[JJZolx]

> When viewing the full size images in the web UI I see URLs reminiscent
> of URLs used to resize artwork. Although they're not being resized, are
> the images going into the server's artwork cache?

By default LMS will never serve the full size picture, but a max. of
1920x1080 (or whatever full HD is). I think that pref is not exposed
(yet). Is this what you're referring to?

Ok, I thought I was looking at the original dimensions. But my question was more about whether they were being cached.

> The full sized images are resized when viewed on the Touch. Are these
> images being cached?

Yes. All resized images are cached. But the full screen images are not
_pre_-cached. Only the thumbs are.

Why bother caching them? That has the potential to grow the artwork cache to huge proportions. Do you have the ability to tell the resizer to not cache the resulting image?

Is the artwork cache ever cleaned? I thought I recalled that it wasn't, or maybe that was only with the old file-based cache.

[maniac103]

> When viewing the full size images in the web UI I see URLs reminiscent
> of URLs used to resize artwork. Although they're not being resized, are
> the images going into the server's artwork cache?

By default LMS will never serve the full size picture, but a max. of
1920x1080 (or whatever full HD is). I think that pref is not exposed
(yet). Is this what you're referring to?

Is there a way to turn off this resizing behaviour? I've set maxUPnPImageSize to 9999, but at least when browsing images through the Web UI, the images still seem to be run through a resizer. I run my SBS on a SheevaPlug, which is why I notice (loading a single image takes something between 5 and 10 seconds at 100% CPU load).

If there is a way to completely turn off resizing and just stream the JPEGs as they are on disk (at least if the source images actually are JPEGs, that is), that would make the image browsing actually useful to me - my client device is a HP TouchPad, so it won't have problems with loading the large images.

[mherger]

> Is there a way to turn off this resizing behaviour? I've set

No, would require some code changes.

> maxUPnPImageSize to 9999, but at least when browsing images through the
> Web UI, the images still seem to be run through a resizer. I run my SBS

Only portrait mode images or all of them?

> on a SheevaPlug, which is why I notice (loading a single image takes
> something between 5 and 10 seconds at 100% CPU load).

Yeah, that hurts. I'm seeing this too, even on my x86 (Via C3/1GHz - soon
to be 8yrs of loyal services :-))

> Is there a way to completely turn off resizing and just stream the
> JPEGs as they are on disk (at least if the source images actually are
> JPEGs, that is)? That would make the image browsing actually useful to
> me - my client device is a HP TouchPad, so it won't have problems with
> loading the large images.

You could modify the plugin code. Edit Slim/Plugin/ImageBrowser/Plugin.pm,
around line 157:

weblink => $id ? "/image/$id/cover_${maxSize}x${maxSize}_o" : undef,

make this:

weblink => $id ? "/image/$id/cover" : undef,

I didn't test this...

--

Michael

[maniac103]

> Is there a way to turn off this resizing behaviour? I've set

No, would require some code changes.

> maxUPnPImageSize to 9999, but at least when browsing images through the
> Web UI, the images still seem to be run through a resizer. I run my SBS

Only portrait mode images or all of them?

I will check.

> on a SheevaPlug, which is why I notice (loading a single image takes
> something between 5 and 10 seconds at 100% CPU load).

Yeah, that hurts. I'm seeing this too, even on my x86 (Via C3/1GHz - soon
to be 8yrs of loyal services :-))

I see we're in the same boat

> Is there a way to completely turn off resizing and just stream the
> JPEGs as they are on disk (at least if the source images actually are
> JPEGs, that is)? That would make the image browsing actually useful to
> me - my client device is a HP TouchPad, so it won't have problems with
> loading the large images.

You could modify the plugin code. Edit Slim/Plugin/ImageBrowser/Plugin.pm,
around line 157:

weblink => $id ? "/image/$id/cover_${maxSize}x${maxSize}_o" : undef,

make this:

weblink => $id ? "/image/$id/cover" : undef,

I didn't test this...

Looks like it works, at least from what I can test right now (I'm at work, so I'm limited by my slow DSL upload anyway).
From how I read the code, the maxUPnPImageSize=9999 should make the UPnP code trigger the same (non-resizing) code path, right? I guess the images also aren't put in the image cache in that case, is that also right?

[mherger]

> From how I read the code, the maxUPnPImageSize=9999 should make the
> UPnP code trigger the same (non-resizing) code path, right?

That's correct. But I missed the opportunity to respect this value in the
ImageBrowser plugin...

> I guess the
> images also aren't put in the image cache in that case, is that also
> right?

I think so, yes.

--

Michael

[maniac103]

> From how I read the code, the maxUPnPImageSize=9999 should make the
> UPnP code trigger the same (non-resizing) code path, right?

That's correct. But I missed the opportunity to respect this value in the
ImageBrowser plugin...

Ok, with your suggested change the Web UI is fine. UPnP is also fine for landscape images, but still slow for portrait ones (as is obvious from the code). Is there a particular reason for always resizing rotated images (is it the PlugPlayer issue mentioned in the moment)? If so, can this be made optional?

> I guess the
> images also aren't put in the image cache in that case, is that also
> right?

I think so, yes.

Ok, thanks. Can the image cache be cleared somehow to get rid of the now-unwanted big items?

Thanks for your quick responses BTW