You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 27, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 27, 2020. It is now read-only.
In the XML of another (HP) user, I saw <pwg:DocumentFormat>application/octet-stream</pwg:DocumentFormat>. That may be a raw pixel format that - if you can identify the data layout - be converted to tiff. You can check what your printer supports easily, the XML is not hard to read.
Super, thank you for taking the time to look into this. I haven't yet gotten back to this project, but I will take a closer look at the XML the printer outputs and update the thread with my findings. You can close this out if you like. Thanks!
In the XML of another (HP) user, I saw <pwg:DocumentFormat>application/octet-stream</pwg:DocumentFormat>. That may be a raw pixel format that - if you can identify the data layout - be converted to tiff. You can check what your printer supports easily, the XML is not hard to read.
Personally, I wouldn't fancy taking on that task. It would be easier to use ImageMagick's convert utility to get a tiff from a jpeg, either after scanning or by modifying Scan.py. Besides, the existence of application/octet-stream and its purpose as a DocumentFormat would need exploring.
The 'application/octet-stream' document format is used to tell the printer it
should automatically detect the format. Detection accuracy varies widely
between printers, so you should specify the actual format whenever possible.
Well, JPEG is a lossy compression, and IIRC it only allows 24 bit color depth (or 8 bit grayscale). You can't undo the lossy compression by converting to tiff later...
That is why 'raw' formats are popular with digital cameras; and I would assume that at least some scanners will provide a similar 'raw' format, probably with a raw bit depth, too. For some scanners, the x and y resolutions also vary, and jpeg may not be able to fully represent this (without distortion in all standard viewers). So I wouldn't be surprised if you just cannot make all the advertised functionality with jpeg alone.
Raw formats may not have a mime type assigned, and then application/octet-stream is probably an okay choice to allow the official driver to select the raw format. So my guess is that this is the uncompressed raw format.
Activity
kno10 commentedon Jan 3, 2019
The printer I have only offered JPEG if I recall correctly. Check the XML file with the options.
kno10 commentedon Jan 9, 2019
In the XML of another (HP) user, I saw
<pwg:DocumentFormat>application/octet-stream</pwg:DocumentFormat>. That may be a raw pixel format that - if you can identify the data layout - be converted to tiff. You can check what your printer supports easily, the XML is not hard to read.trumad commentedon Jan 10, 2019
Super, thank you for taking the time to look into this. I haven't yet gotten back to this project, but I will take a closer look at the XML the printer outputs and update the thread with my findings. You can close this out if you like. Thanks!
debiantriage commentedon Jan 21, 2019
Personally, I wouldn't fancy taking on that task. It would be easier to use ImageMagick's convert utility to get a tiff from a jpeg, either after scanning or by modifying Scan.py. Besides, the existence of application/octet-stream and its purpose as a DocumentFormat would need exploring.
https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippguide-20180918.pdf
kno10 commentedon Jan 21, 2019
Well, JPEG is a lossy compression, and IIRC it only allows 24 bit color depth (or 8 bit grayscale). You can't undo the lossy compression by converting to tiff later...
That is why 'raw' formats are popular with digital cameras; and I would assume that at least some scanners will provide a similar 'raw' format, probably with a raw bit depth, too. For some scanners, the x and y resolutions also vary, and jpeg may not be able to fully represent this (without distortion in all standard viewers). So I wouldn't be surprised if you just cannot make all the advertised functionality with jpeg alone.
Raw formats may not have a mime type assigned, and then application/octet-stream is probably an okay choice to allow the official driver to select the raw format. So my guess is that this is the uncompressed raw format.