Open remmel opened 3 years ago
This is not a fix, but I used fast-png
lib which handle 16 grayscale:
import {decode} from 'fast-png'
[...]
var binDepth = await((await fetch(urlDepth)).arrayBuffer())
let depthPng = await decode(binDepth)
depthPng.data
I have the same problem. Jimp is a very nice tool. You can see that there is a lot of ability and passion behind it. But it's a pity that after almost two years, despite several releases, this error has still not been fixed. That's why I use fast-png as well. The really big shortcoming of fast-png is that it doesn't work with workers. In the scientific field, 8 bits are not enough, 16 bits are very important. If jimp ran with workers and 16 bit, it would be the perfect choice for science
If anyone here want to submit a PR I'm happy to review and merge!
looking into pngjs3 https://github.com/gforge/pngjs3/issues/96
Jimp browser convert my 16 bit grayscale into 8 bit RGBA image (8x4=32 bits) because R=G=B= my original gray, quality is lost as my gray was in 16 bits but R or G or B are in 8 bits. The convertion made by jimp is
>> 8
The tested image is PNG: 640x480 16 bit grayscale ImageMagick:
Expected Behavior
jimpSrc.bitmap.data=Uint8Array(614400) [0, 0, 0, 0, 32, 21, 32, 21, 34, 137,...]
orjimpSrc.bitmap.data=Uint16Array(307200) [0, 0, 8213, 8213, 8841, ...]
(32*256+21=8213 for the 3rd pixel)Current Behavior
jimpSrc.bitmap.data=Uint8Array(1228800) [0, 0, 0, 255, 0, 0, 0, 255, 32, 32, 32, 255, 32, 32, 32, 255, ...]
with thus R=G=B=my_gray>>8 and A=255 And thus for the 3rd pixel32<<8=8192 != 8213
Steps to Reproduce
https://jsfiddle.net/remmel/yvmketx0/
Debugging
Debugging the js code:
FilterSync.process(inflatedData, metaData);
) becauseunfilteredData=Uint8Array(614400) [0, 0, 0, 0, 32, 21, 32, 21, 34, 137,...]
var bitmapData = bitmapper.dataToBitMap(unfilteredData, metaData);
is incorrectVersion
FYI, this bug is related with Stackoverflow question and the PNG 16bit grayscale comes from TUM and represents depth maps