profile
viewpoint

mapbox/node-sqlite3 4434

Asynchronous, non-blocking SQLite3 bindings for Node.js

limonte/dear-habr 87

:incoming_envelope: Открытое письмо Хабрахабру от любящих юзернеймов

Mithgol/FGHI-URL 9

Fidonet Global Hypertext Interface — Uniform Resource Locators

Mithgol/dauria 8

Node.js module for Data URI applications. It performs conversions between Node.js Buffers and RFC2397-compliant Data URIs, or vice versa.

Mithgol/node-abstract-syntax-tree 7

An implementation of AST (abstract syntax tree) for Node.js. Can be used to build renderers of markup languages.

Mithgol/Hello-Habrahabr 4

A helloworld-alike application to illustrate my blog entries on Habrahabr.Ru about node-webkit.

Mithgol/fido2rss 3

Makes RSS feeds out of Fidonet echomail.

Mithgol/fidorest 3

Fidonet RESTful API

Mithgol/agedays 2

Reports a given file's age (in days).

issue commentgoogle/brunsli

brunsli.dev cannot decode JPEG compressed by recent cbrunsli.exe builds (CMake build 78 and newer)

Is it fine for the newer cbrunsli to generate a slightly larger compressed file? (I know the difference is less than 1%, but…)

Mithgol

comment created time in 4 days

issue openedgoogle/brunsli

brunsli.dev cannot decode JPEG compressed by recent cbrunsli.exe builds (CMake build 78 and newer)

Looks like an interoperability problem. Steps to reproduce:

Step 1. We'll use the following “why is the Internet like this” meme (quoted from “Oshi no Ko” manga) as an example JPEG:

(why is the Internet like this)

Download it.

Step 2. Let's confirm that the problem is (relatively) recent.

Visit the “Actions” section and open the page of CMake build 77. Its “windows” artifact looks like that:

windows.zip

Unpack cbrunsli.exe from this ZIP to the subdirectory where the meme from step 1 resides.

Run the command cbrunsli.exe "why is the Internet like this.jpg" in that subdirectory.

The following why is the Internet like this.jpg.brn file (55141 bytes long) is generated (see in the attached ZIP):

why is the Internet like this 1.zip

Dragging and dropping that file to https://brunsli.dev/ generates a decoded picture:

(screenshot)

Step 3. Let's confirm where the problem started.

Visit the “Actions” section and open the page of the next CMake build: CMake build 78. Its “windows” artifact looks like that:

windows78.zip

Unpack cbrunsli.exe from this ZIP to the subdirectory where the meme from step 1 resides (replacing cbrunsli.exe that was unpacked by the previous step).

Run the command cbrunsli.exe "why is the Internet like this.jpg" in that subdirectory.

The following why is the Internet like this.jpg.brn file (55483 bytes long) is generated (see in the attached ZIP):

why is the Internet like this 2.zip

Its difference from the result of step 2 is made obvious by its different filesize.

Dragging and dropping that file to https://brunsli.dev/ generates an error message (“Reconstuction failed”):

(screenshot)

Step 4. Let's confirm that the problem persists.

Visit the “Actions” section and open the page of the latest CMake build: CMake build 85. Its “windows” artifact looks like that:

windows85.zip

Unpack cbrunsli.exe from this ZIP to the subdirectory where the meme from step 1 resides (replacing cbrunsli.exe that was unpacked by the previous step).

Run the command cbrunsli.exe "why is the Internet like this.jpg" in that subdirectory.

Confirm that the generated file why is the Internet like this.jpg.brn has the same filesize (55483 bytes) as the file generated by step 3 and that files' contents do not differ.

Dragging and dropping that file to https://brunsli.dev/ generates the same error message (“Reconstuction failed”).

