1 bit support?

[pnwk112]

I'm trying to add GeoTiff with 1 bit per sample (black and white) and I'm getting this error:

Uncaught (in promise) Error: Unsupported data format/bitsPerSample
    at arrayForType (geotiffimage.js?5c03:55)
    at GeoTIFFImage._callee3$ (geotiffimage.js?5c03:420)
    at tryCatch (runtime.js?4a57:63)
    at Generator.invoke [as _invoke] (runtime.js?4a57:337)
    at Generator.prototype.(/temp/anonymous function) [as next] (webpack-internal:///93:96:21)
    at step (asyncToGenerator.js?7b11:17)
    at eval (asyncToGenerator.js?7b11:35)
    at new Promise (<anonymous>)
    at new F (_export.js?90cd:35)
    at GeoTIFFImage.eval (asyncToGenerator.js?7b11:14)

Thanks for any reply.

[constantinius]

Hi @getDOKI,
thanks for opening this issue!
Unfortunately, I did not get around to implement non-multiple-of-8 bit support.
In theory, this should not be too hard, but I simply lack the time and resources for the effort.
I'll leave this issue open, in case someone wants to contribute or until I get around to do it myself.

[DanielJDufour]

Hi, @getDOKI . I'd love to take on this task. Do you have an example 1-bit file that you want decoded by geotiff.js?

[pnwk112]

Hi, @DanielJDufour thanks for your reply. I will be very grateful if you will be able to add 1 bit support. Here is the 1-bit tiff image.
1bit.zip

[constantinius]

@DanielJDufour @getDOKI
I already implemented n-bit support (up to 24 bits) for unsigned integer data. It is available in the branch 'n-bit-support'.
Could you please test it and see if it suits your need?

[DanielJDufour]

Will do!

[DanielJDufour]

I'm writing some tests now for this including testing the 1bit.tiff @getDOKI has provided.

[constantinius]

@DanielJDufour
I already tried, and I ran into the issue that the CCITTRLE (Fax Group 4) compression is used in the file which is currently not supported. I tried to quick an dirty use the implementation of PDF.js, but failed to get it to work. I'd love to, but I'm out of time to do an implementation right now.
I think doing a gdal_translate to use a different compression should do the trick

[DanielJDufour]

Hey, @getDOKI and @constantinius . Just wanted to give you an update. I copied the n-bit-support branch and add a test for a 2-bit raster. Everything looks good so far! I plan on adding some more tests before it's ready for merging. I'll probably work on the Fax Group 4 decoding issue after the n-bit support is merged. You can view my progress here: #75

And if you have any rasters of different n-bit length that I can test, please attach those. Thanks! :-)

[constantinius]

You can generate n-bit tiffs using gdal_translate like so: gdal_translate -of GTiff -co TILED=YES -co BLOCKXSIZE=32 -co BLOCKYSIZE=32 -co NBITS=1 -ot Byte stripped.tiff 1.tif

[DanielJDufour]

@constantinius , I updated my PR to point to your n-bit-support branch. There was an issue with getUint32 with a 17-bit raster that I noted here: #75

Open to your thoughts. I'm not a pro on bit-math, so definitely open to your guidance :-)

[DanielJDufour]

FYI: I've made some progress with adding n-bit-support. I've completed writing code that passes tests for stripped big-endian TIFFs with between 1 and 32 bits (and currently supported compressions). I now need to check if it works on rasters with internal tiling and numbers stored as both little endian. I'll clean the code up and hopefully submit a final pull request within the next month.

[DanielJDufour]

PR for adding support for unsigned integers of 1-32 bits is ready for review: #78

However, it doesn't include support for CCITTRLE (Fax Group 4) Compression, which I'll work on on a separate branch.

[youyouliangshao]

Has this problem been solved yet, i've met the same problem with “arrayForType“ function params that "bitsPerSample=1"

[DanielJDufour]

@youyouliangshao , thanks for your interest. Unfortunately, this problem hasn't been solved yet. I still have work to do on #78. Unfortunately, I'm busy at the moment and don't expect finding time within the next few months to contribute to it. Would you like to contribute to it? We could sure use your help :-)

[youyouliangshao]

@youyouliangshao , thanks for your interest. Unfortunately, this problem hasn't been solved yet. I still have work to do on #78. Unfortunately, I'm busy at the moment and don't expect finding time within the next few months to contribute to it. Would you like to contribute to it? We could sure use your help :-)

Im afraid i can't do any help for you , its too busy for developers in china ,996 you know

[definitelyme]

Anyone added this yet?