On My Way To The Psyche-ward!!!!

AZ3

Hi all. I have been waging war with some of the PHP image functions and my God I am so fed up I am about ready to rip my entire head off and kick it into the sun.

Specifically I am writing a script to allow the changing of colors within any given JPEG image, which then resaves the modified image as a new JPEG.

Everything works for the most part, but here is my problem. When I create a new image based off the original, no matter what I do the RGB colors shift.

YES, I am "imagecolorallocate()"ing my RGB colors in the new image. In fact, I am literally doing nothing more than copying the original image. After hours of fighting I went even more simple and look where it got me, nowhere. No matter how little or how much I do, the colors of the new image always shift!!!!!

Here is an example of the index and RGB values for the original image and the copycat image (ya right - it's entirely different).

Original Image

Index(0) = [4, 2, 100]

Index(1) = [52, 102, 204]

Duplicate Image

Index(0) = [4, 10, 108]

Index(1) = [68, 94, 196]

I cannot for the life of me figure out why this is happening. I have tried a number of different methods (3-4 days rotting my brain).

PLEASE! PLEASE! PLEASE!

Anyone out there that can help me with this, please write back. I am so frustrated right now, I'm on the verge of throwing away my entire career as a programmer and flying off to some third world country with polluted water and dedicating the rest of my life to writing viruses that destroy everything they encounter (until I die). And yes, I still want to kick my stupid techie-head into the sun!!!

Oh ya, and here is the little piece of crap that is causing my brain so much stress. Just a few simple lines of code... 😕

=========================
$im_size = GetImageSize ("original_image.jpg");
$imageWidth = $im_size[0];
$imageHeight = $im_size[1];

$im = imageCreate( $imageWidth, $imageHeight );

$darkblue = imagecolorallocate($im, 4, 2, 100);
$lightblue = imagecolorallocate($im, 52, 102, 204);

$im2 = ImageCreateFromJPEG($mod_img);

ImageCopy ($im,$im2,0,0,0,0, $imageWidth, $imageHeight);
ImageDestroy ($im2);

imagejpeg($im, "new_image.jpg", 100);

Is there anyone out that can possibly explain why I am getting this color shift?

EXTREMELY FRUSTATED!!!!

I now shall await the extreme intellect of the PHPBuilder community. Heck I'll even look forward to hearing someone else gripe about the same problem. Anything folks!! Anything at all.

Weedpacket

Originally posted by AZ3
Is there anyone out that can possibly explain why I am getting this color shift?

Oh, messing with the palette can be a pain - especially in gd-Lib. I've battled it myself. (But 256-colour JPEGs? Kind've a contradiction in terms when you think about it...)

The problem is, your original image has 256 colours, one of them being rgb(4,2,100) - the colour you allocated. So the entire truecolour JPEG image had all its colours remapped to a 256-colour palette that included that colour.

Now, exactly how gd-Lib figures out what colours should go in that palette I can't recall, but it depends on what colours have already been allocated and what colours are in the original image. Chances are good, however, that it doesn't contain rgb(52,102,204).

So when you copy the image, gd-Lib finds it has to take 257 colours (the allocated colour rgb(52,102,204) and the 256 from the orignal image) and remap them all into a new 256-colour palette. Something's gotta give.

I might suggest either using the truecolour image functions (make sure you have gd-Lib version 2 installed); or alternatively - are you sure you need to use JPEGs? Can't PNGs work just as well - they do support paletted images. If you're only using JPEG because GIF's not supported, then you should be using PNG. JPEGs will cause virtually always cause colour shifts; up to 16,777,216 colours and compression artefacts being squashed into a format that supports no more than 256 colours ... again, somethings got to give.

Actually, I just thought of a third one:

Create the image - this creates the palette you'll be altering.
Find the index of the palette colour you want to change in the image with imagecolorexact() or imagecolorclosest()
Use imagecolorset() to change that colour.

Like I say, I just thought of it, so I haven't tried it.

AZ3

Okay so I agree with what you said, but the problem is right now I am doing nothing more than creating a copy of the original. I am allocating the colors from the original image into the new one, not changing anything yet. I figured if I can't at least get a freegin copy of the original then something is definitely screwed.

Anyway, yes I think this is a color palette issue with the JPEG. And since I am stuck with the GD 1.8, I can't use the true color option. Crap!!! Crap Crap Crap!!!!

Okay so I am going to throw in the towel on JPEG's unless someone else has another idea on why my copy of the original (which uses the standard 256 color palette) comes up with a shift. Anyway, I guess PNG is going to be my last hope. Really, I had thought about going PNG but since I have never seen a PNG image or created one... I guess I was just trying to avoid learning something new. See where it got me.

So PNG it is. Does anyone have any major objections to PNG images. Why would us programmers use JPEG's if PNG's have more support and better compression.

Oh well. Thanks Weedpacket.

Weedpacket

Well, rereading your post, I see you setting two colours in $im, and creating an image from the JPEG in $im2.

$im2 gets a 256-colour palette built up based on the colours in the JPEG. Again, chances are good that this palette doesn't contain either of the colours you've assigned in $im.

So when you copy $im2 into $im, gd-Lib has 258 colours it has to force into a 256-colour palette.

As for why people use JPEGs instad of PNG, the reason is simple: compression. JPEG compresses better at the expense of being increasingly sloppy about getting pixels exactly right. PNG isn't sloppy at al, but that means it doesn't compress as well.

PNG was never intended to replace JPEG, it was intended to replace GIF and takes advantage of improvements in coding theory and processor technology that have been made since 1987. Unlike GIF, PNG can do truecolour images; PNG images compress better than equivalent GIFs; offers genuine alpha channels instead of just the "transparent index" of GIF; has better support for auxiliary data; and PNG is not loaded down by stupid legal hassles that keep it out of products like gd-Lib. Okay, there's no such thing as an animated PNG, but the sister MNG format does exist.