(However, newer dbrunsli.exe correctly decodes files generated by the corresponding newer cbrunsli.exe.

Does that mean that https://brunsli.dev/ needs an update?)

created time in 4 days

issue commentshssoichiro/oxipng

Please support running in parallel across multiple files

Oxipng would then need some hotkeys to pause (and later to resume) such processing — the keys you'd press when you suddenly need some free CPU cores.

Software flow control of Ctrl+S and Ctrl+Q does not pause immediately (it just prevents new threads from running, but the threads already in progress may take many minutes to finish in Zopfli mode).

Oxipng that is not running in parallel across multiple files (i. e. is running in a simple for loop) can be somewhat “paused” by terminating the current instance of oxipng (by Ctrl+C) and can be later resumed by finally answering “No” to the operating system's question of whether the outer for loop should be broken:

(screenshot)

Of course by such “pause” you'd lose the results of your current file's processing and would have to re-run oxipng on that file later or in a parallel window. But at least there's some way to free some CPU cores from oxipng when you need them.

But if there's no outer loop and oxipng loops itself in parallel across multiple files — well, then you won't Ctrl+C to terminate; you'd fear to lose all the progress and won't be able to resume. And thus such improved oxipng would likely need some pause/resume hotkeys of its own.

joshtriplett

comment created time in 5 days

issue commentshssoichiro/oxipng

feature request: report interlaced files

Oxipng also does not seem to report interlacing or deinterlacing in progress (though it happily reports color reductions such as “Reducing image to 1x8 bits/pixel, Grayscale” for example) and thus may eventually lead some of its users to believe that intended deinterlacing never happened and that a re-run (with --force for #62) is necessary.

Mithgol

comment created time in 17 days

issue openedshssoichiro/oxipng

feature request: report interlaced files

OptiPNG reports interlaced files when encountered (such as “1280x720 pixels, 3x8 bits/pixel, RGB, interlaced” for example) even if -i is not given in the command line.

Oxipng should probably report such files as well because it may remind the user that an option to run the optimization again (adding --interlace 0 or --interlace 1 where appropriate) is available.

created time in 17 days

pull request commentipfs-shipyard/ipfs-companion

feat: pop-up menu and share page tweaks

Removes global gateway toggle per conversations with @olizilla and @lidel (don't panic, it's still in preferences page)

Congratulations, y'all have just made some quick decisions (“Does the global gateway currently have a copy of this IPFS resource? Can I share its global URL in Telegram and expect Telegram to generate a preview under my message? Can I share its global URL in Twitter and expect Twitter to generate a Twitter Card under my message?”) significatly less quicker.

This toggle is not even on the first page of the preferences. It becomes necessary to scroll the preferences.

jessicaschilling

comment created time in a month

issue commentspillerrec/Overmix

Unknown crash during aligning

AverageAligner has a tendency to crash sometimes.

I believe that a newer anime “Uzaki-chan wa Asobitai!” has a sequence of frames that reliably “always” (instead of “sometimes”) causes a crash in Overmix version 0.4.0 alpha 3 on Windows.

Steps to reproduce:

Step 1. Unpack https://github.com/spillerrec/Overmix/releases/download/v0.4.0-alpha3/Overmix.v0.4.0-alpha3.win64.7z to an empty folder.

Step 2. Unpack 52 PNG files (00006.png, 00007.png, …, 00057.png) from the following four ZIP archives:

00006-00021.zip

00022-00032.zip

00033-00044.zip

00045-00057.zip

(There has to be four of them because of GitHub's 15 MB limit.)

Step 3. Launch Overmix (unpacked in step 1), open PNG files (unpacked in step 2) in order of their numbering.

Step 4. Check the “Comparing” checkbox.

Step 5. Set “Movement directions” to “Both”.

Step 6. Click the “Align&Draw” button.

Console reports this issue (#116) and then an access violation:

(screenshot)

(An obvious workaround is to stay on version 0.4.0 alpha 2 until this issue is fixed.)

spillerrec

comment created time in a month

issue commentspillerrec/Overmix

Upload new release binary

ZIP and 7-Zip archives currently attached at https://github.com/spillerrec/Overmix/releases/tag/v0.4.0-alpha3 are the same archives (with byte-by-byte equality) that were attached at https://github.com/spillerrec/Overmix/releases/tag/v0.4.0-alpha2 and they're even named with the same “-alpha2” suffix.

They do not look like the new files generated by the newer development environment.

Scyntrus

comment created time in a month

issue commentmarklieberman/foxygestures

Right Click context menu is not showing up on html5 videos/containers, when gesture key is also the right mouse button

Has this issue ever been reported to the developers of Firefox? — for example, is the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1180031 the same or not?

tokariu

comment created time in 2 months

issue closedgoogle/brunsli

Brunsli cannot decode JPEG that was compressed in JPEG XL's reference software's unofficial build

Looks like an interoperability problem. Steps to reproduce:

Step 1. We'll use the following picture of the “Dude! Let Me In! I'm A Fairy!” meme:

(“Dude! Let Me In! I'm A Fairy!”)

Step 2. When I drag-and-drop the meme at https://google.github.io/brunsli/ to the transcoder, the following JPEG XL file is created:

(ZIP archive of Brunsli's JXL file)

When I drag the JPEG XL file back to the transcoder, the returned JPEG file is byte-by-byte equivalent of the original (step 1), I can confirm it using fc /b original.jpg decoded.jpg on Windows.

Step 3. This time I'll try to repeat step 2 using JPEG XL's reference software. I do not build it myself; I'll use an unofficial build (for Windows) distributed by user Jamaika on Doom9 forum; that build is originally hosted on sendspace.com, but here's a backup copy:

(ZIP archive of Jamaika's build of JPEG XL's reference software)

When I run cjpegxl_jxl --version it reports version 0.0.1-6334944f (seems to correspond to the latest commit in the public repo of JPEG XL's reference software).

When I run cjpegXL_jxl -s 9 on the original JPEG file on Windows, the following JPEG XL is created:

(ZIP archive of JXL file generated by Jamaika's build)

When I run djpegXL_jxl --jpeg on this result, the following JPEG file is decoded:

(step 3 decoded meme)

Its size (84 836 bytes) is larger than original's (80 496 bytes) and it lacks all of the Exif metadata of the original JPEG. However, ImageMagick's comparison magick compare -metric ae original.jpg decoded.jpg nul reports that these files are equal pixel-by-pixel, though not byte-by-byte.

Step 4. When I drag-and-drop the JPEG XL file from step 3 (generated by Jamaika's build) at https://google.github.io/brunsli/ to the transcoder, the following error appears:

(screenshot)

Brunsli cannot decode the JPEG file that was compressed in JPEG XL's reference software's unofficial build.

Step 5. Vice versa, when I use Jamaika's build's djpegXL_jxl --jpeg on Brunsli's JPEG XL file (from step 2), the following JPEG file is decoded:

(Brunsli's JPEG XL file decoded by Jamaika's build)

It has the same number of bytes (84 836 bytes) that Jamaika's build's decoded from its own JPEG XL (step 3), but much worse quality.

The above steps were performed in Windows 7 Professional 64-bit (Service Pack 1) running on Intel Core i7-3770 CPU.

The results may indicate that Jamaika's build is built incorrectly.

The results may also indicate that JPEG XL's reference software's authors tried to fix their own version of #80 but failed (the decoded JPEG file started to retain only pixel-by-pixel compatibility instead of its former byte-by-byte, but what's the point if the decoded file becomes larger, and lacks metadata, and does not have full interoperability with https://google.github.io/brunsli/ then).

Would someone kindly make their own build of JPEG XL's reference software and check what's really going on?

closed time in 2 months

Mithgol

issue commentgoogle/brunsli

Brunsli cannot decode JPEG that was compressed in JPEG XL's reference software's unofficial build

Brunsli encoder has a separate CLI and Brunsli decoder is not (yet) included in JXL CLI.

It makes sense, and thus the issue's closed.

Mithgol

comment created time in 2 months

issue openedgoogle/brunsli

Brunsli cannot decode JPEG that was compressed in JPEG XL's reference software's unofficial build

Looks like an interoperability problem. Steps to reproduce:

Step 1. We'll use the following picture of the “Dude! Let Me In! I'm A Fairy!” meme:

(“Dude! Let Me In! I'm A Fairy!”)

Step 2. When I drag-and-drop the meme at https://google.github.io/brunsli/ to the transcoder, the following JPEG XL file is created:

(ZIP archive of Brunsli's JXL file)

When I drag the JPEG XL file back to the transcoder, the returned JPEG file is byte-by-byte equivalent of the original (step 1), I can confirm it using fc /b original.jpg decoded.jpg on Windows.

Step 3. This time I'll try to repeat step 2 using JPEG XL's reference software. I do not build it myself; I'll use an unofficial build (for Windows) distributed by user Jamaika on Doom9 forum; that build is originally hosted on sendspace.com, but here's a backup copy:

(ZIP archive of Jamaika's build of JPEG XL's reference software)

When I run cjpegxl_jxl --version it reports version 0.0.1-6334944f (seems to correspond to the latest commit in the public repo of JPEG XL's reference software).

When I run cjpegXL_jxl -s 9 on the original JPEG file on Windows, the following JPEG XL is created:

(ZIP archive of JXL file generated by Jamaika's build)

When I run djpegXL_jxl --jpeg on this result, the following JPEG file is decoded:

(step 3 decoded meme)

Its size (84 836 bytes) is larger than original's (80 496 bytes) and it lacks all of the Exif metadata of the original JPEG. However, ImageMagick's comparison magick compare -metric ae original.jpg decoded.jpg nul reports that these files are equal pixel-by-pixel, though not byte-by-byte.

Step 4. When I drag-and-drop the JPEG XL file from step 3 (generated by Jamaika's build) at https://google.github.io/brunsli/ to the transcoder, the following error appears:

(screenshot)

Brunsli cannot decode the JPEG file that was compressed in JPEG XL's reference software's unofficial build.

Step 5. Vice versa, when I use Jamaika's build's djpegXL_jxl --jpeg on Brunsli's JPEG XL file (from step 2), the following JPEG file is decoded:

(Brunsli's JPEG XL file decoded by Jamaika's build)

It has the same number of bytes (84 836 bytes) that Jamaika's build's decoded from its own JPEG XL (step 3), but much worse quality.

The above steps were performed in Windows 7 Professional 64-bit (Service Pack 1) running on Intel Core i7-3770 CPU.

The results may indicate that Jamaika's build is built incorrectly.

The results may also indicate that JPEG XL's reference software's authors tried to fix their own version of #80 but failed (the decoded JPEG file started to retain only pixel-by-pixel compatibility instead of its former byte-by-byte, but what's the point if the decoded file becomes larger, and lacks metadata, and does not have full interoperability with https://google.github.io/brunsli/ then).

Would someone kindly make their own build of JPEG XL's reference software and check what's really going on?

created time in 2 months

more