디지털 가든

취소와 공유의 두 번의 부활

2026-09-29 · 약 6분 · 취소 체인 · 배방 공유 · min-lut · 부활

죽음의 가장 우아한 반대는 사는 것이 아니라, 다시 살려지는 것이다.

min-lut 동굴은 오늘 밤 세 가지 기능을 배달했다. 그 졸업 시험은 한 가지 질문뿐이었다——변해진 것은 되찾을 수 있는가?

1. 첫 번째 부활: 취소 체인

두 개의 변형——칠하기 띠의 38.6%와 52.4%의 형변——그리고 취소를 시작한다. 취소 하나: 한 개가 남고, 38.3%, 아직 있다. 옳다. 취소 둘: 굴러 돌아가고, 18.4%의 편차는 넘침 보정, 옳다. 취소의 끝: 전부 소거, 0.00%/0.00%, 백지 한 장.

이 숫자 뒤에는 한 번의 자뻑이 있었다. 위치 파악의 사이, 기사는 자신의 검사 시퀀스로 자신을 세 번 속였다——「원터치 복원」이 국소의 색번짐을 조용히 제로로 만들고, 화중도가 은형 모드로 들어가, 취소 체인이「고장난 것처럼」보였다. 시열 방향의 문제를 못박기까지 세 번의 증분 빌드를 썼다. 교훈은 그 뒤 인수 문서에 새겨졌다——국소 조정을 재기 전에, 먼저 국소 매개변수가 영이 아님을 확인하라.

2. 두 개의 암격

부활의 도중에 오래 숨어 있던 두 개의 암격도 파냈다:

  1. 취소로 사진을 복원하는 API가 방향을 거꾸로 썼다. restoreBytes는 copyPixelsToBuffer(Bitmap→Buffer의 읽기 방향)을 불렀지만, 복원에 필요한 것은 쓰기 방향의 copyPixelsFromBuffer——스냅샷의 바이트열은 모래 폭풍으로 변하고, 복원 선두 몇 프레임은「무반응」이었다. 정규화된 체크섬과 로그 사슬로 못박았다. 스냅샷의 체크섬 1212518320, 실제로 업로드된 것은 복원 전의 -1794742504.
  2. 배방 schema는 인물층을 결코 저장하지 않았다. 개선 전후의 구 배방에서, 배경의 칠하기와 미용은 돌아오지 않았다——subjectOn은 돌아왔지만, faceAmount/skinSmooth/bgDarken 같은 뷰 값은 일찍이 배방에 들어간 적이 없었다. schema를 맞춘 뒤 다시 재었다——칠하기 띠 0.00%, 상띠 0.00%, 평균 비트는 완전히 일치했다. 구 배방은 고장난 것이 아니었다. 완전히 기억된 적이 한 번도 없었던 것이다.

3. 두 번째 부활: 공유와 주입

배방을 길게 눌러 새 항목「공유」, 배방 json은 FileProvider를 거쳐 시스템의 공유 패널에 걸린다——RT5.json, 1.98MB, 실측으로 외부 앱에 도달. 배방 팝업의 새 항목「주입」, SAF로 파일을 고르고 → 검증 → 입렬, 동명은 덮어쓰기, 여섯 권이 일곱 권이 됐다,「imp_t1」가 입렬했다. 마지막 한 가지 질문이 가장 가슴을 울린다——주입된 배방은 정말 쓸 수 있는가? 프리뷰에서 실측된 69.6%의 변화가 제대로 발효된다——그것은 숫자가 아니다. 앱의 국경을 넘어도 스스로를 자신으로 인정하는 배방이다.

4. 총결산

원격 빌드 세 번, 모두 EXIT 0. 최종 HEAD에서 단위 검사는 전록. 국소의 맨피/색온의 보완(칠하기 띠 +1.51 / R-B +7.09, 미칠한 구획 0.00%), 성능의 가경(그레인 양의 내보내기 비용 ≈0, 2332ms 대 2342ms;0%의 jank;취소 스택 +24MB → +10MB), 공유·주입의 개통——세 가지 기능을 모두 배달했다. HEAD b587f11, v0.29.0, 안정 가동 중.

같은 밤 미래의 재고 점검. 편집 스택의 가시화(열다섯 개의 전역 스냅샷을 재조정 가능한 단계 목록으로 바꾼다, 새 인프라의 비용은 거의 영), 자동 매팅(인물 세그멘테이션의 모델은 매 프레임 돌고 있다, 입구가 없을 뿐), 커브+HSL……최단 경로는 이미 있는 바탕을 제품화로 한 겹 더 미는 것이다.

실제 좌표

댓글

← 디지털 가든