Java_Image file that changes when compressed/decompressed

[TheLordOfChaos201]

Hello, it's the Infamous Lord Of Chaos

Ok That's titles out of the way, now lets address the problem.

I need a image file type that changes code when compressed and decompressed, so far I've found Jpg changes when opened and saved but not when compressed or decompressed. This is a programming question because I've heard there are ways of coding into images, but I'm not to interested in that part unless that is the way to change it's compressed bit code and decompressed code.

Thank you in advanced...

PS: I know it's possible because google says that it was a problem in the past where compressed and then decompressed images became corrupted over time, but no longer a problem. How do I make it a problem once again.
Begin!

Explanation:

Your question makes no sense. Maybe you should rephrase it.

An image is made from bit code that is read by it's respective file type manager.

Now, when an image is compressed it's bit code is rearranged to be more efficient and thus smaller. This only happens to a few image types, jpg being one of them. Therefore we can say that the bit code is now different. Hence what I want is a bit code that changes both when compressed and decompressed.

 

[GhostWolf]

Your question makes no sense. Maybe you should rephrase it.

 

[TheLordOfChaos201]

Your question makes no sense. Maybe you should rephrase it.

An image is made from bit code that is read by it's respective file type manager.

Now, when an image is compressed it's bit code is rearranged to be more efficient and thus smaller. This only happens to a few image types, jpg being one of them. Therefore we can say that the bit code is now different. Hence what I want is a bit code that changes both when compressed and decompressed.

 

[GhostWolf]

When an image is in a flat decompressed format, you generally have RGB(A) data.
When an image is compressed, you have...compressed data, how surprising.

In addition, every file format has its headers etc., so the saved and loaded data will never be the same - the file on disk has that extra information, the loaded data is pixels (or the compressed data minus the headers, in the case of special compressed images that you can upload directly to your GPU, such as DXT (aka DDS) images).
The only exception is a raw file of pixels, but I've never seen those used. A file with no headers is pretty useless for general use.

I have no idea what you're on about with "bit code", that's relevant to...code. Virtual machines, compilers, etc.

In short, you make no sense.

 

[TheLordOfChaos201]

so far I have tested all the standard image types... none of them chAnge when compressed and then decompressed. once compressed they remain the same.

and yes I'm talking about bit code because java reads images in bit code

 

[GhostWolf]

Look, you can keep writing the same nonsense, and it will stay nonsense.

The only thing I can perhaps decipher from your posts is that you mean lossy compression, in which case JPG is the major image format to use it.

 

[TheLordOfChaos201]

but it does not change when decompressed

 

[Dr Super Good]

The only exception is a raw file of pixels, but I've never seen those used. A file with no headers is pretty useless for general use.

BLP0 uses them for indexed colour images. However it still has a header just in another file.

so far I have tested all the standard image types... none of them chAnge when compressed and then decompressed. once compressed they remain the same.

Once an image is compressed it will never change. If it does change then the file can be considered corrupted as a result of an error or damage to the underlying file system or data store.

but it does not change when decompressed

Which is what will happen for all images because the data is not mutated when read. Giving a deterministic reader the same input will produce the same output.

One possible exception is for vector image formats. In such a case they are not compressed and the output is resolution and possibly RNG based. However one cannot really save a bitmap as a vector image for logical reasons.

and yes I'm talking about bit code because java reads images in bit code

Bit code has nothing to do with Java ImageIO? It reads images in primitive types returned by various methods of the ImageInputStream class. These primitive types are then fed into various class members and used as arguments for method calls.

The only bit code image format I know of is old Age of Empire 2 terrain blend files. The specifications were never made public or reverse engineered but the principles were eventually reviled by former developers. Due to a lack of standardized hardware acceleration for blending the developers were forced to write a software blender. However software blending in a meaningful way from a hints image directly was too slow for the computers of the time. Instead they pre-compiled the hints image into bit/byte code which at run time would be expanded into machine code to carry out the specific blending between tile types as required. In a sense the terrain blending in Age of Empires 2 was the result of hard-coded constant pixel values in code being written to the display buffer rather than copied from another buffer to the display buffer. Even still the results were deterministic and the files only read so given the same tile textures and same blend file the game produced the same blend results.

PS: I know it's possible because google says that it was a problem in the past where compressed and then decompressed images became corrupted over time, but no longer a problem. How do I make it a problem once again.

