Corrupt poster images

[Spectrum]

Bizarre! All of the images are in the RGB colorspace. They aren't using CMYK/HSL which is what I would expect to show a radical color shift like that. If you have image magick installed you can show the colorspace of the image via 'identify -verbose image.jpg' and it will spit out the colorspace along with a bunch of other info. Photoshop can determine the colorspace as well and Gimp probably can too.

May just have to manually fix these as they show up

[razrsharpe]

Originally Posted by Spectrum

May just have to manually fix these as they show up

or somehow detect them and either just delete them and redownload a different one... or detect, save with some external program to fix the problem...

[stuckless]

Originally Posted by Spectrum

Bizarre! All of the images are in the RGB colorspace. They aren't using CMYK/HSL which is what I would expect to show a radical color shift like that. If you have image magick installed you can show the colorspace of the image via 'identify -verbose image.jpg' and it will spit out the colorspace along with a bunch of other info. Photoshop can determine the colorspace as well and Gimp probably can too.

May just have to manually fix these as they show up

Originally Posted by razrsharpe

or somehow detect them and either just delete them and redownload a different one... or detect, save with some external program to fix the problem...

I'd love to detect them... but the issue is that as Spectrum noted, the color space does appear to be correct. The "fixes" listed rely on detecting the colorspace and handing it differently, but in my testing, it would never trigger the alternate colorspace logic. There is something in the images that Java ImageIO.read() does not like, but I can't really seem to figure what it is.

In my testing... I'd do..

BufferedImage i = ImageIO.read(file);
ImageIO.write(i, "jpg", newfile);

And the resulting image would be corrupt. Since I can't control those 2 operations, it's very hard for me to solve this issue I tried to find some alternate apis for reading/writing images in java, but I can't find anything that is portable and many simply wrap ImageIO.read/write.

[razrsharpe]

Originally Posted by stuckless

In my testing... I'd do..

BufferedImage i = ImageIO.read(file);
ImageIO.write(i, "jpg", newfile);

And the resulting image would be corrupt. Since I can't control those 2 operations, it's very hard for me to solve this issue I tried to find some alternate apis for reading/writing images in java, but I can't find anything that is portable and many simply wrap ImageIO.read/write.

In my head i had something way less elegant, where basically you would:

• when initially downloading the images
• save the file from tvdb (i think basically like you do because at this point i don't think the image is corrupt yet....
• then since we can't detect which images are bad, we would have to open, save, and close all the images as they're downloaded with an editor from the command line (since you said that's how you fixed it...)... (maybe imagemagick, never used it but it looks like its a command line image editor that runs on unix, mac os x, and windows and would fit the bill ... looks like there is also a java interface for directly calling imagemagick from java)

[stuckless]

Yeah, I've looked at the image magic stuff before. I personally have never run into this issue, but I know several other have. What I may do, it add an image download hook to the fanart download process, thta can hand the image off another process once it's downloaded. That way, some people could have it run through an image processor that simply loads and saves the image using some other tool.

I'll take a look at image magic again as well.

[Spectrum]

I used groovy as a way into the classes and it looks like the offending images are distorted when they are read in. I tried writing one out to a bmp and it was distorted. Unfortunately in the imageio class, there is no way to specify the reader type. It is chosen automagically so it looks like there is no way to forcefully say read this image, it's a jpeg, and it's in the RGB colorspace.

I tried digging into the bufferedimage class a little bit, but couldn't get find a straight answer on how to examine the colorspace of an image. There is a colorspace property, but it just goes to another class and doesn't look like it can be simply printed out to determine what colorspace the image is in. I haven't done much java programming (groovy scripting for SJQ is really about it) but this is reminiscent of dependency hell in linux 10 years ago. Oh you want to look at this property, that's another class. But that class is a sub-class of another sub-class of another sub-class By the time I've looked up the properties on the 5th subclass I've forgotten wtf I was originally looking for!

Not a very elegant solution, but hooking into an external converter for jpegs may be the only option

[razrsharpe]

just thinking about this again.... bmt 3.x never had this issue with scaling/transforming images... so did something change on your end (ie how bmt was fetching/caching/saving the images)? or do you think (more likely probably) that the problem has always been there but more people are now creating images for tvdb using a colorspace that java doesnt like?

[stuckless]

Originally Posted by razrsharpe

just thinking about this again.... bmt 3.x never had this issue with scaling/transforming images... so did something change on your end (ie how bmt was fetching/caching/saving the images)? or do you think (more likely probably) that the problem has always been there but more people are now creating images for tvdb using a colorspace that java doesnt like?

The problem has always been there... it's more likely that something has changed in how people are createing the backgrounds, etc.

Since the issue is in the core java ImageIO apis... i've spoken with sagetv to see if they can expose their image apis so that I can use them, instead of the java apis. Once that happens, the phoenix apis will be modified to use the new load/save methods and it should solve this issue.

[razrsharpe]

Originally Posted by stuckless

The problem has always been there... it's more likely that something has changed in how people are createing the backgrounds, etc.

figured that was the case but wanted to double check

Since the issue is in the core java ImageIO apis... i've spoken with sagetv to see if they can expose their image apis so that I can use them, instead of the java apis. Once that happens, the phoenix apis will be modified to use the new load/save methods and it should solve this issue.

[Spectrum]

Would there be any point in filing a bug report with Oracle about the imageIO library? It seems that it has problems with these images when nothing else I've found does. Heck even mspaint can read them fine!

[stuckless]

Originally Posted by Spectrum

Would there be any point in filing a bug report with Oracle about the imageIO library? It seems that it has problems with these images when nothing else I've found does. Heck even mspaint can read them fine!

Some bright folks already did that... apparently it wasn't a priority for Sun... and it's even less of a priority for Oracle

Once we get to use the exposed sagetv apis, then it will be better all around. I'm sure the native apis for loading/scaling/saving are more efficient than the java based apis.

[vividweb]

was this ever resolved? I am starting to see this more and more.

[stuckless]

Yeah, I'm pretty sure it has been resolved for many months now... I haven't seen a corrupt file in ages. Are you running the latest sagetv/bmt/phoenix?

[vividweb]

yeah using the latest according to the plugins. It is a new install. My internet connection can be a little shaky, so that might be the cause.