HNHacker News
TopNewBestAskShowJobs

Daiz

1,974 karma · joined February 14, 2013

Digital Media Expert & UX Designer/Developer

https://daiz.moe

submissionscomments
Daiz··on Save Netflix
>I don't know the right solution to the HTML5 DRM thing.

Easy. If they want content protection, they should build it in JavaScript. Doesn't threaten the entire existence of the Open Web, any sufficiently decent scheme will prevent casual copying (dedicated pirates will always find a way, if nothing else then via screen capture), and it's actually cross-platform (unlike EME, where "cross-platform" is entirely up to the creators of the black box DRM plugins, so if Netflix et al wanted to say "sod off, we're not making our DRM plugin available on Linux" then you'd be totally out of luck).

Sadly, of course this isn't actually enough for the people demanding heavy DRM, since it's not just about "protecting the content" but about controlling the whole platform, which is what really makes EME such an existential threat for the entire Open Web. That's why I can't approve of it, and why you shouldn't either.

But content protection through JavaScript? Totally fair game, I say. Assuming that it's for a catalog rental model like what Netflix offers, anyway. Content protection has no place in any individual (media) products you buy, those should be DRM-free - otherwise you're not really buying them, just renting them for an undefined period.

(On a final note, I also practice what I preach here - I work for a comic publisher and am in charge of most things digital distribution, including the content protection scheme for our catalog rental subscription service. It's developed in JS and I'll do my utmost best to ensure we never ever touch EME in any way. Should be more cost effective for us that way anyway!)

Daiz··on FLIF – Free Lossless Image Format
cjpeg -sample 1x1 does the trick. Also, I recommend using mozjpeg if you already aren't.
Daiz··on Around the World in 33 Keyboards
I'm from Finland and have an used Thinkpad that originally came from Germany and has a German keyboard layout. As long as you can touch type, it's not actually an issue at all, since I can just switch the keyboard layout to Finnish in the OS and go from there - the keyboard has the same amount of keys in all the same places, after all.

The only time I've had an issue in this regard is with US keyboards, because the physical key layout is actually different. Most notably, "international" keyboard layouts have a a button next to left shift that's missing from US keyboards, which is used to write <, >, and | in the Finnish layout (and most other intl layouts), and no key maps to it if you switch to a Finnish layout on a US keyboard. This made programming an exercise in great frustration. (I also really didn't like the short Enter, I kept constantly hitting the button above it due to having used a tall Enter for all of my life before.)

Daiz··on Chrome DevTools: A Glimpse into the Future and RAIL Profiling
Speaking of mobile development, something that's been annoying me for a long time is that while you can "emulate" the devicePixelRatio of a mobile device, it doesn't actually seem to do anything meaningful.

For example, my phone has a resolution of 1080x1920 and a dPR of 3, so the viewport size is 360x640.

If I set these properties in Chrome Dev Tools, I just get a 360x640 rendering out of it. I'd like to be able to get a proper 1080x1920 rendition of the device screen too! It doesn't matter that it will look absolutely enormous on my desktop screen, I just want to make sure that my code and styling actually works like I want on it. I really shouldn't need to use an actual device for something as simple as this.

Daiz··on Unreal Engine 4.10 is Released
Seeing as you listed Game Maker there, I would throw in a recommendation for Construct 2 by Scirra: https://scirra.com

They have an excellent 2D HTML5 game engine and a very nice IDE to go with it. The event programming system they use is at least powerful as Game Maker's GML (if not more so) and you can also write your own plugins with JavaScript. Out of three mentioned programs, C2 is definitely my favorite for a couple reasons:

- It's built from ground up with 2D development in mind. Unity in comparison is primarily for 3D development, and while its 2D tools have improved over the years the difference is still really obvious.

- The overall user interface design of C2 is actually from this decade and makes good use of big screens of today. In comparison, you can still very much see the relatively ancient roots in Game Maker's UI when programs were designed with 640x480 screens in mind, not to mention how tons of features added over the years have just been slapped haphazardly into wherever there was room in the UI at the time. Game Maker's drag & drop coding is also just terrible, it's really either GML or go home with it.

- Pricing. You don't have to pay any extra for additional exporters or such with C2. Of course, there is the caveat of having to pay extra attention to mobile performance with C2 games being HTML5-powered on everything it exports to, but on actual computers you can cover the Windows/OSX/Linux combo very nicely.

Now, I mostly do game development as a hobby (which I've been doing on and off ever since I was ~9 years old), but if I wanted to do a commercial 2D indie game project for release on Steam (or similar) today, I'd definitely use Construct 2 for it. If I wanted to do same except for mobile, I'd probably evaluate C2 for it too (simply because I like it so much), but I might end up using something like Unity instead if performance proved to be too much of a headache with C2.

Daiz··on Forging an Alliance for Royalty-Free Video
>You want to start excluding people because of perceived (or actual) motivations?

Nah, I don't subscribe to the (unfortunately common) mentality of being exclusionary based on ideological purity evaluations. But since they obviously don't really subscribe to the idea of Open Web (as evident by their enthusiastic support for DRM in HTML, which is about as anti-Open Web as it gets), I guess I just wish they could be more honest about it. After all, what good is it that someone uses an "Open Media" format when it's put behind a completely closed black box barrier of DRM that you aren't even allowed to legally poke at thanks to anti-circumvention laws?

I do think this particular development is very much a good thing for the Open Web, and I certainly don't doubt Mozilla commitment to that. But the whole HTML DRM debacle did leave a really bitter taste in my mouth.

Daiz··on Forging an Alliance for Royalty-Free Video
Sounds nice and all, but part of me can't help but feel quite "eh" to see names like Netflix, Google and Microsoft in there, all responsible for bringing DRM into HTML and moving the open web more toward a closed one. So while they might champion for the open web in cases like these, it's obvious that the only thing they really care about is their bottom line and not paying license fees on video formats.
Daiz··on Using Waifu2x to Upscale Japanese Prints
Avisynth should run in Wine, but there is also Vapoursynth[1] (which works natively on OSX & Linux) and a NNEDI3 port[2] for it. After getting both of them up and running, a script like this[3] ran with the vspipe program that comes with Vapoursynth should do the trick. It's a bit cumbersome since Avisynth and Vapoursynth are primarily intended for processing video, not images, but it gets the job done in absence of a dedicated NNEDI3 resizing tool. I'm actually using this exact setup at work myself when I need to do any image upscaling.

[1] http://www.vapoursynth.com/

[2] https://github.com/dubhater/vapoursynth-nnedi3

[3] http://pastebin.com/3k9TEL7Y

Daiz··on Using Waifu2x to Upscale Japanese Prints
Well, OSX Preview seems to be doing something interesting as I can't seem to find an exact match with some quick attempts, but whatever method they use it looks rather similar to Lanczos scaling.
Daiz··on Using Waifu2x to Upscale Japanese Prints
NNEDI3, which I mentioned in another comment, can be used for video upscaling, and was in fact built for video processing in the first place.
Daiz··on Using Waifu2x to Upscale Japanese Prints
Waifu2x is not actually the first or only image scaler to use neural networks - NNEDI3[1], an Avisynth[2] filter used for deinterlacing can also do really nice image upscaling (and it's a lot faster than waifu2x). Here's an example of what it can do to the images in the blogpost:

Image 1: http://i.imgur.com/4cXr51v.png

Image 2: http://i.imgur.com/PZAXeM8.png

It doesn't come with any noise reduction, but nothing stops you from doing that separately from the upscaling process itself, and that way you should be able to control it better anyway (I find the reduction options provided by waifu2x really aggressive even with the low setting, it just kills tons of detail).

As a sidenote, when talking about something like image scaling, it would be a good idea to avoid saying something like "image scaled 2x (normally)" as there are lots of ways to scale images and what's "normal" can vary a lot depending on what you're using.

[1] http://bengal.missouri.edu/~kes25c/

[2] http://avisynth.org

Daiz··on Squarepusher virtual reality music video – WASD to look around
Just a note: Seeing as this is achieved by only showing (distorted) portions of the encoded video, using the 4K option is actually beneficial even if you don't have a 4K screen.

Here's a sample of what the encoded video looks like when viewed in a normal video fashion: http://i.imgur.com/SZmUMSF.jpg

Daiz··on Poll: Do you use GitHub stars for bookmarking or for “Liking”?
Primarily bookmarking. I just really wish you could create categories for your own stars (similar to how you can create your own playlists on YouTube for example), because it's really annoying having everything from "just something fun" to "actually useful for work" in just one big star pile that you can barely do anything about.
Daiz··on Paul's Extreme Sound Stretch
The author's homepage lists a bunch of interesting things where the software has been used and mentioned[1]. Personally I found it quite fitting on the Dredd 3D soundtrack on a song that it plays when people are using a drug called Slo-Mo, which slows the user's perception of time to 1% of normal.

[1] http://www.paulnasca.com/open-source-projects#TOC-Paul-s-Ext...

Daiz··on VP9: Faster, better, buffer-free YouTube videos
>With that said, I have to ask why these groups are interested in 10-bit

I can explain that - I wrote an extensive post on this matter a year back, so I'll just reuse that with a bit of tweaking. So with that clear, let's talk about the medium we're working with a bit first.

Banding is the most common issue with anime. Smooth color surfaces are aplenty, and consumer products (DVDs/BDs) made by "professionals" have a long history of terrible mastering (and then there's companies like QTEC that take terrible mastering to eleven with their ridiculous overfiltering). As such, the fansubbing scene has a long history with video processing in an effort to increase the perceived quality by fixing the various source issues.

This naturally includes debanding. However, due to the large smooth color surfaces, you pretty much always need to use dithering in order to have truly smooth-looking gradients in 8-bit. And since dithering is essentially noise to the encoder, preserving fine dither and not having the H.264 encoder introduce additional banding at the encoding stage meant that you'd have to throw a lot of extra bitrate at it. But we're talking about digital download end products here, with bitrates usually varying between 1-4 Mbps for TV 720p stuff and 2-12 Mbps for BD 720p/1080p stuff, not encodes for Blu-ray discs where the video bitrate is around 30-40 Mbps.

Because of the whole "digital download end products" thing, banding was still the most common issue with anime encodes back when everyone was doing 8-bit video, and people did a whole bunch of tricks to try to minimize it, like overlaying masked static grain on top of the video (a trick I used to use myself, and incidentally is something I've later seen used in professional BDs as well - though they seem to have forgot to properly deband it first). These tricks worked to a degree, but usually came with a cost in picture quality (not everyone liked the look of the overlaid static grain, for example). Alternatively, the videos just had banding, and that was it.

Over the years, our video processing tools got increasingly sophisticated. Nowadays the most used debanding solutions all work in 16-bit, and you can do a whole bunch of other filtering in 16-bit too. Which is nice and all, but ultimately, you had to dither it down to 8-bit and encode it, at which point you ran into the issue of gradient preservation once again.

Enter 10-bit encoding: With the extra two bits per channel, encoding smooth gradients suddenly got a lot easier. You could pass the 16-bit debanded video to the encoder and get nice and smooth gradients at much lower bitrates than what you'd need to have smooth dithered gradients with 8-bit. With the increased precision, truncation errors are also reduced and compression efficiency is increased (despite the extra two bits), so ultimately, if you're encoding at the same bitrate and settings using 8-bit and 10-bit, the latter will give you smoother gradients and more detail, and you don't really need to do any kind of processing tricks to preserve gradients anymore. Which is pretty great!

Now, obviously most people don't have 10-bit screens or so, so dithering the video down to 8-bit is still required at some point. However, with 10-bit, this job is moved from the encoder to the end-user, which is a much nicer scenario, since you don't need to throw a ton of bitrate for preserving the dithering in the actual encode anymore. The end result is that the video looks like such an encode on a 8-bit (or lower) screen, but without the whole "ton of bitrate" actually being required.

So the bottom line is that even with 8-bit sources and 8-bit (or lower) consumer displays, 10-bit encoding provides notable benefits, especially for anime. And since anime encoders generally don't give a toss about hardware decoder compatibility (because hardware players are generally terrible with the advanced subtitles that fansubbers have used for a long time), there really was no reason not to switch.

Daiz··on Show HN: JustWatch – Choose your favorite streaming providers and see what’s new
You know what would be interesting? If the site also had a filter for streaming/digital rental and digital buying. It'd be a pretty concrete example of how terrible the digital media buying landscape is as you'd see the list of titles shrink to basically nothing (since DRM-laden purchases obviously shouldn't count - that's just renting with an undefined rental period, not actual buying).

While you're at it, you could also add a country filter to have yet another way to reduce the list to nothing, showing yet another great feature of the legitimate digital media landscape - region locking!

Daiz··on Front End Developer – Interview Questions
You could use Function.prototype.bind in a couple ways, or even Array.prototype.map (though sadly you can't really do new Array(n).map, if that was true you could make this a one-liner).

    // new Array(n) could just be [] in all examples
    //
    // using Array.prototype.map
    // sadly you can't do new Array(n).map
    // because it doesn't iterate over undefined functions
    function foo(n) {
      for (var ret = new Array(n), i = 0; i < n; ++i) {
        ret[i] = i;
      }
      return ret.map(function(_,n) { return function() { return n; }; });
    }

    // using Function.prototype.bind in a couple ways
    function foo(n) {
      function num() { return +this; }
      for (var ret = new Array(n), i = 0; i < n; ++i) {
        ret[i] = num.bind(i);
      }
      return ret;
    }

    function foo(n) {
      function num(a) { return a; }
      for (var ret = new Array(n), i = 0; i < n; ++i) {
        ret[i] = num.bind(null, i); // could bind this to pretty much whatever here
      }
      return ret;
    }
Daiz··on MozJPEG 3.0
>Does anyone have experience with lossy png tools?

I do. Lossy PNGs work great for images with not a lot of colors. I use pngquant and optipng a lot in my work to compress a lot of PNG images with practically no visual quality loss.

For very colorful images, lossy (quantized & dithered) PNGs just don't work, though. They just end up looking nasty with larger filesizes than what high quality JPG gives you.

Daiz··on Daala progress update
I personally think the whole slider comparison method is pretty dumb - it makes direct comparison of certain image areas much harder (since you have to swivel your mouse around, not to mention how annoying this is on mobile) compared to a simpler solution where the whole image changes on mouse hover (which on mobile works nicely with a tap). This is how basically all screenshot comparison sites out there operate, and it really does work the best for the purpose of comparing two images like this.
Daiz··on Ask HN: What is the best JavaScript stack for a beginner to learn?
I'd say there are ways to combine both approaches - develop userscripts. While you can do tricks to use other libraries, simpler userscript development is easiest with just vanilla JS. It's how I got into JS myself - I first fixed up an userscript I was using that no longer worked, and then I used that userscript as a base to start building a more complex thing. Eventually I ended up completely rewriting the thing from scratch (and I did the same for the original userscript I fixed that started it all). I've been actually thinking of giving it another rewrite one of these days, this time opting to build the thing with Browserify...
Daiz··on BPG Image Comparison
Distributing HEVC content is royalty-free, even commercially[1] - however, royalties come into play with distributing encoders and decoders, and it's the latter that could cause problems (similar to the case of Firefox and H.264 decoding support).

[1] http://www.mpegla.com/main/programs/HEVC/Documents/HEVCweb.p... - page 7, HEVC License Terms

Daiz··on Why we should stop using Grunt and Gulp
The author has a follow-up post that addresses a lot of things that are also popping up in the comments here: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

EDIT: Also a HN submission by the author himself: https://news.ycombinator.com/item?id=8721929

Daiz··on ImageMagick, four point perspective distortion in a video
>As a fan of AviSynth, the scripts that I build often make that line look so, so simple. :)

And now imagine what those scripts would look like as an ffmpeg -vf command! That was basically the point - the -vf line is already pretty messy with just one range-applied command, and would become even more so if you started doing something more complicated. Avisynth on the other hand has actual scripts for the video processing, which scales to much more complex processing while still remaining accessible.

ffmpeg -vf might be good for doing one or two simple things to the whole video, but for anything more complex than that you really should use an actual video processing solution instead.

Daiz··on ImageMagick, four point perspective distortion in a video
>-vf "perspective=60:90:589:147:50:415:582:418:enable='not(between(n,0,149)+between(n,1488,2063))'"

Incidentally, this is a pretty big reason why I'd pick Avisynth over ffmpeg for video filtering any day of the week.

Daiz··on ImageMagick, four point perspective distortion in a video
With someone else mentioning Avisynth here in the comments (which is actually still used widely by video enthusiasts today), I became curious if there was a plugin for this sort of thing, and sure enough, I found Reformer[1]. With that, I figured I'd try reproducing OP's results. (By the way, while Avisynth is Windows software, as far as I know it works quite well under Wine).

Step 1: Download the video with youtube-dl. This gives us zelda.mp4 (original video) and zelda.m4a (extracted audio, requires ffmpeg)

    youtube-dl -x -k -o "zelda.%(ext)s" https://www.youtube.com/watch?v=rMXD5DxbXog
Step 2: Write the Avisynth script (in AvsPmod). Plugins used: LSMASHSource, Reformer, RemapFrames

    lwlibavvideosource("zelda.mp4")
    deskewed = q2r(last,"lanczos",60,90,51,412,588,148,581,417)
    normal = "[0 149] [1488 2063]" # frame ranges where to use original video
    ReplaceFramesSimple(deskewed,last,mappings=normal)
Plugins used: LSMASHSource, Reformer, RemapFrames

Step 3: Pipe it to x264 with avs2yuv (necessary under Wine and with 32-bit Avisynth & 64-bit x264) to encode the video.

    avs2yuv zelda.avs -o - | x264 --preset slower --crf 16 -o zelda.mkv - --demuxer y4m
Step 4: Merge encoded video and original audio back together with mkvmerge from mkvtoolnix. You could use ffmpeg here as well, but I find mkvmerge much nicer for simple muxing like this.

    mkvmerge -o zelda_muxed.mkv zelda.mkv zelda.m4a
And with that, we're done. The whole process took about 20 minutes (of which ~13min was spent encoding the video) and a few hundred megabytes of space (since there's no need to have all the frames as individual image files several times over). Other benefits include having the video run at the original framerate of 29.970 (OP's video runs at 25.000 since he forgot to set the framerate when encoding the processed images), including the audio as well not having distorted picture when the TV isn't visible (which was simple enough to do with the ReplaceFramesSimple function from RemapFrames). You can see the end result here:

https://www.youtube.com/watch?v=Jk_z4TiweHs

[1] http://www.avisynth.nl/users/vcmohan/Reformer/Reformer.html

Daiz··on BPG Image format
Hmm, that does make me wonder, actually - as far as I know, you can freely distribute source code for encoders & decoders without having to pay any royalties. Binaries / compiled versions are where the royalties come in. And technically, JS code is source code that gets compiled by the browser... so I'm not actually sure where it falls in all this.
Daiz··on BPG Image format
I wouldn't be in such a hurry - right now x265 (as far as I know the best HEVC encoder) still loses to x264 in terms of practical use (you only really get better results by using bitrates so low that the end product will look terrible anyway, and x265 loses hard to x264 quality-wise when encoding at similar bitrate and speed). Considering that x264 is backed by about a decade's worth of development, this isn't that surprising.
Daiz··on BPG Image format
You can actually use HEVC for your content for free, even commercially.

Royalties only get involved when distributing encoders & decoders.

See page 7 here http://www.mpegla.com/main/programs/HEVC/Documents/HEVCweb.p...

Daiz··on TinyJPG – compress JPEG files with a balance between quality and file size
Gotta say I really don't like all these sites that re-encode images (even more so with videos) and claim that "we can reduce filesize with, like, no quality loss using our Super Duper Compression Magic!" Because no, it's not magic, you're just re-encoding images, and possibly doing lossless optimizations on top of that (though who knows, they might even think the re-encoding is all the "optimization" an image might need already). Just look at this quick comparison I made, you can clearly see the JPG compression artifacts in the TinyJPG "optimized" version (which turned my optimized 1.27MB original JPG into a crummy-looking 431KB JPG): http://screenshotcomparison.com/comparison/101286 (this is a crop from the original image).

Rather than letting a service re-encode your images, you should rather use something that just optimizes them in an actual lossless fashion (optipng, mozjpegtran, or any service that makes use of these), and if you want to squeeze them to an even smaller size in a lossy fashion, then just save your JPGs at lower quality yourself or quantize your PNGs in a controlled fashion (pngquant does a pretty great job with that) - this is especially true with the latter, because haphazard color reduction with PNGs can lead to completely awful-looking results with higher-res images with lots of colors. Here's a comparison for that too: http://screenshotcomparison.com/comparison/101289

Bottom line: Feel free to apply lossless optimizations to your heart's content, but anything more than that you're better off just saving to lower JPG quality yourself to begin with (you'll get better results this way too since you're doing just a single lossy encode instead of two) or quantizing your PNGs yourself, provided you actually care about the quality of your images.

EDIT: Figured I could post some more images.

1. Original source image: http://blisswater.info/images/tiny/original.png (4987 KB) 2. JPG quality 90 encode: http://blisswater.info/images/tiny/encoded-q90.jpg (1033 KB) (encoded with ImageMagick using convert original.png -quality 90 encoded-q90.jpg) 2. Optimized JPG Q90: http://blisswater.info/images/tiny/encoded-q90-optimized.jpg (978 KB) (lossless optimization with mozjpegtran -copy none -outfile encoded-q90-optimized.jpg encoded-q90.jpg) 4. TinyJPG result with original.png as source: http://blisswater.info/images/tiny/encoded-tinyjpg.jpg (1581 KB) 5. TinyJPG result with encoded-q90.jpg as source: http://blisswater.info/images/tiny/encoded-q90-tinyjpg.jpg (485 KB)

As you can see by comparing 2 and 5, there is a very notable quality loss as a result of the TinyJPG re-encode. What's even more interesting is that if you want to avoid double conversion by uploading JPGs, TinyJPG will actually quantize your PNGs first (like their TinyPNG service does), as can be seen in 4 - this is something I was not expecting and find rather baffling as it quite notably alters the source image on its own even before the JPG compression.

Daiz··on Mobile Last?
>There's a real argument that in a hackathon 10% extra time isn't worth it, but in the real world where you don't always have 48 hour time limits I've always been in the opinion that the initial time investment is far outweighed by the benefits and the additional cost that you would incur by making it mobile-ready later (which usually requires either rebuilding the frontend templates from scratch or hacking away at the existing codebase in a way that is far less organized/sustainable).

Oh, I completely agree with this. I'd say that even during hackathons, mobile is definitely something you should keep in mind when you're building your design, markup, etc. just like you normally would so that things will be easier in the long run. However, the key thing is that when you hit something that would be easy to deal with on desktop but hard on mobile, you should just go the easy desktop route and leave the mobile solution for later (post-hackathon). And when you're building web apps, those kinds of moments will pretty much inevitably come because mobile is hard - compared to desktop, you will generally speaking always have less screen real estate (and input elements need to be larger, making it even smaller), a lot less processing power, lack of precise pointer input and hover (touch vs mouse), etc etc.

Again, the point here is the difference between building websites and web apps. With websites, your biggest concerns are generally that the site scales nicely to various screen sizes and that links are comfortably clickable (and that it all looks nice). This wouldn't be all that hard to do even under time constraints. Web apps on the other hand generally feature a lot more (single-page) interactivity, and getting that right is a lot harder.

← PreviousPage 3 of 7Next →