#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

morning folks!

off for now ... bbl

Hello Bertl, I tried what you suggested.

When I transmit two words alternatively, they are received correctly but there are erroneous words received during change/transit from one word to another

Hello BAndiT1983|away . Could u able to check last commit for videoclip class. Also I have started working on coupling Fuse to OC.

present in OC

supragyaraj,

Hello BAndiT1983

Could u able to check videoclip class in last commit

dev__, when do you plan to approach my comments on static allocator?

After including videoclip class, It has reduced those unnecessary methods from allocators

you have added video clip class to image loader, but this includes another coupling

Imageloader method : - Load will extract related information from file, like framecount

that's why i thought , i could pass it Load function

*couplings

?

it has list of frames which contains information regrading index where the frame is loaded in buffer,

so allocators can know where to place next frames

I was unaware that, It was promoting tight coupling

u mean , video data

as u have pointed out

http://www.dotnet-stuff.com/tutorials/c-sharp/understanding-loose-coupling-and-tight-coupling

https://en.wikipedia.org/wiki/Coupling_(computer_programming)

if you read about it, then why do you still place video clip class in allocator, as firt principle is to avoid tight coupling by using interfaces, which i would have understood the reason for

second thing is, allocator does not need to know about it at all

Can u please answer these queries also https://trello.com/c/k5lQz4zY/20-event-bus

dev__, you don't have to care about the eventMap, this is internal event bus stuff, please focus on using it

there are examples of how to use it, have you checked them out?

???

I was working on Fuse from last two days

sorry

Indian mobile network is not European mobile network :/ ping BAndiT1983 ...

everything else is just usual 3rdParty libs OC uses and FUSE

don't know about EU-wide mobile tendency, but german one is meh

no problem

Slow , But I am doing it

Hmm... Yes... Slow puts it right

How much time do you think the prototype will still take.. dev

Once we have proper Fuse coupling, It won't take too much time , i guess

The problem is somewhere else...

Hmm... Well.. the architecture of what goes where is still not clear

And I don't really feel "updated" - idk how about this project... Some info is always hiding

The code front... Well there are many changes that you have done there... But to me it seems like you are writing something of your own... Without consulting... Without telling why certain things were done the way it was done

Why do I see your commits on GitHub... Isn't your dev env setup properly?

And you edit on GitHub.com ... What kind of software development setup is that

I would need an explanation of why you are jumping to fuse when your mentors are explicit on you focusing on something else at the moment

Hint: Silence may not be the best thing here :)

I worked on videoclip class after that (which i started last to last meeting)

today BAndiT1983 , pointed out about , Tight coupling , I will be solving that too

but I has some doubts regarding that (so i updated trello two days back)

So i thought untill u reply, I can atleast i can work on Fuse

Yes, I will work on it as I said,

I have to understand things, may be slow

BAndiT1983 ... Anything from your end

don't have anything at the moment, as my comments on trello regarding static allocator are not processed yet, which is a bit disappointing, as they focus on standards of development, and it's my daily job to watch over such things

where does it allocate 512MB?

It could be less, If the total size is less than 512 MB,

i would have expected a constructor with possibility to set the size of a page

right now*

*could

what do you mean with less size than a page?

sorry for the delay, we had a network outage

but haven't we aggreed that you take 512MB for first tests and dissect it in buckets of frame size?

reading up at the moment ...

for now

file size is not important, but frame size is, in fact it's channel size

will check it, as i have finished my tasks at work and can focus on apertus again

Okayy

Thanks for your time.

Fares: I think we can start the presentation now

great! I would do it here with some tables and graphs

you have our attention :)

so as we know that images are composed of pixels, for each pixel a constant number of bits

LJ92 is a standard set to compress and decompress images

so for any pixel, if we can predict it's value from neighbors pixels, we can subtract the predicted value from the actual value, and encode the subtracted value only

for raw images you take neigbouring same color values I assume?

right

in "Predictor Functions" section, you will see there is pixel X and pixels A,B and C

from 1 to 7, are different function to predict the pixel value, I chose 1, it can be changed in the future in single module, but it was simple enough and it's results are good

so if everything is clear till now, I described half the process, which is, predict the pixel then subtract to get the value which will be encoded

yes correct, that is why I picked to choose Px = Ra, It is simple and effective

okay, in the standard you can choose 1,2,3 or 4 interleaved components, for 1 component that mean all the pixels are the same color (monochrome)

since RAW12 is stored in memory as RGGB, so 4 components were picked

if the same configuration (4 components) were used to encode (monochrome) it will still work but it will produce slightly less compression ratio since every pixel will be predicted using a 4 pixel behind

Bertl: we may need to combine then when doing the encoding to produce 4 components image, or encode every component alone to produce 4 images

please continue

okay, after getting the subtracted value, it will belong to one of 17 ssss classes

maybe we can do the detailed questions after the main presentation?

ah, sorry

okay thank you

and the final pixel will be [ssss_code][subtracted_value]

the table in it will explain which "difference=subtracted" value will be assigned to which ssss class

for ssss class 1, the code will be set and 1 more bit

if you refer to this link: https://github.com/FaresMehanna/JPEG-1992-lossless-encoder-core/tree/master/test_files

in a normal image, it shows a lot of subtracted values in small ssss classes

to give a complete example, please refer to: https://drive.google.com/file/d/1oIb3nR4NGYF_vBy9Z45RaaHmugD6AuIq/view?usp=sharing

in the top right there is a huffman code for every ssss class, as you notice the ssss classes with the most pixels given short codes

first you predict it using the function 1, then subtract it, then normalize it and know which ssss class it belongs to

in decoding the process is reversed to get the exact same pixel value

