Strange lines on images - UPDATE - PHP CODE BUG

I'm having issues with lines appearing on white areas of my images on 2 opencart installs. 1 is live, other isn't, seems to be worse on the non-live one at the minute.

Here is what is happening on first cart, 3 sizes of image below - 160 x 160, 500 x 500, and original (800px):





And this is on the 2nd site, 3 sizes - 250 x 250, 500 x 500, and original (1000px):





What is with all the vertical lines in the blank white bits?? The 2nd site, where the initial image is larger, seems to suffer worse.

Both on OC 1.5.5

I've bumped image quality to 100 in /system/library/image.php but that's not done it.

Any thoughts?

Hopefully readers of this are using ok monitors - it shows up horribly on my iMac, and also my Galaxy S4.

What lines? Firefox 23.0.1 with laptop pc lcd shows none. Appleseeds.

You may need to adjust your iContraption display settings, for color depth, for resolution, for refresh rate, for whatever else is settable. You may need to adjust your browser settings, presumably Safari, perhaps Firefox for iContraptions.

lol!

No, not an issue with it being a Mac - apart from it is able to display images with sufficient quality so that you can see the lines - same goes for my Galaxy S4, lines, lines, lines. Grab one of the smaller images above and open it up in photoshop, I assure, there are lines present, when the original images was pure white (ffffff).

In fact.... save you the bother, I've taken one of the above images, and scaled it in photoshop, and hopefully made it pretty clear what the issue is:



There's even some fdffe thrown in there for good measure?!?

So something is definitely not working properly with the image engine.

Your own image, still as seen in Firefox 23.0.1, downloaded and reviewed just now on a laptop pc at 3,200x magnification and stepwise downward, SHOWS NO LINES AND NO ASCII. There is nothing wrong in that regard with either OC or your website. The ascii is NOT springing from the website image itself. The ascii is springing somehow from something going on inside your local machine, be it a problem with hardware, software, or both. As for "sufficient quality" itself, I work with 100mb images, well above the 91 kb of the subject image from your website.

Inside your file, opened just to see whether it was compromised, commencing a bit from the top with "Ducky", is this, which you can perhaps take up with Adobe or Apple for the sake of troubleshooting the machine's hardware and software:

Ducky K ÿávhttp://ns.adobe.com/xap/1.0/ <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.0-c060 61.134777, 2010/02/12-17:32:00 "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/" xmlns:aux="http://ns.adobe.com/exif/1.0/aux/" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#" xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#" xmlns:dc="http://purl.org/dc/elements/1.1/" photoshop:DateCreated="2013-08-15T17:26:20+01:00" photoshop:LegacyIPTCDigest="89B47708175FDC1B5C49C05385AD1319" aux:SerialNumber="CP010294" aux:Firmware="P30-M, Firmware: Main=2.5, Boot=1.2, FPGA=1.2.1, CPLD=2.2.3, PAVR=1.0.4, UIFC=1.1.1, TGEN=1.0.1" xmp:CreatorTool="Adobe Photoshop CS5 Macintosh" xmp:ModifyDate="2013-09-09T15:44:27+01:00" xmp:CreateDate="2013-08-15T17:26:20" xmp:MetadataDate="2013-09-09T15:44:27+01:00" xmpMM:DocumentID="xmp.did:F75193300A9F11E3B7EEEDB25C0BB7FD" xmpMM:InstanceID="xmp.iid:F751932F0A9F11E3B7EEEDB25C0BB7FD" xmpMM:OriginalDocumentID="D52C0242A6ADB243FB6E12C663B63488" dc:format="image/jpeg"> <photoshop:DocumentAncestors> <rdf:Bag> <rdf:li>D52C0242A6ADB243FB6E12C663B63488</rdf:li> </rdf:Bag> </photoshop:DocumentAncestors> <xmpMM:History> <rdf:Seq> <rdf:li stEvt:action="saved" stEvt:instanceID="xmp.iid:C73CE0A447206811822ABF8D15E833CC" stEvt:when="2013-08-15T12:02:25+01:00" stEvt:softwareAgent="Adobe Photoshop CS6 (Macintosh)" stEvt:changed="/"/> <rdf:li stEvt:action="saved" stEvt:instanceID="xmp.iid:E662A61B09256811A613DE1B65C19316" stEvt:when="2013-09-03T09:50:22+01:00" stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh" stEvt:changed="/"/> <rdf:li stEvt:action="converted" stEvt:parameters="from image/jpeg to application/vnd.adobe.photoshop"/> <rdf:li stEvt:action="derived" stEvt:parameters="converted from image/jpeg to application/vnd.adobe.photoshop"/> <rdf:li stEvt:action="saved" stEvt:instanceID="xmp.iid:E762A61B09256811A613DE1B65C19316" stEvt:when="2013-09-03T09:50:22+01:00" stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh" stEvt:changed="/"/> <rdf:li stEvt:action="saved" stEvt:instanceID="xmp.iid:E862A61B09256811A613DE1B65C19316" stEvt:when="2013-09-03T09:53:36+01:00" stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh" stEvt:changed="/"/> <rdf:li stEvt:action="saved" stEvt:instanceID="xmp.iid:E962A61B09256811A613DE1B65C19316" stEvt:when="2013-09-03T10:10:12+01:00" stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh" stEvt:changed="/"/> </rdf:Seq> </xmpMM:History> <xmpMM:DerivedFrom stRef:instanceID="xmp.iid:E962A61B09256811A613DE1B65C19316" stRef:documentID="D52C0242A6ADB243FB6E12C663B63488" stRef:originalDocumentID="D52C0242A6ADB243FB6E12C663B63488"/> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="r"?>

Hey butte - thanks for your input, but I'll have to respectfully disagree

