[smf007]

So I've been back looking at this when time allows it. Of note, cximage is used by all image types except jpg. This bring about an interesting test I did. I took a test directory of Nikon NEFs and converted them to TIFFs. Browsing the TIFFS does not appear to leak! So that helps in looking further at cximage.

I also had two test forks, one with libdcr updated the other with cximage being updated. Unfortunately both leaked for RAW images.

To Do: Figure out where in CXIMAGE_FORMAT_RAW that memory is leaking

[smf007]

I believe I have fixed the memory leak for RAW pictures. There was a buffer not being freed in CxImage:ecode. I have a patch file if anyone wants to confirm the fix. http://filepi.com/i/5dEcuTS

[Martijn]

Please use pastebin.com
Devs are reluctant to download from such sites. Best would be creating a pull request on github

[zag]

Nice to see you over here smf007

Github is always best for these things. But here is the pastebin of the above file

http://pastebin.com/h3LLRWyr

[Ace]

The diff is difficult to read, but the buffer you want to free is already freed in the destructor of CxMemFile...

[smf007]

C++ isn't the language I code, I'm a fortran dev so my C++ is not that great. I posted a diff to see if others could confirm or deny what I came across. It "fixed" the problem for me, but if this isn't the correct fix, it at least identifies where the problem is being introduced.

I also wonder if this buffer bit is still needed. Does this comment still apply?

Code:

// libDCR performs a high volume of seeks/reads which XBMC's
// VFS cannot sustain efficiently, therefore read the file into
// memory and send it to the decoder.

As it's libDCR related, it's only done for RAW pictures. Switching back to the stock CXImage coding worked for me and also resolved the memory issue.


Sorry about that link, it was the first that came back in a google search. Was looking for pastebin but couldn't remember the name.

[Memphiz]

@ace20022 i disagree ... this buffer is only freed in CxMemFile::Close (which is called from CxMemFile::~CxMemFile()) when m_bFreeOnClose is true which is not the case as in CxMemFile::CxMemfile (c'tor) the buffer is != 0. That fix is valid imo ... will review a bit more and do a PR for common review.

[Memphiz]

@smf007 there is a unrealted hunk in there

Code:

strcpy(info.szLastError,newima.GetLastError());

i ignore this for now?

[Memphiz]

https://github.com/xbmc/xbmc/pull/4891

[DJ_Izumi]

Don't RAW formats often change while maintaining the same extension? My perspective is as a Canon user who's had a few cameras and uses Adobe Creative Suite/Cloud.

A Canon CR2 does not seem to universally determine format support. Every time a NEW camera comes out, Adobe Camera RAW needs to be updated to support that camera. I've been in situations where Canon T2i CR2's worked fine but T4i CR2's would not open without an update to Adobe Camera RAW and this seems to be the issue whenever a new camera is rolled out. There's always at least some small differences between sensors, sometimes large differences, so their RAW data is different.

[smf007]

@smf007 there is a unrealted hunk in there

Code:

strcpy(info.szLastError,newima.GetLastError());

i ignore this for now?

You could ignore that. The code has two paths depending if it knows the picture/mime type or has to determine it. The code path when determining the mime of RAW is inconsistent with the code path when told the mime is RAW. That just fixes the code path when it has to determine the mime of RAW. Really the code should be refactored to remove the duplicate code.

[smf007]

https://github.com/xbmc/xbmc/pull/4891

Thanks for doing up that PR. Look like you caught a few other scenarios where it wasn't being freed.

[Ace]

Nice find, congrats!

[m_o_d]

hi,
I wanted to ask support for NEF will be developed?

Current Status:
14.0-Helix version displays photos but does not impose information captured image parameters

I noticed watching the discussion thread about libraw. Library is used by Gwenview and is stable. IMHO speed is better in Gwenview than Kodi

[smf007]

hi,
I wanted to ask support for NEF will be developed?

Current Status:
14.0-Helix version displays photos but does not impose information captured image parameters

I noticed watching the discussion thread about libraw. Library is used by Gwenview and is stable. IMHO speed is better in Gwenview than Kodi

I'm fairly certain Gwenview only displays the thumbnail preview that is embedded in some RAW images (not all RAW have this). The thumbnail preview is typically a down resolution JPG created by the camera, however with the post processing applied. Kodi is starting with the actual full resolution RAW image. There are no opensource implementations of the Nikon post processors for the RAW image, so Kodi shows exactly what the sensor recorded, no: colour balance; colour correction; image control; sharpening; etc.