Comments (8)
Complete means tEXt, zTXt, iTXt. Former two use Latin 1, last one UTF-8. There's also a minor complication in that these chunks can be at both ends of the file, the end user probably doesn't want to keep that distinction.
libpng simply accumulates them (though you need to read the start and end chunks both explicitly, unless using the constrained API) and then you can read an array out of the info structure. spng is rather similar.
What I'm doing is requesting values for particular keys, and I'm not interested in “translated keywords”. There can be multiple values for a given key, and the simplest viable high-level API is func(keyword string)[]string
. ISO 8859-1 is trivially converted to UTF-8, so that defines the encoding. A low-level API would call back with:
struct {
keyword, text string
languageCode, translatedKeyword *string
}
Have a look at ~/.cache/thumbnails in a GNOME/KDE system. Specification.
from wuffs.
Thanks for the comment. Just a quick reply to the idea of string
, *string
and []string
in the APIs...
Wuffs' higher level auxiliary C++ API can do this but one memory-safety constraint on the lower level C API is that it cannot allocate memory and specifically, the callee cannot create or hold arbitrarily long strings. C also just doesn't have a good string type. I'm not sure which level you had in mind but, if your program is C and not C++, then you're obviously restricted to the C API, not C++.
In terms of API design, I'll also copy/paste from what I just wrote at #39 (comment)
Wuffs' image, image metadata and color correction APIs span many file formats... so there's some abstraction that might look weird at first glance.
In particular, languageCode
and translatedKeyword
may be part of PNG iTXt chunks, but IIRC they're not part of GIF, JPEG, etc. comments.
from wuffs.
The content encoding can be simply tagged, that would also be viable. I haven't had the necessity to learn about GIF or JPEG.
zTXt is compressed, not sure how you want to handle the decompression there, then.
from wuffs.
iCCP payload is also zlib-compressed and we already handle that.
from wuffs.
Where/by whom is the decompression buffer allocated?
from wuffs.
Throughout Wuffs' C API, it's always the caller (not the callee) who allocates variable-length buffers. Pass that caller-allocated buffer as the wuffs_base__io_buffer* a_dst
argument to wuffs_base__image_decoder__tell_me_more
or wuffs_png__decoder__tell_me_more
.
If the buffer is too short, that call will return wuffs_base__suspension__short_write
and it's up to the caller to re-allocate and call again, or otherwise abort (because it cannot or will not allocate more memory).
The C++ API (e.g. used by example/imageviewer
) manages the memory for you, so that the C++ callback (e.g. imageviewer
's MyDecodeImageCallbacks::HandleMetadata
) gets a contiguous (ptr, len)
pair: the raw
arg. If you want to dig into the C++ code, start with this line:
wuffs/internal/cgen/auxiliary/base.cc
Line 214 in f4c2d46
from wuffs.
That sounds like ISO Latin 1 could still be just another decoder. Sadly, with zlib compression, it might be two levels of transformations to do.
Code for the encoding conversion is a trivial exercise, having it done automatically would just make the API less awkward to use.
Speaking of awkward, it looks like both libpng and spng make you assume the encoding based on the ‘type’ of the chunk, which is exposed in their structures. Luckily for me, everything above ASCII happens to be percent-encoded in thumbnails…
from wuffs.
Wuffs' PNG decoder should now be able to give you text chunks (whether iTXt, tEXt or zTXt). If you're using the C++ API, this patch shows how to get the data. Starting at:
wuffs/example/imageviewer/imageviewer.cc
Line 178 in 66cfd3e
Apply:
diff --git a/example/imageviewer/imageviewer.cc b/example/imageviewer/imageviewer.cc
index 96938453..b0327414 100644
--- a/example/imageviewer/imageviewer.cc
+++ b/example/imageviewer/imageviewer.cc
@@ -175,6 +175,23 @@ class MyDecodeImageCallbacks : public wuffs_aux::DecodeImageCallbacks {
1e5 / (g_flags.screen_gamma * minfo.metadata_parsed__gama());
break;
}
+ } else {
+ const char* name = nullptr;
+ switch (minfo.metadata__fourcc()) {
+ case WUFFS_BASE__FOURCC__KVPK:
+ name = "Key";
+ break;
+ case WUFFS_BASE__FOURCC__KVPV:
+ name = "Val";
+ break;
+ }
+ static char buf[4096];
+ if (name && (raw.len < 4096)) {
+ // Convert raw (a wuffs_base__slice_u8) to a NUL-terminated C string.
+ memcpy(buf, raw.ptr, raw.len);
+ buf[raw.len] = 0x00;
+ printf(" %s %s\n", name, buf);
+ }
}
return wuffs_aux::DecodeImageCallbacks::HandleMetadata(minfo, raw);
}
@@ -244,6 +261,7 @@ load_image(const char* filename) {
uint64_t dia_flags = 0;
if (g_flags.screen_gamma > 0) {
dia_flags |= wuffs_aux::DecodeImageArgFlags::REPORT_METADATA_GAMA;
+ dia_flags |= wuffs_aux::DecodeImageArgFlags::REPORT_METADATA_KVP;
}
MyDecodeImageCallbacks callbacks;
For example, running ./build-example.sh example/imageviewer && gen/bin/example-imageviewer ~/.cache/thumbnails/large/etc.png
prints:
Key Thumb::URI
Val file:///usr/share/images/desktop-base/desktop-grub.png
Key Thumb::MTime
Val 1559986823
If you're using the C API, test_wuffs_png_decode_metadata_kvp
has some code you can study (link below). To keep the test simple, it assumes that the entire PNG input can fit into memory at once, as will each key/value pair within. If you're streaming, then you'll need to take care of Wuffs' usual "short read/write" suspensions.
Line 730 in 66cfd3e
The callee, not the caller, translates from Latin-1 to UTF-8 when necessary.
from wuffs.
Related Issues (20)
- RGB/BGR 16 bit treated like RGBA/BGRA? HOT 1
- OSS-Fuzz issue 59018 HOT 1
- [JPEG] unsupported DQT after SOF markers HOT 1
- OSS-Fuzz issue 59182 HOT 1
- OSS-Fuzz issue 59540 HOT 1
- OSS-Fuzz issue 59966 HOT 1
- A question regarding auxiliary C++ API HOT 4
- What is the status of version 0.3? HOT 3
- Empty slice manipulation triggers UBSAN by offsetting from a null pointer. HOT 2
- error: conversion to ‘uint32_t’ {aka ‘unsigned int’} from ‘int’ may change the sign of the result HOT 3
- OSS-Fuzz issue 66816 HOT 1
- PNG's are stored in RGB order but Wuffs returns BGR/BGRA? HOT 1
- Decode PNG with gray+alpha as 2 channels (i.e. YA not BGRA) HOT 5
- Warning about always true comparison of integers HOT 1
- std/crc64 doesn't build for 32-bit x86 HOT 1
- Allowing LA and RGBA PNGs with a tRNS chunk HOT 2
- How to get the correct 'transparency' value in the DecodeImage API? HOT 2
- wuffs 0.4 significantly slower than 0.3 decoding PNGs HOT 27
- wuffs significantly slower than OpenCV 4.9.0 when decoding PNGs for 7680x4320 image HOT 9
- OSS-Fuzz issue 70340 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wuffs.