As per earlier posts it displays like this on my Galaxy S4 as well - the 2 original images display fine, the 4 opencart resized images display with lines.

I just went to a colleagues machine, she just got a brand new monitor today, at a glance, all looked fine - monitor not good enough. Downloaded the image, opened in photoshop, zoomed in, and there was the banding. Admittedly a lot harder to see on her screen - I could see it, she couldn't. I had to click around with the eye dropper and show her that the colour numbers were changing.

With regards to your comment, whilst a browser might miss display an image, it wouldn't re-write the contents of the file?

How high are your display resolution and color depth set? That goes for monitors and cellphones, which in turn would not be expected to compare favorably to high end monitors or software. If all are LCDs, then interlacing and refresh may have something in common.

If the browser writes a cache file, it might rewrite but that seems doubtful. You apparently have Safari and Android, which if their rendering engines happen to be similar might similarly mis-render images.

The scale of the ascii text relative to pixel size at 1,200x on up is such that the effect is or should be either plainly visible or plainly absent, with or without various adjustments to the image to render subtleties as obvious.

You'll already be aware of this, but others might not be. Since OC is not intended to be a primary graphics program when it makes thumbnails, you should give it originals that are in the kb range and 96 (or 72) dpi, so that it has a fighting chance to generate acceptable thumnails. You can upload originals into /image/data/ and your own custom thumbnails properly named into /image/cache/data, as you might prefer to do for an image gallery.

Sorry, posted earlier without seeing your excerpt from the file - erm, confusing read!! No idea what any of that means.

Ok, so, at home now - testing again. iMac here the effect isn't obvious - it's an older one though, and I've not run a screen calibration in ages. Same situation though - grab the image from Opencart, open in photoshop, zoom in, click around with the eye dropper, and voila - fefefe and ffffff popping up all over the shop. Do the same with the original, and as expected, pure ffffff.

Drop into VMware fusion, fire up a Win7 install running IE8 (shudder), find image, save it, open in photoshop - exactly the same.

Interesting - it looks like my work Mac and S4 might just be hypersensitive to displaying this problem, but there is, IMO, no possible way to deny that ffffff is ending up as fefefe for some reason in some places - and even fdffe in a patch on one image. I guess it might just be a jpg artefact that is usually completely un-noticable?

So I guess it's an agree, but disagree - you're take that it is my display settings making it noticable is IMO correct, but it is only making something that is there noticable.

I will have a dig around some other opencart sites at work tomorrow and see if I can find similar image oddities going on in white spaces.

I might take up that idea of running my own custom thumbs from PS

Whether it shows color tonality or numbers, what seems blank white in a photographic image will vary slightly from #FFFFFF, so the variants should be expected. That was a reason for forcing the image to show subtleties -- there is minor tonality but I encountered no numbers. The tonal variation is normal, showing equivalent hexadecimal numbers is not.

You happened to notice them in white, you might try forcing the image negative to see whether they appear in what becomes white (if so, then the numbers also appear elsewhere than in white).

The Ducky stuff in the file gives firmware and other numbers that might be checked with Adobe and Apple to see whether anything turns up. You are seeing the hexadecimal numbers in photoshop, on a mac.

On the given example the background has been removed entirely and replaced with fff in that section. The 'original' (so edited) version backs this up, with no variation at all in there. Only the smaller versions, downsized by opencart, add in these bonus colours.

I am finding it very strange that you aren't finding the different numbers ??

This may well need writing off as 'meh' - but I will look at some other sites. In fact... do you have a site, with images that you know are on a fff background, that I could look at?

Just got text of colleague - lines are showing up on her laptop too...

Ok so outputting at the correct sizes from photoshop, renaming with the -pixels-x-pixels system = now looks A1.

Need to just crack on and batch this off and get the images up, as it's holding things back, but will come back to investigate at some point

Ok, doing another site (!) - this has immediately reared head...

Can anyone see the lines in this image?!?



Original:



Again completely white zones are getting criss cross tracks added to them during downsampling. Something HAS to be wrong with something in the core.

To (hopefully) prove I'm not totally mad here I've had a quick dig -




The above images are live in the Opencart demo store - I've not blooming touched them!!!

The reduced, 500x500 image has blocks and lines in it. The pre-scaled version is 100% white in those areas. It doesn't appear to be jpg compression (I'm not sure what settings the demo store has) as these artefacts are miles away from any edges.

Ok, pulling the code apart, I've found the problem - yey - but not the solution - booo!

Line 106 of system/library/image.php
imagecopyresampled has a bug in it, see here - https://bugs.oxid-esales.com/view.php?id=3642 and here - https://bugs.php.net/bug.php?id=41820

Ridiculously it hasn't been fixed from what appears to be a 6 year old bug report??

To test this theory I changed it to:
This is the result -

Original code:


New code:


Obviously the resized version is HORRIBLE and can't be used, but it has NO F'ING LINES ALL OVER IT !!!!

So now I just need to replace that function, presumably with imagemagick. Which I plan to try to do now...

A few years later.
Is there a solution?

Nope - best solution I found was

Ok so outputting at the correct sizes from photoshop, renaming with the -pixels-x-pixels system = now looks A1.

So in photoshop export images at the precise image sizes you use on site - e.g. 74x74, 100x100, 500x500, 800x800 - and rename them with the ratios - e.g. some-product-image-500x500.jpg. Then just upload them directly into the image folder.

Basically if Opencart looks for an image of a certain size, if there is one there, it will serve it, if one isn't there, it will generate it.

The same problem here.
Opencart is useless, I need white background of images, and they all have grey lines exactly as you posted before - this lack of quality is not acceptable.
How come that nobody can fix it
It is unbelievable!