[GOWS/send] /send/media omits imageMessage width/height → square placeholder until full media downloads

Start at the POST /send/media message-construction path and trace the existing image decode used to create JPEGThumbnail. Verify where the resulting ImageMessage is assembled and ensure the expected width and height are present for both base64 and HTTP image inputs. Done means wide images no longer arrive without dimensions and the behavior is covered by an appropriate regression check.

Version: v0.7.2 (GOWS engine)

Summary

When sending an image via POST /send/media, the resulting imageMessage has no width/height set. Those fields are what WhatsApp uses to shape the bubble before the full media is downloaded, so the recipient sees a square-cropped placeholder (built from the inline thumbnail) until the full-resolution media finishes downloading. Only then does WhatsApp read the real dimensions from the file and re-render at the correct aspect ratio.

On heavier images / slower connections / when media auto-download is off, the square placeholder stays visible for a long time (or until the user taps to download), which looks broken for wide banners (e.g. 1600×720).

Evidence it's a message-construction gap (the dimensions are already known)

The generated JPEGThumbnail has the correct aspect ratio (72×32 for a 1600×720 source), so the server already decoded the image dimensions to build the thumbnail — it just doesn't write them into the Width/Height fields of the ImageMessage.

Returned imageMessage keys:

JPEGThumbnail, URL, caption, contextInfo, directPath,
fileEncSHA256, fileLength, fileSHA256, mediaKey, mimetype

No width, no height.

Reproduced with both base64 (inline in url) and an HTTP URL — same result (no dimensions either way).

Controlled comparison with Evolution API (Baileys) — same image

The exact same image file sent through Evolution API's POST /message/sendMedia produces an imageMessage with width: 1600, height: 720; through GOWS POST /send/media those fields are absent. Same recipient, same file — the only relevant difference in the message is the missing dimensions, and it maps 1:1 to the square-placeholder behavior.

Expected

imageMessage.Width / imageMessage.Height populated (as Baileys / Evolution API does) so the placeholder renders at the correct aspect immediately (blur → sharp, no reshape).

Actual

Square placeholder on arrival, then a "jump" to the correct horizontal aspect once the full image downloads. Most visible on WhatsApp Desktop and with large files.

Steps to reproduce

1. POST /send/media with a wide image (e.g. 1600×720), type: image.
2. Receive on another device and observe: the bubble is square while the full media downloads, then reshapes to landscape once it finishes.

Suggested fix

Populate ImageMessage.Width / ImageMessage.Height from the decoded image (the same decode already used to generate the JPEGThumbnail). whatsmeow's ImageMessage exposes Width / Height (uint32).

---

🇵🇹 / 🇧🇷 PT

Versão: v0.7.2 (engine GOWS)

Resumo

Ao enviar uma imagem via POST /send/media, o imageMessage resultante fica sem width/height. Como são esses campos que o WhatsApp usa para definir o formato da bolha antes de a media completa ser descarregada, o destinatário vê um placeholder quadrado (montado a partir da thumbnail inline) até a media em resolução completa terminar o download. Só então o WhatsApp lê as dimensões reais do ficheiro e re-renderiza no aspeto correto.

Com imagens mais pesadas / ligações lentas / download automático de media desligado, o placeholder quadrado fica visível muito tempo (ou até o utilizador tocar para descarregar), o que parece defeituoso em banners horizontais (ex.: 1600×720).

Evidência de que é falha na construção da mensagem (as dimensões já são conhecidas)

A JPEGThumbnail gerada tem o aspeto correto (72×32 para uma fonte 1600×720), ou seja o servidor já decodificou as dimensões para montar a thumbnail — apenas não as escreve nos campos Width/Height do ImageMessage.

Chaves retornadas no imageMessage: JPEGThumbnail, URL, caption, contextInfo, directPath, fileEncSHA256, fileLength, fileSHA256, mediaKey, mimetype — sem width, sem height.

Reproduzido com base64 (inline no url) E com URL HTTP — mesmo resultado.

Comparação controlada com a Evolution API (Baileys) — mesma imagem

O mesmo ficheiro de imagem enviado pela POST /message/sendMedia da Evolution API produz um imageMessage com width: 1600, height: 720; pela POST /send/media do GOWS esses campos estão ausentes. Mesmo destinatário, mesmo ficheiro — a única diferença relevante na mensagem são as dimensões em falta, e mapeia 1:1 com o comportamento do placeholder quadrado.

Esperado

imageMessage.Width / imageMessage.Height preenchidos (como o Baileys / Evolution API faz), para o placeholder renderizar já no aspeto correto (desfoca → foca, sem mudar de forma).

Atual

Placeholder quadrado ao chegar, depois "salta" para o aspeto horizontal correto assim que a media completa descarrega. Mais visível no WhatsApp Desktop e com ficheiros grandes.

Passos para reproduzir

1. POST /send/media com uma imagem horizontal (ex.: 1600×720), type: image.
2. Receber noutro dispositivo e observar: a bolha fica quadrada enquanto a media descarrega, depois muda para horizontal quando termina.

Sugestão de correção

Preencher ImageMessage.Width / Height a partir da imagem decodificada (a mesma decodificação já usada para gerar a JPEGThumbnail). O ImageMessage do whatsmeow expõe Width / Height (uint32).