Add PngByteQRCode type about qrcoder HOT 14 CLOSED

Hm, than I don't understand, why you're raising issues and spending your time on a project, which you never have used. Anyway - I attached a png from the lib to this post. (Maybe it's not full standard compliant, but it gets shown without trouble in all webbrowser and windows image viewers I checked. So in general it's fine for me. I prefer a 95% solution over having nothing, because a feature isn't 100% perfect.)

from qrcoder.

Meanwhile I checked the above QRCode with "pngcheck".
Result:

PS C:\Users\RCC-Herrmann\Downloads\pngcheck-2.3.0-win32> .\pngcheck.exe -vt C:\tmp\test.png
File: C:\tmp\test.png (429 bytes)
  chunk IHDR at offset 0x0000c, length 13
    580 x 580 image, 1-bit grayscale, non-interlaced
  chunk IDAT at offset 0x00025, length 372
    zlib: deflated, 32K window, default compression
  chunk IEND at offset 0x001a5, length 0
No errors detected in C:\tmp\test.png (3 chunks, 99.0% compression).

The last line (No errors detected in C:\tmp\test.png (3 chunks, 99.0% compression).) sounds good for me. Let me know, what your tool gives as result.

from qrcoder.

Ok, I think I get an idea what you mean. But that's about my level/knowledge about PNG. If you're able to implement this, feel free to make the needful changes and send in a pull request. So far I will live with solution as it is now. Maybe it's not perfect, but it's better than nothing.

from qrcoder.

Hi @pontusi hi @Hydroque ,
now you've left me behind. As I said am not a PNG expert.

@Hydroque - I'm not able to do this changes easily, so I take your offer to send in a pull request. But I think also, that @pontusi had a valid point and this changes should be added as extra mode/option, so that the user can choose if he wants to go with palettes or with channels.

from qrcoder.

By the help of @pontusi we now have also a raw PNG renderer, which has support for multiple platform.

Pull request: #91
Smaller fixes: 2b98d81 , ab86050 , 9279b52 , 247da1c
Wiki entry: https://github.com/codebude/QRCoder/wiki/Advanced-usage---QR-Code-renderers#25-pngbyteqrcode-renderer-in-detail

Thus this issue can be closed. If needed, feel free to re-open this issue later or open a new issue.

from qrcoder.

Sorta OT, but have you tried loading the png in with libpng or something? libpng warns if an invalid png (which is indeed an old version of png) gets loaded. Go ahead and zip a png file generated and I can test it.

from qrcoder.

Hi @Hydroque ,

just check out the latest code and generate a .png-file yourself. I think this is easier, than generating one and sending it to you.

from qrcoder.

Not really. I haven't actually ever used this library. I just provide needful clarification.

from qrcoder.

You produced a grayscale image, which could be problematic when trying to implement QR codes with color? Especially having to force people to rewrite png loader section and specify specifically to the render api that we are using a monocolor image with it - which probably means a new shader... if they haven't already. This does tack on a lot, so resaving it would be something someone would have to do I guess.

from qrcoder.

Hi @Hydroque ,

it's a grayscaled image because only black and white is used. A coloured code, like attached, produces a valid PNG with color palettes:

PS C:\Users\Raffael Herrmann\Downloads> .\pngcheck.exe -vt c:\tmp\color.png
File: c:\tmp\color.png (447 bytes)
  chunk IHDR at offset 0x0000c, length 13
    580 x 580 image, 1-bit palette, non-interlaced
  chunk PLTE at offset 0x00025, length 6: 2 palette entries
  chunk IDAT at offset 0x00037, length 372
    zlib: deflated, 32K window, default compression
  chunk IEND at offset 0x001b7, length 0
No errors detected in c:\tmp\color.png (4 chunks, 98.9% compression).

So for me this looks ok. But I have to admit, that I don't understand what you mean with:

Especially having to force people to rewrite png loader section and specify specifically to the render api that we are using a monocolor image with it - which probably means a new shader... if they haven't already. This does tack on a lot, so resaving it would be something someone would have to do I guess.

Why should someone re-save a graphic/png-file if it renders without problems?

from qrcoder.

With palettes, you now force people to have to render the image without palettes to get a displayable image - which happens at loading time. Palettes are old are depreciated anyways.

They should resave it so it is unpaletted and a uniform 3 bytes. The compression will note and take care of this to make it grayscale if it is truely grayscale.

from qrcoder.

Solution is easy, and I am being picky here. Say in opengl, you need to define how many color channels an image has. It is usually GL_RED, GL_RGB, and GL_RGBA. With compression, GL_RED (1 color channel, ie grayscale) is indeed an optimization, but that means the user will have to change to GL_RGB (3 color channel) if they want to color it many different colors other than 2. The lack of support for RGB and RGBA can be troublesome for usability.

So just use 3 color channels, and no palette.

If this isn't something you can do easily or add easily I will think about making a pull request. Turn your attention elsewhere, but I do indeed people will run into problems with this format. Especially if they decode the image themselves rather than go with a library or have to rewrite sections of their code to support GL_RED per se.

from qrcoder.

Those are som unsubstantiated claims. Palettes are most certainly not deprecated in the PNG standard and tools like pngcrush will always reduce an image to palettes when possible. I'd prefer not to reduce compression for the general case to support the special case that @Hydroque is dealing with, though I guess you could add an extra mode.

from qrcoder.

@pontusi Some things that have affected me in the past as an OpenGL programmer - where I load in images myself. Reducing to palettes call for load time setup. Anything that isn't raw image data does. Converting from paletted grayscale to grayscale doesn't introduce a size different because of the compression algorithm. I suspect it is noting the lengths of the white horizontal lines and the black boxes and reducing it so. I suspect no such loss in file size that matters.

from qrcoder.