This sounds like magnetic tape based image storage, such as VHS which were used until recently. Over time the image quality degrades due to data corruption/loss of the underlying storage medium. Since the tapes store data in an analogue way which maps directly to pixel values then the loss is represented as a slight degradation in image quality. This is not suitable for digital image formats, especially compressed ones, since any corruption can potentially render the image un-openable or produce unsightly corruption artefacts.

Not all magnetic tapes are lossy. Ones such as used for digital backups are quite lossless however they are only ever intended to be read one time after each time they are written and they are intended to only last a well defined finite time. They also likely have error correction codes and other features to help assure data integrity.

Some formats intended for storing CCTV data may also exhibit loss over time. More specifically the high frequency data of very old or low interest footage might be discarded as time progresses to make room for new footage. Decompressing the footage does not cause data loss and will retain the same quality at any given time no matter how many times it is decompressed. Instead as time progresses and more image data is written then old image data may be lost. Such formats have generally fallen out of fashion or been obsoleted by the cheap cost of data storage, allowing so much full quality CCTV footage to be recorded that by the time space is a concern the old full quality footage is more than eligible for permanent deletion due to having no relevance.

 

[TheLordOfChaos201]

ok then my question remains

how do you make the code of an image change when compressed and again when decompressed?

I've tried encryption but even an encrypted image remains the same

 

[Dr Super Good]

how do you make the code of an image change when compressed and again when decompressed?

What you are asking is not making any sense...

JPEG does cause the image to change when compressed and decompressed.

IMAGE1 -> JPEG compress -> JPEG file -> JPEG decompress -> IMAGE2
IMAGE1 and IMAGE2 are different, unless lossless JPEG compression extension is used (which defeats the purpose of JPEG to some extent).

If you are asking...

how do you make the code of an image change each time it is decompressed?

Then that is a totally different question. As far as I know no such image formats exist as there would be no practical applications for them. Not only does it imply that you would have to read the file, but also write to the file which is even slower.

The Java ImageIO framework does not support such a image format. When reading an image from a file you are using an ImageInputStream which is only capable of reading bytes so cannot modify the underlying file. Similarly when writing an image to a file you are using an ImageOutputStream which can both read and write bytes however the ImageWriter API does not allow you to read images from the file.

I've tried encryption but even an encrypted image remains the same

Which is what one expects because it would be useless encryption if the data outputted was not the same as the input given the correct key.

 

[TheLordOfChaos201]

thank you, you've answered my question

mwahahaha!!!! soon I will rule the world!

 

[pyf]

I am pointing out Stuffit Deluxe can "cheat" with some file formats, when compressing them into a sitx archive.

Stuffit Deluxe may modify the files themselves during compression, in order to achieve better compression ratio. Therefore, the compressed files will *not* be binarily identical anymore, when decompressed afterwards.

Sadly, this behavior is enabled by default, which is a very very bad idea imho. Fortunately, you can disable it by looking into the submenus.

File formats potentially affected are : jls, j2k, gif, tif, tiff, psd, png, pict, pct, pbm, pgm, ppm, pdf, docx, xlsx, pptx, odt, odg, ods, odb...


http://my.smithmicro.com/stuffit-knowledge-base.html
Please read the part named "Bit-perfect vs. Pixel-perfect"

Hope it helps

 

[Dr Super Good]

I am pointing out Stuffit Deluxe can "cheat" with some file formats, when compressing them into a sitx archive.

Actually that is pretty much the modern graphic publication pipeline to some extent.

Uncompressed -> fixed ratio compress -> Lossy compression optimize -> lossless compression

Fixed ratio compression are your compressions like DXTC which reduce file size by a fixed ratio at the cost of some image loss. Lossy compression optimize is where loss is purposely introduced to boost lossless compression ratio, often using a quality setting to guide the amount of loss. Final lossless is one of a variety of algorithms best suited for compressing fixed ratio compressed image data and could include methods such as Huffman compression and such.

In your programs case it adds it to an archive. In the case of some tools such as from google it makes a new separate image format which can be opened for a fixed ratio compressed image (which can be loaded and used by GPU directly).

Only real problem with it is that lossy compression optimize is painfully slow, taking possibly minutes per texture. Apparently google is the biggest distributer of tools which do this because it encourages that developers use such a pipeline to optimize their image file sizes for internet distribution.

 

