Re: CarnaLife Holo link - niby-efektowna kompromitacja produktu

Wszystko co piszesz potwierdza to, co ja tutaj twierdzę o MedAppie:
coś tam wiecie o potrzebach lekarzy, ale macie marne pojęcie o technologii i jakości wdrożenia,
dlatego wcale nie myślicie o złożoności obliczeniowej ani wydajności aplikacji...

Twoja "argumentacja" próbuje odwracać uwagę, gubić wątek i mieszać różne fakty,
dlatego porównujesz urządzenia diagnostyczne w dyskusji o produkcie do pokazywania wyników.

Stacje radiologiczne mają pozyskiwać i dostarczać dane, więc sensowne i oczywiste jest,
że ich produktem są surowe dane rastrowe, które na różnych urządzeniach i w różnych zastosowaniach
można wykorzystywać w różnej rozdzielności i z różną kwantyzacją, która ma wyróżniać różne szczegóły;
dlatego z tych urządzeń nie mogą być zwracane już przetworzone w określony sposób ani zredukowane dane...

Gdyby CarnaLife Holo miało pokazać dokładnie to samo co wyświetlacz stacji radiologicznej, to BYŁOBY ZBĘDNE;
a jako narzędzie do prezentacji wyników badań ma na celu optymalizować ich treść dla określonego użytkownika,
więc gdy wiadomo na urządzeniu z jaką rozdzielczością będą wyświetlane i jakiej specjalizacji lekarz będzie ich używał,
to wiadomo jakich kwantyzacji trzeba dokonać i jak dokładnej segmentacji, żeby uzyskać najlepszy efekt.

Samych lekarzy interesuje tylko czy zobaczą użyteczne dla nich wyniki badań,
ale nie obchodzi ich jak dane są przechowywane i przetwarzane, bo informatyka to nie ich dziedzina;
więc nie mają pojęcia czy wdrożenie jest dobre czy złe, czy można to zrobić lepiej lub gorzej;
co nie znaczy, że nie powinni myśleć o tym i dbać o jakość tego inżynierowie oprogramowania...

Jeśli oferujecie eksperymentalny "proof of concept", z którego sporadycznie, co kilka tygodni, korzysta tylko kilku lekarzy,
to efektywność może mieć niewielkie znaczenie, a optymalizację będzie można zrobić przy komercyjnym wdrożeniu...

...ale jeśli chcielibyście oferować produkt codziennego użytku,
który mógłby pracować w szpitalach niemal 24 godziny na dobę, bo kolejne zespoły lekarzy na zmianę będą go używać,
to nie bez znaczenia będzie czy działa on efektywnie czy powtarzalnie wykonuje 1000 razy więcej zbędnych operacji...
CPU i GPU podczas pracy pobierają więcej energii elektrycznej i wydzielają ciepło, które musi wyprowadzić klimatyzacja,
więc znacznie dłuższy czas pracy przy poborze mocy większym o kilkaset watów przekłada się na znaczące koszty.
Lekarz może o tym nie myśleć, ale dyrektor szpitala decydujący o zakupie powinien brać to pod uwagę.
Nawet kupując np. lodówkę do domu zwykle zwraca się uwagę na jej klasę energetyczną...

MedApp ogłasza na LinkedIn, że med-tech pozwala skracać czas zabiegów, oszczędzać pieniądze i chronić środowisko,
ale nie wspomina przy tym, że efekt zależy też od jakości oprogramowania i efektywności jego działania w praktyce,
o co jak widać wcale nie dbacie ani was to nie interesuje, więc faktycznie nie oferujecie takich wyników...

Oczywiście możesz podać przykład badania, które jest na tyle małe, że szczęśliwie będzie działać przyzwoicie,
ale to jest tylko "akademicki" przykład, który ma pokazać możliwości i pozwala zabłysnąć w publikacjach i na konferencjach...

...jednak komercyjny produkt powinien działać z dowolnymi danymi pojawiającymi się w rzeczywistej praktyce,
a jako "dowolne" należy rozpatrywać najmniej korzystne, bo wtedy w ocenie mieszczą się wszystkie realne przypadki;
więc skoro sam wcześniej wspomniałeś już o "OLBRZYMIEJ ILOŚCI DANYCH" medycznych "IDĄCYCH W GIGABAJTY",
to jasne jest, przy takich danych rastrowych prosta rotacja musi za każdym razem przepisywać wiele miliardów vokseli
i biorąc wszystkie operacje w tym procesie może być poważny problem z uzyskaniem płynnej zmiany obrazu;
dlatego lepiej jest najpierw dane zoptymalizować, a potem wielokrotnie przetwarzać i wyświetlać zmniejszone.

Jeśli w MedAppie tego nie robicie, to po prostu wasz problem;
macie produkt wdrożony w eksperymentalnej, a nie komercyjnej jakości kodu;
więc nie ma sensu w to inwestować, bo tak czy inaczej trzeba to porządnie napisać od zera...