How to edit pixels but maintain file size

[Hitachi1961]

Platform: OSX 10.12.3
IM Version: stable 7.0.5-0

Is it possible to edit an images pixels directly in such a way where when writing out the image the file size is the same size in bytes? I wouldn't be adding or removing pixels or changing the image format/colorspace, I would only change the pixels colors, so theoretically the image should take up the same amount of bytes.

When writing out an image I'm guessing that ImageMagick has it's own algorithm and metadata and thus writes out the image differently from the original format. Is this correct? If so, how would I simply read the pixels from an image, modify them, and then write them back to the same image with the same formatting/metadata?

UPDATE
I ran the contrast sample code on a couple different image formats and the file sizes would always change. Correct me if I'm wrong but doesn't the same just change the pixel rgb colors, so the file size shouldn't change?

It might be worth noting that the sample contrast code isn't updated to work for IM 7 so I had to update a couple things:
code gist here

And I used clang to compile:

Code: Select all

clang contrast.c -std=c11 -o contrast `pkg-config --cflags --libs MagickWand`

Here are 2 sample test images I used:

28487 bytes -> 34985 bytes (size increase)
http://users.usinternet.com/nkelebay/Im ... _Melon.jpg

115739 bytes -> 96885 bytes (size decrease)
http://pngimg.com/uploads/cat/cat_PNG1631.png

[fmw42]

Be cautious of adding new colors. That could change your image from 8-bit palette to 24-bit truecolor. Thus changing the file size.

[fmw42]

If you do not change the image type nor the color depth (nor add new colors so that one has the situation explained above), then Imagemagick will copy the meta data and write it back out with your pixel data. The file date may change, because it is being read and written anew.

[Hitachi1961]

I ran the contrast sample code on a couple different image formats and the file sizes would always change. Correct me if I'm wrong but doesn't the same just change the pixel rgb colors, so the file size shouldn't change?

It might be worth noting that the sample contrast code isn't updated to work for IM 7 so I had to update a couple things:
code gist here

And I used clang to compile:

Code: Select all

clang contrast.c -std=c11 -o contrast `pkg-config --cflags --libs MagickWand`

Here are 2 sample test images I used:

28487 bytes -> 34985 bytes (size increase)
http://users.usinternet.com/nkelebay/Im ... _Melon.jpg

115739 bytes -> 96885 bytes (size decrease)
http://pngimg.com/uploads/cat/cat_PNG1631.png

[fmw42]

You will need to provide an example image, so we can see what you are working with. Are you changing the image type, or depth or colortable? Please always provide your IM version and platform when asking questions.

If you are using HDRI compile of IM, for example default IM 7, then sigmoidal-contrast may produce values outside the range of your original image type (e.g. palette to truecolor). So it is important to know what you are starting with and what format you are writing to.

Sorry, I do not use any API, but I can verify in the command line.

[fmw42]

Please, always provide your IM version and platform when asking questions, since syntax may differ. Also provide your exact command line and if possible your images.

See the top-most post in the Users forum "IMPORTANT: Please Read This FIRST Before Posting" at viewtopic.php?f=1&t=9620

For novices, see

viewtopic.php?f=1&t=9620
http://www.imagemagick.org/script/comma ... essing.php
http://www.imagemagick.org/Usage/reference.html
http://www.imagemagick.org/Usage/

[Hitachi1961]

Updated the original post to include details.

[fmw42]

Sorry, I do not follow your code. Can you tell me did you keep the input and output formats the same. If so, you cannot expect the same size for input and ouput with JPG, because it is a lossy compression. IM has to decompress the jpg, process it, then recompress it. For PNG, you may have started with a more efficient compression than IM can create. So going from/to compressed formats even if not lossy, may cause image size changes.

[Hitachi1961]

Yes, I kept the output image formats the same. I basically ran the program after compiling it with:

Code: Select all

./contrast cat.png output.png

[fmw42]

See my comment above about compression.

[Hitachi1961]

So basically image reading/writing between formats, programs, and platforms is variable and imagemagick can't maintain the exact quality/format because of this? Is this correct?

[fmw42]

It really depends upon exactly what you are doing. If you just go in an change one pixel from one color to another existing color and the format is not compressed. Then I would expect the same size output. But if you have compressed data, then IM will decompress, process (which may cause more colors and thus different types -- palette vs truecolor) and then recompress and the recompress might use a different scheme or efficiency. My opinion. One of the IM developers would have to give you further details or correct my understanding of when it would work and when it would not.

[snibgo]

contrast.c is simply an example MagickWand program that reads a file, modifies pixels, and writes them to a file.

So basically image reading/writing between formats, programs, and platforms is variable and imagemagick can't maintain the exact quality/format because of this? Is this correct?

That's not exactly correct.

If the file format uses no compression, two files of the same format with images of the same size and pixel depth (bits per channel per pixel) and number of channels will give the same filesize in bytes.

But when compression is used, filesizes will be generally be different.

For example, suppose one image contains only pixels that are red. The other image contains pixels of random colours. The red image is easily compressed to a small filesize. The random file cannot be compressed as much.

This is a characteristic of image compression.

[Hitachi1961]

Very interesting. I learned something today about image compression, thanks guys.