2016-12-05, 09:02
can not see my photos taken in RAW format
2016-12-05, 09:43
See Krypton changelog:
Code:
Removed support for RAW image decoding (with removal of CxImage as FFmpeg do not support RAW)
2016-12-06, 08:46
okay then you can not update to krypton because I only Photograph of raw
2016-12-06, 10:52
2016-12-06, 13:37
i tried to hinder this regression but my code was "ignored" sadly.
2016-12-06, 23:15
(2016-12-06, 13:37)ironic_monkey Wrote: i tried to hinder this regression but my code was "ignored" sadly.
I interpreted that differently back at that time: https://github.com/xbmc/xbmc/pull/9918 (Edit: More precisely this: https://github.com/xbmc/xbmc/pull/8583 ) I think we discussed and decided some more work needs to happend so that we can support generic image addons. So my conclusion was: the addon way is the way to go and in order to properly support that, we need to provide an interface for image scaling.
2016-12-07, 11:32
right, i understood the actions as dismissal since nobody ever commented on my image addons at all when i opened the pr. it now seems i have confused myself, the pr was opened against retroplayer on request, and it's over there it went to die, https://github.com/garbear/xbmc/pull/47
i'd have to redo that header, it's nowhere to be found any more :/
i'd have to redo that header, it's nowhere to be found any more :/
2016-12-07, 11:35
I have high interest in bringing that back! Please PR against master and we can discuss open things (if there are any).
Edit: Looking at the code it's nice, really nice (as I have expected). Perhaps we can only check the addons if our internal available FFmpegPicture can't display it. Then could save us a bit of load / time when searching through all the addons available. As I see FCFS is used to determine the imageclass anyways I think that would be good?
Or do you see a usecase where we want to give some external imageaddon priority for formats that are supported internally, too?
Edit: Looking at the code it's nice, really nice (as I have expected). Perhaps we can only check the addons if our internal available FFmpegPicture can't display it. Then could save us a bit of load / time when searching through all the addons available. As I see FCFS is used to determine the imageclass anyways I think that would be good?
Or do you see a usecase where we want to give some external imageaddon priority for formats that are supported internally, too?
2016-12-07, 11:47
yeah, it was written before the ffmpeg stuff hit mainline, so priority and such is probably not sane.
that being said, however, i think we should always prioritize externals. if you want to use libpng i'm not about to stop you, same for libjpeg(turbo) or the likes. and that would be impossible should we prioritize internal. we just need to cache that list to make the checks faster.
that being said, however, i think we should always prioritize externals. if you want to use libpng i'm not about to stop you, same for libjpeg(turbo) or the likes. and that would be impossible should we prioritize internal. we just need to cache that list to make the checks faster.
2017-01-05, 13:53
it's now in a mergeable state. i have tested .cr2, .nef and .arw (just some samples from rawsamples.ch so your mileage may vary).
2017-02-08, 18:20
Pr has been merged, raw image addon has been published. I have done what i can to fix the regression, distribution stuff is beyond my control.
