[過去ﾛｸﾞ] 【paiza】コーディング転職 10社目【AtCoderJobs】 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
567: 2022/06/13(月)20:30 AAS
>>566
そんな事言ったら今の経験者は未経験の時代はなかったことになるがいいか？
もっと言うと最初のIT事業始めた人は未経験者じゃないって事になるが？
568: 2022/06/13(月)21:06 AAS
>>566
経験40年だけど採用される？
569(1): 2022/06/13(月)21:31 AAS
お前ら新卒採用はコネ採用ばかりで驚くぞ
570: 2022/06/13(月)21:45 AAS
中途はコネだけど新卒でコネなんて少ないよ
コネで採りたいけどそんな都合よくいないよ
571: 2022/06/13(月)23:10 AAS
>>569
あなたの妄想ですよね
572(1): 2022/06/14(火)01:34 AAS
>>564
いえいえ仕事やる気出なかったのでw
BitmapがMacで使えなかったのでSkiaSharpっての使ってほぼ書きなおしになっちゃったけど
ザッと書くとこんな感じ？
https://github.com/774g0mb31/lanczos/blob/main/lanczos/ImageResizer.cs
weightはトータルでほぼ１になるように関数がなってるはずなので割ってない
端っこもはみ出たら縁を２度取りしないで無視するようになってる
オブジェクトの分け方としてはかなり細かく分けることが多い
ネスト４つで中が300行とかだと絶対に何か言われるか、言われなくても心の中で思われる
C#とかMSの物滅多に使わないからその辺の作法は怪しいかも
ポインター使えるのも初めて知った
573(1): 514 2022/06/15(水)01:17 AAS
>>572
誤解を招く様な切り貼り方をしてしまいました。
幾ら何でも4重forループの中身だけで300行なんて事は有りません。
Lanczos関数を使うと、結果として画像の縮小と拡大がほぼ同じ様な処理になってしまいましたが、それぞれはこんな感じです。
https://i.imgur.com/D8NtIN5.png
https://i.imgur.com/IrSCJ8F.png
C#で画像のビットマップ操作をする際、unsafeモードにしてポインタを使わないと、絶望的に遅い（遅かったので調べたらこの方法に辿り着いた）です。
Lanczos3関数を使おうと思った理由は、当時（2014年頃）のGimpの画像リサイズメソッドの選択肢の一つにLanczos3が有り、
リサイズ後の品質にも満足してたからです。Lanczos関数の使い方（数式と図で書かれてた）はググって調べました。
574(1): 2022/06/15(水)06:52 AAS
>>573
ああなるほど、なんでShrinkなのかと思ったら拡大と分けてあるのか
見たとこiとjの２と３が括弧に入ってるか入ってないかの違いのようだけどこれはなぜでしょう？
最初にShrinkを書いてEnlargeをやったらOut of Rangeが出たからとか？
575: 2022/06/15(水)08:12 AAS
確かにそもそもアルゴリズムがW＊H＊５＊５なのは避けられないので遅いですねー
Parallelでマシになったけど
O(N)の計算とか基本なのでその辺出来るとおっ？って思うかもですね
576(1): 514 2022/06/17(金)00:47 AAS
>>574
座標を整数ではなく、0.5とかにしたのは、当時参考にしたサイトによる影響です。
https://web.archive.org/web/20150410050105/http://www.maroon.dti.ne.jp:80/twist/4C616E637A6F73B4D8BFF4A4CBA4E8A4EBB2E8C1FCA4CEB3C8C2E7BDCCBEAE.html
縮小（Shrink）では、リサイズ後の座標に比率を掛けてリサイズ前の座標に対応する、計算対象となる前後の対象範囲を求めてます。
From: (int)Math.Floor(scaleFactor * (x - 2))
To: (int)Math.Floor(scaleFactor * (x + 3))
Enlargeの方は、バグかな？と思ったのですが、Shrinkを用いて極端な拡大（例えば100倍）を行った場合、モザイク状になってしまうところ、
偶然、丁度良くスムージングが掛かった画像が得られ、見た目もこちらの方が好みなので、そのままにしておきました。
From: (int)Math.Floor(scaleFactor * x) - 2
To: (int)Math.Floor(scaleFactor * x) + 3
577(1): 514 2022/06/17(金)08:05 AAS
多少無駄な計算を行う事になるかもしれませんが、Enlargeの方の重み計算対象範囲を、
From: (int)Math.Floor(scaleFactor * (y - 2) - 1)
To: (int)Math.Floor(scaleFactor * (y + 3) + 1)
にしたら、かなり改善されました。
578(1): 2022/06/17(金)08:15 AAS
>>576
そのロジックって手前味噌ながら僕のコード見て貰えばわかると思うけど、まずターゲットのWxHのサイズで仮想的なピクセルの絵を作って、次にそのピクセルごとにソースの絵の対応するピクセルを求める（Factorを掛ければ出る）
そしてそのソースのピクセルの周りを前後左右に2個づつ、計５x５（僕のコードはkが可変なのでkが３の場合）のウインドウでとって重みをかけて合わせたものをターゲットのピクセルにセットするものなので、括弧に入れてしまうとおかしなところからサンプリングすることになりますね
例えば10倍に拡大する場合、x(ターゲットの横幅)が30の位置だとソースの3+-2で1から5を取りたいのに、それだと2から3までを取ることになるので滑らかにするロジックが効いてない（2x2になってしまっている）ですね
ガタガタするのはそのせい
Enlargeの方はそこは正しいですけど、真ん中のターゲットを中心に5x５（あるいは7x７など）で正方形にするはずが、左と上に２、右と下に３ずつとズレて取っているので、＋するのは３じゃなくて２が正しいですね
僕の方のコードは同じロジックで拡大縮小、アスペクト比の変換全部カバーしてます
まあ僕のというか元のアルゴリズムが
コンパイルしてやってみるとわかると思いますカーネルのサイズも変えられるし
どっか間違ってたらプルリクくださいw
579: 2022/06/17(金)08:18 AAS
無関係な話題続けるアホはどっかいけ
580: 2022/06/17(金)08:36 AAS
元々就職の話なので無関係ではないですね
気になるのは関数を実装する部分ではなくて、OOPでパーツにバラすやり方とかそういう話なので
581: 2022/06/17(金)08:40 AAS
というわけでw
>>577
>(y - 2) - 1
>(y + 3) + 1
これで改善されたのはなぜか>>578でわかりますよね
2と3しか取ってなくてほぼ滑らかにするロジックが効いてなかったのが、１と４になったからです
まあこんなもんで
582: 2022/06/17(金)11:29 AAS
最初は多少同情したけど、この振る舞い見てると無職で苦しんでるのは当然としか思えん
他人の迷惑考えろ
583: 2022/06/17(金)11:33 AAS
君が何にキレてるのかは君が言わなきゃわからないからなあ
584: 2022/06/17(金)11:53 AAS
>1
>プログラミング問題をコーディングで解いて転職に繋げるサービスについて語るスレ
スレ違いの話題は他所でどうぞ
585: 2022/06/17(金)12:12 AAS
＞プログラミング問題をコーディングで解いて転職に繋げる
日本語って難しいねえw
586: 2022/06/17(金)12:12 AAS
こちらにどうぞ
https://qiita.com/
上下前次1-新書関写板覧索設栞歴
あと 416 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.019s