Are the cover art images also PNGs in Jive?  Should they be JPEGs?

Yes, they are rendered as PNGs in Jive. This was done so alpha channel transparency would be available, particularly for creating non-standard aspect ratio art with padding that was actually tranparent.

If you request a "cover.jpg" with a URL that asks for "cover_130x130_p.png", cover.png is converted to a 130x130 pixel PNG that is padded with alpha channel tranparency if it isn't 130x130 square. FWIW, this image is then cached by SqueezeCenter (Jive will also cache it).

I'm not offering a solution with this comment, merely stating how it currently works.

(In reply to comment #2)
> Yes, they are rendered as PNGs in Jive. This was done so alpha channel
> transparency would be available, particularly for creating non-standard aspect
> ratio art with padding that was actually tranparent.

Is it necessary in the Jive interface for some reason to have only square album art images?

> Is it necessary in the Jive interface for some reason to have only square album
> art images?

for UI layout reasons, it's necessary for Jive to have a space that fills the same dimensions.

Dean thinks that an 8bit PNG will not have the same size issues, so we may be going to that as a workaround.

Ok, now that bug's assigned to me - what's the action? I read the discussion on campfire. Is the consensus to go the 8-big way?

I think that we should test the 8-bit PNG approach and verify that the image quality is sufficient and that it works on all platforms.

I proposed this change in the engineering campfire:

					# if the source image was a png and GD can output png data
					# then return a png, else return a jpg
					if (($returnedType eq "png" || $transparentRequest eq 'png') && GD::Image->can('png') ) {
						$newImage->trueColorToPalette();
						$newImageData = $newImage->png;
						$requestedContentType = 'image/png';

Also play with:
						$newImage->trueColorToPalette(1,256);

and:
						$newImage->trueColorToPalette(0,256);

This uses PNG as a kind of lossy compression, alas it's a compression scheme that works for many graphics but is not one that often looks bad for photographic images.    Can you try it out?

The other key thing to verify is that the image size is not as big as when using trueColor

Bad news.  My suggested code change didn't work.  GD doesn't know how to do 8-bit alpha blended images. 

We'll have to reinvestigate post-7.0

Just so it doesn't get lost in the ether, Andy's idea from Campfire yesterday:

Andy G. hmm what about requesting the image without a file extension, then we can return whatever we want, right?
return the most-optimized file format depending on the file
I think the underlying SDL stuff handles it all, we just say "resize this image to x/y"
so I bet it will work

an extensionless image will require changes in several spots (SC, SC skins, Jive). This should really be taken up post-7.0.

For the Jive layout problems, do the images have to be square with alpha transparency, or would it be sufficient to resize them so that they all _fit_ within the same sized square area?  In other words, resize them so that both the width and the height don't exceed a particular size, maintain the aspect ratio, but don't pad.

For example, if an 80x80 pixel space is the goal:

Original: 200(w)x185(h)
Resized:  80x74

Original: 325x400
Resized:  65x80

This isn't going to be addressed for 7.0?  You're actually planning on releasing software that sends 40k "thumbnails" to web browsers?

On a 100Mbps LAN the problem isn't always noticeable, but it's immediately apparent with connections across the Internet with less bandwidth.  Couldn't jpegs be sent to the web browser and then whatever else for the jive interface?

I agree it would be nice to fix this for 7.0, but given that most people use SC on a LAN it's not a high priority.

Using no extension and having SC determine the best type of file to serve should work.

I think we'd want to do this:

Source Image                Served as
-------------------------------------
Square anything             JPEG
Non-square anything         Transparent PNG (GIF for IE6)

Andy, I think that is a reasonable compromise for the first release, with the caveat that if the source file is a png, we don't send a JPEG.  

Targetting for 7.1 - though I doubt the bandwidth is an issue here. Processing many files imho adds much more to the overhead.

I don't follow Jive developements as closely, but my understanding is that with bug 7642 and change 18102, now only JPEG thumbnails are being rendered for that platform.  Is that for both square and non-square originals?

If that's the case, then would it be time to eliminate the use of PNGs in all of the precached web interface thumbnails for non-square originals?  There was never any reason to use PNG for that platform.

Jive gets JPEG all the time, the web still gets PNG for non-square images so they can be transparently padded.

(In reply to comment #16)
> Jive gets JPEG all the time, the web still gets PNG for non-square images so
> they can be transparently padded.

But wasn't the whole need for transparent padding to make square images a Jive thing in the first place?

Michael, is this necessary for the Default skin, or can you just as easily position non-square JPEGs?

Created attachment 3178 [details]
rectangular cover in Default skin

No need to have cover art as squares in the web UI.

That would be great if the web UI can request images using the same 'o' option that Jive uses.

Andy - could you please give me a pointer where this would have to be introduced?

You should be able to request images as 'cover_100x100_o' which would give you back an image that is resized to 100 for the larger dimension, with the other dimension being whatever is needed to maintain the aspect ratio.

change 20254 - use _o parameter for coverart display

This bug has now been fixed in the 7.1 release version of SqueezeCenter!  Please download the new version from http://www.slimdevices.com if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Reduce number of active targets for SC