Jump to content

Christoph Erdmann

  • Posts

  • Joined

  • Last visited

About Christoph Erdmann

  • Birthday February 18

Contact Methods

Profile Information

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

Recent Profile Visitors

1,618 profile views

Christoph Erdmann's Achievements

  1. Hi, I am trying my hand at scrolltrigger (see codepen) and have the following problem: I would like the scrub functionality to play only once. If the animation is over, the last image should simply remain. If I use once: true there is a lot of space left by the ".pin-spacer". How do I solve this correctly? Best, Christoph
  2. 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.
  3. 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... ?
  4. 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.
  5. This div is at the top. Why do you have to scroll? Could you provide a screenshot?
  6. What a nice feedback, thanks. If you have any ideas to improve it, please let me know.
  7. 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 is not masked perfectly anymore. In my experience gzipped base64 images are a little bit larger than the original images. But Chrome als counts the HTTP header data for requests that is missing in the right part of your screenshot. Maybe that's the reason.
  8. 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.
  9. 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
  10. 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 fiddle: https://jsfiddle.net/McSodbrenner/gtv3earr/ I removed the "i" of the img tags to deactivate the corresponding code. So only one image tag should be correct at the same time to test it. But it's just a very small performance boost. Most of the time is getting lost at "getImageData()" which is needed anyway.
  11. Btw.: Tried UInt32Array with direct pixel manipulation and did not see any improvements in run time. Maybe chrome's V8 optimizes this internally.
  12. 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). Take a look at the compression view. There are stains I've marked with red rectangles: Those stains take space but shouldn't be there, correct? The compression view is really useful to identify dirty transparency. Dungeon: Just use 8 bit PNG and set a color amount that pleases you. If you need more colors that 256 I would break the sheets apart und consolidate images with similar colors. You can use the compression view to check the correctness of your sheets: In area 1 the PNG uses much file size for compressing the ponds of lava. So I think this is an animation. If it's not there is a opportunity for improvement. In area 2 the ponds are duplicates. Fine. In area 3 is a pond. In area 4 is a different pond, why? Copy the blue area from area 3 and you will save space. These are just some examples how to use the compression view. Does that help you?
  13. ... except the funky sprite generation part. Think we are highjacking this thread.