#apertus IRC Channel Logs

anuejn: hokay, I had time to try again this weekend, still not working as expected

E:\dev\axiom\axiom-recorder>target\release\cli.exe from-cli RawDirectoryReader --file-pattern E:\assets\ref\axiom\221201_XriteSnaps\LED_Xrite\*.raw32 --height 3072 --width 4096 ! CinemaDngWriter --dcp-yaml src\nodes_io\default_dcp.yml --path E:\assets\ref\axiom\221201_XriteSnaps\LED_Xrite\DNG

I get

using cpu only processing

I tried looking for where to provide a sample interpretation and there seems to be one in base_ifd.yml

I am on the gpu_node_refactor branch

vup: woohoo! that did it

anybody happen to know how to change the debayer/CFA order? right now it seems not right

polyrhythm: yes, "--bayer=PATTERN", where "PATTERN

nice

E:\dev\axiom\axiom-recorder>target\release\cli.exe from-cli RawDirectoryReader --fp32 --file-pattern E:\assets\ref\axiom\221201_XriteSnaps\LED_Xrite\*.raw32 --height 2160 --width 3840 --bayer GBRG ! CinemaDngWriter --dcp-yaml src\nodes_io\base_ifd.yml --path E:\assets\ref\axiom\221201_XriteSnaps\LED_Xrite\DNG

even Adobe DNG Converter can't read them

please document the working parameters and final commands in the github readme accordingly

se6astian: thats how (part) of the current "header" was developed. Its probably just something "obvious" missing

also in addition to the "cli" way of specifying pipelines we have the yml config files. I think adding a folder with example config files for these operations would be better than adding more and more examples to the README. I would be happy to see PRs for these

great

i'm here!

is that the tool you use to profile the colors?

I'm able to load them in RawDigger but that's really just an analysis tool, and I think the only reason it can open them is because it's an extremely pared down application that is designed to break apart all the metadata and not do anything to the file itself

just getting Adobe DNG convert to be able to "repair" them would be a good start...

I see

does rawdigger provide any output what metadata is present and what is expected/missing?

I will try to take a screenshot or export the data

---- ExifTool ----

---- File ----

Directory : E:/assets/ref/axiom/221201_XriteSnaps/halo_xrite/DNG

File Modification Date/Time : 2023:03:20 10:35:23-04:00

File Creation Date/Time : 2023:03:20 10:35:21-04:00

File Type : DNG

MIME Type : image/x-adobe-dng

---- EXIF ----

DNG Version : 1.4.0.0

Make : Apertus

Software : axiom-recorder

Samples Per Pixel : 1

Fill Order : Normal

Resolution Unit : None

X Resolution : 1

Planar Configuration : Chunky

CFA Repeat Pattern Dim : 2 2

Bits Per Sample : 32

Image Width : 3840

polyrhythm: a pastebin is a great choice ;)

Bertl: right, thanks

Strip Offsets : 388

---- Composite ----

Image Size : 3840x2160

for me it worked to open the resulting dngs in adobe dng converter

can you exchange DNG files please to check

we have a nextcloud on apertus.org if you want I can create an account for you

ahI can also do that

with the comandline from the email-thread:

the dngs we currently write are in fact a bit - unusual but that should not be a problem for a well bahaved dng reader

all my stuff from Japan suddenly arrived so I have to step away for a bit

alright :)

any progress with rock5b?

what's the current problem there?

yup

does the driver allow for DVI like signalling?

anyone else around or anything else to report? otherwise I would conclude the meeting, but feel free to continue HDMI output, DNG metadata, etc. discussion

and that copper sheets have been selected for creating shims, might have talked about it already last week

MEETING CONCLUDED

Bertl: the driver does not as far as we can tell, the SoC supports DVI signalling

vup: how do you know?

hey anuejn is there a difference from using RawBlobReader and RawDirectoryReader?

anuejn: yes

polyrhythm: can you open my dng with your version of adobes tool?

this is how it looks when I open it in RawDigger:

Adobe DNG Converter can open it too though, so that's interesting

polyrhythm: see PM

probably it just interprets it as uint32

why are we using float32 in the first place?

okay, makes sense

yup

even full-on CG renders typically render at float16 buffers, and that's certainly with more stops of info than whatever this dinky sensor is puttin out...

the point is that processing fp16 on cpus is not too fast

for our applications int16 would also certainly be enough

so they can be directly substracted

if you just convert them to fp32 (which is pretty cheap on x86 cpus nowadays with the f16c extension)

although I read that openblas did not see any performance improvements between fp16 and fp32

that is cool