Describe the bug stb_vorbis.c is meant to be included in larger surrounding files. It defines L, C, and R. Now any user code that follows will blow up if it uses single letter variables. I would suggest defining single letters and leaving them defined is bad practice.

To Reproduce Steps to reproduce the behavior:

1. #include <stb/stb_vorbis.c>
2. Use something like int L in your own code afterward

Expected behavior The include won't break use of single letter variables following later. However, it does.

Screenshots

stb_vorbis.c is not a header file, it is not meant to be included in larger surrounding files

It just doesn't seem very necessary? You can make a parallel array of void*, or make an array of void* indexed by id if you need that functionality.

Update stb_rect_pack.h Change the type of stbrp_rect.id from int to void* for more flexible api

this would break anyone using the current id. you can make this change locally but it doesn't make sense to accept.

simplify some code

fix bug in OpenCV rotation

The center of the face was being reported as the center in the internally-cropped image, not the center in the original mask. When the code that detects which face corresponds to which mask ran, it samples the mask at the center of each face, but since the center was wrong, it would use the default index 0.

fix incorrect handling of OpenCV face detection if input image has alpha channel (4 channel input)

face rotation: refactor rotation calculation into a shared function & fix a minor bug in OpenCV case

The OpenCV path includes code to handle if FaceMesh finds 2+ faces when trying to get the FaceMesh corresponding to an OpenCV face, by selecting the face that best matches the OpenCV face. Normally FaceMesh only returns 1 face, but in the case where it found 2+ faces, the previous version would break. (I think, I don't have any examples that trigger this path.)

fix bug in "fixed inverted masks not working" change that broke face swapping more than 1 face per image

generateImages2: try to simplify generateImages

To clarify one thing, my policy on warnings has always (or at least for a long time) been to fix normal warnings but not warnings triggered by -Wextra, and things only enabled by -Wall have been borderline.

But I wouldn't generally say "If the warnings bug you, you can just disable them in your build setup", because we would like the stb libraries to be easy to use, and forcing you to tweak warnings, especially if it affects the rest of your code, isn't cool. BUT we do have to draw the line somewhere, so generally anything -Wextra or otherwise requiring manual enabling is a warning we won't fix, unless it's exceptionally easy (e.g. doesn't add any extra lines of code).

FWIW, while we can presumably fix this, iphone-formatted PNGs have been a steady source of minor friction forever, and it's in support of a format I'm not a big fan of. Given that Apple considers it proprietary, the fact that it gets it tendrils into the format in multiple places, and overhead of de-iphone, every year I think about just dropping support for it entirely.

PNG files have two kinds of checksums, the Adler-32 checksum that is only in IDAT chunks, and the CRC-32 that is in all chunks, including IDAT chunks. iPhone format drops the Adler-32 checksum, but keeps the CRC-32 checksum.

Some context:

I notice Firefox on Windows won't display either of the "bad" PNGs either. Is this true of all CgBI images, or is it just something wrong with these particular ones?

Anyway, reading over the code, basically the code could throw a "premature" end of file if it can't refill the bit buffer it uses for huffman decoding. This means at the very end of the file, it could fail to decode the last few symbols if there isn't further data after the IDAT chunk that contains it. However, there should always be a CRC at the end of the IDAT chunk, plus an IEND chunk after that, so I don't know how it could fail to have enough data to fill the bitbuffer (unless it's using the length of the chunk, not the size of the file, but then EVERY file should fail). So I don't see how you'd trigger that error as long as the file has an IEND chunk. And according to https://www.nayuki.io/page/png-file-chunk-inspector it does have a CRC and an IEND at the end. So without stepping through the code I'm not sure what's going on.

We should just use sprintf_s instead as needed. It just requires conditional compilation to support all the compilers, so it requires search and testing to get right.

It is true that the general rule of thumb in the stb libraries is that values returned through pointers are optional and the pointers can be NULL, but usually that's because the data is optional / auxiliary. Here, the point of the function is to return the bounding box. Without an actual scenario where you'd only want some of the values, it seems frivolous to invoke that rule of thumb, which is only a general principle and not an absolute rule.

Yeah, I had to pip install mediapipe when I installed. What do you mean by "add mediapipe to requirements"? There's an install.py to install it, but I don't know how Automatic1111 is supposed to gather or run requirements of extensions. Is there a place I can just add it in the code? If so I can fix it.

So:

• Item 4 discussed above
• Item 3 seems like a nice idea, I've made it a separate proposal, #27.
• Item 2: variants of this--doing some kind of expanding the face to more of the head, all of the head, all of the hair--have been discussed on the discussion boards. I want to look into doing something like this, but I only have so much time to put into this. (Personally I'd like to fix cloned hair styles, not just cloned faces.) At the same time, kex0 has some other ideas for swapping more than just faces that he may or may not be working on currently.
• Item 1 I'll let kex0 give a real response, but my interpretation is basically, as long as this is a Batch File Swap, I think it's really meant to be more of a "walk away and let it run" (or "let it run overnight") thing, rather than something interactive. I don't actually know how hard something like that would, as I don't know the details of how extensions interact with the UI while running, but no other scripts I use support anything like that, so it may be hard to do in the Auto1111 web framework. But maybe not, I don't actually know.

One idea in #26 is to rotate the faces so SD processing a vertical face, then rotate it back when compositing with the main image.

This seems like a good idea if it can be done easily. Since we use FaceMesh to detect faces, it might be possible to use the info we already get from it to figure out the 3D orientation of the face, figure out the best 2D orientation, and then do the above--but only if we can detect the rotated face in the first place.

I have experience with 3D math, so I can look into it.

Haha, I just read over my comment. "Single mask per image" may not be very clear if you don't read the tips, it means "process all masks in one pass".

Do you have "single mask per image" checked? It's off by default, but if you turn it on it does them all at once.

What do you mean "I have it set for just one face"? There's no setting for that.

For item 4, detecting multiple faces, it already does that, unless the faces overlap.

Sometimes you might want to do something like swap a particular face into a bunch of images, so the prompt gets specific about who it is. In this case, you probably don't want to face swap all the faces in the image, only the most prominent one (unless you're trying to make quintuplets or whatever).

But maybe the background faces are all clones, so you still want to face swap all the background faces as well, but with a different prompt. While we could investigate an implementation that has two prompts that it chooses between for different subsets of faces, for now a simpler approach is to just limit which faces get swapped, and you can run through the batch twice: the first time replacing the most prominent face, the second time the background faces.

To do this, I propose adding a dropdown to the UI that has these choices:

"Swap all faces",
"Swap only largest face",
"Swap all faces except largest",
"Swap only faces roughly in the foreground",
"Swap only faces not in the foreground",

• "All faces" is the current behavior.
• "Only largest face" picks whichever face has the largest area (or really, its bounding box has largest area).
• "All faces except largest" discards just the face from the previous entry
• "...in the foreground" would just do faces found by FaceMesh, at least at first, we can try to get more clever down the line
• "...not in the foreground" would do all the faces that "...in the foreground" doesn't do

"Largest face" is really a stand in for "closest face", since we don't know actual distances it's the best we can do. Also, there might be cases where the subject of the image is in the center, but there's a "background person" at the edge of the image whose face is slightly larger but they're clearly in the background, so maybe instead of "largest face" we need to pick "largest face that's towards the middle of the image" or something like that. Maybe call that "most prominent face". We can add that later though.

If this sounds good to you, I'll work on it this weekend.

(Also, let me know if you prefer to discuss things like this in Discussions or email or etc. instead of opening an Issue)

If your platforms' allocator has neither realloc nor a way to figure out the size of an allocation gives it base pointer, there is already an easy way to support it using the existing API: just put a tag value with the size in front in your realloc implementation. That way, the code that deals with the peculiarities of your platform lives on your side where you can test and debug it. By contrast, if we merged this, 99.9% of stb_ds users (ourselves included) would be on a platform that ignores size_in_use which means it's only a matter of time until it breaks.

I guess this is a good argument, so yeah, nevermind, not going to accept this.

For environments that have malloc and free but not realloc. STBDS_REALLOC can be implemented with something like this thanks to the addition of size_in_use:

void * realloc(void * old_ptr, size_t new_size, size_t size_in_use) {
    void * new_ptr = malloc(new_size);
    memcpy(new_ptr, old_ptr, size_in_use);
    return new_ptr;
}

Also made the arguments for STBDS_REALLOC/FREE match in the definition and documentation.

Although the only reason I said it would be ok to add it is because I didn't realize there was already an STBDS_REALLOC etc., so I thought size_in_use would be ok to support if we were adding the feature, but I suppose if there already is one I need to reconsider whether it's worth it.

For environments that have malloc and free but not realloc. STBDS_REALLOC can be implemented with something like this thanks to the addition of size_in_use:

void * realloc(void * old_ptr, size_t new_size, size_t size_in_use) {
    void * new_ptr = malloc(new_size);
    memcpy(new_ptr, old_ptr, size_in_use);
    return new_ptr;
}

Also made the arguments for STBDS_REALLOC/FREE match in the definition and documentation.

Haha, no, I said by email I'd be ok with this, although it needs to be changed to not break existing code.