Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

Christoph Erdmann

  • Content Count

  • Joined

  • Last visited

Community Reputation

23 Newbie

About Christoph Erdmann

  • Rank
  • Birthday February 18

Profile Information

  • Gender
  • Location
    Bielefeld, Germany
  • Interests
    Coding, 3D, Animating, Drumming

Recent Profile Visitors

1,226 profile views
  1. That's nice, thanks! Are you thinking of a process where all images are uploaded and all images are compressed with the same settings? Or should every picture be presented to you? Yes, a better preview has been a topic for quite some time, and I simply don't know how to do it best. Moving the image and zooming is good at squoosh.app, but I don't like this comparison slider. It's rather good to hide the fact that two images are different after all.
  2. Batch processing is a difficult subject for me. I built the tool to get the most out of the images. Batch processing contradicts this in that it can't matter how big the compressed images are. And then you can use one of the countless other tools. But maybe you mean it differently... ?
  3. It's been a few days. But you are the ones I wrote this image compression tool for. So I'd like to know if you're still happy with it? Are all features understandable? Do you have better results with other tools? I'm always happy about your feedback.
  4. This div is at the top. Why do you have to scroll? Could you provide a screenshot?
  5. What a nice feedback, thanks. If you have any ideas to improve it, please let me know.
  6. I've used PNG8 for the masks some time ago but most of the time the PNG was a little larger than the JPG. And you need two requests. So I decided to go with a JPG mask. I've also tried mask quality settings but removed it. If you really want a smaller JPG mask you would have to do two requests. That adds HTTP header data. "Selective quality" seems not to be the solution for this. If you use quality settings that are not similar to each other the JPG algorithm uses different patterns from the 8*8 table. And then you get a glow around the JPG because the background color of the source image
  7. My new article "Finally understanding PNG" is now online. It also explains the "predator view": http://compress-or-die.com/Understanding-PNG Just a warning. English is not my native language and thus it is possible you are stumbling over some quirks. My english speaking colleague is proofreading this article at the moment, but I couldn't wait and would be glad to get your feedback.
  8. I added an explanation for the PNG "predator view" aka "compression view". Hope it is more clear now what it does: http://compress-or-die.com/png
  9. That was mean. I've implemented your code in compress-or-die and it was slower than the 8bit code. I've created a fiddle to show it to you. But in this fiddle the 32bit code was faster. But I got it: The difference is that I've inlined the code in compress-or-die within the onload attribute of the img tag. That made the 8bit code a little bit slower, but the 32bit code a lot slower than all other variants! So you only get the performance boost of the 32bit code if you define a function (an IIFE seems not to be enough) otherwise the situation switches completely. Here is the fi
  10. Btw.: Tried UInt32Array with direct pixel manipulation and did not see any improvements in run time. Maybe chrome's V8 optimizes this internally.
  11. Jackets: This is actually the perfect case for transparent JPGs. jacket0.png gets a file size of 205kB instead of 2637kB with the default quality settings. But I suppose you have to say good bye to your texture packer then. Think it would be worth it. But you have to keep an eye on the decompression time (you know, the typed array is on my list). I also don't see notable differences using 8 bit PNGs (908kB instead of 2637kB), but I think this won't work for all your products. Spine: Just use 8 bit PNG and set a color amount that pleases you (48kB instead of 212kB width 256 colors).
  12. ... except the funky sprite generation part. Think we are highjacking this thread.
  13. If you want to rotate an asset you don't use this technique of course. It's just another technique in your toolbox for standard animations with position and opacity
  14. Yes, the images are just a little bit bigger than the alternatives because they are most of the time PNGs. And of course this is not the holy grail for every type of campaign. But for standard campaigns with many size adaptions it's working well.