[pyf]

It is indeed a two-in-one process, and it takes more time to create the final sitx archive.


Regarding compressed files, I am unaware of any "bit code" (whatever that means) that changes when decompressed.

However I also point out, some specific versions of any software can have issues. They may create corrupted / non-compliant files. In which case, you would need at least that faulty specific software version to (hopefully) read / decompress them properly. But here, it is obviously a bug, not a feature.

 

[TheLordOfChaos201]

It is indeed a two-in-one process, and it takes more time to create the final sitx archive.


Regarding compressed files, I am unaware of any "bit code" (whatever that means) that changes when decompressed.

However I also point out, some specific versions of any software can have issues. They may create corrupted / non-compliant files. In which case, you would need at least that faulty specific software version to (hopefully) read / decompress them properly. But here, it is obviously a bug, not a feature.

hmm... when did you post this

It would have been helpful, but I'm afraid I found a better solution now, besides I needed the file to be corrupted no matter the encryption tool used... which I guess is impossible

 

[Dr Super Good]

It would have been helpful, but I'm afraid I found a better solution now, besides I needed the file to be corrupted no matter the encryption tool used... which I guess is impossible

You can corrupt a file simply by bitwise exclusive or-ing it with a random bit stream. One could call the data encrypted because the bit sequence has no meaningful interpretation while still is based on some sort of input (not just a random bit stream). Not sure what possible reason one would want to do this though.

 

[TheLordOfChaos201]

You can corrupt a file simply by bitwise exclusive or-ing it with a random bit stream. One could call the data encrypted because the bit sequence has no meaningful interpretation while still is based on some sort of input (not just a random bit stream). Not sure what possible reason one would want to do this though.

not how I would want it

what I'm looking for is that the image code changes it's self when encrypted into an archieve, and decrypts it's self

unfortunately so far it seems that the encryption and decryption of a file is determined by the encryption tool and there is no way for me to make the image corruption proned

thanks for the help anyway, I see the common factor that changes with encryption/decryption is the sum check. which I will uses for my protect

 

[Dr Super Good]

unfortunately so far it seems that the encryption and decryption of a file is determined by the encryption tool and there is no way for me to make the image corruption proned

thanks for the help anyway, I see the common factor that changes with encryption/decryption is the sum check. which I will uses for my protect

Encrypt the image data and use a cryptographic hash to check its integrity.
Encryption -> prevents unwanted reading/modification of data
Cryptographic Hash -> detects changes to data

You can produce a Cryptographic Hash of either the original data, or the hashed data. You store this hash somewhere, eg in the code or a file or on a server. When the application reads the file, it takes a hash of the data and if it matches the stored hash then it is correct, otherwise it has been tampered/corrupted. Both achieve the same level of security because even a single bit change will result in a total change of the cryptographic hash with an as good as certain probability.

 

[TheLordOfChaos201]

Encrypt the image data and use a cryptographic hash to check its integrity.
Encryption -> prevents unwanted reading/modification of data
Cryptographic Hash -> detects changes to data

You can produce a Cryptographic Hash of either the original data, or the hashed data. You store this hash somewhere, eg in the code or a file or on a server. When the application reads the file, it takes a hash of the data and if it matches the stored hash then it is correct, otherwise it has been tampered/corrupted. Both achieve the same level of security because even a single bit change will result in a total change of the cryptographic hash with an as good as certain probability.

unfortunately I have already got a cryptographic hash function. it would have been brilliant if I didn't have one because it would mean just that extra bit of help in preventing theft.

still thanks, keep them coming.

 

[pyf]

Back to OP, maybe a first step leading to what you want to do?
uncmpJPG | packJPG

Quoting:
"uncmpJPG accepts JPEG and UJG (Uncompressed JpeG) files as input – JPEG are converted to UJG and vice versa. An UJG file consists of all information needed to losslessly reconstruct the original JPEG file. Contained are JFIF file header, decompressed DCT coefficients and, if needed, some special file reconstruction information." [emphasis added]

You might wish to have a look at the other development tools there.


** update **

Forgot link: GitHub - packjpg/JPEG-Developers-Package: This package contains source code for special JPEG decompression and recompression routines, which may help developers as a framework in building their own JPEG recompression applications or as a base for other JPEG related projects.