No compression happened
sanjeetsahoo opened this issue · 35 comments
I tested two of the pre trained models on an image directory with JPEG images of the size 50-70KB. The output images in the sample folder were of the size 600-800KB. So basically no compression. Am I doing something wrong?
What kind of images did you compress? The models are trained on natural images. And when you say 600-800KB, you mean the .l3c files generated with --write_to_file or the bpsp outputted by test.py?
Or are you using l3c.py?
After I update my gcc, I can run the codes now.
But I also find that when I run l3c.py on a .jpg file of the size 100kB, the out.l3c becomes to 850kB and the out.png becomes to 1.6M :P (the bpsp of output is great:2.68, but the file is so big...)
Then I tried larger pictures but it allocated more than 10G memory of GPU and it was been killed.
uh...I don't know if it is normal...
@BUAAHugeGun This is because it's a JPG, a lossy format :) So if you feed a .jpg to L3C you are asking it to compress the artefacts from JPG losslessly. The number you should care about is how L3C compares to PNG, which is also lossless.
Regarding the GPU: this is the problem of using CNNs. I think this could be optimized but I did not spend the time. If you have more RAM, you can also try the CPU version of torchac.
@fab-jul thanks a lot for your response. 👍
I made the mistake because I thought it could conpress any picture sRGB images.
thx
uh...I'm coming back here for your help.
Today I tried .png & .NEF files.
But I found that the output image(out.png) was full of blur and noise. :(
I used:
python l3c.py 'logs dir' 0524_0001 enc 'input dir' out.l3c
and
python l3c.py 'logs dir' 0524_0001 dec out.l3c out.png
the output will always be equal to the input. what kind of images are in input dir?
First I tried .jpg as I said. They were the same, Though the size of output is much larger than input.
Then I tried a .png image from Internet, a .png image from kodak test dataset, two .NEF images from the test dataset mentioned in your paper and got outputs of them which were full of noise and blur.
I'm sorry if this will trouble you. : (
Can you post one such .png that produces noise here?
I just downloaded this image and ran it through L3C:
python l3c.py $RELEASED_CKPTS 0524_0001 enc ~/62377157-db349180-b574-11e9-851d-b79e5efc8067.png out.l3c
python l3c.py $RELEASED_CKPTS 0524_0001 dec out.l3c ~/decoded_github.png
And I get the same image back, as expected, i.e. decoded_github.png is exactly the same image I put in.
In theory, the code will always produce the same image. I'm really confused by what you get. Can you post the blurred result as well?
This is very unexpected. It looks very much like you are getting a sampled version of the image. Some questions:
- Are you putting in exactly the image you posted above? I.e. what happens when you download that image and feed it?
- Are you using the command you posted above? I.e. no
--sampleor anything? - Are you on the latest git commit?
I'm sure about the 3 questions. And I tried some times again.
It is strange that I succeeded once using the image above.
And then it failed again.
I noticed that the size of out.l3c is constant, so I guess there is something wrong when using decoder?
...I downloaded the code again.
And then I installed torchac(GPU).
Now when I use a .jpg image, I also get a blurred image...
Maybe something with torchac is wrong. Can you try to run
python test.py /path/to/logdir 0524_0001 /some/imgdir --write_to_files=files_out_dir
because that runs multiscale_tester.py's _write_to_file which has an assert to check decoding works.
Alternatively, can you send out.l3c?
I sent a email to you. : )
Thanks! I’ll have a look. If you can, running the above command (the one with --write_to_files) would also be really helpful.
So, I just tried, and I get the same blurry output as you. I then went and compared the binary file you gave me to the one I get when I encode. They only match in the part that encodes the smallest bottleneck (which is encoded with a uniform prior). So, for some reason, your network must produce different probability distributions when encoding.
Now, I don't see how --write_to_files worked, because it should raise an assertion. I'm really not sure what's going on here. Are you encoding on GPU? If so, which GPU do you have? If you try with this file here, does it work, i.e., does --write_to_files work and does l3c.py work?
Hey
I have the same problem, tested it with the .png files from the CIFAR10 dataset like this car.
I used this command to get the l3c:
python test.py ../ 0524_0001 ~/images/bar/ --names "L3C" --recursive=auto --write_to_files ~/images/foo/
and this command to decode it again:
python l3c.py ../ 0524_0001 dec ~/Bilder/foo/automobile4.l3c auto.png
yielding these blurs:
When I use the command for encoding,
python l3c.py ../ 0524_0001 enc ~/images/bar/automobile4.png foo.l3c
I get the different blurs.
The code is executed on NVIDIA RTX 2070, with the anaconda environment installed according to the repository, with torch 1.1.0
I‘ll check this out. Since it happens on CIFAR also, it most likely is not a memory issue
It is strange that when I first used l3c.py, the output was the same as the input, but when I found this problem, I tried the same input as the first one, the output changed to a blurred image.
And the only commit between the two tries was the modification of torchac...
Wait, are you saying that everything worked before that commit? Or are you not 100% sure?
Edit: Are you running both encoding and decoding on the CPU?
Uh, I just tried .jpg images on GPU before that commit and they were OK.
Round after the commit, I asked you why the output was larger than input when trying .jpg.
Then I edit the code of torchac as your description and run it on .png images and it didn't work well.
Finally I download code again and found it also didn't work well on .jpg images.
So, I finally have some time to dig into this. Good news: I can now finally reproduce it, with the steps provided by @ChipsSpectre.
Update: This has to do with CUDA.
If I compile torchac without CUDA support AND run all commands with CUDA_VISIBLE_DEVICES="", no errors appear.
Currently however, there is some weird behavior in torchac.py, where it always thinks CUDA is available. I'll dig more later this week.
thx a lot. I guess it's hard to find this problem.
Thank you for the tip. I will also have a look into the torchac module.
I could reproduce correct encryption and decryption with
CUDA_VISIBLE_DEVICES=""
on my machine, too.
Edit: The Arithmetic coder does not adapt the device before calling the torchac module.
The data are transferred to the default device (e.g. a GPU) before starting the bitcoding, where the data is only converted to float.
I assume now that maybe the error can be avoided by transferring the data to cpu if torchac-cpu is available only, similar to the function encode_logistic_mixture in torchac.
@ChipsSpectre Yes I realized that too now. Another problem is that if you compile with GPU support once, it stays in your build dir, and then torchac.py will always use the GPU version. I'll fix both things.
What's really weird to me however is that it works when using test.py. Because there is a line in there that does an assert output == input. So, when using the decoder in test.py, everything works. Somehow however, when using the decoder through l3c.py, it doesn't work anymore...
If you want to dig into that, it would also be much appreciated :)
fixed.
the restorer class was the problem.
i create a pull request.
Still working on making the backend selection more seamless, so keeping this open.
@BUAAHugeGun Please try again with the latest master commit and let me know how it goes
Closing this due to inactivity.