What I Built
Ita Studio is a browser-based layout planner for ita bags: bags with transparent display windows used to showcase character badges, collectibles, and decorations.
The idea comes from my interest in anime, Chinese otome games, and character merchandise. Planning an ita bag involves more than choosing attractive images. A collector needs to know whether the actual badges will fit, which parts will remain visible through the bag’s window, and what size decorations to buy or make.
A digital arrangement can look convincing while being physically impossible. Shrinking a badge image might solve a design problem on screen, but it does not change the badge someone owns.
I built Ita Studio around that distinction. It lets users:
- Enter bag, insert-board, and transparent-window dimensions.
- Position the window relative to the board and preview hidden areas.
- Upload and manually crop their collectible images.
- Set how many copies of each design they own.
- Move, rotate, duplicate, and layer items at their specified physical sizes.
- Resize decorations that have not yet been purchased or made.
- Export a preview image and a dimension list.
- Request layouts through an interface connected to an open-weight language model.
The intended users are collectors preparing their own bags and creators who offer custom ita-bag arrangements.
For the Side Hustle theme, my business hypothesis is that a reliable planning tool could save preparation time and help users avoid unsuitable purchases. Possible paid features include multiple saved designs, additional window shapes, and printable placement guides. These are future opportunities, not existing paid features. I have not validated pricing or generated revenue.
Demo
The project currently runs locally on Windows through a Python server.
The demonstration covers entering dimensions, importing a badge image, adjusting its crop, placing multiple copies, checking overlap, and switching between the board editor and bag preview.
The AI demonstration should also show the original instruction, returned parameters, and resulting arrangement, so viewers can distinguish model interpretation from geometric execution.
Code
The application uses HTML, CSS, JavaScript modules, SVG, and Python’s standard library. It does not require a frontend build step to run locally.
The project source includes an MIT license. Model weights are downloaded separately and retain their own license. User-uploaded artwork is not covered by the source-code license.
How I Built It
Keeping physical measurements separate from screen size
All layout measurements are stored in millimetres.
A circular badge can have a width and height of 58mm, a centre position of (150, 110), and a rotation angle. SVG maps these values onto the display. Zooming the workspace changes the view, rather than changing the badge’s physical dimensions.
Pointer positions are transformed from screen coordinates into SVG coordinates before updating item positions. This keeps dragging consistent when the workspace is scaled.
Materials have two size modes:
- Fixed: existing badges and physical decorations retain their entered dimensions.
- Free: planned decorations can be resized, and their final dimensions become suggested finished sizes.
The distinction is enforced in the interaction code, not only through disabled input fields.
Modelling what people will actually see
The board and transparent window are separate rectangles with separate dimensions. The window also has an offset relative to the board.
This matters because an item can fit on the board while still being hidden behind the bag’s fabric.
The editor shows a visible-window boundary, a safety margin, and shaded hidden areas. The bag-preview mode masks the hidden portions to approximate the outward-facing result.
This is a two-dimensional planning model. It does not simulate fabric curvature, thickness, weight, or attachment methods.
Checking collisions and generating layouts
The geometry module checks circle–circle, circle–rectangle, and rotated rectangle–rectangle intersections.
For two circular badges, overlap depends on the distance between their centres and the sum of their radii:
Math.hypot(a.x - b.x, a.y - b.y)
< (a.w + b.w) / 2 + gap - EPS
The layout generator uses a heuristic approach. It retains locked items, accounts for available inventory, prioritizes the requested focal design, and searches candidate positions.
A candidate must fit inside the permitted region and satisfy the spacing checks against existing placements. If the algorithm does not find a position, it reports the item as unplaced rather than shrinking it.
The current layouts are grid, staggered, and centre-focused arrangements. They are candidate solutions, not guaranteed optimal packings or objectively best-looking designs.
Making image cropping useful for physical objects
Local testing revealed a problem with the original centred crop: product photographs could include white margins and text inside the displayed badge.
I added a manual crop editor with dragging, zoom adjustment, a boundary guide, and a live result preview. Users can also recrop an existing material without changing its physical size or placement.
The guide represents the outer boundary of the physical badge. Aligning the actual badge edge with this guide makes the image correspond more closely to the entered diameter.
I also added editable inventory quantities directly to material cards. Multiple copies of one design now share the same image, so users do not need to upload it repeatedly.
Using an open-weight model for natural-language control
The implemented AI integration uses Qwen2.5 1.5B through Ollama.
Its role is to translate a user’s description into parameters supported by the layout engine. It does not generate merchandise images or determine physical dimensions from photographs.
For example, a request such as “Make the arrangement compact, emphasize the purple badge, and leave 30mm at the bottom” is translated into fields such as:
- Layout type.
- Density.
- Focal material ID.
- Bottom reservation.
- Minimum spacing.
The Python adapter calls Ollama with a JSON schema:
result = ollama_json('/api/chat', {
'model': MODEL,
'stream': False,
'format': SCHEMA,
'messages': [
{'role': 'system', 'content': SYSTEM},
{
'role': 'user',
'content': json.dumps(
clean,
ensure_ascii=False
)
}
],
'options': {
'temperature': 0,
'num_predict': 400,
'num_ctx': 4096
}
}, timeout=180)
The response is parsed and validated before being passed to the layout engine. Unsupported layouts, invalid measurements, and nonexistent material IDs are rejected.
The browser sends material names, dimensions, quantities, and the user’s instruction. It does not send the uploaded images. Consequently, this version cannot identify character faces or guarantee that deliberate overlaps leave faces visible.
The application also exposes the latest returned parameters, model name, and request duration to make the process inspectable.
The Python tests use mocked model transport. They verify the integration contract and validation logic, rather than proving real-model performance.
I have launched the website locally, imported personal badge images, and used that experience to identify cropping and inventory usability issues. Ollama installation and the model download are complete. Successful end-to-end model inference remains a validation step; I am not reporting measured inference accuracy or latency yet.
I used ChatGPT to help implement and revise the code. My contribution includes the hobby-specific requirements, physical-size rules, product decisions, and local testing feedback.
Why Does Open Innovation Matter?
Open-weight models make the language interface replaceable and locally deployable.
The model name is configured separately from the frontend and geometry engine. This allows future comparisons between compatible models without rebuilding the editor.
With the default local configuration, the website communicates with Ollama on the same computer. Once the model is downloaded, that inference path does not require a paid external model API. Local computation still requires hardware resources, and performance depends on the user’s machine.
The project also keeps the model’s interpretation inspectable. Users can see the returned parameters, while developers can modify the prompt, schema, validation rules, and layout algorithm.
For a small hobby-community product, this creates room to experiment with specialized vocabulary and workflows without tying the entire application to one hosted model service. I have not yet benchmarked these benefits against a closed API or calculated production operating costs.
However in actual use, I found that the model parsing and layout program have not yet clearly distinguished between "necessary conditions" and "aesthetic preferences". For instance, when a user requests to include at least 12 badges, the white space strategy might result in a reduction in the final number. In the future, explicit quantity constraints will be added to ensure that the layout first meets the quantity requirements before optimizing the spacing and visual effects.