if there is any question till now please ask

okay I will continue :)

then if 4 pixels are encoded in the same cycle that will be anywhere from 4 to 124 bits and that can take a lot of resources

the first graph explain the basic pipeline for LJ92, but it now may encode multiple pixels per cycle, and that last stage is "Merger" to combine all the encoded values

so I worked in "V-bits to C-bits" module, that will input a variable amount of bits and will output a constant amount of bits using a buffer ((buffer << new_count) | new_output)

so to optimize it a little I wrote a converter module after the "LJ92 pipeline" and before the "V-bits to C-bits"

for in our first example I said if 4 pixels are encoded the values will be anywhere between 4 and 124

after the "V-bits to C-bits", there is a module to detect any 0xFF byte and append after it a 0x00 byte, it is crucial in LJ92 standard

that was high level overview of how the core is actually implemented in the fpga

since this is lossless so there is no guarantee in the upper limit

performance issues that are related to the implementation itself

the actual problem arise when there is part of the image with low details and other part with high details

and the part with high details will over-saturate the output resulting in stall cycles in the input module

that will allow more data to be outputted when the encoded values are small

hmm?

we can't really process more data than we have :)

now the questions :)

I mean because of the buffer in usb3.0 module, more data can be processed and sent there

"overflows" of what exactly?

so the core will work till an end signal is set, then the core will be reseted to accept the next frame, I'm currently writing a small module that will work as a counter, when it hit predefined number it will force end using a special ending marker

as I mention a special ending marker will be used to indicate to the receiver that this frame is not full

correct, the received data can be decoded successfully

thank you all for listening, if there is any other questions please ask

what is the state of implementation currently?

okay? please elaborate

the last segment of data is repeated and when I reload the bit file again it doesn't work, that bug is in the dma I try to build no in the actual core

okay

is that reasonable?

thanks a lot for the nice presentation

thank you :)

Thank you!

sure

firstly, the header part is tricky since the header will have info about the number of components and the huffman table used

or should the receiver send those info to the camera first before shooting the video?

In theory you can change them between every frame and the other, but generally they are constant for the camera or at least for the video

what I meant is, are there any mechanisms in the encoder which would change the tables?

AXI-Lite interface only have access to change them, the encoder itself do not

for now it's fine to assume that the receiver and the camera 'know' the table

any other questions?

since I wanted to work in the decoder in software, there is already good only in Adobe DNG SDK

Fares, i would keep the fingers off the adobe stuff

other than that, it's probably checking the licenses and what they permit, etc

BAndiT1983: because of license?

I have seen some of them using adobe sdk as well

okay, I'm off .. got some work to do ...

You can get away without SDK, as DNG is TIFF extension, OC also can read it without any SDK

I was only going to use the LJ92 decoder part from it

Would not try to use any parts from some company, as it can result in nasty legal problems

okay I will check dcraw, mlv_dump and other open source solutions, thank you.

but I think I can write the part to decode several components

ah, you use components to encode different Bayer channels?

yes, I used 4 components with the first predictor function

I read a lot about your work and how it all squeezed into single components

with predictor function 1

baldand (the author of lj92.c) describes the internals here: https://www.thndl.com/how-dng-compresses-raw-data-with-lossless-jpeg92.html

(in the original firmware, LJ92 was used to compress only still photos, i.e. CR2; we reused that encoder for video, but it wasn't designed by Canon to work like that)

you will find that the encoder is used in those cameras id different configurations

the image is sliced, for some reason

number of components are not one

hm, it starts to make sense

"the Full Raw Jpeg is encoded with 14 bits, in 2 colors (prior to the 50D and the Digic IV), then using 4 colors with the 50D up to 1100D. Since 1D X and up to 6D, Canon is back to 2 components."

and, indeed, the encoder expects two slices of data

I think you use special configuration because not only you don't use any slices, but you use single components with different predictor function

sliced are not the same as components

(Canon code was feeding first the left half of the image, and then the right half - these were the two slices)

the LJ92 decoder used in DNG happens to work fine with this trick, but I don't really understand why it just works

slices are not part of LJ92 standard, but number of components and predictor function are. and both are different, and there is something called small raw as well. just maybe an area of improvement in the future.

small raw is a different beast; iirc it contains debayered data

and predictor function is documented to be always one

they use single component and different function

interesting, and a plain CR2 from the EOS M matches the docs from lclevy?

I didn't really look into CR2 as I was interested in MLV only, but I will check it

who knows what that will reveal :)

ha, I see you actually fixed some bugs in lj92.c some time ago: https://github.com/FaresMehanna/MLV-App/commit/a04b571f01e5ea8b0338ec5858c3bd2650d11bc6

that was the test file: https://github.com/FaresMehanna/MLV-File-Format/blob/master/LJPEG-1992/Andrew_Baldwin_Implementation/test.c

ah, feeding random data, cool

thanks

interesting one

no, that was the step missing to remove the overwrite entry

ok, I need to play with this stuff a bit

all those steps are part of generating the Huffman table codes, also another optimization in the encoder part I am going to commit later is that there are huffman tables that are better but would never get generated with the standard way, so those may be hard coded to be tested against the standard generated ones.

yeah

but for now I use xilinx DMA core, hopefully later I will replace it with dma using axihp_reader|writer from the beta

cool, I'd like to look at this code, is it on the repo somewhere?

"We couldn’t find any code matching 'core_test32' in FaresMehanna/JPEG-1992-lossless-encoder-core"

ah sorry, I didn't commit the software side yet, I will clean and commit the code in the following days

nice job, it sounds like we'll soon be able to encode LJ92 streams directly on the beta; that's something I'd like to test

cool :)

off to bed